<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 1, 2020, at 11:14 , Hank Nussbacher <<a href="mailto:hank@interall.co.il" class="">hank@interall.co.il</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="moz-cite-prefix" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">On 01/08/2020 00:50, Mark Tinka wrote:<br class=""></div><blockquote type="cite" cite="mid:aeceb486-57f2-a23b-bbe3-df47c5e4f085@seacom.com" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><pre class="moz-quote-pre" wrap="">On 31/Jul/20 23:38, Sabri Berisha wrote:

</pre><blockquote type="cite" class=""><pre class="moz-quote-pre" wrap="">Kudos to Telia for admitting their mistakes, and fixing their processes.
</pre></blockquote><pre class="moz-quote-pre" wrap="">Considering Telia's scope and "experience", that is one thing. But for
the general good of the Internet, the number of intended or
unintentional route hijacks in recent years, and all the noise that
rises on this and other lists each time we have such incidents (this
won't be the last), Telia should not have waited to be called out in
order to get this fixed.

Do we know if they are fixing this on just this customer of theirs, or
all their customers? I know this has been their filtering policy with us
(SEACOM) since 2014, as I pointed out earlier today. There has not been
a shortage of similar incidents between now and then, where the
community has consistently called for more deliberate and effective
route filtering across inter-AS arrangements.


</pre></blockquote><div style="margin-bottom: 0cm; margin-top: 0pt; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">AS  level filtering is easy.  IP prefix level filtering is hard.  Especially when you are in the top 200:</div><div style="margin-bottom: 0cm; margin-top: 0pt; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a class="moz-txt-link-freetext" href="https://asrank.caida.org/">https://asrank.caida.org/</a></div></div></blockquote><div><br class=""></div>IP Prefix level filtering at backbone<->backbone connections is hard (and mostly pointless).</div><div><br class=""></div><div>IP Prefix level filtering at the customer edge is not that hard, no matter how large of a transit</div><div>provider you are. Customer edge filtration by Telia in this case would have prevented this</div><div>problem from spreading beyond the misconfigured ASN.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="margin-bottom: 0cm; margin-top: 0pt; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">That being said, and due to these BGP "polluters" constantly doing the same thing, wouldn't an easy fix be to use the max-prefix/prefix-limit option:</div><div style="margin-bottom: 0cm; margin-top: 0pt; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a class="moz-txt-link-freetext" href="https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/25160-bgp-maximum-prefix.html">https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/25160-bgp-maximum-prefix.html</a></div><div style="margin-bottom: 0cm; margin-top: 0pt; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a class="moz-txt-link-freetext" href="https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/prefix-limit-edit-protocols-bgp.html">https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/prefix-limit-edit-protocols-bgp.html</a></div></div></blockquote><div><br class=""></div>That’s a decent pair of suspenders to go with the belt of prefix filtration at the edge, but it’s no substitute.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="margin-bottom: 0cm; margin-top: 0pt; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">For every BGP peer,  the ISP determines what the current max-prefix currently is.  Then add in 2% and set the max-prefix. </div><div style="margin-bottom: 0cm; margin-top: 0pt; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">An errant BGP polluter would then only have limited damage to the Internet routing table.</div><div style="margin-bottom: 0cm; margin-top: 0pt; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">Not the greatest solution, but easy to implement via a one line change on every BGP peer.</div></div></blockquote><div><br class=""></div>To the best of my knowledge, that’s already fairly common practice. It’s usually more like 10% (2% would require way</div><div>too much active change and create churn and risk).</div><div><br class=""></div><div>Owen</div><div><br class=""></div></body></html>