Ah yes BusinessTorg (AS60937). I have also seen this one doing what you are describing. Not to MSFT or GOOG, but another major technology company that we peer with. In fact, it is going on right now but only visible if you receive routes directly from them. A while ago, I sent them a note describing what was happening and suggested they might want to stop accepting routes from that AS, but they still do.
Be aware that even if you don't think you're
peering with them directly, you may be picking
up routes via the public route servers at exchange
points, so check to see if you need to apply
filters on your route server peerings as well.
Matt
Would it not help if RIPE un-publishes these ASN's from their whois database ?
I filed the abuse report at RIPE but haven't heard back from them. We
are NOT a RIPE member but an APNIC member.
Regards
-Tarun
Hi Tarun
Not really. People who are filtering route are filtering already since only
you have route object for it and people who are not filtering, for them
RIPE DB and whois won't matter.
Hi,
Would it not help if RIPE un-publishes these ASN's from their whois database ?
I filed the abuse report at RIPE but haven't heard back from them. We
are NOT a RIPE member but an APNIC member.
Not sure against what RIPE rule it would be and what kind of leverage RIPE
could have here, even if we know they are intentionally evil.
However if I'd be supporting my family with this type of business model, I
would simply appear to be very bad at it, not evil. So I would claim that we
didn't do anything bad here, it was one of our customer (as they do have
different origin AS), and when pointed out, that this ASN has never been your
customer and cannot be, as completely different physical location, I'd simply
say we seeme to have verify-first-as turned off, so it could have been anyone,
and we're hard at work resolving it.
All of this with appropriate delay in answering to queries so you can keep on
doing it years before it's even clear you're evil not just really bad in your
job.
Hi,
Matthew Petach wrote:
Be aware that even if you don't think you're peering with them
directly, you may be picking up routes via the public route
servers at exchange points, so check to see if you need to apply
filters on your route server peerings as well.
At the risk of receiving 1,000 critical replies along the lines of "an internet exchange is not the routing police", I will point out that an IXP route-server is actually a really elegant place to do route filtering.
The IXPs I help to maintain (LONAP & IXLeeds in the UK) do perform IRR filtering on the MLP route-servers. This is handy in the scenario that the ISP is manually filtering customers, where such a technique scales badly when considering how to filter peers. We're transparent and help customers fix route objects when they don't understand why an MLP peering is not effective. If IRR wasn't a total crock, it'd be a really good system.
Saku Ytti wrote:
Companies who are likely target for this, like MSFT and GOOG,
might want to monitor DFZ and see if they are receiving prefixes
no one else is receiving.
The more eyes on the problem, the harder it is for these attacks to work, so the more likely targets (not specifically identifying the two companies in your example, there are lots of likely targets, many in the "Enterprise" space) who feed services like RIPE RIS or Routeviews, the easier it will be to learn what the attack vectors are and fight them.
Andy