[102272] in North American Network Operators' Group
RE: Blackholes and IXs and Completing the Attack.
daemon@ATHENA.MIT.EDU (Ben Butler)
Sun Feb 3 08:15:30 2008
Date: Sun, 3 Feb 2008 13:17:12 -0000
From: "Ben Butler" <ben.butler@c2internet.net>
To: "Rick Astley" <jnanog@gmail.com>
Cc: <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu
This is a multi-part message in MIME format.
------_=_NextPart_001_01C86667.175774B2
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
yes absolutely, if an agreement could be reached - then that is a neater
solution, but I wonder if an agreement could ever be reached in a
timescale that doesn't make deployment of the alternative more
attractive as it doesn't require everyone to agree.
________________________________
From: Rick Astley [mailto:jnanog@gmail.com]=20
Sent: 03 February 2008 06:56
To: Ben Butler
Cc: nanog@merit.edu
Subject: Re: Blackholes and IXs and Completing the Attack.
I see your point, but I think maintaining the box for the control
session would also require a decent amount of work.
Presumably, since you must all adhere to some quasi-standard to
communicate with the control peer, you could probably also agree on
creating a standard BGP community (ie. 64666:666 & no-export) to use and
just skip the middle man.
Granted, I am kind of new as well, and I assume if the solution were
that simple more people would be using it.
On Feb 2, 2008 9:07 PM, Ben Butler <ben.butler@c2internet.net> wrote:
Hi,
=20
Agreed, but when you have >100 peers that is still a fair bit of
work. I know technically how to do it and am doing this with transits
but then there are only seven of those. It is not a question of how or
can, but should / is it valuable / constructive?
=20
The starting point in the thought process having just done it
for transits was right ok, now how do we sensibly scale this to apply it
at IXes without everyone having to run round contacting everyone else
and to see if there was an easier way of doing things, hence the
suggestion. Plus it keeps things nice a separated, your IX peering
sessions announce just the main prefixes, the session to the "blackhole
reflector" can be in a separate peer-group and you only send the /32s to
the reflector. You don't have to worry about who uses which communities
as each member that chooses to peer with the reflector is able to apply
an inbound routemaps of their own choosing to any prefixes they receive
from this reflector at each individual IX.
=20
Given that an ISP has elected to Complete the attack on a host
that is being DoSed, for whatever reason, and they have chosen to send
blackhole announcements to transit the logical extension seems to be to
automate the sending of them to IXs to try to further cut down on
traffic. This seems like a easy way, internally you just community tag
on the trigger box for where you want the announcement to go, transit,
internal, customers, IX all,1 2 not 3 - whatever - and BGP sends it out.
Easy, and a single system to send out all updates when you choose to and
easy to remove when you want to take it out again.
=20
If you subscribe to completing the attack as a strategy, then
the suggestion seemed like an easy way of rolling it out to the next
logical point after transit.
=20
Kind Regards
=20
Ben
=09
=09
------_=_NextPart_001_01C86667.175774B2
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16544" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D494561413-03022008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>yes absolutely, if an agreement could be =
reached <SPAN=20
class=3D868381613-03022008>- then </SPAN>that is a neater solution, but =
I wonder=20
if an agreement could ever be reached in a timescale that doesn't make=20
deployment of the alternative more attractive as it doesn't require =
everyone to=20
agree.</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Rick Astley =
[mailto:jnanog@gmail.com]=20
<BR><B>Sent:</B> 03 February 2008 06:56<BR><B>To:</B> Ben =
Butler<BR><B>Cc:</B>=20
nanog@merit.edu<BR><B>Subject:</B> Re: Blackholes and IXs and Completing =
the=20
Attack.<BR></FONT><BR></DIV>
<DIV></DIV>I see your point, but I think maintaining the box for the =
control=20
session would also require a decent amount of work.<BR>Presumably, since =
you=20
must all adhere to some quasi-standard to communicate with the control =
peer, you=20
could probably also agree on creating a standard BGP community (ie. =
64666:666=20
& no-export) to use and just skip the middle man.<BR><BR>Granted, I =
am kind=20
of new as well, and I assume if the solution were that simple more =
people would=20
be using it.<BR><BR><BR>
<DIV class=3Dgmail_quote>On Feb 2, 2008 9:07 PM, Ben Butler <<A=20
href=3D"mailto:ben.butler@c2internet.net">ben.butler@c2internet.net</A>&g=
t;=20
wrote:<BR>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
<DIV>
<DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff=20
size=3D2>Hi,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN><FONT face=3DArial color=3D#0000ff =
size=3D2>Agreed,=20
but when you have >100 peers that is still a fair bit of =
work. =20
</FONT></SPAN><SPAN><FONT face=3DArial color=3D#0000ff size=3D2>I know =
technically=20
how to do it and am doing this with transits but then there are only =
seven of=20
those. It is not a question of how or can, but should / is it =
valuable /=20
constructive?</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN>The starting =
point in the=20
thought process having just done it for transits was right ok, now how =
do we=20
sensibly scale this to apply it at IXes without everyone having to run =
round=20
contacting everyone else and to see if there was an easier way of =
doing=20
things, hence the suggestion. Plus it keeps things nice a =
separated,=20
your IX peering sessions announce just the main prefixes, the session =
to the=20
"blackhole reflector" can be in a separate peer-group and you only =
send the=20
/32s to the reflector. You don't have to worry about who uses =
which=20
communities as each member that chooses to peer with the reflector is =
able to=20
apply an inbound routemaps of their own choosing to any prefixes they =
receive=20
from this reflector at each individual IX.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN>Given that an =
ISP has elected=20
to Complete the attack on a host that is being DoSed, for whatever =
reason, and=20
they have chosen to send blackhole announcements to transit the =
logical=20
extension seems to be to automate the sending of them to IXs to try to =
further=20
cut down on traffic. This seems like a easy way, internally you =
just=20
community tag on the trigger box for where you want the announcement =
to go,=20
transit, internal, customers, IX all,1 2 not 3 - whatever - and BGP =
sends it=20
out. Easy, and a single system to send out all updates when you choose =
to and=20
easy to remove when you want to take it out again.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN>If you =
subscribe to=20
completing the attack as a strategy, then the suggestion seemed like =
an easy=20
way of rolling it out to the next logical point after=20
transit.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN>Kind=20
Regards</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN>Ben</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT><BR></DIV></DIV></BLOCKQUOTE></DIV><BR></BODY></HTML>
------_=_NextPart_001_01C86667.175774B2--