[102734] in North American Network Operators' Group
Re: BGP prefix filtering, how exactly? [Re: YouTube IP Hijacking]
daemon@ATHENA.MIT.EDU (Danny McPherson)
Mon Feb 25 13:59:17 2008
From: Danny McPherson <danny@tcb.net>
To: NANOG NANOG <nanog@merit.edu>
In-Reply-To: <alpine.LRH.1.00.0802251457270.15100@netcore.fi>
Date: Mon, 25 Feb 2008 11:54:58 -0700
Errors-To: owner-nanog@merit.edu
--Apple-Mail-542-172715607
Content-Type: text/plain;
charset=US-ASCII;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit
On Feb 25, 2008, at 6:08 AM, Pekka Savola wrote:
>
> In a lot of this dialogue, many say, "you should prefix filter".
> However, I'm not seeing how an ISP could easily adopt such filtering.
>
> So, this is no excuse for not doing prefix filtering if you only do
> business in the RIPE region, but anywhere else the IRR data is
> pretty much useless, incorrect, or both.
Agreed.
>
> (Yeah, we prefix filter all our customers. Our IPv6 peers are also
> prefix filtered, based on RIPE IRR data (with one exception). IPv4
> peers' advertisements seem to be too big a mess, and too long
> filters, to fix this way.)
Do you explicitly filter routes from your upstream or transit providers?
E.g., if one were to announce, say, a more specific of one of your
customer's routes to you would you accept it? What about someone
else's address space?
The only full set of prefix filtering I've ever seen implemented (i.e.,
BGP customers AND peers) was b y ANS during my days at iMCI
~95. It was extremely painful at times, even for us, if we wanted to
advertise new address space we had to update IRR objects and
wait on their nightly push of updated routing policies at ANS. We
generated our own routing policies automatically off our IRR, which
mirrored others as well, and explicitly prefix filtered customers with
some fixed prefix and AS path-based policies applied to peers. If it
became really urgent, then we'd call ANS and have them manually
update their policy, and subsequently 'bounce' the route
announcement to trigger transmission of a new update.
This was long before incrementally updated filters and things like
BGP route refresh ever existed. Prefixes and AS-MACROs had to
be right in the IRRs or the policies wouldn't be updated. It's to bad
other folks didn't follow suit.
As for this event, a slightly different spin here:
http://tinyurl.com/3y3pzl
-danny
--Apple-Mail-542-172715607
Content-Type: text/html;
charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><div>On Feb 25, 2008, =
at 6:08 AM, Pekka Savola wrote:</div><blockquote type=3D"cite"><br>In a =
lot of this dialogue, many say, "you should prefix filter". However, I'm =
not seeing how an ISP could easily adopt such filtering.<br><br>So, this =
is no excuse for not doing prefix filtering if you only do business in =
the RIPE region, but anywhere else the IRR data is pretty much useless, =
incorrect, or both.</blockquote><div><br =
class=3D"webkit-block-placeholder"></div>Agreed.</div><div><br><blockquote=
type=3D"cite"><br>(Yeah, we prefix filter all our customers. Our =
IPv6 peers are also prefix filtered, based on RIPE IRR data (with one =
exception). IPv4 peers' advertisements seem to be too big a mess, =
and too long filters, to fix this =
way.)</blockquote></div><div><br></div><div>Do you explicitly filter =
routes from your upstream or transit providers?</div><div>E.g., if one =
were to announce, say, a more specific of one of =
your </div><div>customer's routes to you would you accept it? =
What about someone </div><div>else's address space? =
</div><div><br class=3D"webkit-block-placeholder"></div><div>The =
only full set of prefix filtering I've ever seen implemented =
(i.e., </div><div>BGP customers AND peers) was b y ANS during =
my days at iMCI </div><div>~95. It was extremely painful at =
times, even for us, if we wanted to </div><div>advertise =
new address space we had to update IRR objects =
and </div><div>wait on their nightly push of updated routing =
policies at ANS. We </div><div>generated our own routing =
policies automatically off our IRR, =
which </div><div>mirrored others as well, and explicitly =
prefix filtered customers with </div><div>some fixed prefix and AS =
path-based policies applied to peers. If =
it</div><div> became really urgent, then we'd call ANS =
and have them manually </div><div>update their policy, =
and subsequently 'bounce' the =
route </div><div>announcement to trigger transmission of a =
new update. </div><div><br =
class=3D"webkit-block-placeholder"></div><div>This was long before =
incrementally updated filters and things like</div><div>BGP route =
refresh ever existed. Prefixes and AS-MACROs had =
to </div><div>be right in the IRRs or the policies wouldn't be =
updated. It's to bad </div><div>other folks didn't =
follow suit.</div><div><br =
class=3D"webkit-block-placeholder"></div><div>As for this event, a =
slightly different spin here:</div><div><br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-style-span" style=3D"font-family: Verdana; font-size: =
11px; font-weight: bold; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px; "><a =
href=3D"http://tinyurl.com/3y3pzl">http://tinyurl.com/3y3pzl</a></span></d=
iv><div><font class=3D"Apple-style-span" face=3D"Verdana" size=3D"3"><span=
class=3D"Apple-style-span" style=3D"font-size: 11px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px;"><b><br =
class=3D"webkit-block-placeholder"></b></span></font></div><div>-danny</di=
v></body></html>=
--Apple-Mail-542-172715607--
