NTAC Peering Working Group

[Michael H Lambert <>]

Bill Owens wrote on 2019-12-28 15:12:
> *> 170.158.66.0/23 146.57.255.241 1379 202 0 11537 3754 46158 46158
> 46158 46158 46158 46887 3356 6453 55002 i
> 
> This is an interesting test case for our filters, which have obviously
> failed. The end-user is AS46158 and has, shall we say interesting BGP
> policies, and is also plagued by almost-continuous DDoS attacks. I think
> what’s happening here is they’ve heard their own prefix coming from the
> DDoS scrubber, and arriving back in their table from one of their ISPs.
> Our filters limit them to their own IP block but otherwise give them a
> lot of flexibility about how they advertise to us, in part so they can
> deal with these problems. Obviously we didn’t anticipate them
> readvertising their own prefix from another origin AS. We’ll have a
> conversation on Monday and figure out what kind of filter we need to
> establish to let them continue tweaking their routing as needed but
> prevent this kind of oops.

The occurrence of AS 0 in the AS_PATH is interesting.  At first glance
it would appear that neither 11537 nor 202 is handling RFC 7607
correctly.  Having said that, I'm not certain we would, either.

Michael