Re: Last-call DoS/DoS Attack BCOP

[Christopher Morrow]

On Wed, Mar 25, 2015 at 8:50 AM, John Kristoff  wrote:
> On Wed, 25 Mar 2015 08:27:14 -0400
> Rob Seastrom  wrote:
>
>> John's statement was in the context of general advice to be included
>> in a BCOP document and I felt compelled to say "whoa there".

ok, that was my reaction as well.

> My intent was for it to be taken as a DDoS mitigation response option,
> not as a general practice.

ok, I read over the bcop, I'm certain I wouldn't have used some of the
words on the page, I'm certain that there are things suggested which I
disagree with (mass filtering at your edge, if you are an ISP, all the
time)... but I've not got the energy to poke too  much more at this
document :( and folk will find their balance anyway.

RE: Last-call DoS/DoS Attack BCOP

[Chuck Church]

Other phrases can be substituted.

"no guts, no glory"
"go big or go home"
"no pain, no pain"

Chuck

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Scott Weeks
Sent: Wednesday, March 25, 2015 1:41 AM
To: nanog@nanog.org
Subject: Re: Last-call DoS/DoS Attack BCOP



--
> measures".  I volunteer to write the article on "YOLO upgrades", 
> wherein one loads untested software on equipment with no OOB, types 
> "request system reboot", shouts "YOLO", and hits return.

:: YOLO
-



If a manager forces me to do this is it a requirement that I have to yell yolo? 
 ;-)

One day I'm going to write that into the test plan. I absolutely hate it when 
they do that...

scott

Re: Last-call DoS/DoS Attack BCOP

[John Kristoff]

On Wed, 25 Mar 2015 08:27:14 -0400
Rob Seastrom  wrote:

> John's statement was in the context of general advice to be included
> in a BCOP document and I felt compelled to say "whoa there".

My intent was for it to be taken as a DDoS mitigation response option,
not as a general practice.

John

Re: Last-call DoS/DoS Attack BCOP

[Rob Seastrom]

Christopher Morrow  writes:

> On Tue, Mar 24, 2015 at 5:27 AM, Rob Seastrom  wrote:
>>
>> John Kristoff  writes:
>>
>>> If the attack is an infrastructure attack, say a routing interface that
>>> wouldn't normally receive or emit traffic from its assigned address
>>> except perhaps for network connectivity testing (e.g. traceroute) or
>>> control link local control traffic (e.g. local SPF adjacencies, BGP
>>> neighbors), you can "hide" those addresses, making them somewhat less
>>> easy to target by using something like unnumbered or unadvertised or
>>> ambiguous address space (e.g. RFC 1918).
>>
>> That comes at a cost, both operational/debugging and breaking pmtud.
>
> being hidden stops pmtud only if the route isn't in the global table,
> right? There  is not a requirement to do that if you can drop the
> traffic at your edge in other ways (filter).

Yes, you can filter the incoming traffic at the edge of your network
and not have to suffer the "ICMP fragmentation needed" messages coming
from addresses that are either (a) 1918 and so likely to be dropped on
the floor due to bogon filters, or (b) not in the routing table, and
so likely to be dropped on the floor due to loose unicast rpf.

> It's probably (arguably) better to not route to the space, but failing
> that (because you might like pmtud to work, or other error-type
> messaages to not be dropped by uRPFers) just rate-limit + filter at
> the edge seems like a decent compromise.

Sure, rate limiting potentially bad traffic to some multiple of normal
background that doesn't cause you pain and protects you from disaster
sounds like a plan.  The other end of that telescope os COPP and we've
been doing that for years...

>> But if you don't care about collateral damage, setting the interface to
>> admin-down stops attacks against it *cold*.
>>
>> Due to the drawbacks, I wouldn't consider this a good candidate for
>> inclusion in a BCOP document.
>
> this is highly dependent upon your network design and topology though,
> right? By this i mean, if the device is an LSR and won't have IP
> traffic hit it's interfaces no harm no foul making them invisible.

Yes, there are many corner cases where all sorts of creative solutions
can be deployed.  I'll bet the filters for your personal devices are
different from the backbone filters at $DAYJOB too.

John's statement was in the context of general advice to be included
in a BCOP document and I felt compelled to say "whoa there".

> With some modern platforms you can even specify a single 'filter' and
> adjunct 'rate limiters' to be used across the entire device, right?
>
> This means you can permit traffic into your borders and let the device
> control access to itself with some relatively simple filters and
> rate-limits, so your access works, and pmtud works and dos attacks
> don't kill the device, just fill the interface to the device.

ayup

>> I have often thought there ought to be a companion series for
>> Questionable Current Operational Practices, or maybe "desperate
>> measures".  I volunteer to write the article on "YOLO upgrades",
>> wherein one loads untested software on equipment with no OOB, types
>> "request system reboot", shouts "YOLO", and hits return.
>
> YOLO

YOLO!

-r

Re: Last-call DoS/DoS Attack BCOP

[Scott Weeks]

--
> measures".  I volunteer to write the article on "YOLO upgrades",
> wherein one loads untested software on equipment with no OOB, types
> "request system reboot", shouts "YOLO", and hits return.

:: YOLO
-



If a manager forces me to do this is it a requirement that 
I have to yell yolo?  ;-)

One day I'm going to write that into the test plan. I 
absolutely hate it when they do that...

scott

Re: Last-call DoS/DoS Attack BCOP

[Christopher Morrow]

On Tue, Mar 24, 2015 at 5:27 AM, Rob Seastrom  wrote:
>
> John Kristoff  writes:
>
>> If the attack is an infrastructure attack, say a routing interface that
>> wouldn't normally receive or emit traffic from its assigned address
>> except perhaps for network connectivity testing (e.g. traceroute) or
>> control link local control traffic (e.g. local SPF adjacencies, BGP
>> neighbors), you can "hide" those addresses, making them somewhat less
>> easy to target by using something like unnumbered or unadvertised or
>> ambiguous address space (e.g. RFC 1918).
>
> That comes at a cost, both operational/debugging and breaking pmtud.

being hidden stops pmtud only if the route isn't in the global table,
right? There  is not a requirement to do that if you can drop the
traffic at your edge in other ways (filter).

It's probably (arguably) better to not route to the space, but failing
that (because you might like pmtud to work, or other error-type
messaages to not be dropped by uRPFers) just rate-limit + filter at
the edge seems like a decent compromise.

> But if you don't care about collateral damage, setting the interface to
> admin-down stops attacks against it *cold*.
>
> Due to the drawbacks, I wouldn't consider this a good candidate for
> inclusion in a BCOP document.

this is highly dependent upon your network design and topology though,
right? By this i mean, if the device is an LSR and won't have IP
traffic hit it's interfaces no harm no foul making them invisible.

With some modern platforms you can even specify a single 'filter' and
adjunct 'rate limiters' to be used across the entire device, right?

This means you can permit traffic into your borders and let the device
control access to itself with some relatively simple filters and
rate-limits, so your access works, and pmtud works and dos attacks
don't kill the device, just fill the interface to the device.

> I have often thought there ought to be a companion series for
> Questionable Current Operational Practices, or maybe "desperate
> measures".  I volunteer to write the article on "YOLO upgrades",
> wherein one loads untested software on equipment with no OOB, types
> "request system reboot", shouts "YOLO", and hits return.

YOLO

Re: Last-call DoS/DoS Attack BCOP

[Maxwell Cole]

On 3/24/15 5:27 AM, Rob Seastrom wrote:

John Kristoff  writes:


If the attack is an infrastructure attack, say a routing interface that
wouldn't normally receive or emit traffic from its assigned address
except perhaps for network connectivity testing (e.g. traceroute) or
control link local control traffic (e.g. local SPF adjacencies, BGP
neighbors), you can "hide" those addresses, making them somewhat less
easy to target by using something like unnumbered or unadvertised or
ambiguous address space (e.g. RFC 1918).

That comes at a cost, both operational/debugging and breaking pmtud.
But if you don't care about collateral damage, setting the interface to
admin-down stops attacks against it *cold*.

Due to the drawbacks, I wouldn't consider this a good candidate for
inclusion in a BCOP document.

I have often thought there ought to be a companion series for
Questionable Current Operational Practices, or maybe "desperate
measures".  I volunteer to write the article on "YOLO upgrades",
wherein one loads untested software on equipment with no OOB, types
"request system reboot", shouts "YOLO", and hits return.

-r




You could have a whole blog series about redistributing BGP into IGPs.  
Or a "tricks and tips" section to add an allow any to all of your ACLs.

Re: Last-call DoS/DoS Attack BCOP

[Rob Seastrom]

John Kristoff  writes:

> If the attack is an infrastructure attack, say a routing interface that
> wouldn't normally receive or emit traffic from its assigned address
> except perhaps for network connectivity testing (e.g. traceroute) or
> control link local control traffic (e.g. local SPF adjacencies, BGP
> neighbors), you can "hide" those addresses, making them somewhat less
> easy to target by using something like unnumbered or unadvertised or
> ambiguous address space (e.g. RFC 1918).

That comes at a cost, both operational/debugging and breaking pmtud.
But if you don't care about collateral damage, setting the interface to
admin-down stops attacks against it *cold*.

Due to the drawbacks, I wouldn't consider this a good candidate for
inclusion in a BCOP document.

I have often thought there ought to be a companion series for
Questionable Current Operational Practices, or maybe "desperate
measures".  I volunteer to write the article on "YOLO upgrades",
wherein one loads untested software on equipment with no OOB, types
"request system reboot", shouts "YOLO", and hits return.

-r

Re: Last-call DoS/DoS Attack BCOP

[John Kristoff]

On Mon, 23 Mar 2015 19:00:14 -0400
Yardiel D.Fuentes  wrote:

> Since there have been good feedback for this BCOP. The committee
> decided to extend the "last-call period" for another two weeks to
> give ample chance to further feedback.
> 
> So, it is not late for more comments,

Hi Yardiel,

Nice work so far.  A couple of additional ideas for you if you care to
use them.

If the attack is an infrastructure attack, say a routing interface that
wouldn't normally receive or emit traffic from its assigned address
except perhaps for network connectivity testing (e.g. traceroute) or
control link local control traffic (e.g. local SPF adjacencies, BGP
neighbors), you can "hide" those addresses, making them somewhat less
easy to target by using something like unnumbered or unadvertised or
ambiguous address space (e.g. RFC 1918).

A second suggestion, if you want to add a reference to it is the UTRS
project, which is a free community project that brings networks
together for the purpose of exchanging RTBH announcements.  We've
recently enabled automated relay for IPv4 /32's that have a history of
sole origination from a peer.  This is another DDoS mitigation tool in
the tool box that many may find helpful.  More detail can be found here:

  

John

Re: Last-call DoS/DoS Attack BCOP

[Yardiel D . Fuentes]

Thank you all who have contributed your feedback, comments and discussion 
points towards the DDoS/DoS attack BCOP. 
I have updated the current version of the BCOP with the agreed upon feedback:

http://bcop.nanog.org/index.php/BCOP_Drafts

Since there have been good feedback for this BCOP. The committee decided to 
extend the "last-call period" for another two weeks to give ample chance to 
further feedback.

So, it is not late for more comments,

Yardiel Fuentes


On Feb 27, 2015, at 11:16 AM, Yardiel D. Fuentes wrote:

> 
> 
> Hello NANOGers,
> 
> Following up on the below effort from last year, the DDoS/DoS Attack BCOP 
> Draft document is ready for the last call 2-week period. After this period 
> and unless notable objections are raised, the current document will be 
> ratified as such. The current document can be found in the NANOG BCOP site -- 
> link to current document found below:
> 
> http://bcop.nanog.org/index.php/BCOP_Drafts
> 
> Any additional community-wide comments or feedback in order to ensure quality 
> documentation are not only very welcome but encouraged.
> 
> Cheers,
> 
> Yardiel Fuentes
> 
> 
> On Jul 2, 2014, at 6:48 PM, Yardiel D. Fuentes wrote:
> 
>> 
>> 
>> OK NANOGers,
>> 
>> Some of us got the call to arms from Chris G email below and the NANOG BCOP 
>> Committee and now we are interested in generating DoS attack-related Best 
>> Common Practices (BCOP) appeal to serve the entire NANOG community.
>> 
>> This document, as other BCOP appeals are expected to be as brief as possible 
>> and to the point in order to keep it practical and useful.
>> 
>> The goal is to generate a set of best practices of what to do 
>> before/during/after a DoS/DDoS attack -- including what seems to have worked 
>> best and what hasn't. Time dedicated to this effort should extensive and 
>> participation can be non-real-time given that  it can be done over email 
>> with no need for conference calls if desired.
>> 
>> DoS and DDoS attacks have been a topic that have captured high interest from 
>> NANOGers based on the archived list topics and email threads. So, now is 
>> your time to help shape a NANOG BCOP Appeal on this topic.
>> 
>> Please contact me off-list if you want participate by either sharing your 
>> experience, expertise or opinions towards generating a DoS Attack BCOP.
>> 
>> 
>> Yardiel Fuentes
>> yard...@gmail.com
>> twitter: #techguane
>> 
>> 
>> 
>> On Jun 1, 2014, at 5:25 PM, Chris Grundemann wrote:
>> 
>>> Hail NANOGers!
>>> 
>>> As most of you hopefully know, NANOG now has a BCOP Ad Hoc Committee
>>> and we are pushing forward with new BCOPs!
>>> http://nanog.org/governance/bcop
>>> 
>>> We currently have three BCOPs in active development:
>>> 
>>> eBGP configuration, shepherd Bill Armstrong
>>> Public Peering Exchange update, shepherd Shawn Hsiao
>>> Ethernet OAM, shepherd Mark Calkins
>>> 
>>> All three of these nascent BCOPs will be presented in the BCOP Track
>>> on Monday: http://nanog.org/meetings/abstract?id=2348
>>> 
>>> We have also collected a list of Appeals (BCOPs that need to be
>>> written): http://bcop.nanog.org/index.php/Appeals
>>> 
>>> If you would like to help out with any of these BCOPs (or others yet
>>> to be identified) please join the BCOP mailing list and reach out to
>>> the shepherd (if applicable of course):
>>> http://mailman.nanog.org/mailman/listinfo/bcop
>>> 
>>> Our committee is brand new and we are still finding and smoothing
>>> wrinkles, etc. We would love your help in any capacity. As a BCOP
>>> shepherd or SME or just to point out potential pit falls or room for
>>> improvement, with the process, the wiki, a BCOP or anything at all
>>> really.
>>> 
>>> This is a bottom-up, community led effort and it will only succeed
>>> with your help - join us in creating what I believe will be a vital
>>> and long-lasting institution!
>>> 
>>> Cheers,
>>> ~Chris
>>> 
>>> -- 
>>> @ChrisGrundemann
>>> http://chrisgrundemann.com
>> 
> 

Last-call DoS/DoS Attack BCOP

[Yardiel D . Fuentes]

Hello NANOGers,

Following up on the below effort from last year, the DDoS/DoS Attack BCOP Draft 
document is ready for the last call 2-week period. After this period and unless 
notable objections are raised, the current document will be ratified as such. 
The current document can be found in the NANOG BCOP site -- link to current 
document found below:

http://bcop.nanog.org/index.php/BCOP_Drafts

Any additional community-wide comments or feedback in order to ensure quality 
documentation are not only very welcome but encouraged.

Cheers,

Yardiel Fuentes


On Jul 2, 2014, at 6:48 PM, Yardiel D. Fuentes wrote:

> 
> 
> OK NANOGers,
> 
> Some of us got the call to arms from Chris G email below and the NANOG BCOP 
> Committee and now we are interested in generating DoS attack-related Best 
> Common Practices (BCOP) appeal to serve the entire NANOG community.
> 
> This document, as other BCOP appeals are expected to be as brief as possible 
> and to the point in order to keep it practical and useful.
> 
> The goal is to generate a set of best practices of what to do 
> before/during/after a DoS/DDoS attack -- including what seems to have worked 
> best and what hasn't. Time dedicated to this effort should extensive and 
> participation can be non-real-time given that  it can be done over email with 
> no need for conference calls if desired.
> 
> DoS and DDoS attacks have been a topic that have captured high interest from 
> NANOGers based on the archived list topics and email threads. So, now is your 
> time to help shape a NANOG BCOP Appeal on this topic.
> 
> Please contact me off-list if you want participate by either sharing your 
> experience, expertise or opinions towards generating a DoS Attack BCOP.
> 
> 
> Yardiel Fuentes
> yard...@gmail.com
> twitter: #techguane
> 
> 
> 
> On Jun 1, 2014, at 5:25 PM, Chris Grundemann wrote:
> 
>> Hail NANOGers!
>> 
>> As most of you hopefully know, NANOG now has a BCOP Ad Hoc Committee
>> and we are pushing forward with new BCOPs!
>> http://nanog.org/governance/bcop
>> 
>> We currently have three BCOPs in active development:
>> 
>> eBGP configuration, shepherd Bill Armstrong
>> Public Peering Exchange update, shepherd Shawn Hsiao
>> Ethernet OAM, shepherd Mark Calkins
>> 
>> All three of these nascent BCOPs will be presented in the BCOP Track
>> on Monday: http://nanog.org/meetings/abstract?id=2348
>> 
>> We have also collected a list of Appeals (BCOPs that need to be
>> written): http://bcop.nanog.org/index.php/Appeals
>> 
>> If you would like to help out with any of these BCOPs (or others yet
>> to be identified) please join the BCOP mailing list and reach out to
>> the shepherd (if applicable of course):
>> http://mailman.nanog.org/mailman/listinfo/bcop
>> 
>> Our committee is brand new and we are still finding and smoothing
>> wrinkles, etc. We would love your help in any capacity. As a BCOP
>> shepherd or SME or just to point out potential pit falls or room for
>> improvement, with the process, the wiki, a BCOP or anything at all
>> really.
>> 
>> This is a bottom-up, community led effort and it will only succeed
>> with your help - join us in creating what I believe will be a vital
>> and long-lasting institution!
>> 
>> Cheers,
>> ~Chris
>> 
>> -- 
>> @ChrisGrundemann
>> http://chrisgrundemann.com
>