New BCOPs in Progress

Mailman List Mirror (Read Only)
1

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

2

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
yardiel@gmail.com
twitter: #techguane

3

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

4

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

5

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:

  <http://www.cymru.com/jtk/misc/utrs.html>

John

6

John Kristoff <jtk@cymru.com> 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

7

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.

8

John Kristoff <jtk@cymru.com> 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

9

Christopher Morrow <morrowc.lists@gmail.com> writes:

John Kristoff <jtk@cymru.com> 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

10

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

John

11

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 :frowning: and folk will find their balance anyway.