Hello, I understand that there may have been some discussion of the rogue AS201640 at the WG meeting in London. For the benefit of those of us who were not able to attend that, could someone (anyone) please post a brief summary of the WG's discussion of AS201640? (The transcripts do not seem to be available just yet.) Separately and additionally, I have been seeking answers to several questions relating to AS201640, mostly on the anti-abuse WG mailing list, but I have so far been rather spectacularly unsuccessful at obtaining any answers whatsoever to any of these questions. Given that, I hope that no one will mind very much if I put these questions here. (Note: I am sure that some of these questions only occur to me because of my abundant ignorance. I am admittedly not very familiar with RIPE or RIPE NCC operating procedures. I hope that the members of this WG will show me the courtesy of forgiving my ignorance and also attempt to remedy it.) +_+_+_+_+_+_+_+_+_ 1) How was it possible for various IPv4 block WHOIS records to be stored in the RIPE WHOIS DB, even though it is quite apparently the case that, according to IANA WHOIS records, the IP blocks in question do not even belong to the RIPE region? Is there really no pre-checking performed on such records before they are stored in the RIPE data base, e.g. to see if the blocks in question belong either to RIPE or to some other RiR? 2) How was it possible for a particular Bulgarian commercial organization to be granted its own AS number, when all available evidence seems to indicate that it actually had, and has, -zero- IP addresses which are actually and properly registered to it? Is there really no pre-checking performed on AS number allocations, e.g. to see if the organization requesting the AS has at least some IP addresses? 3) Why are some of the clearly bogus WHOIS records (for IPv4 blocks) relating to this incident still present within the RIPE WHOIS DB, even as we speak, in particular, these ones? 41.198.224.0/20 119.227.224.0/19 105.154.248.0/21 210.57.0.0/19 202.39.112.0/20 Is anyone anywhere still harboring *any* lingering doubt about the fact that these are all quite plainly bogus? If not, then why have these records not already been removed from the WHOIS data base? 4) Why is AS201640 still registered, as we speak? 5) Without reference to any specific incident, AS, legal entity, or any other specifics, I have the following very general question: With respect to the contracts that RIPE enters into with those parties for whom RIPE provides registration services of *AS numbers*, specifically, are the terms and conditions of those contracts adequate and sufficient to strongly deter any and all AS registrants from deliberately and willfully announcing routes to IP space to which neither they nor any of their direct or indirect customers have any legitimate claim? +_+_+_+_+_+_ I look forward to the WG's responses to the above questions.
Hi Ronald,
1) How was it possible for various IPv4 block WHOIS records to be stored in the RIPE WHOIS DB, even though it is quite apparently the case that, according to IANA WHOIS records, the IP blocks in question do not even belong to the RIPE region? Is there really no pre-checking performed on such records before they are stored in the RIPE data base, e.g. to see if the blocks in question belong either to RIPE or to some other RiR?
First one clarification: we're talking about route objects here, not inetnum or aut-num objects. Route objects document which ASN is supposed to announce which address space. There are valid use cases for an ASN from one region to announce address space from another region. In other words: the inetnum object from one region's database is linked to the aut-num object in another region's database. Making referential integrity and authorisation work in such cases is very hard. The current implementation is quite permissive to make it possible to document real-life situations. Unfortunately it also makes it possible to reference some resources in other regions that don't belong to you.
2) How was it possible for a particular Bulgarian commercial organization to be granted its own AS number, when all available evidence seems to indicate that it actually had, and has, -zero- IP addresses which are actually and properly registered to it? Is there really no pre-checking performed on AS number allocations, e.g. to see if the organization requesting the AS has at least some IP addresses?
Having IP addresses is not a requirement for getting an ASN. There are many legitimate cases where an ASN may be used to announce address space belonging to someone else. For example an ISP announcing address space belonging to its customer. Or a transit provider. Cheers, Sander
In message <2359D829-0A68-40C2-ABF4-78199D8B49E0@steffann.nl>, Sander Steffann <sander@steffann.nl> wrote:
1) How was it possible for various IPv4 block WHOIS records to be stored in the RIPE WHOIS DB, even though it is quite apparently the case that, according to IANA WHOIS records, the IP blocks in question do not even belong to the RIPE region? Is there really no pre-checking performed on such records before they are stored in the RIPE data base, e.g. to see if the blocks in question belong either to RIPE or to some other RiR?
First one clarification: we're talking about route objects here, not inetnum or aut-num objects. Route objects document which ASN is supposed to announce which address space. There are valid use cases for an ASN from one region to announce address space from another region. In other words: the inetnum object from one region's database is linked to the aut-num object in another region's database. Making referential integrity and authorisation work in such cases is very hard. The current implementation is quite permissive to make it possible to document real-life situations. Unfortunately it also makes it possible to reference some resources in other regions that don't belong to you.
Thank you. The above response is both clear and enlightening... for me anyway. And it makes perfect sense. I will certainly be paying a lot more attention to those WHOIS field names in the future!
2) How was it possible for a particular Bulgarian commercial organization to be granted its own AS number, when all available evidence seems to indicate that it actually had, and has, -zero- IP addresses which are actually and properly registered to it? Is there really no pre-checking performed on AS number allocations, e.g. to see if the organization requesting the AS has at least some IP addresses?
Having IP addresses is not a requirement for getting an ASN. There are many legitimate cases where an ASN may be used to announce address space belonging to someone else. For example an ISP announcing address space belonging to its customer. Or a transit provider.
OK, that's a good point. But I'm not sure that it fully negates the possible value of my question. Everybody is _supposed_ to have working e-mail address contacts in their IP allocation records within the WHOIS data bases of the various RiRs, yes? So suppose that there had been a protocol in place that required an affirmative e-mail response from at least one legitimate IP address block registrant (in some/any region) before the allocation of an AS number would proceed. Such a protocol would have forestalled the situation that we now see with AS201640, would it not? Regards, rfg
Hi Ronald,
Having IP addresses is not a requirement for getting an ASN. There are many legitimate cases where an ASN may be used to announce address space belonging to someone else. For example an ISP announcing address space belonging to its customer. Or a transit provider.
OK, that's a good point. But I'm not sure that it fully negates the possible value of my question.
Everybody is _supposed_ to have working e-mail address contacts in their IP allocation records within the WHOIS data bases of the various RiRs, yes? So suppose that there had been a protocol in place that required an affirmative e-mail response from at least one legitimate IP address block registrant (in some/any region) before the allocation of an AS number would proceed. Such a protocol would have forestalled the situation that we now see with AS201640, would it not?
It is a possible implementation but one that only has a one-time check. It wouldn't keep track of changes to resources in other regions. The working group asked the RIPE NCC to look into the possibilities and report back to the working group. Let's see if there is a easy to use solution that makes sure we don't import data into our database that then end up being invalid or outdated. Cheers, Sander
In message <35CC580F-0722-4973-A1E6-9F14A63A6D64@steffann.nl>, Sander Steffann <sander@steffann.nl> wrote:
Everybody is _supposed_ to have working e-mail address contacts in their IP allocation records within the WHOIS data bases of the various RiRs, yes? So suppose that there had been a protocol in place that required an affirmative e-mail response from at least one legitimate IP address block registrant (in some/any region) before the allocation of an AS number would proceed. Such a protocol would have forestalled the situation that we now see with AS201640, would it not?
It is a possible implementation but one that only has a one-time check. It wouldn't keep track of changes to resources in other regions. The working group asked the RIPE NCC to look into the possibilities and report back to the working group. Let's see if there is a easy to use solution that makes sure we don't import data into our database that then end up being invalid or outdated.
I agree that this is an emminently reasonable way to proceed. And yes, as we now know, a simple one-time up-front check of the kind I described would _not_ have prevented the sitiation with AS201640 from arising, because that AS _did_ start out life with its own legitimate /24 allocation... which was subsequently withdrawn. So in this case, the kind of consistancy check I proposed would have been no help at all in preventing what ultimately ensued. (And in fact, that initial & temporary /24 allocation for AS201640 would seem to have been deliberately *engineered* to defeat exactly such a check, even if such a thing had been in place at the time AS201640 was created.) Regards, rfg
Hi, On 07/11/14 22:20, Ronald F. Guilmette wrote:
Hello,
I understand that there may have been some discussion of the rogue AS201640 at the WG meeting in London. For the benefit of those of us who were not able to attend that, could someone (anyone) please post a brief summary of the WG's discussion of AS201640? (The transcripts do not seem to be available just yet.) as far as I understand, the WG will talk to the RIPE NCC and request an action point from the NCC on whether there is a better way to allow creation of route objects in the RIPE Database for IP addresses or AS Numbers that are assigned/allocated by an other RIR.
Separately and additionally, I have been seeking answers to several questions relating to AS201640, mostly on the anti-abuse WG mailing list, but I have so far been rather spectacularly unsuccessful at obtaining any answers whatsoever to any of these questions. Given that, I hope that no one will mind very much if I put these questions here.
(Note: I am sure that some of these questions only occur to me because of my abundant ignorance. I am admittedly not very familiar with RIPE or RIPE NCC operating procedures. I hope that the members of this WG will show me the courtesy of forgiving my ignorance and also attempt to remedy it.)
+_+_+_+_+_+_+_+_+_
1) How was it possible for various IPv4 block WHOIS records to be stored in the RIPE WHOIS DB, even though it is quite apparently the case that, according to IANA WHOIS records, the IP blocks in question do not even belong to the RIPE region? Is there really no pre-checking performed on such records before they are stored in the RIPE data base, e.g. to see if the blocks in question belong either to RIPE or to some other RiR? address space allocated by an other RIR can have a route object in the RIPE Database.
Usually, for address space and AS Numbers assigned by the RIPE NCC, you would need two passwords, the AS password and the IP password. In this case, they only needed the AS password as the IP password is public.
2) How was it possible for a particular Bulgarian commercial organization to be granted its own AS number, when all available evidence seems to indicate that it actually had, and has, -zero- IP addresses which are actually and properly registered to it? Is there really no pre-checking performed on AS number allocations, e.g. to see if the organization requesting the AS has at least some IP addresses?
It had a /24 IPv4 PA assigned by the Sponsoring LIR. That IPv4 PA assignment got deleted days after the request for the ASN. That leads me to thinking that the Sponsoring LIR (Nettera Ltd from Bulgaria) knew exactly what they are doing and helped this spammer get it's own ASN,
3) Why are some of the clearly bogus WHOIS records (for IPv4 blocks) relating to this incident still present within the RIPE WHOIS DB, even as we speak, in particular, these ones?
41.198.224.0/20 119.227.224.0/19 105.154.248.0/21 210.57.0.0/19 202.39.112.0/20
Already responded by Sander, those are route objects that you see.
Is anyone anywhere still harboring *any* lingering doubt about the fact that these are all quite plainly bogus? If not, then why have these records not already been removed from the WHOIS data base?
Because this is private data maintained by a maintainer and removing that data can only be done by that maintainer.
4) Why is AS201640 still registered, as we speak?
good question.. it's probably because the request of the ASN has never been fraudulent. As far as I know, there is a ticket opened with the RIPE NCC asking them to investigate if the ASN assignment request has been in order. As it has been more than two months since that ticket was opened, I presume they have found nothing fraudulent.
5) Without reference to any specific incident, AS, legal entity, or any other specifics, I have the following very general question:
With respect to the contracts that RIPE enters into with those parties for whom RIPE provides registration services of *AS numbers*, specifically, are the terms and conditions of those contracts adequate and sufficient to strongly deter any and all AS registrants from deliberately and willfully announcing routes to IP space to which neither they nor any of their direct or indirect customers have any legitimate claim?
how do you demonstrate that something has been deliberate and not just some fat fingering (typoes)?
+_+_+_+_+_+_
I look forward to the WG's responses to the above questions.
cheers, elvis
In message <545E581F.604@velea.eu>, Elvis Daniel Velea <elvis@velea.eu> wrote:
as far as I understand, the WG will talk to the RIPE NCC and request an action point from the NCC on whether there is a better way to allow creation of route objects in the RIPE Database for IP addresses or AS Numbers that are assigned/allocated by an other RIR.
...
Usually, for address space and AS Numbers assigned by the RIPE NCC, you would need two passwords, the AS password and the IP password. In this case, they only needed the AS password as the IP password is public.
The IP password is public?!? I am sitting here trying to fathom that. I expect that I may be doing so for some time yet. In am online world where essentially _everything_ is password protected, to be informed that entire (and sometimes even sizable) IP address blocks are not is... well... a bit mystifying. So, um, this ``request'' for an ``action point'' that has been sent to RIPE NCC... Did it contain any helpful suggestions, you know, like along the lines of ``Maybe a check for non-public passwords would be a Good Thing?'' (I _do_ understand from the context that this is most likely an issue that is not confined to RIPE or to any other single RiR.)
2) How was it possible for a particular Bulgarian commercial organization to be granted its own AS number, when all available evidence seems to indicate that it actually had, and has, -zero- IP addresses which are actually and properly registered to it? Is there really no pre-checking performed on AS number allocations, e.g. to see if the organization requesting the AS has at least some IP addresses? It had a /24 IPv4 PA assigned by the Sponsoring LIR. That IPv4 PA assignment got deleted days after the request for the ASN. That leads me to thinking that the Sponsoring LIR (Nettera Ltd from Bulgaria) knew exactly what they are doing and helped this spammer get it's own ASN,
Ahhhhhhh! Thank you ever so much for sharing this information. (So far, both RIPE NCC and everybody else has been characteristically tight-lipped regarding attribution for the genesis of this mess. But where I come from, the tidbit you just revealed would almost certainly qualify as a ``smoking gun''.)
3) Why are some of the clearly bogus WHOIS records (for IPv4 blocks) relating to this incident still present within the RIPE WHOIS DB, even as we speak, in particular, these ones?
41.198.224.0/20 119.227.224.0/19 105.154.248.0/21 210.57.0.0/19 202.39.112.0/20 ... Because this is private data maintained by a maintainer and removing that data can only be done by that maintainer.
RIPE NCC cannot manually go in and remove those records??
4) Why is AS201640 still registered, as we speak? good question.. it's probably because the request of the ASN has never been fraudulent. As far as I know, there is a ticket opened with the RIPE NCC asking them to investigate if the ASN assignment request has been in order. As it has been more than two months since that ticket was opened, I presume they have found nothing fraudulent.
#1) Is it the consensus view in this WG that AS201640 is entirely non- fradulent, according to however that term might be defined within the RIPE region? #2) Could you give me that ticket number please?
5) Without reference to any specific incident, AS, legal entity, or any other specifics, I have the following very general question:
With respect to the contracts that RIPE enters into with those parties for whom RIPE provides registration services of *AS numbers*, specifically, are the terms and conditions of those contracts adequate and sufficient to strongly deter any and all AS registrants from deliberately and willfully announcing routes to IP space to which neither they nor any of their direct or indirect customers have any legitimate claim? how do you demonstrate that something has been deliberate and not just some fat fingering (typoes)?
Easy. If multiple (or even several) parties contact the AS and suggest to them that they should immediately and carefully review what they are announcing routes for, and if nothing changes after several days, then what they are doing is, in legal terminology, ``willful and deliberate''. The law in most jurisdictions _is_ able to recognize the substantial difference between transient stupidity and deliberate intent, and in fact _has_ recognized the difference between the two, I would guess for at least hundreds of years now, if not millennia. I see no obvious impediment which would prevent those involved in Internet networking from likewise being able to discern this distinction. http://en.wikipedia.org/wiki/Intention_%28criminal_law%29 Regards, rfg
participants (3)
-
Elvis Daniel Velea -
Ronald F. Guilmette -
Sander Steffann