From rfg at tristatelogic.com Sat Nov 1 04:52:43 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 31 Oct 2014 20:52:43 -0700 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers Message-ID: <23204.1414813963@server1.tristatelogic.com> A few questions, if you don't mind... Given some arbitrary record which is stored within the RIPE WHOIS data base, such as an organization (ORG-*) record or a record for a number resource, such as an AS, how can I determine the date on which that record was created? Do I just look for the earliest date found in any of the associated changed: fields? Give an AS number, issued within the RIPE region, how can I find the identity of the associated LIR? Is the identity of the associated LIR provided by the sponsoring-org: field of the WHOIS record for the AS? What sorts of credentials or bona fides must or should applicants who are requesting AS number allocations provide to the RIPE LIR which processes the request(s)? Has any AS number allocation, issued within the RIPE region, ever been revoked without the consent of the registrant of that allocation? If so, which ones? And in those cases, what policies and/or procedures were used or followed during the revocation process? Are these policies and/or procedures written down someplace, or are they entirely ad hoc? From brian.nisbet at heanet.ie Tue Nov 4 16:04:09 2014 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 04 Nov 2014 15:04:09 +0000 Subject: [anti-abuse-wg] Final Draft Version - Appointment & Removal of AA-WG Chairs Message-ID: <5458EAE9.3040207@heanet.ie> Colleagues, Apologies for the long delay on this, here is some very slightly revised text. It hasn't diverged much from the text of the 26th of September, but I've taken into account a number of comments that were made, especially around language. It is still my intention, at least initially, to limit this to the people in the room at a WG session at a RIPE meeting, but obviously this is up to the WG, so we can discuss this tomorrow. ************** Note on Language: Throughout this document the word Chair shall be used for both Chairs and Co-Chairs. ** Introduction: This document outlines procedures dealing with the tenure of RIPE Working Group Chairs. It applies to all RIPE Working Groups. ** WG Chair Term: The term of a WG Chair is three years. A current chair may stand for re-selection at the end of their term. A WG Chair may resign voluntarily at any time. ** Selection of a WG Chair: WG Chair vacancies, along with a call for candidates, must be announced on the WG mailing list at least one month in advance of the date upon which the selection will be held. The announcement should set a closing date for candidates. A WG may request that a WG Chair vacancy be opened so long as the addition of a new Chair would not cause the number of Chairs of that WG to exceed three. WG Chairs are elected at WG sessions at RIPE meetings. Anyone physically present at the WG session is eligible to participate in the selection process. The candidate does not need to be physically present at the WG session. If possible the Chair should be elected by acclamation by the WG or by consensus after discussion. If the result is unclear, then a secret ballot should be held. In the case of a ballot, votes will be counted by RIPE NCC Staff and/or Chairs of other WGs. The result will be determined by simple majority. ** Removal of a WG Chair: A WG Chair may be unable to fulfil their duties as described in this document or otherwise fail to serve the WG and the community. With the endorsement of a significant share of the WG, a vote of no confidence may be initiated. Before a vote of no confidence is taken, due effort should be made to address the issue(s) leading to the vote. The right of reply must be given to all parties involved in the procedure. If this effort fails to resolve the issue, the vote may proceed. The vote must be requested on the WG mailing list at least one week in advance of the WG Session at a RIPE meeting and should take place during the WG session. Anyone physically present at the WG session may take part in the vote. The vote should be conducted by secret ballot and votes counted by RIPE NCC Staff and/or WG Chairs of other WGs. The result will be determined by simple majority. If the vote of no confidence in a WG Chair is passed, the seat is vacated and the WG Chair is not eligible for stand for re-selection. ** No Chair: If a working group is left with no Chair, e.g. due to the resignation or removal of the sole WG Chair, then the WG may elect an interim WG Chair according to the selection procedures specified above, but with candidates nominated at the WG session. An interim WG Chair must resign at the next WG session, but may stand for re-selection. ** Staggered Introduction: For the purposes of staggering the introduction of this policy, in the case where all co-Chairs of a WG have served for more than the standard WG Chair term limit, an optional waiver is given to these WGs to allow them to schedule the automatic resignations of their Chairs over the two RIPE meetings immediately following the adoption of this policy. If the WG decides to avail of this waiver, it is the responsibility of the WG to decide in what order its co-Chairs should stand down. From brian.nisbet at heanet.ie Tue Nov 4 16:05:43 2014 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 04 Nov 2014 15:05:43 +0000 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <23204.1414813963@server1.tristatelogic.com> References: <23204.1414813963@server1.tristatelogic.com> Message-ID: <5458EB47.5000901@heanet.ie> Ronald, I've raised this with the NCC and asked them to prepare an answer to these questions as I feel they fall within their purview. Hopefully they will be able to get back to you soon. Brian Ronald F. Guilmette wrote, On 01/11/2014 03:52: > A few questions, if you don't mind... > > Given some arbitrary record which is stored within the RIPE WHOIS > data base, such as an organization (ORG-*) record or a record for > a number resource, such as an AS, how can I determine the date on > which that record was created? Do I just look for the earliest > date found in any of the associated changed: fields? > > Give an AS number, issued within the RIPE region, how can I find > the identity of the associated LIR? Is the identity of the > associated LIR provided by the sponsoring-org: field of the > WHOIS record for the AS? > > What sorts of credentials or bona fides must or should applicants > who are requesting AS number allocations provide to the RIPE LIR > which processes the request(s)? > > Has any AS number allocation, issued within the RIPE region, ever > been revoked without the consent of the registrant of that allocation? > If so, which ones? And in those cases, what policies and/or procedures > were used or followed during the revocation process? Are these > policies and/or procedures written down someplace, or are they entirely > ad hoc? > From gilles.massen at restena.lu Tue Nov 4 16:28:24 2014 From: gilles.massen at restena.lu (Gilles Massen) Date: Tue, 04 Nov 2014 15:28:24 +0000 Subject: [anti-abuse-wg] Final Draft Version - Appointment & Removal of AA-WG Chairs In-Reply-To: <5458EAE9.3040207@heanet.ie> References: <5458EAE9.3040207@heanet.ie> Message-ID: <5458F098.3090408@restena.lu> Brian, Without wanting to argue on the local presence for the election, I wanted to know whether you think if the chair-selection-process should be considered a kind of policy (and thus be decided consensus based on the mailing list), or rather something to be managed under the authority of the chair? Or in-between? (...and no, I'm not proposing a PDP to define the process for selecting a process for choosing WG chair - this is not ICANN after all...) best, Gilles (who is slightly annoyed for having to chose between MAT-wg and anti-abuse-wg...) On 4/11/2014, 15:04 , Brian Nisbet wrote: > Colleagues, > > Apologies for the long delay on this, here is some very slightly revised > text. It hasn't diverged much from the text of the 26th of September, > but I've taken into account a number of comments that were made, > especially around language. > > It is still my intention, at least initially, to limit this to the > people in the room at a WG session at a RIPE meeting, but obviously this > is up to the WG, so we can discuss this tomorrow. > > ************** From brian.nisbet at heanet.ie Tue Nov 4 17:32:34 2014 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 04 Nov 2014 16:32:34 +0000 Subject: [anti-abuse-wg] Final Draft Version - Appointment & Removal of AA-WG Chairs In-Reply-To: <5458F098.3090408@restena.lu> References: <5458EAE9.3040207@heanet.ie> <5458F098.3090408@restena.lu> Message-ID: <5458FFA2.4090301@heanet.ie> Gilles, Yes, it my hope that the will of the WG, as expressed through the mailing list, will be made clear on this. Brian Gilles Massen wrote, On 04/11/2014 15:28: > Brian, > > Without wanting to argue on the local presence for the election, I > wanted to know whether you think if the chair-selection-process should > be considered a kind of policy (and thus be decided consensus based on > the mailing list), or rather something to be managed under the authority > of the chair? Or in-between? (...and no, I'm not proposing a PDP to > define the process for selecting a process for choosing WG chair - this > is not ICANN after all...) > > best, > Gilles > (who is slightly annoyed for having to chose between MAT-wg and > anti-abuse-wg...) > > > On 4/11/2014, 15:04 , Brian Nisbet wrote: >> Colleagues, >> >> Apologies for the long delay on this, here is some very slightly revised >> text. It hasn't diverged much from the text of the 26th of September, >> but I've taken into account a number of comments that were made, >> especially around language. >> >> It is still my intention, at least initially, to limit this to the >> people in the room at a WG session at a RIPE meeting, but obviously this >> is up to the WG, so we can discuss this tomorrow. >> >> ************** > From rfg at tristatelogic.com Tue Nov 4 20:16:44 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 04 Nov 2014 11:16:44 -0800 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <5458EB47.5000901@heanet.ie> Message-ID: <70603.1415128604@server1.tristatelogic.com> In message <5458EB47.5000901 at heanet.ie>, you wrote: >Ronald, > >I've raised this with the NCC and asked them to prepare an answer to >these questions as I feel they fall within their purview. > >Hopefully they will be able to get back to you soon. > >Brian >Ronald F. Guilmette wrote, On 01/11/2014 03:52: >> A few questions, if you don't mind... >> >> Given some arbitrary record which is stored within the RIPE WHOIS >> data base, such as an organization (ORG-*) record or a record for >> a number resource, such as an AS, how can I determine the date on >> which that record was created? Do I just look for the earliest >> date found in any of the associated changed: fields? Just to make sure I'm clear... No one on this list knows the answer, even to the above trivial question? >> Give an AS number, issued within the RIPE region, how can I find >> the identity of the associated LIR? Is the identity of the >> associated LIR provided by the sponsoring-org: field of the >> WHOIS record for the AS? Same again. I am rather astonished that not a single person within a group focused on dealing with network abuse issues within the RIPE region can even say how to find the LIR that issued a given AS. Does no one, other than me, ever even get curious about such things? >> What sorts of credentials or bona fides must or should applicants >> who are requesting AS number allocations provide to the RIPE LIR >> which processes the request(s)? Same comments as above. >> Has any AS number allocation, issued within the RIPE region, ever >> been revoked without the consent of the registrant of that allocation? >> If so, which ones? And in those cases, what policies and/or procedures >> were used or followed during the revocation process? Are these >> policies and/or procedures written down someplace, or are they entirely >> ad hoc? Someone did write to me, off-list, with a semi-response to the above, informing me that ``details'' of RIPE investigations are non-public. I should probably have clarified that I wasn't asking for any specific details about any specific case. I asked, in the first instance, if any AS allocation had ever been revoked. That's a yes/no question, and one which I thought would have been easy to answer, particularly by members of a group focused on network abuse issues. But if all of these questions can only be answered by the NCC, then I guess that's the way it is, and I thank you for forwarding my queries to them. From Piotr.Strzyzewski at polsl.pl Wed Nov 5 00:17:41 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 5 Nov 2014 00:17:41 +0100 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <70603.1415128604@server1.tristatelogic.com> References: <5458EB47.5000901@heanet.ie> <70603.1415128604@server1.tristatelogic.com> Message-ID: <20141104231741.GA2154@hydra.ck.polsl.pl> On Tue, Nov 04, 2014 at 11:16:44AM -0800, Ronald F. Guilmette wrote: > >> A few questions, if you don't mind... > >> > >> Given some arbitrary record which is stored within the RIPE WHOIS > >> data base, such as an organization (ORG-*) record or a record for > >> a number resource, such as an AS, how can I determine the date on > >> which that record was created? Do I just look for the earliest > >> date found in any of the associated changed: fields? > > Just to make sure I'm clear... No one on this list knows the answer, > even to the above trivial question? Or noone care/want to answer "above trivial question". My advice is - check the --list-versions description plus latest updates from the db-wg. Best regards, Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From zsako at iszt.hu Wed Nov 5 00:28:59 2014 From: zsako at iszt.hu (Janos Zsako) Date: Wed, 05 Nov 2014 00:28:59 +0100 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <70603.1415128604@server1.tristatelogic.com> References: <70603.1415128604@server1.tristatelogic.com> Message-ID: <5459613B.6010604@iszt.hu> Dear Ronald, I will try to answer some of your questions. Others may correct me if I am wrong. >> I've raised this with the NCC and asked them to prepare an answer to >> these questions as I feel they fall within their purview. >> >> Hopefully they will be able to get back to you soon. >> >> Brian >> Ronald F. Guilmette wrote, On 01/11/2014 03:52: >>> A few questions, if you don't mind... >>> >>> Given some arbitrary record which is stored within the RIPE WHOIS >>> data base, such as an organization (ORG-*) record or a record for >>> a number resource, such as an AS, how can I determine the date on >>> which that record was created? Do I just look for the earliest >>> date found in any of the associated changed: fields? > > Just to make sure I'm clear... No one on this list knows the answer, > even to the above trivial question? I guess there is no good answer to this. As far as I can tell, you have no means to find out when an object was first added to the database (i.e. created). The earliest changed: field usually gives you only an upper limit (i.e the object is most probably not younger than that date). You can also look at the historical data of the object, see https://labs.ripe.net/Members/kranjbar/proposal-to-display-history-of-objects-in-ripe-database however, this does not necessarily help either. As far as I know, the RIPE NCC, however, in a given case, could tell you exactly when the given object was created. There are, however, plans to introduce new attributes (created: and last-modified:) that would replace the (rather useless) changed: attribute. >>> Give an AS number, issued within the RIPE region, how can I find >>> the identity of the associated LIR? Is the identity of the >>> associated LIR provided by the sponsoring-org: field of the >>> WHOIS record for the AS? > > Same again. I am rather astonished that not a single person within > a group focused on dealing with network abuse issues within the RIPE > region can even say how to find the LIR that issued a given AS. This is probably due to the fact that there is no such data available in the database. You can make some assumptions, but these may be wrong in some cases. The sponsoring-org: is probably not what you are looking for, as it only says which LIR is currently taking care of this resource. A question comes to my mind, however, why do you care about who issued a given AS? I would think that from an abuse point of view who _uses_ the AS is much more relevant. I hope this helps. > Does > no one, other than me, ever even get curious about such things? This is not necessarily the case. However, as I pointed out, there are some data that at present cannot be retrieved form the database. Best regards, Janos >>> What sorts of credentials or bona fides must or should applicants >>> who are requesting AS number allocations provide to the RIPE LIR >>> which processes the request(s)? > > Same comments as above. > >>> Has any AS number allocation, issued within the RIPE region, ever >>> been revoked without the consent of the registrant of that allocation? >>> If so, which ones? And in those cases, what policies and/or procedures >>> were used or followed during the revocation process? Are these >>> policies and/or procedures written down someplace, or are they entirely >>> ad hoc? > > Someone did write to me, off-list, with a semi-response to the above, > informing me that ``details'' of RIPE investigations are non-public. > I should probably have clarified that I wasn't asking for any specific > details about any specific case. I asked, in the first instance, if any > AS allocation had ever been revoked. That's a yes/no question, and one > which I thought would have been easy to answer, particularly by members > of a group focused on network abuse issues. > > But if all of these questions can only be answered by the NCC, then I > guess that's the way it is, and I thank you for forwarding my queries to > them. > > From rfg at tristatelogic.com Wed Nov 5 01:37:13 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 04 Nov 2014 16:37:13 -0800 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <5459613B.6010604@iszt.hu> Message-ID: <73461.1415147833@server1.tristatelogic.com> In message <5459613B.6010604 at iszt.hu>, Janos Zsako wrote: >I will try to answer some of your questions. Thank you. >>>> Given some arbitrary record which is stored within the RIPE WHOIS >>>> data base, such as an organization (ORG-*) record or a record for >>>> a number resource, such as an AS, how can I determine the date on >>>> which that record was created? Do I just look for the earliest >>>> date found in any of the associated changed: fields? >>... >I guess there is no good answer to this. As far as I can tell, you have no >means to find out when an object was first added to the database >(i.e. created). The earliest changed: field usually gives you only an upper >limit (i.e the object is most probably not younger than that date). > >You can also look at the historical data of the object, see >https://labs.ripe.net/Members/kranjbar/proposal-to-display-history-of-objects- >in-ripe-database >however, this does not necessarily help either. > >As far as I know, the RIPE NCC, however, in a given case, could tell you >exactly when the given object was created. Thanks, but that begs the question... What exactly do you mean by "case" in this context? (I _had_ vaguely hoped that I might be able to do at least some very modest and very preliminary investigation of some fishy goings on, *without* having to initiate a full blown and formal legal proceeding in order to do so. But it is looking more any more as if RIPE NCC is not making available even some very basic types of information... e.g. age... about the objects in its data base. Over here on this side of the pond, we have a name for this. It's called "hiding the ball.") >There are, however, plans to introduce new attributes (created: and >last-modified:) that would replace the (rather useless) changed: attribute. That will be helpful. (Of course, it will be even more helpful if those things actually make their debut within my lifetime.) >> Same again. I am rather astonished that not a single person within >> a group focused on dealing with network abuse issues within the RIPE >> region can even say how to find the LIR that issued a given AS. > >This is probably due to the fact that there is no such data available >in the database. You can make some assumptions, but these may be wrong So there is no trace... no chain of documentation on how an AS got to be an AS. Is that correct? Is that really what you are telling me? (Where I live, it is necessary to obtain a formal written license from the state, even if all you want to do is to cut people's hair in exchange for money. And the relevant documents get filed, in triplicate, and are available for public inspection in Sacramento. Given what we all know these days about the kind of damage that can be caused, throughout the world, and for millions of people and companies, e.g. by a "rogue" AS operator, I remain both stunned and mystified that in the RIPE region, no documentation is available on how a given AS came to be.) >A question comes to my mind, however, why do you care about who issued >a given AS? I would think that from an abuse point of view who _uses_ the AS >is much more relevant. The answer to the question in the first sentence just above is contained in the second sentence just above. I want to know who registered a given AS. And I would like to know how they demonstrated that they were indeed who they said they were (and/or I'd like to know if the LIR even bothered to check). Remember, I also asked this: >>>> What sorts of credentials or bona fides must or should applicants >>>> who are requesting AS number allocations provide to the RIPE LIR >>>> which processes the request(s)? At the present moment, it appears to me that a drunken one-eyed sailor can simply show up in the offices of certain LIRs in certain European cities, claim to have lost his wallet, driver's license, birth certificate, and all other forms of identification, and then can ask for his own AS, which will be awarded to him on the spot, and without any of those silly annoying questions of the kind those stupid impolite Americans are in the habit of asking... like for instance who he actually is or whether or not he had ever been convicted of murdering anyone. Alternatively, if you call in to the right LIR(s) and simply pretend to be some famous big-name movie star who is well known within the country in question, then in deference to your status, they will give you your AS, no questions asked... and none of that annoying paperwork stuff. Regards, rfg P.S. I _would_ just simply ask RIPE NCC for the info I'm seeking, but past experience suggests to me that if I did that, their first response would most probably be to start to grill _me_, e.g. asking me who I am and why I want to know. Then in the end, they would go off and do their own sooper sekrit investigation, and never tell me a single blessed thing. From ops.lists at gmail.com Wed Nov 5 02:12:09 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 05 Nov 2014 01:12:09 +0000 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers References: <5459613B.6010604@iszt.hu> <73461.1415147833@server1.tristatelogic.com> Message-ID: I thought it was more like "we will set up a shell company by paying some random guy in a bar drinking money to use his ID and register one". At least if we're talking of a certain european country with LIRs known for handing out /14s earlier, smaller but still significant IP blocks now, to some "high volume email deployers" among others. Most of what you ask is, I suspect, doable if people decide to forget that "we're not the internet police" trope. And if there's more active participation from the security and abuse handling side of various RIPE members rather than just their network and DNS people. --srs On Wed, 5 Nov 2014 at 06:07 Ronald F. Guilmette wrote: > > In message <5459613B.6010604 at iszt.hu>, > Janos Zsako wrote: > > >I will try to answer some of your questions. > > Thank you. > > >>>> Given some arbitrary record which is stored within the RIPE WHOIS > >>>> data base, such as an organization (ORG-*) record or a record for > >>>> a number resource, such as an AS, how can I determine the date on > >>>> which that record was created? Do I just look for the earliest > >>>> date found in any of the associated changed: fields? > >>... > >I guess there is no good answer to this. As far as I can tell, you have no > >means to find out when an object was first added to the database > >(i.e. created). The earliest changed: field usually gives you only an > upper > >limit (i.e the object is most probably not younger than that date). > > > >You can also look at the historical data of the object, see > >https://labs.ripe.net/Members/kranjbar/proposal-to- > display-history-of-objects- > >in-ripe-database > >however, this does not necessarily help either. > > > >As far as I know, the RIPE NCC, however, in a given case, could tell you > >exactly when the given object was created. > > Thanks, but that begs the question... What exactly do you mean by "case" > in this context? > > (I _had_ vaguely hoped that I might be able to do at least some very > modest and very preliminary investigation of some fishy goings on, > *without* having to initiate a full blown and formal legal proceeding > in order to do so. But it is looking more any more as if RIPE NCC is > not making available even some very basic types of information... e.g. > age... about the objects in its data base. Over here on this side of > the pond, we have a name for this. It's called "hiding the ball.") > > >There are, however, plans to introduce new attributes (created: and > >last-modified:) that would replace the (rather useless) changed: > attribute. > > That will be helpful. > > (Of course, it will be even more helpful if those things actually make > their debut within my lifetime.) > > >> Same again. I am rather astonished that not a single person within > >> a group focused on dealing with network abuse issues within the RIPE > >> region can even say how to find the LIR that issued a given AS. > > > >This is probably due to the fact that there is no such data available > >in the database. You can make some assumptions, but these may be wrong > > So there is no trace... no chain of documentation on how an AS got to > be an AS. Is that correct? Is that really what you are telling me? > > (Where I live, it is necessary to obtain a formal written license from > the state, even if all you want to do is to cut people's hair in exchange > for money. And the relevant documents get filed, in triplicate, and are > available for public inspection in Sacramento. Given what we all know > these days about the kind of damage that can be caused, throughout the > world, and for millions of people and companies, e.g. by a "rogue" AS > operator, I remain both stunned and mystified that in the RIPE region, > no documentation is available on how a given AS came to be.) > > >A question comes to my mind, however, why do you care about who issued > >a given AS? I would think that from an abuse point of view who _uses_ the > AS > >is much more relevant. > > The answer to the question in the first sentence just above is contained > in the second sentence just above. > > I want to know who registered a given AS. And I would like to know how > they demonstrated that they were indeed who they said they were (and/or > I'd like to know if the LIR even bothered to check). > > Remember, I also asked this: > > >>>> What sorts of credentials or bona fides must or should applicants > >>>> who are requesting AS number allocations provide to the RIPE LIR > >>>> which processes the request(s)? > > > At the present moment, it appears to me that a drunken one-eyed sailor > can simply show up in the offices of certain LIRs in certain European > cities, claim to have lost his wallet, driver's license, birth certificate, > and all other forms of identification, and then can ask for his own AS, > which will be awarded to him on the spot, and without any of those silly > annoying questions of the kind those stupid impolite Americans are in > the habit of asking... like for instance who he actually is or whether > or not he had ever been convicted of murdering anyone. > > Alternatively, if you call in to the right LIR(s) and simply pretend to > be some famous big-name movie star who is well known within the country > in question, then in deference to your status, they will give you your > AS, no questions asked... and none of that annoying paperwork stuff. > > > Regards, > rfg > > > P.S. I _would_ just simply ask RIPE NCC for the info I'm seeking, but > past experience suggests to me that if I did that, their first response > would most probably be to start to grill _me_, e.g. asking me who I am > and why I want to know. Then in the end, they would go off and do their > own sooper sekrit investigation, and never tell me a single blessed thing. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Wed Nov 5 04:12:34 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 04 Nov 2014 19:12:34 -0800 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: Message-ID: <74505.1415157154@server1.tristatelogic.com> In message Suresh Ramasubramanian wrote: >Most of what you ask is, I suspect, doable... Huh?? I am genuinely puzzled. What did I ask? I didn't ask anybody to _do_ anything. At least nothing other than to tell me how to find certain bits of unarguably useful information (which apparently aren't available to mere mortals... I am guessing by design, since it wouldn't exactly be rocket surgery to add them into the WHOIS responses). I don't have a big agenda to make the world safe for democracy here or anything like that. I already know many of the reasons why THAT ain't gonna happen. But my innate curiosity does cause me to at least want to know who the outright crooks are, and who the screw-ups are who let them onto the Internet, and when. I feel that everyone has a right to this information, not to punish, but to protect ourselves from the bad guys and also maybe from the dopes who, wittingly or otherwise, help them. From lists-ripe at c4inet.net Wed Nov 5 07:38:36 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 5 Nov 2014 06:38:36 +0000 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <73461.1415147833@server1.tristatelogic.com> References: <5459613B.6010604@iszt.hu> <73461.1415147833@server1.tristatelogic.com> Message-ID: <20141105063836.GB58573@cilantro.c4inet.net> On Tue, Nov 04, 2014 at 04:37:13PM -0800, Ronald F. Guilmette wrote: >>> Same again. I am rather astonished that not a single person within >>> a group focused on dealing with network abuse issues within the RIPE >>> region can even say how to find the LIR that issued a given AS. That is because LIRs do not "issue" (or assign) ASN resources. Had you bothered to read http://www.ripe.net/ripe/docs/ripe-525 and http://www.ripe.net/ripe/docs/ripe-452 , you would be closer to an understanding of the process to assign ASN resources to end-users. >So there is no trace... no chain of documentation on how an AS got to >be an AS. Is that correct? Is that really what you are telling me? It is not. There is a contract for every independent resource assigned after -525 came into force and when Phase 3 is completed, there will be contracts for legacy ASN/PI resources also. These contracts are confidential and not public information. On this side of the pond, we call it "data protection" and it is the law. >I want to know who registered a given AS. And I would like to know how >they demonstrated that they were indeed who they said they were (and/or >I'd like to know if the LIR even bothered to check). > >Remember, I also asked this: > >>>>> What sorts of credentials or bona fides must or should applicants >>>>> who are requesting AS number allocations provide to the RIPE LIR >>>>> which processes the request(s)? This is laid down in http://www.ripe.net/ripe/docs/ripe-556 rgds, Sascha Luck From rfg at tristatelogic.com Wed Nov 5 10:31:04 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 05 Nov 2014 01:31:04 -0800 Subject: [anti-abuse-wg] EU Data Protection In-Reply-To: <20141105063836.GB58573@cilantro.c4inet.net> Message-ID: <76074.1415179864@server1.tristatelogic.com> In message <20141105063836.GB58573 at cilantro.c4inet.net>, Sascha Luck wrote: >>So there is no trace... no chain of documentation on how an AS got to >>be an AS. Is that correct? Is that really what you are telling me? > >It is not. There is a contract for every independent resource assigned >after -525 came into force and when Phase 3 is completed, there will be >contracts for legacy ASN/PI resources also. >These contracts are confidential and not public information. On this >side of the pond, we call it "data protection" and it is the law. I admit to being eager to be further educated, by you and/or others, about the law of which you speak, and especially how it may relate to the disbursment, or lack thereof, of various bits of information held by RIPE NCC. As a result of your response, I've already tried to educate myself, at least a little bit, about the subject of "data protection" regulation within the EU. I began here, and started reading: http://en.wikipedia.org/wiki/Data_Protection_Directive Of course, I don't take anything appearing in Wikipedia as being the absolute correct and final word on any subject, so perhaps, since you know about the law you have referred to... at least presumably a bit better than this ignorant American, who has never had to deal with it or live under it... perhaps you can explain one or two small points which are still eluding me. To begin with, I noticed this within the above Wikipedia page: Scope Personal data are defined as "any information relating to an identified or identifiable natural person ("data subject");... I am asuming that, in this context, "natural person" has the same meaning on both your side of the pond and mine, i.e. a carbon-based life form, and an entity composed of flesh and blood. Does that term have that meaning also within the EU? Assuming, just for the sake of argument, that it does, I am wondering how the EU data protection law applies to the particular sorts of entities that typically register ASNs within the EU. I'll just pick one at random, for the purposes of example... let's say the AS from which you sent the e-mail message to which I am now responding, AS47720. It appears from the RIPE data base record for AS47720... a record which I believe is generally available, without restriction, to the public at large on all parts of planet earth, and in some cases perhaps even beyond... that the entity that registered AS47720 is known as, or wishes to be known as "Chip Electronic Services Limited". So, um, using that as just an arbitrary, but perhaps representative ex- ample of the kinds of entities that might typically register ASNs with RIPE NCC, and assuming that this entity is not in fact a "natural person", per se... at least as I understand that term... I am left rather befuddled, because Wikipedia seems to say that EU data protection only applies to "natural persons" and yet it seems that you just asserted the opposite, i.e. that the registrant of AS47720... or of any arbitrary AS for that matter... is entitled to have its name and, perhaps more importantly, any an all other identifying details protected under EU data protection regulations. So, um, which view is correct? Do EU data protection regulations apply to all European entities, natural or otherwise, as it seems you have said? Or do they in fact only apply to natural persons, as Wikipedia says? If the latter, then it remains unclear why... as you seem to have asserted... "{all} contracts {with RIPE} are confidential and not public information". Do EU data protection regulations prevent RIPE from being open and trans- parent with respect to the contracts which it has entered into with things which are not "natural persons", e.g. Chip Electronic Services Limited? Well, leaving that aside for the moment, even if, as I believe you have correctly stated, RIPE, which is resident within the EU and which deals with EU data, is obligated to obey EU data protection directives... either for all entities it has data on or only the natural ones... I do confess that I am still terrifically puzzled by your assertion that RIPE is somehow obligated to keep *everything* secret. I am puzzled by that assertion for the simple reason that it seems self evident that in fact RIPE does not do so. Even though RIPE is clearly subject to EU data protection regulations, I, here in the United States, just now had no trouble at all fetching from the RIPE data base the following record, which, I believe, contains some very specific types of "protected" information relating to _both_ a legal (business) entity _and_ also to a protected "natural person": ========================================================================= % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Information related to 'JS6689-RIPE' person: Jerry Sweeney address: Cork Internet Exchange Hollyhill Ind. Estate Cork, Ireland e-mail: js at cix.ie phone: +353 21 4854300 nic-hdl: JS6689-RIPE mnt-by: MNT-CIX changed: sascha at cix.ie 20100622 source: RIPE % This query was served by the RIPE Database Query Service version 1.75 (DB-1) ========================================================================= So, as I say, I am perplexed. You tell me that RIPE has a legal obligation to protect secrecy/privacy, and I _do_ believe you. The several online articles I've read on the subject this evening are all quite clear that this is indeed correct. Nontheless, the clear evidence which is right before my eyes (and which is reproduced just above) would seem to indicate that it, RIPE NCC, has found some legally tenable way around these draconian EU privacy regulations. If it had not, then how was it able to send me the above data base record without some humorless unforgiving EU data protection commissar coming down on them like the proverbial ton of bricks? And if, as would seem to be the case, RIPE *has* indeed found a legally viable way to be transparent about certain things... e.g. the entries in its data base... even while still remaining within bounds of EU data protection regulations... then why can it not do so also with respect to all those contracts that it signs with things which are not natural persons? I do look forward to being enlightened on both of the above points. Regards, rfg P.S. I learned something relevant today. The web-based WHOIS service for the .EU TLD _will_ show the user full contact details for any domain which is registered by something other than a natural person. Those details are however suppressed, selectively, in the WHOIS output, but only in cases where the registrant is a natural person. Anyway, the point is that the operators of the .EU registry seem to have mastered this dicotomy... between "natural" and other-than-natural registrants... and to have done so within the EU data protection legal framework, even while being as transparent as possible. Is there some specific reason that I am not aware of why RIPE cannot do likewise? From furio+as at spin.it Wed Nov 5 11:06:34 2014 From: furio+as at spin.it (furio ercolessi) Date: Wed, 5 Nov 2014 11:06:34 +0100 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <20141105063836.GB58573@cilantro.c4inet.net> References: <5459613B.6010604@iszt.hu> <73461.1415147833@server1.tristatelogic.com> <20141105063836.GB58573@cilantro.c4inet.net> Message-ID: <20141105100634.GA26368@spin.it> On Wed, Nov 05, 2014 at 06:38:36AM +0000, Sascha Luck wrote: > On Tue, Nov 04, 2014 at 04:37:13PM -0800, Ronald F. Guilmette wrote: > [...] > >So there is no trace... no chain of documentation on how an AS got to > >be an AS. Is that correct? Is that really what you are telling me? > > It is not. There is a contract for every independent resource assigned > after -525 came into force and when Phase 3 is completed, there will be > contracts for legacy ASN/PI resources also. > These contracts are confidential and not public information. On this > side of the pond, we call it "data protection" and it is the law. But if the community perceives that the amount of information disclosed in the public database is not adequate to the needs (and I personally regretted to be unable to get the informations that RFG is talking about, several times!), then new information could be supplied in the whois after asking for consent from the resource holder, no ? So perhaps we can take this opportunity to discuss an extension of the data shown in the public whois. furio From Piotr.Strzyzewski at polsl.pl Wed Nov 5 11:08:50 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 5 Nov 2014 11:08:50 +0100 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <20141105100634.GA26368@spin.it> References: <5459613B.6010604@iszt.hu> <73461.1415147833@server1.tristatelogic.com> <20141105063836.GB58573@cilantro.c4inet.net> <20141105100634.GA26368@spin.it> Message-ID: <20141105100850.GB32098@hydra.ck.polsl.pl> On Wed, Nov 05, 2014 at 11:06:34AM +0100, furio ercolessi wrote: > On Wed, Nov 05, 2014 at 06:38:36AM +0000, Sascha Luck wrote: > > On Tue, Nov 04, 2014 at 04:37:13PM -0800, Ronald F. Guilmette wrote: > > [...] > > >So there is no trace... no chain of documentation on how an AS got to > > >be an AS. Is that correct? Is that really what you are telling me? > > > > It is not. There is a contract for every independent resource assigned > > after -525 came into force and when Phase 3 is completed, there will be > > contracts for legacy ASN/PI resources also. > > These contracts are confidential and not public information. On this > > side of the pond, we call it "data protection" and it is the law. > > But if the community perceives that the amount of information disclosed > in the public database is not adequate to the needs (and I personally > regretted to be unable to get the informations that RFG is talking about, > several times!), then new information could be supplied in the whois after > asking for consent from the resource holder, no ? > > So perhaps we can take this opportunity to discuss an extension of > the data shown in the public whois. Have any of you ever consider making a policy proposal to change this? Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From lists-ripe at c4inet.net Wed Nov 5 11:12:22 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 5 Nov 2014 10:12:22 +0000 Subject: [anti-abuse-wg] EU Data Protection In-Reply-To: <76074.1415179864@server1.tristatelogic.com> References: <20141105063836.GB58573@cilantro.c4inet.net> <76074.1415179864@server1.tristatelogic.com> Message-ID: <20141105101221.GC58573@cilantro.c4inet.net> On Wed, Nov 05, 2014 at 01:31:04AM -0800, Ronald F. Guilmette wrote: > Personal data are defined as "any information relating to an identified > or identifiable natural person ("data subject");... > >I am asuming that, in this context, "natural person" has the same meaning >on both your side of the pond and mine, i.e. a carbon-based life form, and >an entity composed of flesh and blood. Does that term have that meaning >also within the EU? You are probably right that the DPD only applies to natural persons, however natural persons also hold independent resources (I personally had both a PI assignment and an ASN at some stage) >% Information related to 'JS6689-RIPE' > >So, as I say, I am perplexed. You tell me that RIPE has a legal obligation >to protect secrecy/privacy, and I _do_ believe you. The several online >articles I've read on the subject this evening are all quite clear that >this is indeed correct. Nontheless, the clear evidence which is right I personally think that publishing "person" objects does indeed break the law, NCC Legal clearly disagrees. TTBOMK, this has never been tested in court. However, there is currently no requirement to have any other info than some contact info in this object, so data hygiene is clearly possible. (it also does not have to be "official" information) >And if, as would seem to be the case, RIPE *has* indeed found a legally >viable way to be transparent about certain things... e.g. the entries >in its data base... even while still remaining within bounds of EU data >protection regulations... then why can it not do so also with respect >to all those contracts that it signs with things which are not natural >persons? So there might not be an actual legal obligation to keep these contracts confidential. I'm not even sure now that the general LIR Service Contract (which states that all contractual information is confidential) applies in this case as (in case of a sponsoring LIR) it is not a contract that the NCC is a party to. In any case, this is for NCC Legal to answer, not for me. I'm not sure that the contract contains any relevant information, besides that which is published in the db already. Whatever pricing and other conditions were agreed is none of your business. Whatever documentation is used to verify ID is, in case of passport copies, etc, very much subject to the DPD; in case of registration documents, these are (usually) public information, there may be a copyright issue though as many authorities make these available, but not for free. In any case, I'm sure I'm not the only member whose idea of what we pay the NCC for is to be a resource registry, *not* an intelligence repository for curtain-twitchers and anyone who fancies themselves some kind of Internet Stasi. We already pay taxes for government agencies to be that. rgds, Sascha Luck From lists-ripe at c4inet.net Wed Nov 5 11:14:42 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 5 Nov 2014 10:14:42 +0000 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <20141105100634.GA26368@spin.it> References: <5459613B.6010604@iszt.hu> <73461.1415147833@server1.tristatelogic.com> <20141105063836.GB58573@cilantro.c4inet.net> <20141105100634.GA26368@spin.it> Message-ID: <20141105101442.GD58573@cilantro.c4inet.net> On Wed, Nov 05, 2014 at 11:06:34AM +0100, furio ercolessi wrote: >several times!), then new information could be supplied in the whois after >asking for consent from the resource holder, no ? Which will not be forthcoming from *this* resource holder. >So perhaps we can take this opportunity to discuss an extension of >the data shown in the public whois. Not while this member pays membership fees. rgds, Sascha Luck From ops.lists at gmail.com Wed Nov 5 11:20:26 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 5 Nov 2014 15:50:26 +0530 Subject: [anti-abuse-wg] EU Data Protection In-Reply-To: <20141105101221.GC58573@cilantro.c4inet.net> References: <20141105063836.GB58573@cilantro.c4inet.net> <76074.1415179864@server1.tristatelogic.com> <20141105101221.GC58573@cilantro.c4inet.net> Message-ID: Ah, a Godwin on the other side, just to start with. Stasi are the new Hitler like orange is the new black? Right now Ronald is, in admittedly a rather roundabout way, talking about people who are running rings around your favorite 'resource registry' processes, such as they are, and leaving the rest of you very little v4 space that isn't irretrievably poisoned after a day or two of their using it. And yes, everybody is supposed to have switched to v6 over a decade back, funny how v4 manages to be so long lived. And as for arguments about let them register as much v6 ad they want, there is plenty, remember that 'should be enough for everyone' attitude in the early days of v4? History, especially operational history, is out there for people to actually learn from it, not trot out stale tropes about Internet police and the stasi. On Nov 5, 2014 3:42 PM, "Sascha Luck" wrote: > On Wed, Nov 05, 2014 at 01:31:04AM -0800, Ronald F. Guilmette wrote: > >> Personal data are defined as "any information relating to an identified >> or identifiable natural person ("data subject");... >> >> I am asuming that, in this context, "natural person" has the same meaning >> on both your side of the pond and mine, i.e. a carbon-based life form, and >> an entity composed of flesh and blood. Does that term have that meaning >> also within the EU? >> > > You are probably right that the DPD only applies to natural persons, > however natural persons also hold independent resources (I personally had > both a PI assignment and an ASN at some stage) > > % Information related to 'JS6689-RIPE' >> >> So, as I say, I am perplexed. You tell me that RIPE has a legal >> obligation >> to protect secrecy/privacy, and I _do_ believe you. The several online >> articles I've read on the subject this evening are all quite clear that >> this is indeed correct. Nontheless, the clear evidence which is right >> > > I personally think that publishing "person" objects does indeed break the > law, NCC Legal clearly disagrees. TTBOMK, this has never been tested in > court. > However, there is currently no requirement to have any other info than > some contact info in this object, so data hygiene is clearly possible. > (it also does not have to be "official" information) > > And if, as would seem to be the case, RIPE *has* indeed found a legally >> viable way to be transparent about certain things... e.g. the entries >> in its data base... even while still remaining within bounds of EU data >> protection regulations... then why can it not do so also with respect >> to all those contracts that it signs with things which are not natural >> persons? >> > > So there might not be an actual legal obligation to keep these contracts > confidential. I'm not even sure now that the general LIR Service > Contract (which states that all contractual information is confidential) > applies in this case as (in case of a sponsoring LIR) it is not a > contract that the NCC is a party to. In any case, this is for NCC Legal > to answer, not for me. > > I'm not sure that the contract contains any relevant information, > besides that which is published in the db already. Whatever pricing and > other conditions were agreed is none of your business. > > Whatever documentation is used to verify ID is, in case of passport > copies, etc, very much subject to the DPD; in case of registration > documents, these are (usually) public information, there may be a > copyright issue though as many authorities make these available, but > not for free. > In any case, I'm sure I'm not the only member whose idea of what we pay > the NCC for is to be a resource registry, *not* an intelligence > repository for curtain-twitchers and anyone who fancies themselves some > kind of Internet Stasi. We already pay taxes for government agencies to > be that. > rgds, > Sascha Luck > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From furio+as at spin.it Wed Nov 5 11:23:08 2014 From: furio+as at spin.it (furio ercolessi) Date: Wed, 5 Nov 2014 11:23:08 +0100 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <20141105101442.GD58573@cilantro.c4inet.net> References: <5459613B.6010604@iszt.hu> <73461.1415147833@server1.tristatelogic.com> <20141105063836.GB58573@cilantro.c4inet.net> <20141105100634.GA26368@spin.it> <20141105101442.GD58573@cilantro.c4inet.net> Message-ID: <20141105102308.GC26368@spin.it> On Wed, Nov 05, 2014 at 10:14:42AM +0000, Sascha Luck wrote: > On Wed, Nov 05, 2014 at 11:06:34AM +0100, furio ercolessi wrote: > > >So perhaps we can take this opportunity to discuss an extension of > >the data shown in the public whois. > > Not while this member pays membership fees. I do not see how your membership status can affect the ability of people to discuss abuse-related topics in this working group. furio From wilfried.woeber at univie.ac.at Wed Nov 5 11:23:05 2014 From: wilfried.woeber at univie.ac.at (=?utf-8?B?V2lsZnJpZWQgV8O2YmVy?=) Date: Wed, 5 Nov 2014 11:23:05 +0100 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <20141105101442.GD58573@cilantro.c4inet.net> References: <5459613B.6010604@iszt.hu> <73461.1415147833@server1.tristatelogic.com> <20141105063836.GB58573@cilantro.c4inet.net> <20141105100634.GA26368@spin.it> <20141105101442.GD58573@cilantro.c4inet.net> Message-ID: On Wed, November 5, 2014 11:14, Sascha Luck wrote: > On Wed, Nov 05, 2014 at 11:06:34AM +0100, furio ercolessi wrote: >>several times!), then new information could be supplied in the whois >> after asking for consent from the resource holder, no ? Anyone believing that those parties which can expect to become the target of Ronald-Style investigations would consent and supply the info? This is barking up the wrong tree (again). Wilfried > Which will not be forthcoming from *this* resource holder. > >>So perhaps we can take this opportunity to discuss an extension of >>the data shown in the public whois. > > Not while this member pays membership fees. > > rgds, > Sascha Luck > > > From ops.lists at gmail.com Wed Nov 5 11:35:05 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 5 Nov 2014 16:05:05 +0530 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: References: <5459613B.6010604@iszt.hu> <73461.1415147833@server1.tristatelogic.com> <20141105063836.GB58573@cilantro.c4inet.net> <20141105100634.GA26368@spin.it> <20141105101442.GD58573@cilantro.c4inet.net> Message-ID: On Wed, Nov 5, 2014 at 3:53 PM, Wilfried W?ber wrote: > Anyone believing that those parties which can expect to become the target > of Ronald-Style investigations would consent and supply the info? > > This is barking up the wrong tree (again). No. But sometimes even faked whois can tell an interesting story. -- Suresh Ramasubramanian (ops.lists at gmail.com) From rfg at tristatelogic.com Wed Nov 5 12:03:15 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 05 Nov 2014 03:03:15 -0800 Subject: [anti-abuse-wg] EU Data Protection In-Reply-To: <20141105101221.GC58573@cilantro.c4inet.net> Message-ID: <77093.1415185395@server1.tristatelogic.com> In message <20141105101221.GC58573 at cilantro.c4inet.net>, Sascha Luck wrote: >You are probably right that the DPD only applies to natural persons, Thank you. >however natural persons also hold independent resources (I personally >had both a PI assignment and an ASN at some stage) Yes, but is that the general rule, or is that the exceptional case? Do we want the tail to wag the dog? >>% Information related to 'JS6689-RIPE' >> >>So, as I say, I am perplexed. You tell me that RIPE has a legal obligation >>to protect secrecy/privacy, and I _do_ believe you. The several online >>articles I've read on the subject this evening are all quite clear that >>this is indeed correct. Nontheless, the clear evidence which is right > >I personally think that publishing "person" objects does indeed break the >law, NCC Legal clearly disagrees. It would seem so, and may God bless them for that. I am of the opinion that the net would fall apart at the seams in short order if the people who operate it, day in and day out, had no off-net way of contacting one another about problems. >TTBOMK, this has never been tested in court. You say that as if it is a bad thing. Personally, I think it is great... terrific... that nobody has ever challenged RIPE on this in a courtroom. That fact alone tends to support the belief that the RIPE legal folks who have decided to allow WHOIS to continue to operate as it always has are in fact on a solid legal footing in doing so, or at the very least that the question presents such a level of complexity and ambiguity that nobody has been motivated to spend the kinds of sums that would be necessary to mount a legal challenge. >So there might not be an actual legal obligation to keep these contracts >confidential. No one could be happier to hear that than I. >In any case, this is for NCC Legal to answer, not for me. I can only agree. >I'm not sure that the contract contains any relevant information, >besides that which is published in the db already. Well, I'm not so sure. Having read one or two of the RIPE documents I have been pointed at, I can say that it _seems_ that if you read between the lines, RIPE NCC will perform "due diligence"... a term which is left somewhat ill defined, but which, one hopes, means at least -some- kind of verification... at the time a resource allocation first occurs. Thereafter, it is up to the registrant to maintain the relevant WHOIS data, and all registrants are pledged to, and expected to do so in a way that causes the WHOIS data to always be accurate. But I did not get any clear sense that RIPE NCC would always and in all cases vet, or re-vet changes made by a registrant to a WHOIS record, post- allocation... and perhaps they routinely do not do so. This would leave open the door to deliberately malicious registrants who might provide all correct contact information initially, and then, a week or a month later, go in and scramble their WHOIS to make it point to something/someone entirely fictitious. >Whatever pricing and >other conditions were agreed is none of your business. I agress completely, and as should be obvious from the context of my questions, I really do not give a hoot about any of that anyway. >Whatever documentation is used to verify ID is, in case of passport >copies, etc, very much subject to the DPD; in case of registration >documents, these are (usually) public information Registration documents for RIPE resources??? They are??? Where can I view those please? TIFFs will be fine, but PDFs will work for me too. (Many U.S. State level authorities do make available, via their web sites, actual TIFF images of original corporate registration documents. If RIPE is doing, or can do likewise, for resource registrants, I believe that might be most helpful, i.e. to the ongoing fight against network abuse.) >there may be a >copyright issue though as many authorities make these available, but >not for free. I am willing to pay any price, bear any burden, etc., etc. >In any case, I'm sure I'm not the only member whose idea of what we pay >the NCC for is to be a resource registry, *not* an intelligence >repository In order to insure the viability and success of the former mission, it may occasionally be helpful to also serve the latter one as well. If there are people out there... and there are... who are stealing other people's identities and/or number resources, does it not seem wise to gather as much data about those miscreants as possible, in order to protect the community from their misdeeds in the future? To be clear, I _do not_ want to bug their homes and/or offices, but anything that _corporations_ have _voluntarily_ given to RIPE should be fair game, and a matter of public record, I think. Regards, rfg P.S. While I do think that EU data protection regulation goes rather too far, I do nontheless admire and applaud you folks in the EU for having the wisdom and good common sense to at least recognize the clear and overwhelming distinction between living, breathing people and corporations. Now, if only you Europeans could somehow find a way to impart that same simple understanding to our United States Supreme Court, quite a lot of people over here would be in your eternal debt for that. From rfg at tristatelogic.com Wed Nov 5 12:19:52 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 05 Nov 2014 03:19:52 -0800 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: Message-ID: <77224.1415186392@server1.tristatelogic.com> In message Suresh Ramasubramanian wrote: >On Wed, Nov 5, 2014 at 3:53 PM, Wilfried W=C3=B6ber > wrote: >> Anyone believing that those parties which can expect to become the target >> of Ronald-Style investigations would consent and supply the info? >> >> This is barking up the wrong tree (again). > >No. But sometimes even faked whois can tell an interesting story. And has indeed done so, time and time again, in my own personal experience. Regards, rfg P.S. As those of you who have seen the Ben Affleck movie "The Town" already know, if you see someone dressed as a nun, wearing a Haloween mask, heading into your local bank, be afraid. Be very afraid. From rfg at tristatelogic.com Wed Nov 5 13:00:42 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 05 Nov 2014 04:00:42 -0800 Subject: [anti-abuse-wg] EU Data Protection In-Reply-To: Message-ID: <77457.1415188842@server1.tristatelogic.com> In message Suresh Ramasubramanian wrote: >History, especially operational history, is out there for people to >actually learn from it, not trot out stale tropes about Internet police and >the stasi. I thank Suresh for coming to my defense, if that is what he intended. But for the record let me also say that I am not at all offended, in the present context, to be equated to the hated Stasi of old. I recognize that there is a difficult balance between security on the one hand and privacy on the other, and that one man's defender of the public good is another man's loathsome Stasi agent, and vise versa. In fact, I'm more of a privacy advocate that some here might expect, and was myself greatly amused upon seeing on TV scenes of European protesters carrying satirical posters of Barack Obama with headphones, clearly reminicent of the old Stasi listeners. (He richly deserved that, I think. And I say that as somebody who voted for the guy... twice.) To be clear, I detest what our NSA has done, both to us here in the US and also to the rest of the world. I believe it to be immoral, illegal, and downright criminal. The hair stands up on the back of my neck, and I get up on my hind legs and start screaming whenever someone reminds me that my own tax dollars have been used to collect the SMTP metadata for each e-mail I send... e-mails for which I believe I have... or had, anyway... a reasonable expectation of privacy, at least until Mr. Snowden came along and helpfully diabused me of that notion. I do however draw a distinction... as it seems you Europeans do... between gathering intelligence about individual natural persons for whom there is -zero- basis for any clearly articulatable suspicion, and gathering intelligence about relationships between -corporations- and more specifically about ones for which there _is_ a clearly articulatable basis for suspicion. Also and separately, I believe that there should be complete transparancy in the operations of, and relationships with any and all `public interest'' organizations, and I personally would categorize RIPE, and all other RiRs, under that banner, even if a majority of the dues paying members would prefer it to be viewed strictly as a private commercial consortium, with no external or public responsibilities whatsoever. Regards, rfg From lists-ripe at c4inet.net Wed Nov 5 13:23:01 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 5 Nov 2014 12:23:01 +0000 Subject: [anti-abuse-wg] EU Data Protection In-Reply-To: <77093.1415185395@server1.tristatelogic.com> References: <20141105101221.GC58573@cilantro.c4inet.net> <77093.1415185395@server1.tristatelogic.com> Message-ID: <20141105122301.GA58004@cilantro.c4inet.net> On Wed, Nov 05, 2014 at 03:03:15AM -0800, Ronald F. Guilmette wrote: >Thereafter, it is up to the registrant to maintain the relevant WHOIS >data, and all registrants are pledged to, and expected to do so in >a way that causes the WHOIS data to always be accurate. But I did >not get any clear sense that RIPE NCC would always and in all cases >vet, or re-vet changes made by a registrant to a WHOIS record, post- >allocation... and perhaps they routinely do not do so. This would I don't think so. However, the "organisation:" object is maintained by the NCC and they will revert changes that don't agree with the documentation they have. (Actually has happened to me) >leave open the door to deliberately malicious registrants who might >provide all correct contact information initially, and then, a week >or a month later, go in and scramble their WHOIS to make it point >to something/someone entirely fictitious. Not possible AFAIK. You can put anything you want in role: and person: objects but the organisation: object is under NCC control. (and if you put fictional info in the objects that refers, you can be sanctioned up to de-registration of resources and closure if a LIR. (cf MoU and service terms) >Registration documents for RIPE resources??? They are??? Where can I >view those please? For corporations: At the appropriate national registrar-of-companies. Usually from their website, depends on the country though. The NCC requires those for the registration of independent resources (cf ripe-556) but I don't know whether they even keep them after checking. For natural persons I think you are out of luck. >>In any case, I'm sure I'm not the only member whose idea of what we pay >>the NCC for is to be a resource registry, *not* an intelligence >>repository > >To be clear, I _do not_ want to bug their homes and/or offices, but >anything that _corporations_ have _voluntarily_ given to RIPE should >be fair game, and a matter of public record, I think. This information is not voluntary and given to the NCC on the understanding that it is confidential and used only to verify that a resource holder exists, be it a natural or legal person. It is certainly not "fair game". rgds, Sascha Luck From lists-ripe at c4inet.net Wed Nov 5 13:32:01 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 5 Nov 2014 12:32:01 +0000 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <20141105102308.GC26368@spin.it> References: <5459613B.6010604@iszt.hu> <73461.1415147833@server1.tristatelogic.com> <20141105063836.GB58573@cilantro.c4inet.net> <20141105100634.GA26368@spin.it> <20141105101442.GD58573@cilantro.c4inet.net> <20141105102308.GC26368@spin.it> Message-ID: <20141105123200.GB58004@cilantro.c4inet.net> On Wed, Nov 05, 2014 at 11:23:08AM +0100, furio ercolessi wrote: >> Not while this member pays membership fees. > >I do not see how your membership status can affect the ability of >people to discuss abuse-related topics in this working group. Apologies, this was supposed to be in reply to the post that wanted a policy proposal for this. Of course you can discuss anything you want. rgds, Sascha Luck From ops.lists at gmail.com Wed Nov 5 13:35:12 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 5 Nov 2014 18:05:12 +0530 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <20141105123200.GB58004@cilantro.c4inet.net> References: <5459613B.6010604@iszt.hu> <73461.1415147833@server1.tristatelogic.com> <20141105063836.GB58573@cilantro.c4inet.net> <20141105100634.GA26368@spin.it> <20141105101442.GD58573@cilantro.c4inet.net> <20141105102308.GC26368@spin.it> <20141105123200.GB58004@cilantro.c4inet.net> Message-ID: On Wed, Nov 5, 2014 at 6:02 PM, Sascha Luck wrote: > Apologies, this was supposed to be in reply to the post that > wanted a policy proposal for this. Of course you can discuss anything you > want. Sure. That includes policy proposals that furio may or may not propose. You are of course free to vote against it if you like. -- Suresh Ramasubramanian (ops.lists at gmail.com) From lists-ripe at c4inet.net Wed Nov 5 15:32:14 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 5 Nov 2014 14:32:14 +0000 Subject: [anti-abuse-wg] EU Data Protection In-Reply-To: <77457.1415188842@server1.tristatelogic.com> References: <77457.1415188842@server1.tristatelogic.com> Message-ID: <20141105143214.GC58004@cilantro.c4inet.net> On Wed, Nov 05, 2014 at 04:00:42AM -0800, Ronald F. Guilmette wrote: >I do however draw a distinction... as it seems you Europeans do... >between gathering intelligence about individual natural persons for >whom there is -zero- basis for any clearly articulatable suspicion, >and gathering intelligence about relationships between -corporations- >and more specifically about ones for which there _is_ a clearly >articulatable basis for suspicion. Also and separately, I believe >that there should be complete transparancy in the operations of, >and relationships with any and all `public interest'' organizations, >and I personally would categorize RIPE, and all other RiRs, under >that banner, even if a majority of the dues paying members would >prefer it to be viewed strictly as a private commercial consortium, >with no external or public responsibilities whatsoever. I think this is a fundamental (if very common) misunderstanding that often happens with people from the US. For personal data: in the US, data belongs to whomever holds it. in the EU at least, data belongs to the subject of this data regardless of who holds it. And the owner of the data still determines how it is used (usually by agreement to T&C, outside of which propagation is forbidden). I've asked my lawyer and he is of the opinion that this does *not* apply to data regarding corporations. So, in theory, the NCC could publish the company registration number in whois, for what *that* is worth (it's public information anyway in most countries) rgds, Sascha Luck From gert at space.net Wed Nov 5 15:45:41 2014 From: gert at space.net (Gert Doering) Date: Wed, 5 Nov 2014 15:45:41 +0100 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <74505.1415157154@server1.tristatelogic.com> References: <74505.1415157154@server1.tristatelogic.com> Message-ID: <20141105144541.GX31092@Space.Net> Hi, On Tue, Nov 04, 2014 at 07:12:34PM -0800, Ronald F. Guilmette wrote: > bits of unarguably useful information (which apparently aren't available > to mere mortals... I am guessing by design, since it wouldn't exactly be > rocket surgery to add them into the WHOIS responses). All of this (both publication of the sponsoring LIR and the creation and modification date of an object) is being worked on as we speak. Changing the output of the RIPE DB not something being done lightly as people's programs use that information and might be upset if new fields appear - so there's an implementation plan, timeline, advance warning, and so on. What already appeared is the historical information "which version of this object exist in the database, when has it been changed, and what is the difference between version X and Y". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From brian.nisbet at heanet.ie Wed Nov 5 17:15:49 2014 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Wed, 05 Nov 2014 16:15:49 +0000 Subject: [anti-abuse-wg] Revised Minutes, RIPE 68 Message-ID: <545A4D35.6000809@heanet.ie> Colleagues, It was pointed out in the meeting today that there were mistakes with the previous minutes and we've discovered that an important section or two were missing. Below I have pasted the new version of the RIPE 68 minutes, including the conversation about LEA attendance at RIPE related meetings (Section D.3). If you could take a look at these that would be great. Also, if I could ask the NCC to look at the possibilities around the action that was assigned to them in that section. Thanks, Brian *********************************** === A. Administrative Matters Brian welcomed the participants to the Working Group session and introduced himself and Tobias as co-chairs. and thanked the RIPE NCC for providing support in the form of chat monitor, scribe and stenographers. The minutes from RIPE 67 and RIPE 66 were approved and there were no additions to the agenda. B. Update Brian asked the room if there was anything pertaining "abuse-c:" that needed to be raised. As nobody spoke up, Brian stated that it could be covered later on if needed. Brian mentioned that he had circulated some text for the working group charter. He noted that there had been some discussion but was happy to keep any discussion on the list. He invited the room to make any comments there and then if needed. There were no comments. Brian urged the participants to read the charter on the mailing list. C. Policies Brian stated that there were no open policies at the moment. D1. Interactions With Other Working Groups Regarding interactions with other working groups on policy, Brian noted that he and Tobias had agreed with Nigel Titley and Wilfried Wober, the Database Working Group Chairs, that he and Tobias would work on the data verification policy. He mentioned that he and Tobias would not have time for this soon, and therefore urged participants that, should they want to take on the task, they were welcome. D2. Proof of identity discussions ? RIPE Policy Proposal 2007-01 There was some discussion about the level of proof of identity that the RIPE NCC should expect. Athina Fragkouli, RIPE NCC, stated that this was also discussed in the Address Policy Working Group and there were not many concerns about how the RIPE NCC handles proof of identity. She added that the RIPE NCC is always open to changing procedures. Brian asked the room whether the RIPE NCC are doing enough, too little, or to much regarding proof of identity. He asked if there should be more trust. Jim Reid, unaffiliated, felt that things should be left as they are. He expressed that he thought it was bad to collect personal data unless there is a strong need for the data. However, he can appreciate the RIPE NCC's point and can see how it's useful in some cases, such as for law enforcement and other aspects of anti-abuse. Brian agreed that it's okay for the RIPE NCC to continue as it is. D3. RIPE NCC Government/LEA Interactions Update -Marco Hogewoning, RIPE NCC The presentation is available online: https://ripe68.ripe.net/presentations/387-AA-LEA-Update-MH1_AG.pdf Alexander Isavnin, NetLine, asked if it was possible for a Dutch membership organisation to join closed meetings and not reveal what was discussed. Marco responded that he thought it was possible. Alexander stated that the community wants to know what happens at these meetings and urged for no secrecy. He wanted to know the name, rank, and position of those attending these meetings with law enforcement. Marco stressed that these meetings are with law enforcement agencies (LEAs), not with the intelligence community. Alexander responded that name, rank and position will support that the attendees are not from the intelligence community. Marco responded that the RIPE NCC is looking at a way to improve the reporting but needs to work with LEAs about the information that can be published. He added that it may be possible to publish attendee lists and or give more information about the attendees, however, it's important that the trust level is maintained between the LEAs and the RIPE NCC. Alexander responded that he wants European interaction to be more clear. Jochem De Ruig, RIPE NCC, stated that Brian Nisbet is invited to these meetings so that he can provide input from the community's perspective. Brian added that he has been asked by someone from the National Crime Agency (NCA) to remove their name from a public agenda as their friends and family did not know with whom they were employed. Brian felt that there would not be much cooperation if a full list of attendees was to be published. Malcolm Hutty, LINX, added that it's about balance and satisfying all parties reasonably. With some advance planning, he feels that basic information could be disclosed and some transparency added. He added that it would be best to avoid mentioning whether anything operational was discussed (or not). He also noted that some individuals would probably need their names kept secret and off lists, and therefore it may make sense to ask them if the name of their organisation could be published. Brian agreed that he fully advocates transparency and agreed with the need for balance. Jim Reid agreed with Malcolm, and urged for more forward planning. He also added that he felt it would be wrong to disclose the name, rank and identity of everybody attending a meeting because that, in itself, could disclose operational details. Marco concluded that that he will take this back to law enforcement and work with them on future events to achieve better reporting. E1. "Anti-Abuse: The View from the Messaging World" -Jerome Cudelou, M3AAWG The presentation is available online: https://ripe68.ripe.net/presentations/373-M3AAWG.pdf Brian asked whether there are any more areas of mutual engagement that could be touched upon. Jerome responded that it would be best to become members of M3AAWG. Brian asked whether non-members of M3AAWG could contribute to M3AAWG?s documentation. Jerome responded that he didn?t think it was easy to do and that it is better to become a member. R?diger Volk, Deutsche Telekom, asked if there were documents that would explain what is expected of an abuse contact. Jerome responded that the document is under discussion. Vincent Schonau, abuseix and co-chair of the Training Committee at M3AAWG, further clarified that there is the Abuse Desk Best Practises document that is now a few years old. He added that the Abuse Desk Special Interest Group has revived the document and would work on it in upcoming meetings. Alex de Joode, LeaseWeb, stated that LeaseWeb is not a member of M3AAWG but are participating in the Hosting Special Interest Group (SIG) and the Abuse SIG so participation is possible without becoming a member. Brian asked Alex what the procedure was for participation. Alex responded that he had sent a message to Gerry Upton and received a free invitation. Samaneh Tajalizadehkhoob, Delft University of Technology, asked if M3AAWG cooperate with research institutions. She mentioned that Delft University of Technology are working on banking malware and mobile malware, and asked if M3AAWG share data with them. Jerome responded that they do share data with research institutions. Vincent noted that M3AAWG has a very open policy about inviting people to come to the European meetings and the emerging groups such as the Hosting SIG. He directed interested parties to Gerry, Jerome or himself for an invitation. Brian asked an open question to RIPE NCC members in the room whether there had been any interaction with M3AAWG since RIPE 45 in Barcelona. Jochem de Ruig, RIPE NCC, responded that the RIPE NCC would try to come to Brussels and that the RIPE NCC did find the meeting useful for engagement with the community. E2: Impact of abuse-c -Bengt G?rd?n, Resilans The presentation is available online: https://ripe68.ripe.net/presentations/383-impact_abuse-c.pdf Ruediger asked whether the message to the abuse-c at Spamhaus was successful. Bengt replied that it was not, and asked if there were questions about that. Ruediger continued, adding that Spamhaus is bullying people on the Internet and that a joke he had heard is that it may be possible to send a claim of copyright or trademark infringement with the name Spamhaus and send it to .org. Bengt added that it would work. Ruediger added that the Internet community needs to make sure that things are balanced out, thanking Bengt for his presentation. Erik Bais, ATB Internet, added that they had been in the same situation with Spamhaus and it had been well-documented. Bengt responded that he had read about it. Erik continued that they had disclosed fully about their interactions with Spamhaus, who had behaved brazenly in return, finding the situation amusing and even blogging about it on their website. Erik added that Spamhaus do not care and that they have been invited to the RIPE Anti-Abuse Working Group sessions, to have a panel and discuss the proper policies, but had refused the invitation. Brian added that that the relations between the Working Group and Spamhaus were not as good as they would like, and redirected the discussion back to ?abuse-c:?. Erik stated that they transferred some of their address blocks and even after six months they still receive emails to their abuse mailbox regarding blocks that they don?t own anymore. He called for people to use the RIPE Database and asked how it is possible to make people update their information. Bengt replied that he feels the community needs to work on this issue collectively, but not necessarily in a way that results in any legislation or policy. Erik added that it?s good to remember that Spamhaus does not block mail and there is always a need for well-managed block lists. Peter Koch, DENIC, asked Bengt about his slides as they seemed somewhat contradictory to him, as they looked more like a ?suffering story? rather than a success story and he did not understand why it was being used as an example, as Bengt?s ?I told you so.? Bengt responded that maybe it is time that they give up on optimising the ?abuse-c:? for an audience that cannot be educated. Brian invited Tobias Knecht, his fellow chair of the Anti-Abuse Working Group to comment on similar policies in other regions. Tobias stated that the policy about ?abuse-c:? was brought into APNIC in a different way, as well as at AFRINIC. While the implementations were different, the end result was the same - that there is an abuse contact in the Whois Database, a single space. Bengt noted that he had tried to get an abuse contact for Spamhaus and it hadn?t worked. Alex Le Heux, Kobo Inc, added that they had similar experiences with many of those blacklists. He stated that Spamhaus regularly attends M3AAWG and advised those who wanted to meet with them, to go to the Brussels meeting. He invited those with similar experiences to come to the meeting so that some sort of best practises for blacklists can be set up. Brian confirmed that a best practises document that has come out of M3AAWG already exists. E3: Abuse-c: Next Steps for ?abuse-c:? -Denis Walker and Christian Teuschel, RIPE NCC The presentation is available online: https://ripe68.ripe.net/presentations/162-aa_wg.pdf Brian noted that time was running short, and some discussion may need to be directed to the mailing list. Ruediger asked if it was explained anywhere how ORGANISATION objects should be used. Denis responded that it was one of the big problems with the RIPE Database. Ruediger noted that there is no documentation and explanation of the data model that the RIPE NCC says that the community should be following. Denis replied, saying that no business rules were built into the software to enforce any of this, and agreeing that there are no guidelines. Ruediger argued that, if there is a data architecture that should be followed, it should be documented and agreed upon. He called for a document that explains what the architecture is. Brian asked whether this discussion would be something better suited to the Database Working Group. Peter thanked Denis and Christian for their hard work. He noted that the RIPE Policy Development Process allows early and often objections and he believes that they are at risk of going completely overboard in a variety of aspects. He stated that he thinks that the model is in the wrong direction, and he is opposed to ?salami tactics?. His interpretation of one of the slides is that there is an ORG object and the addresses hang off it, and he cannot find any document that describes it that way. The database model with which he is familiar is one built around the objects you ask for, and the information attached to the objects, in other objects. He called for changes to the model. He added that if this were moved to the Database Working Group, that would only partly help as the changes proposed from the Anti-Abuse Working Group may not be compatible with the Database Working Group point of view. Brian clarified that, if there were issues with the architecture and business rules and documentation, then it would be more appropriate for the Database Working Group to work with the RIPE NCC to get that written. Peter stated that it may be time to reconfirm the mission of the RIPE Database, adding that it should not become a ?compliance stick? for Local Internet Registries or resource holders. Christian asked Peter what he had meant by ?salami tactic? regarding the validation. Peter clarified that having a mailbox does not mean that mail is delivered or read. The next slice of salami is to validate, so that mail can be expected to be deliverable. He envisioned that, three months later, it won?t only be deliverable, but there would be a reply. Christian replied that this is what they had proposed, improving the data quality. Peter added that caution would need to be taken when regarding data quality as it is a topic for the admin-c and the resource holder. He believes that the data should be correct because that is the core mission. Via remote participation, Gilles Massen asked if, as the existing IRT objects are becoming more invisible, would it be possible to reference an IRT from the ?abuse-c:? or at least add the useful IRT features like BGP keys to the ?abuse-c:?. He stated that he would like to see relaxed constraints like a copyright-abuse-mailbox: NULL for signalling that one should not expect a reply to those sorts of messages. He also asked that IRT objects not be touched without prior discussion in the Working Group. Denis responded that the RIPE NCC understands that the IRT object is not very popular and that they have been asked to propose to the community as to how the IRT could be made more useful. He will provide feedback to the Working Group for further review. Piotr Strzy?ewski, Silesian University of Technology, referred to Bengt's presentation, noting that some of these corporations don't care about the "abuse-c:" and therefore it wouldn't be useful to establish another point of contact for them. He sarcastically added that he ?loves" the idea of national responsibility (with the opposite being his true feelings on the matter). However, he does feel that there should be some policy regarding validation. Christian responded that he thinks validation and extending the ROLE object should go through the RIPE Policy Development Process. Brian stated that he thinks it must go through that process. Christian continued, stating that extending the ROLE object is something that has come from the community. While he acknowledges that some countries have more than one national CSIRT, the implementation needs to be clear and the list of contact details for all of them should be provided. He added that the RIPE NCC is trying to work with them, in the case that the ?abuse-c:? fails. Brian asked about the origin of the request from the community. Christian replied that it hadn?t come from the mailing list, and had come from a meeting of the computer security community. Kaveh Ranjbar, RIPE NCC, added that the provision of a proper abuse contact was a recurring point in the RIPE NCC Survey 2013?s results and therefore the RIPE NCC had started to attend security conferences. Ruediger asked Christian if the CSIRTS were happy about getting the reports, or if they were unhappy. Christian replied that they were happy. Ruediger expressed doubt and surprise that they would be happy to be ?flooded? by copyright abuse reports. He called for guidelines and information as to what kind of report people should be sending to abuse contact, and how people should be responding to these reports. Denis added that, if Ruediger wants the RIPE NCC to provide these guidelines, then the community should provide the text. Ruediger agreed with Denis that this is a task for the Working Group. Brian added that he was surprised that the CSIRTS were happy, and noted that many countries don?t have a CSIRT. He added that he would put out a call for volunteers to help work on the guidelines. Ruediger added that, without guidelines, doing validation beyond mechanics is meaningless. E4: Introduction to Contact Databases for Abuse Handling -Aaron Kaplan, nic.at Aaron explained how they do contact lookups at csirt.at, a national CSIRT for Austria. He noted that a national CSIRT is usually just a router for abuse contact information and that there are different approaches in different countries. Aaron asked those involved with the RIPE Database to have IRT objects, ?abuse-c?, etc. as specific and up-to-date as possible as it will help those sending information to national CSIRTS for lookups. Brian asked where the information about Aaron?s presentation would be available and if he could publish it to the list. Aaron added that it is a document on Github. Brian asked if he could email the list with the URL. Aaron replied that it is part of a document that Christian Teuschel and Mirjam Keuhne, RIPE NCC, and Wilfried Woeber started. It is connected to a GitHub project called GitHub.com/CERTtools that is a contact cache/contact database for national CSIRTs so that they can build on the process. Brian added that it might be good to discuss this in more depth at a future RIPE Meeting. Aaron stated again that the CSIRT is just acting as a router, passing copyrights through, and the copyrights end up with network owners under their policies. However, he noted that the routing process can be optimised. There were no further questions or comments. Brian thanked Aaron for his presentation and invited the room to contribute agenda items for RIPE 69 in London. He thanked the scribe, speakers, stenographers and participants before closing the session. From lists-ripe at c4inet.net Wed Nov 5 17:20:30 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 5 Nov 2014 16:20:30 +0000 Subject: [anti-abuse-wg] EU Data Protection In-Reply-To: <77093.1415185395@server1.tristatelogic.com> References: <20141105101221.GC58573@cilantro.c4inet.net> <77093.1415185395@server1.tristatelogic.com> Message-ID: <20141105162030.GA58817@cilantro.c4inet.net> On Wed, Nov 05, 2014 at 03:03:15AM -0800, Ronald F. Guilmette +wrote: >> I personally think that publishing "person" objects does +indeed break the >> law, NCC Legal clearly disagrees. > > It would seem so, and may God bless them for that. Actually, this is something I'd like to hear the "official" answer to, so let's ask the NCC: Having looked at some resources registered in the ripedb to natural persons and having found that the organisation: objects contain information such as full names, addresses and phone numbers, Assuming that this information is *required* to be there in order to be assigned independent resources, how does the uncontrolled publishing of that data possibly comply with the EU Data Protection Directive and imminent General Data Protection Regulation, especially considering the entirely uncontrolled transfer of such data to non-EU countries (whois lookups!)? IANAL, but to me it looks like a breach of said regulations. rgds, Sascha Luck From ops.lists at gmail.com Wed Nov 5 18:02:34 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 05 Nov 2014 17:02:34 +0000 Subject: [anti-abuse-wg] Revised Minutes, RIPE 68 References: <545A4D35.6000809@heanet.ie> Message-ID: So, curious. How many colleagues from ripe aa wg were at MAAWG brussels or the subsequent Boston meeting last month? Were you able to talk to spamhaus there? On Wed, 5 Nov 2014 at 21:46 Brian Nisbet wrote: > Colleagues, > > It was pointed out in the meeting today that there were mistakes with > the previous minutes and we've discovered that an important section or > two were missing. Below I have pasted the new version of the RIPE 68 > minutes, including the conversation about LEA attendance at RIPE related > meetings (Section D.3). If you could take a look at these that would be > great. > > Also, if I could ask the NCC to look at the possibilities around the > action that was assigned to them in that section. > > Thanks, > > Brian > > *********************************** > > === > > A. Administrative Matters > > Brian welcomed the participants to the Working Group session and > introduced himself and Tobias as co-chairs. and thanked the RIPE NCC for > providing support in the form of chat monitor, scribe and > stenographers. The minutes from RIPE 67 and RIPE 66 were approved and > there were no additions to the agenda. > > B. Update > > Brian asked the room if there was anything pertaining "abuse-c:" that > needed to be raised. As nobody spoke up, Brian stated that it could be > covered later on if needed. Brian mentioned that he had circulated some > text for the working group charter. He noted that there had been some > discussion but was happy to keep any discussion on the list. He invited > the room to make any comments there and then if needed. There were no > comments. Brian urged the participants to read the charter on the > mailing list. > > C. Policies > > Brian stated that there were no open policies at the moment. > > D1. Interactions With Other Working Groups > > Regarding interactions with other working groups on policy, Brian noted > that he and Tobias had agreed with Nigel Titley and Wilfried Wober, the > Database Working Group Chairs, that he and Tobias would work on the data > verification policy. He mentioned that he and Tobias would not have time > for this soon, and therefore urged participants that, should they want > to take on the task, they were welcome. > > D2. Proof of identity discussions ? RIPE Policy Proposal 2007-01 > > There was some discussion about the level of proof of identity that the > RIPE NCC should expect. Athina Fragkouli, RIPE NCC, stated that this > was also discussed in the Address Policy Working Group and there were > not many concerns about how the RIPE NCC handles proof of identity. She > added that the RIPE NCC is always open to changing procedures. Brian > asked the room whether the RIPE NCC are doing enough, too little, or to > much regarding proof of identity. He asked if there should be more > trust. Jim Reid, unaffiliated, felt that things should be left as they > are. He expressed that he thought it was bad to collect personal data > unless there is a strong need for the data. However, he can appreciate > the RIPE NCC's point and can see how it's useful in some cases, such as > for law enforcement and other aspects of anti-abuse. > Brian agreed that it's okay for the RIPE NCC to continue as it is. > > D3. RIPE NCC Government/LEA Interactions Update > -Marco Hogewoning, RIPE NCC > > The presentation is available online: > https://ripe68.ripe.net/presentations/387-AA-LEA-Update-MH1_AG.pdf > > Alexander Isavnin, NetLine, asked if it was possible for a Dutch > membership organisation to join closed meetings and not reveal what was > discussed. > > Marco responded that he thought it was possible. > > Alexander stated that the community wants to know what happens at these > meetings and urged for no secrecy. He wanted to know the name, rank, and > position of those attending these meetings with law enforcement. > > Marco stressed that these meetings are with law enforcement agencies > (LEAs), not with the intelligence community. > > Alexander responded that name, rank and position will support that the > attendees are not from the intelligence community. > > Marco responded that the RIPE NCC is looking at a way to improve the > reporting but needs to work with LEAs about the information that can be > published. He added that it may be possible to publish attendee lists > and or give more information about the attendees, however, it's > important that the trust level is maintained between the LEAs and the > RIPE NCC. > > Alexander responded that he wants European interaction to be more clear. > > Jochem De Ruig, RIPE NCC, stated that Brian Nisbet is invited to these > meetings so that he can provide input from the community's perspective. > > Brian added that he has been asked by someone from the National Crime > Agency (NCA) to remove their name from a public agenda as their friends > and family did not know with whom they were employed. Brian felt that > there would not be much cooperation if a full list of attendees was to > be published. > > Malcolm Hutty, LINX, added that it's about balance and satisfying all > parties reasonably. With some advance planning, he feels that basic > information could be disclosed and some transparency added. He added > that it would be best to avoid mentioning whether anything operational > was discussed (or not). He also noted that some individuals would > probably need their names kept secret and off lists, and therefore it > may make sense to ask them if the name of their organisation could be > published. > > Brian agreed that he fully advocates transparency and agreed with the > need for balance. > > Jim Reid agreed with Malcolm, and urged for more forward planning. He > also added that he felt it would be wrong to disclose the name, rank and > identity of everybody attending a meeting because that, in itself, could > disclose operational details. > > Marco concluded that that he will take this back to law enforcement and > work with them on future events to achieve better reporting. > > E1. "Anti-Abuse: The View from the Messaging World" > -Jerome Cudelou, M3AAWG > > The presentation is available > online: https://ripe68.ripe.net/presentations/373-M3AAWG.pdf Brian > asked whether there are any more areas of mutual engagement that could > be touched upon. Jerome responded that it would be best to become > members of M3AAWG. Brian asked whether non-members of M3AAWG could > contribute to M3AAWG?s documentation. Jerome responded that he didn?t > think it was easy to do and that it is better to become a > member. R?diger Volk, Deutsche Telekom, asked if there were documents > that would explain what is expected of an abuse contact. Jerome > responded that the document is under discussion. Vincent Schonau, > abuseix and co-chair of the Training Committee at M3AAWG, further > clarified that there is the Abuse Desk Best Practises document that is > now a few years old. He added that the Abuse Desk Special Interest > Group has revived the document and would work on it in upcoming > meetings. Alex de Joode, LeaseWeb, stated that LeaseWeb is not a member > of M3AAWG but are participating in the Hosting Special Interest Group > (SIG) and the Abuse SIG so participation is possible without becoming a > member. Brian asked Alex what the procedure was for > participation. Alex responded that he had sent a message to Gerry Upton > and received a free invitation. Samaneh Tajalizadehkhoob, Delft > University of Technology, asked if M3AAWG cooperate with research > institutions. She mentioned that Delft University of Technology are > working on banking malware and mobile malware, and asked if M3AAWG share > data with them. Jerome responded that they do share data with research > institutions. Vincent noted that M3AAWG has a very open policy about > inviting people to come to the European meetings and the emerging groups > such as the Hosting SIG. He directed interested parties to Gerry, Jerome > or himself for an invitation. Brian asked an open question to RIPE NCC > members in the room whether there had been any interaction with M3AAWG > since RIPE 45 in Barcelona. Jochem de Ruig, RIPE NCC, responded that > the RIPE NCC would try to come to Brussels and that the RIPE NCC did > find the meeting useful for engagement with the community. > > E2: Impact of abuse-c > > -Bengt G?rd?n, Resilans The presentation is available > online: https://ripe68.ripe.net/presentations/383-impact_abuse-c.pdf > Ruediger > asked whether the message to the abuse-c at Spamhaus was > successful. Bengt replied that it was not, and asked if there were > questions about that. Ruediger continued, adding that Spamhaus is > bullying people on the Internet and that a joke he had heard is that it > may be possible to send a claim of copyright or trademark infringement > with the name Spamhaus and send it to .org. Bengt added that it would > work. Ruediger added that the Internet community needs to make sure > that things are balanced out, thanking Bengt for his presentation. Erik > Bais, ATB Internet, added that they had been in the same situation with > Spamhaus and it had been well-documented. Bengt responded that he had > read about it. Erik continued that they had disclosed fully about their > interactions with Spamhaus, who had behaved brazenly in return, finding > the situation amusing and even blogging about it on their website. Erik > added that Spamhaus do not care and that they have been invited to the > RIPE Anti-Abuse Working Group sessions, to have a panel and discuss the > proper policies, but had refused the invitation. Brian added that that > the relations between the Working Group and Spamhaus were not as good as > they would like, and redirected the discussion back to ?abuse-c:?. Erik > stated that they transferred some of their address blocks and even after > six months they still receive emails to their abuse mailbox regarding > blocks that they don?t own anymore. He called for people to use the RIPE > Database and asked how it is possible to make people update their > information. Bengt replied that he feels the community needs to work on > this issue collectively, but not necessarily in a way that results in > any legislation or policy. Erik added that it?s good to remember that > Spamhaus does not block mail and there is always a need for well-managed > block lists. Peter Koch, DENIC, asked Bengt about his slides as they > seemed somewhat contradictory to him, as they looked more like a > ?suffering story? rather than a success story and he did not understand > why it was being used as an example, as Bengt?s ?I told you so.? Bengt > responded that maybe it is time that they give up on optimising the > ?abuse-c:? for an audience that cannot be educated. Brian invited > Tobias Knecht, his fellow chair of the Anti-Abuse Working Group to > comment on similar policies in other regions. Tobias stated that the > policy about ?abuse-c:? was brought into APNIC in a different way, as > well as at AFRINIC. While the implementations were different, the end > result was the same - that there is an abuse contact in the Whois > Database, a single space. Bengt noted that he had tried to get an abuse > contact for Spamhaus and it hadn?t worked. Alex Le Heux, Kobo Inc, > added that they had similar experiences with many of those blacklists. > He stated that Spamhaus regularly attends M3AAWG and advised those who > wanted to meet with them, to go to the Brussels meeting. He invited > those with similar experiences to come to the meeting so that some sort > of best practises for blacklists can be set up. Brian confirmed that a > best practises document that has come out of M3AAWG already exists. > > E3: Abuse-c: Next Steps for ?abuse-c:? > -Denis Walker and Christian Teuschel, RIPE NCC The presentation is > available > online: https://ripe68.ripe.net/presentations/162-aa_wg.pdf Brian noted > that time was running short, and some discussion may need to be directed > to the mailing list. Ruediger asked if it was explained anywhere how > ORGANISATION objects should be used. Denis responded that it was one of > the big problems with the RIPE Database. Ruediger noted that there is > no documentation and explanation of the data model that the RIPE NCC > says that the community should be following. Denis replied, saying that > no business rules were built into the software to enforce any of this, > and agreeing that there are no guidelines. Ruediger argued that, if > there is a data architecture that should be followed, it should be > documented and agreed upon. He called for a document that explains what > the architecture is. Brian asked whether this discussion would be > something better suited to the Database Working Group. Peter thanked > Denis and Christian for their hard work. He noted that the RIPE Policy > Development Process allows early and often objections and he believes > that they are at risk of going completely overboard in a variety of > aspects. He stated that he thinks that the model is in the wrong > direction, and he is opposed to ?salami tactics?. His interpretation of > one of the slides is that there is an ORG object and the addresses hang > off it, and he cannot find any document that describes it that way. The > database model with which he is familiar is one built around the objects > you ask for, and the information attached to the objects, in other > objects. He called for changes to the model. He added that if this were > moved to the Database Working Group, that would only partly help as the > changes proposed from the Anti-Abuse Working Group may not be compatible > with the Database Working Group point of view. Brian clarified that, if > there were issues with the architecture and business rules and > documentation, then it would be more appropriate for the Database > Working Group to work with the RIPE NCC to get that written. Peter > stated that it may be time to reconfirm the mission of the RIPE > Database, adding that it should not become a ?compliance stick? for > Local Internet Registries or resource holders. Christian asked Peter > what he had meant by ?salami tactic? regarding the validation. Peter > clarified that having a mailbox does not mean that mail is delivered or > read. The next slice of salami is to validate, so that mail can be > expected to be deliverable. He envisioned that, three months later, it > won?t only be deliverable, but there would be a reply. Christian > replied that this is what they had proposed, improving the data > quality. Peter added that caution would need to be taken when regarding > data quality as it is a topic for the admin-c and the resource holder. > He believes that the data should be correct because that is the core > mission. Via remote participation, Gilles Massen asked if, as the > existing IRT objects are becoming more invisible, would it be possible > to reference an IRT from the ?abuse-c:? or at least add the useful IRT > features like BGP keys to the ?abuse-c:?. He stated that he would like > to see relaxed constraints like a copyright-abuse-mailbox: NULL for > signalling that one should not expect a reply to those sorts of > messages. He also asked that IRT objects not be touched without prior > discussion in the Working Group. Denis responded that the RIPE NCC > understands that the IRT object is not very popular and that they have > been asked to propose to the community as to how the IRT could be made > more useful. He will provide feedback to the Working Group for further > review. Piotr Strzy?ewski, Silesian University of Technology, referred > to Bengt's presentation, noting that some of these corporations don't > care about the "abuse-c:" and therefore it wouldn't be useful to > establish another point of contact for them. He sarcastically added that > he ?loves" the idea of national responsibility (with the opposite being > his true feelings on the matter). However, he does feel that there > should be some policy regarding validation. Christian responded that he > thinks validation and extending the ROLE object should go through the > RIPE Policy Development Process. Brian stated that he thinks it must go > through that process. Christian continued, stating that extending the > ROLE object is something that has come from the community. While he > acknowledges that some countries have more than one national CSIRT, the > implementation needs to be clear and the list of contact details for all > of them should be provided. He added that the RIPE NCC is trying to work > with them, in the case that the ?abuse-c:? fails. Brian asked about the > origin of the request from the community. Christian replied that it > hadn?t come from the mailing list, and had come from a meeting of the > computer security community. Kaveh Ranjbar, RIPE NCC, added that the > provision of a proper abuse contact was a recurring point in the RIPE > NCC Survey 2013?s results and therefore the RIPE NCC had started to > attend security conferences. Ruediger asked Christian if the CSIRTS > were happy about getting the reports, or if they were > unhappy. Christian replied that they were happy. Ruediger expressed > doubt and surprise that they would be happy to be ?flooded? by copyright > abuse reports. He called for guidelines and information as to what kind > of report people should be sending to abuse contact, and how people > should be responding to these reports. Denis added that, if Ruediger > wants the RIPE NCC to provide these guidelines, then the community > should provide the text. Ruediger agreed with Denis that this is a task > for the Working Group. Brian added that he was surprised that the > CSIRTS were happy, and noted that many countries don?t have a CSIRT. He > added that he would put out a call for volunteers to help work on the > guidelines. Ruediger added that, without guidelines, doing validation > beyond mechanics is meaningless. > > E4: Introduction to Contact Databases for Abuse Handling > -Aaron Kaplan, nic.at > > Aaron explained how they do contact lookups at csirt.at, a national > CSIRT for Austria. He noted that a national CSIRT is usually just a > router for abuse contact information and that there are different > approaches in different countries. Aaron asked those involved with the > RIPE Database to have IRT objects, ?abuse-c?, etc. as specific and > up-to-date as possible as it will help those sending information to > national CSIRTS for lookups. Brian asked where the information about > Aaron?s presentation would be available and if he could publish it to > the list. Aaron added that it is a document on Github. Brian asked if > he could email the list with the URL. Aaron replied that it is part of > a document that Christian Teuschel and Mirjam Keuhne, RIPE NCC, and > Wilfried Woeber started. It is connected to a GitHub project called > GitHub.com/CERTtools that is a contact cache/contact database for > national CSIRTs so that they can build on the process. Brian added that > it might be good to discuss this in more depth at a future RIPE > Meeting. Aaron stated again that the CSIRT is just acting as a router, > passing copyrights through, and the copyrights end up with network > owners under their policies. However, he noted that the routing process > can be optimised. There were no further questions or comments. Brian > thanked Aaron for his presentation and invited the room to contribute > agenda items for RIPE 69 in London. He thanked the scribe, speakers, > stenographers and participants before closing the session. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Wed Nov 5 17:48:03 2014 From: jim at rfc1035.com (Jim Reid) Date: Wed, 5 Nov 2014 16:48:03 +0000 Subject: [anti-abuse-wg] [ncc-services-wg] EU Data Protection In-Reply-To: <20141105162030.GA58817@cilantro.c4inet.net> References: <20141105101221.GC58573@cilantro.c4inet.net> <77093.1415185395@server1.tristatelogic.com> <20141105162030.GA58817@cilantro.c4inet.net> Message-ID: <29220C49-0DE9-4778-964B-3E1C9C218774@rfc1035.com> On 5 Nov 2014, at 16:20, Sascha Luck wrote: > how does the uncontrolled publishing of that data possibly comply > with the EU Data Protection Directive and imminent General Data Protection Regulation, > > especially considering the entirely uncontrolled transfer of such > data to non-EU countries (whois lookups!)? > > IANAL, but to me it looks like a breach of said regulations. Sacha, what matters here is how Dutch law enacts the EU directive and regulation and how the Dutch Data Protection Authority enforces that law(s). I would presume/expect the NCC's legal staff have already checked this or got expert advice. The NCC is already publishing Personal Data -- eg names and addresses for Contact Objects -- without violating Dutch/EU Data Protection and/or Privacy legislation. So I would assume that publishing Person Objects will be equally acceptable. My understanding is the issues around export of Personal Data apply to cases where the data are processed/controlled in a country that does not have a Data Protection regime or Safe Harbour provisions equivalent to the EU Directives and Regulations. Publishing whois data probably does not fall into that. IANAL either. Though I have dealt with whois issues, ICANN, Data Protection and far too many lawyers in a previous life. The scars have nearly healed. From rfg at tristatelogic.com Wed Nov 5 20:10:18 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 05 Nov 2014 11:10:18 -0800 Subject: [anti-abuse-wg] RIPE Autonomous System Numbers In-Reply-To: <20141105144541.GX31092@Space.Net> Message-ID: <79853.1415214618@server1.tristatelogic.com> In message <20141105144541.GX31092 at Space.Net>, Gert Doering wrote: >On Tue, Nov 04, 2014 at 07:12:34PM -0800, Ronald F. Guilmette wrote: >> bits of unarguably useful information (which apparently aren't available >> to mere mortals... I am guessing by design, since it wouldn't exactly be >> rocket surgery to add them into the WHOIS responses). > >All of this (both publication of the sponsoring LIR and the creation >and modification date of an object) is being worked on as we speak. Thank you. I am very pleased to hear this, and look forward to the completion of this project. Regards, rfg From rfg at tristatelogic.com Wed Nov 5 22:38:18 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 05 Nov 2014 13:38:18 -0800 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 Message-ID: <81559.1415223498@server1.tristatelogic.com> How does one go about making a formal request to RIPE NCC to investigate a given AS registrant/registration? Given that AS201640 appears to exist exclusively for the purpose of hijacking multiple/numerous blocks of IPv4 space that it rather clearly has no rights to, I would like to formally lodge exactly such a request. http://blogs.cisco.com/security/talos/help-my-ip-address-has-been-hijacked/ http://mailman.nanog.org/pipermail/nanog/2014-October/071056.html This is ongoing, as we speak. Among the many IP blocks being hijacked, one of them even belongs to the Taiwan Network Information Center. Note that the hijacked IP space is being used, perhaps by multiple parties, by also by at least one convicted felon, and for one very specific purpose... http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ Regards, rfg P.S. To be clear, I would like to see there be an investigation of _both_ AS201640 and also the one and only other AS that appears to connect AS201640 to the rest of the world, i.e. AS200002. Somebody please help me here. I did try to read at least one of the official RIPE NCC registration requirement documents yesterday, and I was left with the impression... perhaps incorrect on my part... that in order to obtain an AS, the network in question must be multi-homed. Doesn't that mean that the network in question must have connectivity to the outside world via *more than one* other AS? P.P.S. Unlike RIPE number resource allocations, it _is_ easily possible to find the registration date for most domain names in most TLDs. The AS primarily at issue here is AS201640 and it seems to be associated with a (contact) domain name of "grimhosting.com". (The associated web site, by the way, is _not_ hosted within any IP space which is being announced by AS201640. Rather it is hosted on Cloudflare.) Anyway, the registration date for the domain name grimhosting.com is 2014-06-18. The person name on the registration for both the AS and that domain name is "Bogomil Simeonov". In the domain name registration, this name is associated with the e-mail address . That address in turn seems to be associated with some company named Zepter Bulgaria Ltd., which is apparently a "direct sales" organization, and also, perhaps, with the young man who is pictured in/on this web page: http://cv-simeonov.hit.bg/ From ops.lists at gmail.com Thu Nov 6 00:40:38 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 05 Nov 2014 23:40:38 +0000 Subject: [anti-abuse-wg] Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud References: <81757.1415224757@server1.tristatelogic.com> Message-ID: I knew the time was, well, ripe for something like this to pop up directly after rfg started asking those questions yesterday. ---------- Forwarded message --------- From: Ronald F. Guilmette Date: Thu, 6 Nov 2014 at 03:31 Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud To: I already posted about this rogue AS days ago, but nothing has really changed much, since then, with respect to its hijacking of IP space. Well, at least Brian Krebs was kind anough to write about it: http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ (Please note that that is a convicted felon spamming from the hijacked IP space. He's not allowed to own firearms, but he _can_ apparently own a keyboard.) As of today, AS201640 is still hijacking a total of eleven routes to IP space scattered all over the world... none of which appears to belong to anybody in or near Bulgaria. In fact, it would appear that the organization that is the registrant of AS201640 currently has exactly -zero- IP addresses to call its own. Nobody in a postion to _do_ anything about this gives a darn? As of today: 36.0.56.0/21 41.92.206.0/23 41.198.80.0/20 41.198.224.0/20 61.242.128.0/19 119.227.224.0/19 123.29.96.0/19 177.22.117.0/24 177.46.48.0/22 187.189.158.0/23 202.39.112.0/20 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at nickshorey.com Thu Nov 6 13:19:50 2014 From: nick at nickshorey.com (Nick Shorey) Date: Thu, 6 Nov 2014 12:19:50 +0000 Subject: [anti-abuse-wg] Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud In-Reply-To: References: <81757.1415224757@server1.tristatelogic.com> Message-ID: <8F1040D0-94EA-47DC-97DD-027F186F2B12@nickshorey.com> Hi all, These are really interesting discussions so please keep me updated on progress against these rogue ASNs. Kind regards, Nick [personal information removed] On 5 Nov 2014, at 23:40, Suresh Ramasubramanian wrote: > I knew the time was, well, ripe for something like this to pop up directly after rfg started asking those questions yesterday. > > ---------- Forwarded message --------- > From: Ronald F. Guilmette > Date: Thu, 6 Nov 2014 at 03:31 > Subject: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud > To: > > > > I already posted about this rogue AS days ago, but nothing has really > changed much, since then, with respect to its hijacking of IP space. > > Well, at least Brian Krebs was kind anough to write about it: > > http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ > > (Please note that that is a convicted felon spamming from the hijacked > IP space. He's not allowed to own firearms, but he _can_ apparently > own a keyboard.) > > As of today, AS201640 is still hijacking a total of eleven routes to > IP space scattered all over the world... none of which appears to > belong to anybody in or near Bulgaria. In fact, it would appear that > the organization that is the registrant of AS201640 currently has > exactly -zero- IP addresses to call its own. > > Nobody in a postion to _do_ anything about this gives a darn? > > > As of today: > > 36.0.56.0/21 > 41.92.206.0/23 > 41.198.80.0/20 > 41.198.224.0/20 > 61.242.128.0/19 > 119.227.224.0/19 > 123.29.96.0/19 > 177.22.117.0/24 > 177.46.48.0/22 > 187.189.158.0/23 > 202.39.112.0/20 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From laura at ripe.net Thu Nov 6 15:27:14 2014 From: laura at ripe.net (Laura Cobley) Date: Thu, 06 Nov 2014 14:27:14 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <81559.1415223498@server1.tristatelogic.com> References: <81559.1415223498@server1.tristatelogic.com> Message-ID: <545B8542.9010203@ripe.net> Dear Ronald and all, The RIPE NCC investigates reports about Internet number resource registrations. These fall into different categories: - Violation of RIPE Policies and RIPE NCC Procedures - Provision of untruthful information to the RIPE NCC - Bankruptcy, liquidation or insolvency - Incorrect contact information in the RIPE Database You can read more about the procedure together with a link for submitting a report at: https://www.ripe.net/contact/reporting-procedure Kind regards, Laura Cobley Customer Services Manager RIPE NCC On 05/11/14 21:38, Ronald F. Guilmette wrote: > How does one go about making a formal request to RIPE NCC to investigate > a given AS registrant/registration? > > Given that AS201640 appears to exist exclusively for the purpose of > hijacking multiple/numerous blocks of IPv4 space that it rather clearly > has no rights to, I would like to formally lodge exactly such a request. > > http://blogs.cisco.com/security/talos/help-my-ip-address-has-been-hijacked/ > > http://mailman.nanog.org/pipermail/nanog/2014-October/071056.html > > This is ongoing, as we speak. Among the many IP blocks being hijacked, > one of them even belongs to the Taiwan Network Information Center. > > Note that the hijacked IP space is being used, perhaps by multiple > parties, by also by at least one convicted felon, and for one very > specific purpose... > > http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-years/ > > > Regards, > rfg > > > P.S. To be clear, I would like to see there be an investigation of > _both_ AS201640 and also the one and only other AS that appears to > connect AS201640 to the rest of the world, i.e. AS200002. > > Somebody please help me here. I did try to read at least one of the > official RIPE NCC registration requirement documents yesterday, and > I was left with the impression... perhaps incorrect on my part... that > in order to obtain an AS, the network in question must be multi-homed. > Doesn't that mean that the network in question must have connectivity > to the outside world via *more than one* other AS? > > > P.P.S. Unlike RIPE number resource allocations, it _is_ easily possible > to find the registration date for most domain names in most TLDs. The > AS primarily at issue here is AS201640 and it seems to be associated > with a (contact) domain name of "grimhosting.com". (The associated web > site, by the way, is _not_ hosted within any IP space which is being > announced by AS201640. Rather it is hosted on Cloudflare.) Anyway, > the registration date for the domain name grimhosting.com is 2014-06-18. > > The person name on the registration for both the AS and that domain name > is "Bogomil Simeonov". In the domain name registration, this name is > associated with the e-mail address . That address > in turn seems to be associated with some company named Zepter Bulgaria Ltd., > which is apparently a "direct sales" organization, and also, perhaps, with > the young man who is pictured in/on this web page: > > http://cv-simeonov.hit.bg/ > > > From anfernandez at lavanguardia.es Thu Nov 6 15:55:52 2014 From: anfernandez at lavanguardia.es (anfernandez at lavanguardia.es) Date: Thu, 6 Nov 2014 14:55:52 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <545B8542.9010203@ripe.net> References: <81559.1415223498@server1.tristatelogic.com> <545B8542.9010203@ripe.net> Message-ID: Hi Ronald, Don't waste your time. RIPE is not going to do anything about piracy. They will tell you that they can't become judges and that they obligation is limited to the four points raised by Ms. Cobley. When RIPE is actually a judge that decided to protecting internet piracy. You can be sure that RIPE will open an expedient to any LIR that do not pay its fee, but you can keep waiting to see RIPE opening an expedient to investigate bad use of internet by one of their associated LIRs. Regards, ?ngel -----Mensaje original----- De: anti-abuse-wg-bounces at ripe.net [mailto:anti-abuse-wg-bounces at ripe.net] En nombre de Laura Cobley Enviado el: jueves, 06 de noviembre de 2014 15:27 Para: Ronald F. Guilmette; anti-abuse-wg at ripe.net Asunto: Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 Dear Ronald and all, The RIPE NCC investigates reports about Internet number resource registrations. These fall into different categories: - Violation of RIPE Policies and RIPE NCC Procedures - Provision of untruthful information to the RIPE NCC - Bankruptcy, liquidation or insolvency - Incorrect contact information in the RIPE Database You can read more about the procedure together with a link for submitting a report at: https://www.ripe.net/contact/reporting-procedure Kind regards, Laura Cobley Customer Services Manager RIPE NCC On 05/11/14 21:38, Ronald F. Guilmette wrote: > How does one go about making a formal request to RIPE NCC to > investigate a given AS registrant/registration? > > Given that AS201640 appears to exist exclusively for the purpose of > hijacking multiple/numerous blocks of IPv4 space that it rather > clearly has no rights to, I would like to formally lodge exactly such a request. > > http://blogs.cisco.com/security/talos/help-my-ip-address-has-been-hija > cked/ > > http://mailman.nanog.org/pipermail/nanog/2014-October/071056.html > > This is ongoing, as we speak. Among the many IP blocks being > hijacked, one of them even belongs to the Taiwan Network Information Center. > > Note that the hijacked IP space is being used, perhaps by multiple > parties, by also by at least one convicted felon, and for one very > specific purpose... > > http://krebsonsecurity.com/2014/11/still-spamming-after-all-these-year > s/ > > > Regards, > rfg > > > P.S. To be clear, I would like to see there be an investigation of > _both_ AS201640 and also the one and only other AS that appears to > connect AS201640 to the rest of the world, i.e. AS200002. > > Somebody please help me here. I did try to read at least one of the > official RIPE NCC registration requirement documents yesterday, and I > was left with the impression... perhaps incorrect on my part... that > in order to obtain an AS, the network in question must be multi-homed. > Doesn't that mean that the network in question must have connectivity > to the outside world via *more than one* other AS? > > > P.P.S. Unlike RIPE number resource allocations, it _is_ easily > possible to find the registration date for most domain names in most > TLDs. The AS primarily at issue here is AS201640 and it seems to be > associated with a (contact) domain name of "grimhosting.com". (The > associated web site, by the way, is _not_ hosted within any IP space > which is being announced by AS201640. Rather it is hosted on > Cloudflare.) Anyway, the registration date for the domain name grimhosting.com is 2014-06-18. > > The person name on the registration for both the AS and that domain name > is "Bogomil Simeonov". In the domain name registration, this name is > associated with the e-mail address . That > address in turn seems to be associated with some company named Zepter > Bulgaria Ltd., which is apparently a "direct sales" organization, and > also, perhaps, with the young man who is pictured in/on this web page: > > http://cv-simeonov.hit.bg/ > > > From gert at space.net Thu Nov 6 16:08:14 2014 From: gert at space.net (Gert Doering) Date: Thu, 6 Nov 2014 16:08:14 +0100 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <20141106145630.BA17A60157@mobil.space.net> References: <81559.1415223498@server1.tristatelogic.com> <545B8542.9010203@ripe.net> <20141106145630.BA17A60157@mobil.space.net> Message-ID: <20141106150814.GX31092@Space.Net> Hi, On Thu, Nov 06, 2014 at 02:55:52PM +0000, anfernandez at lavanguardia.es wrote: > When RIPE is actually a judge that decided to protecting internet piracy. You can be sure that RIPE will open an expedient to any LIR that do not pay its fee, but you can keep waiting to see RIPE opening an expedient to investigate bad use of internet by one of their associated LIRs. It should be made totally clear that spamming, pirating movies, and so on is a legitimate usage of IP addresses IF THE JURISDICTION OF THE LIR IN QUESTION PERMITS IT. We might not *like* it, but if it's legal in, say, Romania to send out large amounts of e-mail, attacking the RIPE NCC for providing IP addresses to a LIR in .ro is not the way to fix it. Now, we all might agree that SPAM is evil, and pirating moviez is also evil. What about encouraging political debate? China might have a stance here. What about pictures of men kissing men? Russia might not like that. Things that are totally inacceptable for some parties are things that other parties want protected by freedom of speech, or freedom of doing business. So, the NCC can, will and *should* not act on "things people do not like" - it will (and does) act if being lied to, or if a judge decides that a LIR's business is illegal. In this particular case, I wonder why nobody is yelling at the upstream who is happily forward packets for that AS... due dilligence at accepting customer prefixes would have easily caught the announcements. (Yes, I understand that I'm now officially part of the problem, as I'm obviously not willing to do everything technically possible to stop particular sorts of badness) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ops.lists at gmail.com Thu Nov 6 16:28:19 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 6 Nov 2014 20:58:19 +0530 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <20141106150814.GX31092@Space.Net> References: <81559.1415223498@server1.tristatelogic.com> <545B8542.9010203@ripe.net> <20141106145630.BA17A60157@mobil.space.net> <20141106150814.GX31092@Space.Net> Message-ID: If you want that argument - 1. Several countries have a 'country link' concept to assert jurisdiction of their antispam laws. So if a US or Australian citizen or ISP was spammed, or a relay in their country abused etc they'd have jurisdiction. 2. Romania does have antispam legislation and there is a European Parliament ruling dating back to 2002 related to spam Quoting from a romanian page passed through Google translate : http://www.legi-internet.ro/articole-drept-it/spamul-aspecte-legislative-si-jurisprudentiale.html e) In Romania, the legislation on spam is relatively recent and it was adopted as a result of harmonization of national legislation with Community law. (17) Thus, the main laws relating to privacy and related to spammmingul are: - Law .677 of 21 November 2001 on the protection of individuals with regard to the processing of personal data and the free movement of such data; - Law no.506 of 17 November 2004 concerning the processing of personal data and privacy in the electronic communications sector; - In Additionally, GEO no.130 / 2000 on distance, through the provisions of Article 16 in relation to Article 15 enshrines the opt-out method in the context of the e-commerce Directive 31/2000 on leave to the states to choose between opt-in and opt-out; Law no.365 / 2002 on electronic commerce and establishes rules for the application opt-in categorical manner, leading to an inconsistent girl GEO no.130 / 2000. Linking domestic legal provisions and employment in the field of e-mail opt-in comes after approving Ordinance no.130 / 2000 by Law No.51 / 2003, which amended this. Regarding the Law no.506 / 2004, this is a transposition into national law of European Directive 58/2002 and requires opt-way relationship between practitioners in the direct marketing and Internet users. This is provided for by article 12, paragraph 1, which states that "It is prohibited to make commercial communications through the use of automated calling systems that do not require human intervention, by fax or by electronic mail, or by any other method uses publicly available electronic communications services, unless the subscriber concerned has given his prior express consent to receive such communications. " >From this rule there is an exception provided for in Article 2, which concerns those who have obtained addresses when selling a product or service, but provides a simple means and free recipient opposition. In paragraph 3 states that are prohibited spam that hide the identity of the sender or they work for, nor gives the recipient the opportunity to object. The sanctions provided by the law are such contravention, if the violation of its provisions was not the facts that constitute crimes. Thus, observing the provisions of Article 12, relating to unsolicited communications are misdemeanors and are punishable by a fine of 50 million lei to 1,000,000,000 lei, and for companies with a turnover of over 50,000,000,000 lei, notwithstanding the provisions of Ordinance No.2 / 2001 on the legal regime of contraventions, approved with amendments and completions by Law no.180 / 2002, with subsequent amendments, with a fine of up to 2% of turnover. A competent independent authority in the fight against spam exunctioneaz? not yet, as a separate entity. Responsibilities in this regard incumbent Ombudsman, the officials whom he has available. However there is a bill in the House of Deputies adopted only in the meeting of March 8, 2005, which establishes the national supervisory authority of the processing of personal data. Also an important role in managing the problem of spam and the processing of personal data plays Regulatory Authority for Communications. Together they can work and professional associations to adopt and enforce codes of conduct in the network. We find such French model on professional associations or non-governmental and Netiquette code. Regarding the competence of the courts and the right of individuals to go to court, the Law no.677 / 2001 provides (Article 18) that: "(1) Without prejudice to the possibility of addressing the supervisory authority, people subjects have the right to go to court to defend the rights guaranteed by this law, they have been violated. (2) Any person who has suffered damage as a result of the processing of personal data carried out illegally, may address competent court for repair. (3) is the competent court within whose jurisdiction the applicant resides. Application for summons is exempt from stamp duty. " Such a person, if he has not filed a complaint in court, we can address the Ombudsman, according to article 27 of Law no.677 / 2001. As regards the law applicable to this international element are not made ??explicit reference so it will Specific rules apply to common law. On Nov 6, 2014 8:38 PM, "Gert Doering" wrote: > Hi, > > On Thu, Nov 06, 2014 at 02:55:52PM +0000, anfernandez at lavanguardia.es > wrote: > > When RIPE is actually a judge that decided to protecting internet > piracy. You can be sure that RIPE will open an expedient to any LIR that do > not pay its fee, but you can keep waiting to see RIPE opening an expedient > to investigate bad use of internet by one of their associated LIRs. > > It should be made totally clear that spamming, pirating movies, and so > on is a legitimate usage of IP addresses IF THE JURISDICTION OF THE LIR > IN QUESTION PERMITS IT. > > We might not *like* it, but if it's legal in, say, Romania to send out > large amounts of e-mail, attacking the RIPE NCC for providing IP addresses > to a LIR in .ro is not the way to fix it. > > Now, we all might agree that SPAM is evil, and pirating moviez is also > evil. What about encouraging political debate? China might have a > stance here. What about pictures of men kissing men? Russia might not > like that. > > Things that are totally inacceptable for some parties are things that > other parties want protected by freedom of speech, or freedom of doing > business. > > So, the NCC can, will and *should* not act on "things people do not > like" - it will (and does) act if being lied to, or if a judge decides > that a LIR's business is illegal. > > In this particular case, I wonder why nobody is yelling at the upstream > who is happily forward packets for that AS... due dilligence at > accepting customer prefixes would have easily caught the announcements. > > (Yes, I understand that I'm now officially part of the problem, as > I'm obviously not willing to do everything technically possible to > stop particular sorts of badness) > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anfernandez at lavanguardia.es Thu Nov 6 16:41:51 2014 From: anfernandez at lavanguardia.es (anfernandez at lavanguardia.es) Date: Thu, 6 Nov 2014 15:41:51 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <20141106150814.GX31092@Space.Net> References: <81559.1415223498@server1.tristatelogic.com> <545B8542.9010203@ripe.net> <20141106145630.BA17A60157@mobil.space.net> <20141106150814.GX31092@Space.Net> Message-ID: Hi Gert, Let me ask you a question: Which is the mision of RIPE? RIPE's web site say: We serve our members by delivering a high quality registry and supporting the core Internet infrastructure. Connecting people within and beyond the technical community through our inclusive, multi-stakeholder approach, we contribute to an innovative and reliable Internet. Do you really think RIPE is serving its mission? Do you really think RIPE database is a high quality registry when the single requirement to the LIRs is not provide untruthful information , but it does not matter if it is unuseful, as, for example, abuse contact email address? Do you really think RIPE is providing a reliable internet? RIPE's delegation of their responsabilities is driving internet to be blocked by a lot of national firewall because of local application of copyright or anti abuse legislaton. Is this the RIPE's reliable internet? Regards, ?ngel -----Mensaje original----- De: Gert Doering [mailto:gert at space.net] Enviado el: jueves, 06 de noviembre de 2014 16:08 Para: Angel Fernandez Pineda CC: anti-abuse-wg at ripe.net; laura at ripe.net Asunto: Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 Hi, On Thu, Nov 06, 2014 at 02:55:52PM +0000, anfernandez at lavanguardia.es wrote: > When RIPE is actually a judge that decided to protecting internet piracy. You can be sure that RIPE will open an expedient to any LIR that do not pay its fee, but you can keep waiting to see RIPE opening an expedient to investigate bad use of internet by one of their associated LIRs. It should be made totally clear that spamming, pirating movies, and so on is a legitimate usage of IP addresses IF THE JURISDICTION OF THE LIR IN QUESTION PERMITS IT. We might not *like* it, but if it's legal in, say, Romania to send out large amounts of e-mail, attacking the RIPE NCC for providing IP addresses to a LIR in .ro is not the way to fix it. Now, we all might agree that SPAM is evil, and pirating moviez is also evil. What about encouraging political debate? China might have a stance here. What about pictures of men kissing men? Russia might not like that. Things that are totally inacceptable for some parties are things that other parties want protected by freedom of speech, or freedom of doing business. So, the NCC can, will and *should* not act on "things people do not like" - it will (and does) act if being lied to, or if a judge decides that a LIR's business is illegal. In this particular case, I wonder why nobody is yelling at the upstream who is happily forward packets for that AS... due dilligence at accepting customer prefixes would have easily caught the announcements. (Yes, I understand that I'm now officially part of the problem, as I'm obviously not willing to do everything technically possible to stop particular sorts of badness) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Thu Nov 6 16:56:49 2014 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 06 Nov 2014 15:56:49 +0000 Subject: [anti-abuse-wg] New on RIPE Labs: Security and Privacy Objectives by Geoff Huston Message-ID: <545B9A41.5050805@ripe.net> Dear colleagues, Please find a new article by Geoff Huston on RIPE Labs: Privacy and Security - Five Objectives https://labs.ripe.net/Members/gih/privacy-and-security-five-objectives Kind regards, Mirjam Kuehne RIPE NCC From gert at space.net Thu Nov 6 17:05:34 2014 From: gert at space.net (Gert Doering) Date: Thu, 6 Nov 2014 17:05:34 +0100 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: References: <81559.1415223498@server1.tristatelogic.com> <545B8542.9010203@ripe.net> <20141106145630.BA17A60157@mobil.space.net> <20141106150814.GX31092@Space.Net> Message-ID: <20141106160534.GZ31092@Space.Net> Hi, On Thu, Nov 06, 2014 at 08:58:19PM +0530, Suresh Ramasubramanian wrote: > Quoting from a romanian page passed through Google translate : > > http://www.legi-internet.ro/articole-drept-it/spamul-aspecte-legislative-si-jurisprudentiale.html > > e) In Romania, the legislation on spam is relatively recent and it was > adopted as a result of harmonization of national legislation with Community > law. (17) This is very good news (I do not like SPAM any more than you do, I just differ in what I think is the right means to fight back). So, I think all that is needed is to get a court to convict them, and then the NCC can close the LIR and take back the resources - see the documented procedure on LIR closures. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From gert at space.net Thu Nov 6 17:09:39 2014 From: gert at space.net (Gert Doering) Date: Thu, 6 Nov 2014 17:09:39 +0100 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <20141106154228.33165608D0@mobil.space.net> References: <81559.1415223498@server1.tristatelogic.com> <545B8542.9010203@ripe.net> <20141106145630.BA17A60157@mobil.space.net> <20141106150814.GX31092@Space.Net> <20141106154228.33165608D0@mobil.space.net> Message-ID: <20141106160939.GA31092@Space.Net> Hi, On Thu, Nov 06, 2014 at 03:41:51PM +0000, anfernandez at lavanguardia.es wrote: > Let me ask you a question: Which is the mision of RIPE? "Distribute Internet resources in a fair and impartial way to those entities that need Internet resources to go about their business". > RIPE's web site say: We serve our members by delivering a high quality registry and supporting the core Internet infrastructure. Connecting people within and beyond the technical community through our inclusive, multi-stakeholder approach, we contribute to an innovative and reliable Internet. > > Do you really think RIPE is serving its mission? Yes. > Do you really think RIPE database is a high quality registry when the single requirement to the LIRs is not provide untruthful information , but it does not matter if it is unuseful, as, for example, abuse contact email address? If the information provided to the RIPE NCC is not correct, this can lead to closure of a LIR. If someone is not reading their abuse mail, there is nothing the NCC can do about it unless the community(!) mandates it to do so. > Do you really think RIPE is providing a reliable internet? RIPE's delegation of their responsabilities is driving internet to be blocked by a lot of national firewall because of local application of copyright or anti abuse legislaton. Is this the RIPE's reliable internet? The RIPE NCC is not running the internet, but it *is* providing one of the better registration services as far as transparency of policy making and mission go. Especially the fact that it is very clearly defined what the RIPE NCC will do and what it will not do, and that everything can be changed if the community comes to consensus to do so. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From anfernandez at lavanguardia.es Thu Nov 6 17:23:13 2014 From: anfernandez at lavanguardia.es (anfernandez at lavanguardia.es) Date: Thu, 6 Nov 2014 16:23:13 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <20141106160534.GZ31092@Space.Net> References: <81559.1415223498@server1.tristatelogic.com> <545B8542.9010203@ripe.net> <20141106145630.BA17A60157@mobil.space.net> <20141106150814.GX31092@Space.Net> <20141106160534.GZ31092@Space.Net> Message-ID: Hi, About spam in Romania you say: "This is very good news (I do not like SPAM any more than you do, I just differ in what I think is the right means to fight back). So, I think all that is needed is to get a court to convict them, and then the NCC can close the LIR and take back the resources - see the documented procedure on LIR closures." and I add to your comentary: and the spammer will move to a new site and you will need a court convict again, and again, and again. I'm sorry, but I'm not so rich to do it ?ngel -----Mensaje original----- De: Gert Doering [mailto:gert at space.net] Enviado el: jueves, 06 de noviembre de 2014 17:06 Para: Suresh Ramasubramanian CC: Gert Doering; Angel Fernandez Pineda; anti-abuse-wg at ripe.net; laura at ripe.net Asunto: Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 Hi, On Thu, Nov 06, 2014 at 08:58:19PM +0530, Suresh Ramasubramanian wrote: > Quoting from a romanian page passed through Google translate : > > http://www.legi-internet.ro/articole-drept-it/spamul-aspecte-legislati > ve-si-jurisprudentiale.html > > e) In Romania, the legislation on spam is relatively recent and it was > adopted as a result of harmonization of national legislation with > Community law. (17) This is very good news (I do not like SPAM any more than you do, I just differ in what I think is the right means to fight back). So, I think all that is needed is to get a court to convict them, and then the NCC can close the LIR and take back the resources - see the documented procedure on LIR closures. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From mir at ripe.net Thu Nov 6 18:04:27 2014 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 06 Nov 2014 17:04:27 +0000 Subject: [anti-abuse-wg] Link to data sets document Message-ID: <545BAA1B.1090309@ripe.net> Hi, As promised earlier this week during the WG session, here is the link to the document describing various abuse contact data sets for IT security incident handling: https://github.com/certtools/contactdb/blob/rest/doc/datasets.mkd Please let us know if you have any comments or suggestions. Any feedback is welcome. Kind regards, Mirjam Kuehne From rfg at tristatelogic.com Thu Nov 6 20:24:44 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 06 Nov 2014 11:24:44 -0800 Subject: [anti-abuse-wg] Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud In-Reply-To: <8F1040D0-94EA-47DC-97DD-027F186F2B12@nickshorey.com> Message-ID: <91004.1415301884@server1.tristatelogic.com> In message <8F1040D0-94EA-47DC-97DD-027F186F2B12 at nickshorey.com>, Nick Shorey wrote: >These are really interesting discussions so please keep me updated on >progress against these rogue ASNs. Progress?? I'll give you an update, but it hardly represents anything that could be called ``progress''. As of today, AS201640 is still squatting on these same 11 routes: 36.0.56.0/21 41.92.206.0/23 41.198.80.0/20 41.198.224.0/20 61.242.128.0/19 119.227.224.0/19 123.29.96.0/19 177.22.117.0/24 177.46.48.0/22 187.189.158.0/23 202.39.112.0/20 If you check back in a month or two, perhaps one or more of the networks that provides connectivity to AS201640's upstream, i.e. AS200002, may have finally taken its head out of its ass and done something about this ridiculously blatant case, but I wouldn't hold my breath if I were you. Regards, rfg P.S. Of course, it would be Nice if RIPE NCC eventually terminated the registration of AS201640. I think that's their only reasonable course of action, long term. But as is often noted, they are not the routing police, and even if they did so today or tomorrow, there would still be all these bogus route announcements being propagated to the far corners of the earth. The announcements would all then just be attached to an AS number that isn't in the RIPE DB anymore. But as far as I know, the announcements would still flow anyway. (I feel sure that somebody here will correct me if I'm wrong about that.) Its the network operators who need to put a stop to this over-the-top ludicrous situation. And so far, not a single one is stepping up to do that. From rfg at tristatelogic.com Thu Nov 6 21:03:18 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 06 Nov 2014 12:03:18 -0800 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <545B8542.9010203@ripe.net> Message-ID: <91221.1415304198@server1.tristatelogic.com> In message <545B8542.9010203 at ripe.net>, Laura Cobley wrote: >Dear Ronald and all, > >The RIPE NCC investigates reports about Internet number resource >registrations. These fall into different categories: > >- Violation of RIPE Policies and RIPE NCC Procedures >- Provision of untruthful information to the RIPE NCC >- Bankruptcy, liquidation or insolvency >- Incorrect contact information in the RIPE Database > >You can read more about the procedure together with a link for >submitting a report at: https://www.ripe.net/contact/reporting-procedure Thank you Laura. This information is really most helpful. As should be apparent, I would like to file a report on AS201640, but I believe that I may need some help with that, from you, from the members of this mailing list, or both. This is not a case involving any kind of bankruptcy, so that one (out of four) is clearly inapplicable. But with regards to the remaining three possibilities, I could use some guidance. Let's take them one at a time. (*) Violation of RIPE Policies and RIPE NCC Procedures I asked the list about this earlier. Is there a requirement that an AS be ``multi-homed'' and does AS201640 currently appear to be fulfilling that requirement? Could some list participants who know more than me on this point... which is to say just about everybody... please comment and enlighten me? (*) Provision of untruthful information to the RIPE NCC Here again, I need to ask for guidance. Last night, I did see several things... things in the RIPE WHOIS data base... that did seem entirely wrong to me. If one queries the RIPE WHOIS data base, right now, about any of the following IP addresses, you will see what I mean: 105.154.248.0 210.57.0.0 202.39.112.0 119.227.224.0 41.198.224.0 The responses that come back from the RIPE WHOIS server say that each of the above IP addresses belongs to "MEGA - SPRED LTD". I believe that these responses are all incorrect however, and that in fact, none of the relevant IP ranges is actually, formally, and properly registered to either "MEGA - SPRED LTD" or to -any- entity within the RIPE region for that matter. (The addresses in question belong to other RiRs. So sayeth IANA.) So there are two seemingly obvious questions: 1) Did these RIPE data base entries come about because "MEGA - SPRED LTD" ``provided untruthful information to the RIPE NCC''? I can't tell. I guess that it largely depends upon one's definition of ``untruthful''. It *is* in fact true/truthful that AS201640 *has* in fact been announcing routes to the relevant blocks of IPv4 space. But it is my contention that they have no rights to do so. If true, would that situation imply untruthfulness... actionable or otherwise... on on that part of AS201640? 2) How on earth did these RIPE IPv4 block registration records even manage to get in to the RIPE WHOIS data base anyway?? As I have said, the IP blocks in question all seem to belong to other RiRs. That is what the whois.iana.org WHOIS server is telling me anyway. Does the RIPE WHOIS data base routinely contradict the IANA data base in this way? Is it _supposed_ to do so? Does any checking occur on newly added RIPE WHOIS records... before they go into the RIPE WHOIS data base... to make sure that no such newly added RIPE WHOIS records conflict with what IANA believes (regarding number resource allocations)? If not, why not? And if so, how did the five examples above slip past these simple consistancy checks? (*) Incorrect contact information in the RIPE Database I gather that this one is intended to deal with contact data that, while once having been accurate, has not been properly maintained, over time. So I guess that this doesn't apply to the present case either. Regards, rfg From rfg at tristatelogic.com Thu Nov 6 21:26:09 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 06 Nov 2014 12:26:09 -0800 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 Message-ID: <91360.1415305569@server1.tristatelogic.com> wrote: >Don't waste your time. RIPE is not going to do anything about piracy... I already took my turn, years ago now, howling my disappointment that neither RIPE, nor RIPE NCC, nor any other RiR is willing to play the role of the Internet Police. I'm over that adolecent phase now, and have come to accept what they are, and the fact that no howling on my part is in the least bit likely to change what they are. The RiRs are fundamentally data base companies. I don't intend by saying that to slight them, or anybody associated with them in any way. I am quite completely sure that they also do quite a lot of other very fine work also... making all sorts of logistical arrange- ments for regular meetings, and all that goes with that, and RIPE Labs produces some fine tools and excelent technical reports. In short, they do a _lot_ of fine work. But at base, their first order task... RIPE NCC anyway... is the orderly allocation of resources and the maintenance of the data base. Anybody who knows anything about the history of the United States, as I do, can grasp the notion that RIPE is just a sort of ``federal'' system... a federation of a bunch of sometimes waring tribes/states, each with its own separate agenda, and a federation with intentionally limited powers over its constituents. So I'm not really either expecting or even asking them to ``do'' anything about ``piracy''. I will however ask them to look into some of the things that seem wrong to me and that appear in their data base. And I have faith that they will do so, because that _is_ their job. Regards, rfg From rfg at tristatelogic.com Thu Nov 6 21:32:48 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 06 Nov 2014 12:32:48 -0800 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <20141106150814.GX31092@Space.Net> Message-ID: <91408.1415305968@server1.tristatelogic.com> In message <20141106150814.GX31092 at Space.Net>, Gert Doering wrote: >In this particular case, I wonder why nobody is yelling at the upstream >who is happily forward packets for that AS... due dilligence at >accepting customer prefixes would have easily caught the announcements. I personally would be ``yelling at the upstream'' right now, but someone made a comment on the NANOG mailing list which sort-of hinted that this would be entirely futile in the case of AS200002. I don't know, but I suspect that he already knows something that I don't know, so I'm not wasting my time on sending comlaints to an entity that, it seems, may perhaps not give a damn. >(Yes, I understand that I'm now officially part of the problem, as >I'm obviously not willing to do everything technically possible to >stop particular sorts of badness) To the extent that you might be able to avoid forwarding route announcements which originate from AS201640, allow me to express my personal opinion that doing so would be admirable. Regards, rfg From rfg at tristatelogic.com Thu Nov 6 21:46:09 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 06 Nov 2014 12:46:09 -0800 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 Message-ID: <91548.1415306769@server1.tristatelogic.com> anfernandez at lavanguardia.es you wrote: >Let me ask you a question: Which is the mision of RIPE? You didn't ask _me_, but I will answer anyway. The first order mission of RIPE NCC is to make and oversee number re- source allocations, insuring that they are done in an orderly fashion, and to maintain the data base of said allocations. The first order mission of RIPE is to fund and maintain RIPE NCC. >RIPE's web site say: We serve our members by delivering a high quality regi >stry and supporting the core Internet infrastructure. Connecting people wit >hin and beyond the technical community through our inclusive, multi-stakeho >lder approach, we contribute to an innovative and reliable Internet. > >Do you really think RIPE is serving its mission? I do, yes. >Do you really think RIPE is providing a reliable internet? I do, yes. Every time I go to visit, for example, www.bbc.com, it just works. Younger people sometimes don't appreciate what a minor miracle this seemingly simple thing is, and what a colossally large number of different things *all* have to work, and work correctly, in order to make it happen. (I've been working on computers since the mid 1970's, and let me tell you, back then it was _really_ a minor miracle when anything did in fact work.) Regards, rfg From R.mahmoudi at mobinnet.net Thu Nov 6 21:50:59 2014 From: R.mahmoudi at mobinnet.net (Reza Mahmoudi) Date: Thu, 6 Nov 2014 20:50:59 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <91408.1415305968@server1.tristatelogic.com> References: <20141106150814.GX31092@Space.Net>, <91408.1415305968@server1.tristatelogic.com> Message-ID: <9BF4935858C6234189573116954E7F6E4723D425@Mobinnetex01.mobinnet.net> I was wondering if this kind of hijacking falls into the category of Cybercrime and authorities like Europol (https://www.europol.europa.eu/ ) can help? Reza Mahmoudi ________________________________________ From: anti-abuse-wg-bounces at ripe.net [anti-abuse-wg-bounces at ripe.net] on behalf of Ronald F. Guilmette [rfg at tristatelogic.com] Sent: Friday, November 07, 2014 12:02 AM To: anti-abuse-wg at ripe.net Subject: Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In message <20141106150814.GX31092 at Space.Net>, Gert Doering wrote: >In this particular case, I wonder why nobody is yelling at the upstream >who is happily forward packets for that AS... due dilligence at >accepting customer prefixes would have easily caught the announcements. I personally would be ``yelling at the upstream'' right now, but someone made a comment on the NANOG mailing list which sort-of hinted that this would be entirely futile in the case of AS200002. I don't know, but I suspect that he already knows something that I don't know, so I'm not wasting my time on sending comlaints to an entity that, it seems, may perhaps not give a damn. >(Yes, I understand that I'm now officially part of the problem, as >I'm obviously not willing to do everything technically possible to >stop particular sorts of badness) To the extent that you might be able to avoid forwarding route announcements which originate from AS201640, allow me to express my personal opinion that doing so would be admirable. Regards, rfg -- This email was Virus checked by Juniper Security Gateway. From vovan at fakmoymozg.ru Thu Nov 6 21:46:07 2014 From: vovan at fakmoymozg.ru (fmm) Date: Thu, 06 Nov 2014 21:46:07 +0100 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <91360.1415305569@server1.tristatelogic.com> References: <91360.1415305569@server1.tristatelogic.com> Message-ID: Hi Ronald, Try to DDoS them e.g with the help of IP spoofing + NTP. Sometimes that helps with small offending networks as upstream providers nullroute them. Cheers From ops.lists at gmail.com Fri Nov 7 02:12:01 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 07 Nov 2014 01:12:01 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 References: <91360.1415305569@server1.tristatelogic.com> Message-ID: Nice troll. On Fri, 7 Nov 2014 at 03:01 fmm wrote: > Hi Ronald, > > Try to DDoS them e.g with the help of IP spoofing + NTP. Sometimes that > helps with small offending networks as upstream providers nullroute them. > > Cheers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Fri Nov 7 02:23:26 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 07 Nov 2014 01:23:26 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 References: <20141106150814.GX31092@Space.Net> <91408.1415305968@server1.tristatelogic.com> <9BF4935858C6234189573116954E7F6E4723D425@Mobinnetex01.mobinnet.net> Message-ID: There are two or three things here. RIPE is under dutch law and the Netherlands does have a law against spam, and other cybercrime legislation as well that has historically been actively enforced. The LIR is under romanian law and that does appear to have some laws against spam on their books but none of it appears to have been tested in court. As a LE organization, Europol, like Interpol, deals with coordination and clearinghouse work between national LE and neither is an international police force. This simply means that LE or the appropriate regulator in either country where the different parts of this contract exist (the Netherlands - opta or dutch high tech crime police, and whoever are their peers in Romania) should be able to act on this information. U.S. LE as well given that the actual perpetrators are there. Whether dutch, romanian or US law are able to take cognizance of publicly available information to open an investigation, or they need a local victim of IP hijacking (or an international victim through the normal LE channels) remains to be seen. In either case we do need to see how much RIPE NCC can do to exercise its fiduciary duty over v4 space. A bank manager who loaned money on the same slapdash implementation of criteria that NCC allocates IP space on (due diligence being interpreted as 'internet policing' might explain that) would be fired and/or prosecuted in very short order indeed. On Fri, 7 Nov 2014 at 02:21 Reza Mahmoudi wrote: > I was wondering if this kind of hijacking falls into the category of > Cybercrime and authorities like Europol (https://www.europol.europa.eu/ ) > can help? > > Reza Mahmoudi > ________________________________________ > From: anti-abuse-wg-bounces at ripe.net [anti-abuse-wg-bounces at ripe.net] on > behalf of Ronald F. Guilmette [rfg at tristatelogic.com] > Sent: Friday, November 07, 2014 12:02 AM > To: anti-abuse-wg at ripe.net > Subject: Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 > > In message <20141106150814.GX31092 at Space.Net>, > Gert Doering wrote: > > >In this particular case, I wonder why nobody is yelling at the upstream > >who is happily forward packets for that AS... due dilligence at > >accepting customer prefixes would have easily caught the announcements. > > I personally would be ``yelling at the upstream'' right now, but someone > made a comment on the NANOG mailing list which sort-of hinted that this > would be entirely futile in the case of AS200002. I don't know, but I > suspect that he already knows something that I don't know, so I'm not > wasting my time on sending comlaints to an entity that, it seems, may > perhaps not give a damn. > > >(Yes, I understand that I'm now officially part of the problem, as > >I'm obviously not willing to do everything technically possible to > >stop particular sorts of badness) > > To the extent that you might be able to avoid forwarding route > announcements which originate from AS201640, allow me to express > my personal opinion that doing so would be admirable. > > > Regards, > rfg > > > -- > This email was Virus checked by Juniper Security Gateway. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at velea.eu Fri Nov 7 03:53:48 2014 From: elvis at velea.eu (Elvis Daniel Velea) Date: Fri, 7 Nov 2014 02:53:48 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: References: <20141106150814.GX31092@Space.Net> <91408.1415305968@server1.tristatelogic.com> <9BF4935858C6234189573116954E7F6E4723D425@Mobinnetex01.mobinnet.net> Message-ID: <9085052988871123386@unknownmsgid> Nex time, before sending an e-mail learn how to use whois. the AS is assigned and used in Bulgaria and the Sponsoring LIR is also from Bulgaria (Nettera Ltd) Btw, how are the laws against spam in India? I see it's still in top 10 countries sending spam... Excuse the briefness of this mail, it was sent from a mobile device. On 07 Nov 2014, at 01:23, Suresh Ramasubramanian wrote: There are two or three things here. RIPE is under dutch law and the Netherlands does have a law against spam, and other cybercrime legislation as well that has historically been actively enforced. The LIR is under romanian law and that does appear to have some laws against spam on their books but none of it appears to have been tested in court. As a LE organization, Europol, like Interpol, deals with coordination and clearinghouse work between national LE and neither is an international police force. This simply means that LE or the appropriate regulator in either country where the different parts of this contract exist (the Netherlands - opta or dutch high tech crime police, and whoever are their peers in Romania) should be able to act on this information. U.S. LE as well given that the actual perpetrators are there. Whether dutch, romanian or US law are able to take cognizance of publicly available information to open an investigation, or they need a local victim of IP hijacking (or an international victim through the normal LE channels) remains to be seen. In either case we do need to see how much RIPE NCC can do to exercise its fiduciary duty over v4 space. A bank manager who loaned money on the same slapdash implementation of criteria that NCC allocates IP space on (due diligence being interpreted as 'internet policing' might explain that) would be fired and/or prosecuted in very short order indeed. On Fri, 7 Nov 2014 at 02:21 Reza Mahmoudi wrote: > I was wondering if this kind of hijacking falls into the category of > Cybercrime and authorities like Europol (https://www.europol.europa.eu/ ) > can help? > > Reza Mahmoudi > ________________________________________ > From: anti-abuse-wg-bounces at ripe.net [anti-abuse-wg-bounces at ripe.net] on > behalf of Ronald F. Guilmette [rfg at tristatelogic.com] > Sent: Friday, November 07, 2014 12:02 AM > To: anti-abuse-wg at ripe.net > Subject: Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 > > In message <20141106150814.GX31092 at Space.Net>, > Gert Doering wrote: > > >In this particular case, I wonder why nobody is yelling at the upstream > >who is happily forward packets for that AS... due dilligence at > >accepting customer prefixes would have easily caught the announcements. > > I personally would be ``yelling at the upstream'' right now, but someone > made a comment on the NANOG mailing list which sort-of hinted that this > would be entirely futile in the case of AS200002. I don't know, but I > suspect that he already knows something that I don't know, so I'm not > wasting my time on sending comlaints to an entity that, it seems, may > perhaps not give a damn. > > >(Yes, I understand that I'm now officially part of the problem, as > >I'm obviously not willing to do everything technically possible to > >stop particular sorts of badness) > > To the extent that you might be able to avoid forwarding route > announcements which originate from AS201640, allow me to express > my personal opinion that doing so would be admirable. > > > Regards, > rfg > > > -- > This email was Virus checked by Juniper Security Gateway. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Fri Nov 7 03:55:33 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 06 Nov 2014 18:55:33 -0800 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: Message-ID: <93498.1415328933@server1.tristatelogic.com> [[ I'm adopting now the new terminology that I learned yesterday. What has happened in this case, and what is happening, is ``IP squatting'' rather than ``IP hijacking'' because the IP space involved was not otherwise routed. ]] In message Suresh Ramasubramanian wrote: >This simply means that LE or the appropriate regulator in either country >where the different parts of this contract exist (the Netherlands - opta or >dutch high tech crime police, and whoever are their peers in Romania) >should be able to act on this information. Given the history of LE globally, specifically how ineffectual most of them end up being in these sorts of matters, particularly in the absence of readily identifiable monetary harm to some well-healed local or multinational corporation, I for one will not be holding my breath waiting for that particular cavalry to arrive and save the day. I would however like to see... and would most probably be satisfied with... some sort of a blacklist entry which would insure that these same miscreants are not able to sneak in and obtain any form of arguably legitimate number resource registrations again in the future, ever. However I am still mightily puzzled by by the question of how they managed to even get an AS number _this time_. As I understand it, an AS number is just a sort of device or artifice, useful when one needs to do some routing, i.e. of some IP space which one, presumably, already has a legitimate claim to. But as far as I can tell, this thing, MEGA - SPRED LTD, does not have, and indeed may never have had even a single IP address which was or is legitmately there's. Are AS numbers given out, by _any_ RiR, to people or entities which have -zero- IPs that need routing? >U.S. LE as well given that the actual perpetrators are there. As noted in the Krebs article, the spammer Michael Persaud, a resident of San Diego, California, claims to have simply contracted for rights to use some portion of the squatted IP space from some other party. Persaud did not give Krebs, the reporter, any indication of who or where that other party might be. Based on the evidence, a reasonable first order supposition might be that the other party in this case... the one which sold Persaud the squatted IP space... was most probably MEGA - SPRED LTD, which claims to be located in Sofia, Bulgaria. It would thus appear to be a vast over-simplification to say that ``the actual perpetrators are {located in the United States}'', and/or that thus, as a consequence, US LE would have even the slightest interest in this case. I would be willing to bet money right now that U.S. LE would have no such interest, even if they did take the time to speak with Persaud himself. He would just repeat the claim he's already made to Krebs, i.e. that he was simply duped by some fast-talking IP salesmen located elsewhere, and that he is as much of a victim as anybody. I would love to see U.S. LE nail him for violations of the CAN-SPAM Act (which he is apparently not fully complying with, i.e. by failing to provide a snail mail opt-out address in each spam), but as regards to his potentially non-existant role in the IP space squatting, I highly doubt that any evidence exists for that, either in the city of Sofia or elsewhere, which has not already been destroyed. No evidence means no case. More to the point however, as far as I know IP space squatting is not illegal under U.S. law, nor even under any of the many flavors of EU law. So the squatting itself is most likely non-prosecutable anywhere. (It might be an entirely different story if these ``squats'' had instead been actual ``hijacks'' and if some servers which had been located in the IP space involved had been effectively disconnected from the Internet due to one of these route announcements. But there is no evidence of that for any of these bogus route announcements.) Ignoring the legal non-issue of squatting, there is still the possibility of prosecutable fraud. Fraud is a fairly old, fairly well-defined, and fairly universal legal concept which is prosecutable virtually everywhere. If and only if MEGA - SPRED LTD submitted some false documentation to RIPE NCC, _and_ if RIPE NCC felt like pressing charges... which might not actually be worth either their time or effort to do... then European LE might perhaps become involved. But that is a lot of ``ifs''. As I've said, I for one will be happy if all that happens is that these bastards have their AS registration revoked, and if they are summarily kicked out of RIPE altogether, and permanently, and the sooner the better. Regards, rfg P.S. Among the many many things that I remain puzzled by about this case, I should mention also, just in passing, that I am puzzled by the fact that at least one Cisco security guy blogged about AS201640 and its hijacking activities over a month ago, documenting it rather admirably. Yet it seems that he made no effort at all to follow-up, e.g. to see if the one route hijack that he noticed and documented was going to be short-lived or long-lived, whether the AS in question was already known for this sort of thing, or whether the bogus route he blogged about had any brothers or sisters. (As we now know, it did, and does, and 100% of AS201640's routes appear to be of this bogus variety, and most probably always have been.) Are network security researchers everywhere nowadays so completely jaded about these kinds of events that new and blatant instances of route squatting/hijacking elicit no more than a yawn and a return to other business? If so, then I think we have bigger problems than just those generated by AS201640. (Of course it is possible that the Cisco guy in question _did_ notice, over a month ago, all of the badness that AS201640 was up to, and just didn't feel like sharing that information with anybody outside of Cicso. If so, then that is a trend which would worry me too... sort of like hording your own private stash of 0-days.) From ops.lists at gmail.com Fri Nov 7 04:05:50 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 7 Nov 2014 08:35:50 +0530 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <9085052988871123386@unknownmsgid> References: <20141106150814.GX31092@Space.Net> <91408.1415305968@server1.tristatelogic.com> <9BF4935858C6234189573116954E7F6E4723D425@Mobinnetex01.mobinnet.net> <9085052988871123386@unknownmsgid> Message-ID: This one is, yes. No shortage of previous incidents though as you're probably aware. Anyway the question before the house here is NCC policies, not which country a specific incident took place in. On Nov 7, 2014 8:23 AM, "Elvis Daniel Velea" wrote: > Nex time, before sending an e-mail learn how to use whois. > > the AS is assigned and used in Bulgaria and the Sponsoring LIR is also > from Bulgaria (Nettera Ltd) > > Btw, how are the laws against spam in India? I see it's still in top 10 > countries sending spam... > > Excuse the briefness of this mail, it was sent from a mobile device. > > On 07 Nov 2014, at 01:23, Suresh Ramasubramanian > wrote: > > There are two or three things here. > > RIPE is under dutch law and the Netherlands does have a law against spam, > and other cybercrime legislation as well that has historically been > actively enforced. > > The LIR is under romanian law and that does appear to have some laws > against spam on their books but none of it appears to have been tested in > court. > > As a LE organization, Europol, like Interpol, deals with coordination and > clearinghouse work between national LE and neither is an international > police force. > > This simply means that LE or the appropriate regulator in either country > where the different parts of this contract exist (the Netherlands - opta or > dutch high tech crime police, and whoever are their peers in Romania) > should be able to act on this information. > > U.S. LE as well given that the actual perpetrators are there. > > Whether dutch, romanian or US law are able to take cognizance of publicly > available information to open an investigation, or they need a local victim > of IP hijacking (or an international victim through the normal LE channels) > remains to be seen. > > In either case we do need to see how much RIPE NCC can do to exercise its > fiduciary duty over v4 space. > > A bank manager who loaned money on the same slapdash implementation of > criteria that NCC allocates IP space on (due diligence being interpreted as > 'internet policing' might explain that) would be fired and/or prosecuted in > very short order indeed. > On Fri, 7 Nov 2014 at 02:21 Reza Mahmoudi wrote: > >> I was wondering if this kind of hijacking falls into the category of >> Cybercrime and authorities like Europol (https://www.europol.europa.eu/ >> ) can help? >> >> Reza Mahmoudi >> ________________________________________ >> From: anti-abuse-wg-bounces at ripe.net [anti-abuse-wg-bounces at ripe.net] on >> behalf of Ronald F. Guilmette [rfg at tristatelogic.com] >> Sent: Friday, November 07, 2014 12:02 AM >> To: anti-abuse-wg at ripe.net >> Subject: Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 >> >> In message <20141106150814.GX31092 at Space.Net>, >> Gert Doering wrote: >> >> >In this particular case, I wonder why nobody is yelling at the upstream >> >who is happily forward packets for that AS... due dilligence at >> >accepting customer prefixes would have easily caught the announcements. >> >> I personally would be ``yelling at the upstream'' right now, but someone >> made a comment on the NANOG mailing list which sort-of hinted that this >> would be entirely futile in the case of AS200002. I don't know, but I >> suspect that he already knows something that I don't know, so I'm not >> wasting my time on sending comlaints to an entity that, it seems, may >> perhaps not give a damn. >> >> >(Yes, I understand that I'm now officially part of the problem, as >> >I'm obviously not willing to do everything technically possible to >> >stop particular sorts of badness) >> >> To the extent that you might be able to avoid forwarding route >> announcements which originate from AS201640, allow me to express >> my personal opinion that doing so would be admirable. >> >> >> Regards, >> rfg >> >> >> -- >> This email was Virus checked by Juniper Security Gateway. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at velea.eu Fri Nov 7 04:12:43 2014 From: elvis at velea.eu (Elvis Daniel Velea) Date: Fri, 7 Nov 2014 03:12:43 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: References: <20141106150814.GX31092@Space.Net> <91408.1415305968@server1.tristatelogic.com> <9BF4935858C6234189573116954E7F6E4723D425@Mobinnetex01.mobinnet.net> <9085052988871123386@unknownmsgid> Message-ID: <-827564976827469824@unknownmsgid> the policies are RIPE policies, NCC only has procedures. if you would be interested in the RIPE policies (and not only noise on this mailing list), you would have followed the discussions happening during the RIPE Meeting today; there was a lenghty discussion at the routing wg about this particular case and similar cases in general. regards, elvis Excuse the briefness of this mail, it was sent from a mobile device. On 07 Nov 2014, at 03:05, Suresh Ramasubramanian wrote: This one is, yes. No shortage of previous incidents though as you're probably aware. Anyway the question before the house here is NCC policies, not which country a specific incident took place in. On Nov 7, 2014 8:23 AM, "Elvis Daniel Velea" wrote: > Nex time, before sending an e-mail learn how to use whois. > > the AS is assigned and used in Bulgaria and the Sponsoring LIR is also > from Bulgaria (Nettera Ltd) > > Btw, how are the laws against spam in India? I see it's still in top 10 > countries sending spam... > > Excuse the briefness of this mail, it was sent from a mobile device. > > On 07 Nov 2014, at 01:23, Suresh Ramasubramanian > wrote: > > There are two or three things here. > > RIPE is under dutch law and the Netherlands does have a law against spam, > and other cybercrime legislation as well that has historically been > actively enforced. > > The LIR is under romanian law and that does appear to have some laws > against spam on their books but none of it appears to have been tested in > court. > > As a LE organization, Europol, like Interpol, deals with coordination and > clearinghouse work between national LE and neither is an international > police force. > > This simply means that LE or the appropriate regulator in either country > where the different parts of this contract exist (the Netherlands - opta or > dutch high tech crime police, and whoever are their peers in Romania) > should be able to act on this information. > > U.S. LE as well given that the actual perpetrators are there. > > Whether dutch, romanian or US law are able to take cognizance of publicly > available information to open an investigation, or they need a local victim > of IP hijacking (or an international victim through the normal LE channels) > remains to be seen. > > In either case we do need to see how much RIPE NCC can do to exercise its > fiduciary duty over v4 space. > > A bank manager who loaned money on the same slapdash implementation of > criteria that NCC allocates IP space on (due diligence being interpreted as > 'internet policing' might explain that) would be fired and/or prosecuted in > very short order indeed. > On Fri, 7 Nov 2014 at 02:21 Reza Mahmoudi wrote: > >> I was wondering if this kind of hijacking falls into the category of >> Cybercrime and authorities like Europol (https://www.europol.europa.eu/ >> ) can help? >> >> Reza Mahmoudi >> ________________________________________ >> From: anti-abuse-wg-bounces at ripe.net [anti-abuse-wg-bounces at ripe.net] on >> behalf of Ronald F. Guilmette [rfg at tristatelogic.com] >> Sent: Friday, November 07, 2014 12:02 AM >> To: anti-abuse-wg at ripe.net >> Subject: Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 >> >> In message <20141106150814.GX31092 at Space.Net>, >> Gert Doering wrote: >> >> >In this particular case, I wonder why nobody is yelling at the upstream >> >who is happily forward packets for that AS... due dilligence at >> >accepting customer prefixes would have easily caught the announcements. >> >> I personally would be ``yelling at the upstream'' right now, but someone >> made a comment on the NANOG mailing list which sort-of hinted that this >> would be entirely futile in the case of AS200002. I don't know, but I >> suspect that he already knows something that I don't know, so I'm not >> wasting my time on sending comlaints to an entity that, it seems, may >> perhaps not give a damn. >> >> >(Yes, I understand that I'm now officially part of the problem, as >> >I'm obviously not willing to do everything technically possible to >> >stop particular sorts of badness) >> >> To the extent that you might be able to avoid forwarding route >> announcements which originate from AS201640, allow me to express >> my personal opinion that doing so would be admirable. >> >> >> Regards, >> rfg >> >> >> -- >> This email was Virus checked by Juniper Security Gateway. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ops.lists at gmail.com Fri Nov 7 04:17:59 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 7 Nov 2014 08:47:59 +0530 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <-827564976827469824@unknownmsgid> References: <20141106150814.GX31092@Space.Net> <91408.1415305968@server1.tristatelogic.com> <9BF4935858C6234189573116954E7F6E4723D425@Mobinnetex01.mobinnet.net> <9085052988871123386@unknownmsgid> <-827564976827469824@unknownmsgid> Message-ID: I have been meaning to check the transcript later today so thanks for the information. On Nov 7, 2014 8:42 AM, "Elvis Daniel Velea" wrote: > the policies are RIPE policies, NCC only has procedures. > > if you would be interested in the RIPE policies (and not only noise on > this mailing list), you would have followed the discussions happening > during the RIPE Meeting today; there was a lenghty discussion at the > routing wg about this particular case and similar cases in general. > > regards, > elvis > > Excuse the briefness of this mail, it was sent from a mobile device. > > On 07 Nov 2014, at 03:05, Suresh Ramasubramanian > wrote: > > This one is, yes. > > No shortage of previous incidents though as you're probably aware. > > Anyway the question before the house here is NCC policies, not which > country a specific incident took place in. > On Nov 7, 2014 8:23 AM, "Elvis Daniel Velea" wrote: > >> Nex time, before sending an e-mail learn how to use whois. >> >> the AS is assigned and used in Bulgaria and the Sponsoring LIR is also >> from Bulgaria (Nettera Ltd) >> >> Btw, how are the laws against spam in India? I see it's still in top 10 >> countries sending spam... >> >> Excuse the briefness of this mail, it was sent from a mobile device. >> >> On 07 Nov 2014, at 01:23, Suresh Ramasubramanian >> wrote: >> >> There are two or three things here. >> >> RIPE is under dutch law and the Netherlands does have a law against spam, >> and other cybercrime legislation as well that has historically been >> actively enforced. >> >> The LIR is under romanian law and that does appear to have some laws >> against spam on their books but none of it appears to have been tested in >> court. >> >> As a LE organization, Europol, like Interpol, deals with coordination and >> clearinghouse work between national LE and neither is an international >> police force. >> >> This simply means that LE or the appropriate regulator in either country >> where the different parts of this contract exist (the Netherlands - opta or >> dutch high tech crime police, and whoever are their peers in Romania) >> should be able to act on this information. >> >> U.S. LE as well given that the actual perpetrators are there. >> >> Whether dutch, romanian or US law are able to take cognizance of publicly >> available information to open an investigation, or they need a local victim >> of IP hijacking (or an international victim through the normal LE channels) >> remains to be seen. >> >> In either case we do need to see how much RIPE NCC can do to exercise its >> fiduciary duty over v4 space. >> >> A bank manager who loaned money on the same slapdash implementation of >> criteria that NCC allocates IP space on (due diligence being interpreted as >> 'internet policing' might explain that) would be fired and/or prosecuted in >> very short order indeed. >> On Fri, 7 Nov 2014 at 02:21 Reza Mahmoudi >> wrote: >> >>> I was wondering if this kind of hijacking falls into the category of >>> Cybercrime and authorities like Europol (https://www.europol.europa.eu/ >>> ) can help? >>> >>> Reza Mahmoudi >>> ________________________________________ >>> From: anti-abuse-wg-bounces at ripe.net [anti-abuse-wg-bounces at ripe.net] >>> on behalf of Ronald F. Guilmette [rfg at tristatelogic.com] >>> Sent: Friday, November 07, 2014 12:02 AM >>> To: anti-abuse-wg at ripe.net >>> Subject: Re: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 >>> >>> In message <20141106150814.GX31092 at Space.Net>, >>> Gert Doering wrote: >>> >>> >In this particular case, I wonder why nobody is yelling at the upstream >>> >who is happily forward packets for that AS... due dilligence at >>> >accepting customer prefixes would have easily caught the announcements. >>> >>> I personally would be ``yelling at the upstream'' right now, but someone >>> made a comment on the NANOG mailing list which sort-of hinted that this >>> would be entirely futile in the case of AS200002. I don't know, but I >>> suspect that he already knows something that I don't know, so I'm not >>> wasting my time on sending comlaints to an entity that, it seems, may >>> perhaps not give a damn. >>> >>> >(Yes, I understand that I'm now officially part of the problem, as >>> >I'm obviously not willing to do everything technically possible to >>> >stop particular sorts of badness) >>> >>> To the extent that you might be able to avoid forwarding route >>> announcements which originate from AS201640, allow me to express >>> my personal opinion that doing so would be admirable. >>> >>> >>> Regards, >>> rfg >>> >>> >>> -- >>> This email was Virus checked by Juniper Security Gateway. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Fri Nov 7 04:35:28 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 06 Nov 2014 19:35:28 -0800 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: Message-ID: <93729.1415331328@server1.tristatelogic.com> I wrote: >Ignoring the legal non-issue of squatting, there is still the possibility >of prosecutable fraud. I just realized that this raises yet another question... In the case of the contracts that RIPE enters into with parties that request AS number assignments, do these contracts routinely include any clause or provision which legally binds the entity in question to only announce routes to IP space which has been formally registered to that entity, or to one of that entity's customers, by one of the Regional Internet Registries, i.e. ARIN, RIPE, APNIC, LACNIC, or AFRINIC? If not, why not? Perhaps there is/are some technical reasons (that I don't know about) why that sort of contractual provision would be technically unworkable. But if not, then this would seem to be a reasonable obligation to include in such contracts, perhaps along with some language that makes it clear that _willful_ violations will be prosecuted to the full extent of the law (as contract fraud). (Obviously it would be silly for RIPE to go around suing people for foolish, inadvertant, unintentional, and short-lived ``fat finger'' incidents, and I would expect that RIPE would never actually do so. But it would be helpful, I think, when situations like this one with AS201640 come up, for RIPE to at least have the clear legal option to come down hard on a party that is enjoying the many benefits of RIPE membership... e.g the ability for formally register their own AS number... even as they flagrantly violate the well-accepted norms of the community, e.g. by announcing and maintaining, over an extended period of time, routes to IP space that isn't their's to route.) Regards, rfg From rfg at tristatelogic.com Fri Nov 7 04:41:20 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 06 Nov 2014 19:41:20 -0800 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <-827564976827469824@unknownmsgid> Message-ID: <93767.1415331680@server1.tristatelogic.com> In message <-827564976827469824 at unknownmsgid>, Elvis Daniel Velea wrote: >if you would be interested in the RIPE policies (and not only noise on this >mailing list), you would have followed the discussions happening during the >RIPE Meeting today; there was a lenghty discussion at the routing wg about >this particular case and similar cases in general. Would it be possible for you, or anyone else who attended to provide a brief summary of the discussion at that meeting, for the benefit of those of us who were not able to attend? If so, that would be greatly appreciated. Regards, rfg From nibbler at nibbler.de Fri Nov 7 05:23:52 2014 From: nibbler at nibbler.de (Michael Horn) Date: Fri, 7 Nov 2014 05:23:52 +0100 Subject: [anti-abuse-wg] Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud In-Reply-To: References: <81757.1415224757@server1.tristatelogic.com> Message-ID: <20141107052352.4e01cacd@carbonium> Just to get to the bottom of ripe-policy-addressable parts of this issue... are there any statistics on the legitimate and necessary usage of RIPE-NCC-RPSL-MNT? How reasonable would it be to do either one (or a combination) of these: a) deprecate this mechanism entirely b) devise a way to (manually and/or automagically) check if the respective usage in a certain case is legitimate c) check existing objects for likeliness of fraudulent usage (in coordination with the legitimate address space users) It seems that all route-objects in the ripe db that can be viewed via "whois -i or AS201640" were "authenticated" via RIPE-NCC-RPSL-MNT. From my point of view, this would be an obvious "it's about time"-thing to tackle by means of a policy change or change of operational procedures, employing the above mentioned measures, in order to combat the potential abuse of this aged and imperfect puzzle piece of RPSL goodness. A quick check however revealed that there is a humongous amount of objects affected. So any of those proposed options but a) will result in significant workload. Holy dingus, is this database a mess... -mh From gert at space.net Fri Nov 7 12:25:19 2014 From: gert at space.net (Gert Doering) Date: Fri, 7 Nov 2014 12:25:19 +0100 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <91408.1415305968@server1.tristatelogic.com> References: <20141106150814.GX31092@Space.Net> <91408.1415305968@server1.tristatelogic.com> Message-ID: <20141107112519.GD31092@Space.Net> Hi, On Thu, Nov 06, 2014 at 12:32:48PM -0800, Ronald F. Guilmette wrote: > In message <20141106150814.GX31092 at Space.Net>, > Gert Doering wrote: [..] > >(Yes, I understand that I'm now officially part of the problem, as > >I'm obviously not willing to do everything technically possible to > >stop particular sorts of badness) > > To the extent that you might be able to avoid forwarding route > announcements which originate from AS201640, allow me to express > my personal opinion that doing so would be admirable. This is, unfortunately, something where I have only very limited influence - our AS (5539) is mostly a leaf AS, so if I do not accept prefixes from this AS (which we indeed could and might do), the fraction of Internet users that will no longer see 201640 is very small. I'm certainly willing to help with the database issue that people can register "out of region" route: objects in the RIPE DB - which was, back in the day, fully intentional to be able to actually register a *legitimate* routing policy that involves customers that legitimately(!) hold out-of-region IP networks (e.g. due to international companies being active in multiple regions, or legacy networks that came from InterNIC). Now this is backfiring, and discussion (in the routing and database working group) has already started how to handle this without causing collateral damage. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From gert at space.net Fri Nov 7 12:34:56 2014 From: gert at space.net (Gert Doering) Date: Fri, 7 Nov 2014 12:34:56 +0100 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <93729.1415331328@server1.tristatelogic.com> References: <93729.1415331328@server1.tristatelogic.com> Message-ID: <20141107113456.GE31092@Space.Net> Hi, On Thu, Nov 06, 2014 at 07:35:28PM -0800, Ronald F. Guilmette wrote: > >Ignoring the legal non-issue of squatting, there is still the possibility > >of prosecutable fraud. > > I just realized that this raises yet another question... > > In the case of the contracts that RIPE enters into with parties that > request AS number assignments, do these contracts routinely include > any clause or provision which legally binds the entity in question to > only announce routes to IP space which has been formally registered > to that entity, or to one of that entity's customers, by one of the > Regional Internet Registries, i.e. ARIN, RIPE, APNIC, LACNIC, or AFRINIC? > > If not, why not? These are valid questions. I think the main reason is history and decoupling between "resource management" (= handing out AS numbers, and having a contract that primarily ensures we know where they go to) and "operations" (= what people actually *do* with these AS numbers, and whether we like it or not). Need to think more about this and talk to people and see whether this can be done (legal framework) and how our policies would be to get there (formal policy proposal in anti-abuse?). OTOH, the existing contracts people need to sign *do* contain clauses that resource holders will abide "all RIPE policies" (or such), so the contracts in place could be good enough if the policies are made clear... as always, there's legitimate cases which we don't know about, so policy texting is never easy. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From lists-ripe at c4inet.net Sat Nov 8 00:23:37 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 7 Nov 2014 23:23:37 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <20141107113456.GE31092@Space.Net> References: <93729.1415331328@server1.tristatelogic.com> <20141107113456.GE31092@Space.Net> Message-ID: <20141107232337.GB58817@cilantro.c4inet.net> On Fri, Nov 07, 2014 at 12:34:56PM +0100, Gert Doering wrote: >there (formal policy proposal in anti-abuse?). NO. Please NO. put any such proposals in apwg, where they belong. I cannot be that address policy that affects *every* member is made on a mailing list that few people read (largely due to the noise and regular incoherent ranting). I would consider any "consensus" reached in this way invalid. It's the equivalent of approving ACTA at 2am in the Fisheries Commission session (yup, that happened) I would also note that the only WG whose charter explicitly permits policy-making is address-policy and I think that was the intention. (ergo the above goes for any other "special interest" WG as well. >OTOH, the existing contracts people need to sign *do* contain clauses >that resource holders will abide "all RIPE policies" (or such), so Indeed and penalties for non-compliance exist. rgds, Sascha Luck From lists-ripe at c4inet.net Sat Nov 8 00:31:23 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 7 Nov 2014 23:31:23 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <93729.1415331328@server1.tristatelogic.com> References: <93729.1415331328@server1.tristatelogic.com> Message-ID: <20141107233123.GC58817@cilantro.c4inet.net> On Thu, Nov 06, 2014 at 07:35:28PM -0800, Ronald F. Guilmette wrote: >in such contracts, perhaps along with some language that makes it clear >that _willful_ violations will be prosecuted to the full extent of the >law (as contract fraud). I'm pretty certain, most members do *not* want higher fees in order to prosecute dead-horse lawsuits. Besides, an ASN is not some bit of magic that only a RIR can create, it is a simple number and one can pick any of them and advertise networks through it. Having it registered merely increases the likelihood that an upstream will route it... rgds, Sascha Luck From ops.lists at gmail.com Sat Nov 8 01:03:57 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sat, 08 Nov 2014 00:03:57 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 References: <93729.1415331328@server1.tristatelogic.com> <20141107113456.GE31092@Space.Net> <20141107232337.GB58817@cilantro.c4inet.net> Message-ID: Throwing Richard Cox out of a wg vice chair role in an AOB session where lots of regulars from other parts of the ripe meeting just happened to wander in happened too, not too long back, so please don't remind me about ACTA. As for the policy proposal I assume whoever makes it will make it in public and with drafts posted here so you're entirely free not to vote for it. But I doubt you or anyone else can ask to stop any proposal at all being placed on the agenda. Whether or not it gets consensus is a different next step. On Sat, 8 Nov 2014 at 04:54 Sascha Luck wrote: > On Fri, Nov 07, 2014 at 12:34:56PM +0100, Gert Doering wrote: > >there (formal policy proposal in anti-abuse?). > > NO. Please NO. > > put any such proposals in apwg, where they belong. > I cannot be that address policy that affects *every* member is > made on a mailing list that few people read (largely due to the > noise and regular incoherent ranting). > > I would consider any "consensus" reached in this way invalid. > It's the equivalent of approving ACTA at 2am in the Fisheries > Commission session (yup, that happened) > > I would also note that the only WG whose charter explicitly > permits policy-making is address-policy and I think that was the > intention. (ergo the above goes for any other "special interest" > WG as well. > > >OTOH, the existing contracts people need to sign *do* contain clauses > >that resource holders will abide "all RIPE policies" (or such), so > > Indeed and penalties for non-compliance exist. > > rgds, > Sascha Luck > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists-ripe at c4inet.net Sat Nov 8 01:53:03 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Sat, 8 Nov 2014 00:53:03 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: References: <93729.1415331328@server1.tristatelogic.com> <20141107113456.GE31092@Space.Net> <20141107232337.GB58817@cilantro.c4inet.net> Message-ID: <20141108005303.GD58817@cilantro.c4inet.net> On Sat, Nov 08, 2014 at 12:03:57AM +0000, Suresh Ramasubramanian wrote: >But I doubt you or anyone else can ask to stop any proposal at all being >placed on the agenda. Whether or not it gets consensus is a different next Just. Try. Me. This goes to the full forum or it goes nowhere. From rfg at tristatelogic.com Sat Nov 8 04:33:26 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 07 Nov 2014 19:33:26 -0800 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <20141107233123.GC58817@cilantro.c4inet.net> Message-ID: <1700.1415417606@server1.tristatelogic.com> In message <20141107233123.GC58817 at cilantro.c4inet.net>, Sascha Luck wrote: >On Thu, Nov 06, 2014 at 07:35:28PM -0800, Ronald F. Guilmette wrote: >>in such contracts, perhaps along with some language that makes it clear >>that _willful_ violations will be prosecuted to the full extent of the >>law (as contract fraud). > >I'm pretty certain, most members do *not* want higher fees in order >to prosecute dead-horse lawsuits. To be clear, I did not say that RIPE should routinely be initiating lawsuits. However in cases such as this present one with AS201640, I do think that RIPE NCC would have a lot more leverage in its efforts to cause the hijacking (or squatting) to quickly stop if they were in a position to _threaten_ the perpetrator with massive damages. For example, back when I first noticed this situation, On October 31st, AS201640 was announcing illegitimate routes to 48,384 IPv4 addresses. But it appears that it may have been doing something like that for a period of perhaps two full months. Now, imagine that MEGA - SPRED's contract with RIPE said that it would pay liquidated damages of, say, one euro for each day and for each IP address that was improperly routed. You do the math... forty eight thousand euros times sixty days. If that was the penalty, don't you think that a simple phone call or e-mail from RIPE NCC to MEGA - SPRED, reminding them of the contract terms, might possibly have a helpful effect in bringing this situation to a speedy close? I do. One thing _is_ perfectly clear and apparent... Whatever _is_ being done now to try to stop this madness, and MEGA - SPRED's *ongoing* route squatting (and the help it is providing to spammers and who knows what other sorts of criminals), it is not working. AS201640 is *still* announcing fully eight bogus routes as we speak. If you think this is all just fine, then yes, the solution is to do absolutely nothing. So far, all of RIPE seems to be very good at doing exactly that. Regards, rfg From gert at space.net Sat Nov 8 18:40:31 2014 From: gert at space.net (Gert Doering) Date: Sat, 8 Nov 2014 18:40:31 +0100 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: References: <93729.1415331328@server1.tristatelogic.com> <20141107113456.GE31092@Space.Net> <20141107232337.GB58817@cilantro.c4inet.net> Message-ID: <20141108174031.GH31092@Space.Net> Hi, On Sat, Nov 08, 2014 at 12:03:57AM +0000, Suresh Ramasubramanian wrote: > Throwing Richard Cox out of a wg vice chair role in an AOB session where > lots of regulars from other parts of the ripe meeting just happened to > wander in happened too, not too long back, so please don't remind me about > ACTA. > > As for the policy proposal I assume whoever makes it will make it in public > and with drafts posted here so you're entirely free not to vote for it. > > But I doubt you or anyone else can ask to stop any proposal at all being > placed on the agenda. Whether or not it gets consensus is a different next > step. Well, actually the chair *is* free to reject a formal(!) policy proposal if it better fits into another WG, and the other chair is happy to take it - you know, there's a well-defined formal policy development process, and "WG chair accepts proposal" is one of the first steps... Anyway, I'm not sure I agree or disagree with Sascha - it affects address policy (which covers AS numbers), OTOH, the anti-abuse WG is free to come to consensus and send over messages to other working groups. If it happens in AP, you have the "policy community" scrutiny it, but they might not fully understand the underlying abuse issues - so input would be needed to demonstrate why this would be a necessary change. If it happens here, the abuse side of things is understood, but the secondary implications on "legitimate use cases" might not be (see the question about "why can an AS number be assigned to an entity that is not actually announcing any own space"). But then, WG chairs have been overheard to talk to each other, so WGs can coordinate closely if useful. Gert Doering -- member of the abuse-wg, chair of the AP WG -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From rfg at tristatelogic.com Sat Nov 8 21:11:48 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 08 Nov 2014 12:11:48 -0800 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <20141108005303.GD58817@cilantro.c4inet.net> Message-ID: <8940.1415477508@server1.tristatelogic.com> In message <20141108005303.GD58817 at cilantro.c4inet.net>, Sascha Luck wrote: >On Sat, Nov 08, 2014 at 12:03:57AM +0000, Suresh Ramasubramanian wrote: >>But I doubt you or anyone else can ask to stop any proposal at all being >>placed on the agenda. Whether or not it gets consensus is a different next > >Just. Try. Me. This goes to the full forum or it goes nowhere. "This" what? Other than my own rather informal suggestion that contract terms and expectation could be made more plain, I don't recall having seen anything specific put forward here would might even vaguely be called an actual "proposal". So I'm mystified about what it is that you are, I gather, opposed to. Regards, rfg From lists-ripe at c4inet.net Sun Nov 9 14:55:21 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Sun, 9 Nov 2014 13:55:21 +0000 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <8940.1415477508@server1.tristatelogic.com> References: <20141108005303.GD58817@cilantro.c4inet.net> <8940.1415477508@server1.tristatelogic.com> Message-ID: <20141109135521.GF58817@cilantro.c4inet.net> On Sat, Nov 08, 2014 at 12:11:48PM -0800, Ronald F. Guilmette wrote: >Other than my own rather informal suggestion that contract terms and >expectation could be made more plain, I don't recall having seen >anything specific put forward here would might even vaguely be called >an actual "proposal". So I'm mystified about what it is that you >are, I gather, opposed to. I'm opposed to this recent trend of wanting to make policy "in the back room". Traditionally, the forum to debate and agree policy proposals is the address-policy WG which also has the most subscribers (although participation is lower than I'd like to see there, too). Only in the last couple of years has there been a trend to attempt to make policy in the "specialist" WGs. Policy-making at RIPE needs all the democracy it can get and my intention is to prevent "disenfranchisement" of stakeholders who do not want to (or can't) be subscribed to every ML there is. This does not affect my opposition to the matter in hand, but I reserve argument until something more concrete is on the table. > rgds, Sascha Luck From gert at space.net Sun Nov 9 19:44:32 2014 From: gert at space.net (Gert Doering) Date: Sun, 9 Nov 2014 19:44:32 +0100 Subject: [anti-abuse-wg] Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud In-Reply-To: <20141107052352.4e01cacd@carbonium> References: <81757.1415224757@server1.tristatelogic.com> <20141107052352.4e01cacd@carbonium> Message-ID: <20141109184432.GO31092@Space.Net> Hi, On Fri, Nov 07, 2014 at 05:23:52AM +0100, Michael Horn wrote: > Just to get to the bottom of ripe-policy-addressable parts of this > issue... are there any statistics on the legitimate and necessary usage > of RIPE-NCC-RPSL-MNT? I have no statistics. The legitimate and necessary usage is if you want to document your routing policy in the RIPE region but happen to have out of region networks "in your AS", for whatever reason. Now, enabling creation of database entries without authentication for the good guys (because we had no idea how to *do* authentication for these objects, the RPSL-dist-auth drafts didn't really fly) also enables this attack angle. > How reasonable would it be to do either one (or a combination) of these: > > a) deprecate this mechanism entirely > b) devise a way to (manually and/or automagically) check if the > respective usage in a certain case is legitimate > c) check existing objects for likeliness of fraudulent usage > (in coordination with the legitimate address space users) This mechanism needs to go away, and I think everybody agrees here. George Michaelson's idea to use RPKI to permit foreign-region entries into the RIPE DB ("if the ROA validates, route: objects may be created") might work out nicely (or not, for legacy resources that currently cannot get an ROA) - or Kaveh's approach to refuse creation of route: objects for those with a conflicting ROA. Sounds similar, isn't :-) c) might actually be not that hard ("just check the originating database if a route: or ROA exists") but will quite likely turn up a pile of old and non-maintained junk, so be a lot of work... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From rfg at tristatelogic.com Sun Nov 9 19:57:36 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 09 Nov 2014 10:57:36 -0800 Subject: [anti-abuse-wg] Hijack Factory: AS201640 / AS200002 In-Reply-To: <20141109135521.GF58817@cilantro.c4inet.net> Message-ID: <18571.1415559456@server1.tristatelogic.com> In message <20141109135521.GF58817 at cilantro.c4inet.net>, Sascha Luck wrote: >On Sat, Nov 08, 2014 at 12:11:48PM -0800, Ronald F. Guilmette wrote: >>Other than my own rather informal suggestion that contract terms and >>expectation could be made more plain, I don't recall having seen >>anything specific put forward here would might even vaguely be called >>an actual "proposal". So I'm mystified about what it is that you >>are, I gather, opposed to. > >I'm opposed to this recent trend of wanting to make policy "in >the back room". Traditionally, the forum to debate and agree >policy proposals is the address-policy WG which also has the most >subscribers (although participation is lower than I'd like to see >there, too). Only in the last couple of years has there been a >trend to attempt to make policy in the "specialist" WGs. > >Policy-making at RIPE needs all the democracy it can get and my >intention is to prevent "disenfranchisement" of stakeholders who >do not want to (or can't) be subscribed to every ML there is. Well, I personally am totally unaware of this trend you speak of, but I do agree that any policy that is likely to affect all of RIPE must be debated and agreed by all of RIPE. That is, quite obviously, fair and reasonable. However having said that, I'd just also like to point out that in legislative bodies worldwide, it is not at all unusual for some matters to be delegated to either legislative committees or subcommittees, in the first instance, before they are forwarded to the entire body for consideration. Is this not the way your own Parliment works? This committee/subcommittee approach does not preclude consideration of any and all matters by the full body. The full body still gets to have the final word on any and all matters. But it is often viewed as an efficient way of proceeding to have matters considered, in the first instance, by committees composed of those members with the greatest interest in and the greates familiarity with a certain area before they are taken up by the full body. Does that seem inappropriate to you? >This does not affect my opposition to the matter in hand... Again, I'm trying to understand what it is that you are opposed to with respect to ``the matter in hand''. Can you elaborate? From mir at ripe.net Tue Nov 11 13:19:09 2014 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 11 Nov 2014 13:19:09 +0100 Subject: [anti-abuse-wg] New on RIPE Labs: ECDSA and DNSSEC by Geoff Huston Message-ID: <5461FEBD.8050901@ripe.net> Dear colleagues, Please find another security related article by Geoff Huston on RIPE Labs: Elliptic Curve Digital Signature Algorithm (ECDSA) and DNSSEC https://labs.ripe.net/Members/gih/ecdsa-and-dnssec Kind regards, Mirjam Kuehne RIPE NCC From mir at ripe.net Thu Nov 13 17:05:25 2014 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 13 Nov 2014 17:05:25 +0100 Subject: [anti-abuse-wg] New on RIPE Labs: Who's Watching Message-ID: <5464D6C5.9000705@ripe.net> Dear colleagues, For those of you who missed Geoff Huston's "Who's Watching" lightning talk during RIPE 69, the write-up is now on RIPE Labs: https://labs.ripe.net/Members/gih/whos-watching Kind regards, Mirjam Kuehne RIPE NCC From ops.lists at gmail.com Fri Nov 14 13:47:24 2014 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 14 Nov 2014 18:17:24 +0530 Subject: [anti-abuse-wg] Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud In-Reply-To: <20141109184432.GO31092@Space.Net> References: <81757.1415224757@server1.tristatelogic.com> <20141107052352.4e01cacd@carbonium> <20141109184432.GO31092@Space.Net> Message-ID: On Mon, Nov 10, 2014 at 12:14 AM, Gert Doering wrote: > Now, enabling creation of database entries without authentication for > the good guys (because we had no idea how to *do* authentication for > these objects, the RPSL-dist-auth drafts didn't really fly) also enables > this attack angle. And Krebs weighs in with episode #2 - now with additional statements from RIPE NCC, and documenting the scale of this hijack. http://krebsonsecurity.com/2014/11/network-hijackers-exploit-technical-loophole/ --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From rfg at tristatelogic.com Sun Nov 16 21:13:08 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 16 Nov 2014 12:13:08 -0800 Subject: [anti-abuse-wg] Fwd: Hijack factory: AS201640 -- MEGA - SPRED LTD / Michael A. Persaud In-Reply-To: Message-ID: <26407.1416168788@server1.tristatelogic.com> In message Suresh Ramasubramanian wrote: >http://krebsonsecurity.com/2014/11/network-hijackers-exploit-technical-loophole/ I just want to apologize, publically, to everyone in RIPE NCC and the RIPE community generally, for some of the quotes attributed to me in the Krebs online article about this story/issue. Some of what he quoted me as saying was, I feel, taken out of context, and I'm not entirely happy that my comments about this situation came off as being overly critical of RIPE NCC and/or the RIPE community. I understand that there are difficult issues involved here, and that while technical measures (e.g. RPKI) might help to reduce the frequency of this sort of event, even those things are dependent upon a universal or nearly universal community acceptance and ratification of some hypothetical new requirement for that... an acceptance which is not in fact universal within the RIPE community at the present time. Regards, rfg From rfg at tristatelogic.com Mon Nov 17 04:32:25 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 16 Nov 2014 19:32:25 -0800 Subject: [anti-abuse-wg] AS43890 Message-ID: <29441.1416195145@server1.tristatelogic.com> Based upon the information I am currently looking at (see below) I now believe that it was perhaps a mistake for myself, and possibly others, to have become focused on the issue of insuring the correctness and/or validity of route objects within the RIPE data base only in those cases where the IP blocks in question are under the dominion of other (non-RIPE) RiRs. It now seems certain to me that the absence of anything even remotely approximating proper validation of RIPE route objects is not, in fact, a problem which is limited to just inter-RiR situations. Apparently, RIPE member LIRs can just as easily hijack the IP blocks of other RIPE members as they can in the case of IP blocks belonging to parties in other regions. Also, RIPE-resident hijackers can just as easily place validating route objects for these hijacked RIPE-issued IP blocks into the RIPE DB as they can for any other hijacked blocks taken from any other region(s). Readily available public data indicates that approximately three weeks ago, on or about October 25th, AS197207, an Iranian ISP, began announcing the following routes to the following chunks of its own properly registered IP space: 31.2.128.0/17 46.51.0.0/17 95.64.0.0/17 164.138.128.0/18 188.229.0.0/17 Prior to AS197207's decision to begin announcing the above routes (which they did, starting on Oct. 25th), it appears that the proprietors of AS43890, a Romanian ISP and RIPE LIR in good standing, apparently elected to announce their own set of routes to some or all of the above Iranian IP blocks, using lots and lots of little deaggregated /24 announcements to do so. Evidence in my possession indicates that some of the /24 blocks in question were in fact used by so-called ``snowshoe spammers'' during the time when AS43890 (aka "Netserv Consult SRL") was routing these blocks. This fact leads me to believe that the proprietor(s) of AS43890 most probably did not in fact have anything like real authorization from AS197207 to announce routes to any of the Iranian AS197207's legitimately registered IP space. Further and additionally, as in the recent case involving (Bulgarian) AS201640, it appears that (Romanian) AS43890 also and likewise created multiple route objects within the RIPE data base as a way of legitimizing what appears to me to have been several substantial IP space hijackings. Lastly, many, most, or all of the fradulent route objects created by AS43890 are still present within the RIPE data base, as of today. I am including a list of all 61 of these below. As was the case with the fradulent route objects created within the RIPE DB by AS201640, these 61 apparently fradulent route objects which were created by the proprietor(s) of AS43890 have likewise also been imported into the MERIT RADb, from the RIPE DB, thus spreading the bogus ``authorization'' to route these blocks even further, in a manner not unlike a viral contaminant. Regards, rfg ======================================================================= route: 188.229.1.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.2.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.3.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.9.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.11.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.16.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.17.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.18.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.19.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.20.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.21.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.22.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.23.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.33.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.35.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.36.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.38.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.39.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.49.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.50.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.51.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.52.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.53.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.54.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.55.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.66.0/24 descr: Netserv Clinet origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.89.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.90.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.91.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.92.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.93.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.94.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.95.0/24 descr: Enternet Land SRL origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.96.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.97.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.98.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.99.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.100.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.101.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.102.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.103.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.104.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.105.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.106.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.107.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.108.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.109.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.110.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.111.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.113.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.114.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.117.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.118.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.119.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.120.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.121.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.122.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.123.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.124.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.125.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered route: 188.229.126.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered From sander at steffann.nl Mon Nov 17 09:21:23 2014 From: sander at steffann.nl (Sander Steffann) Date: Mon, 17 Nov 2014 11:21:23 +0300 Subject: [anti-abuse-wg] AS43890 In-Reply-To: <29441.1416195145@server1.tristatelogic.com> References: <29441.1416195145@server1.tristatelogic.com> Message-ID: Hi Ronald, > It now seems certain to me that the absence of anything even remotely > approximating proper validation of RIPE route objects is not, in fact, > a problem which is limited to just inter-RiR situations. Apparently, > RIPE member LIRs can just as easily hijack the IP blocks of other > RIPE members as they can in the case of IP blocks belonging to parties > in other regions. I don't think so... To be able to create the route object route: 188.229.1.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE Authorisation from both the address block inetnum: 188.229.0.0 - 188.229.63.255 netname: LTE-4G descr: new service for data country: IR admin-c: RL7844-RIPE tech-c: RL7844-RIPE status: ASSIGNED PA mnt-by: MCCI-MNT source: RIPE and the AS number aut-num: AS43890 as-name: NETSERV-AS descr: Netserv Consult SRL [...] org: ORG-SNCS6-RIPE status: ASSIGNED mnt-by: NETSERV-MNT mnt-by: RIPE-NCC-END-MNT mnt-routes: NETSERV-MNT source: RIPE is required. So the route cannot be created unless MCCI-MNT and NETSERV-MNT both authorise it. I understand that the route objects look a little weird, but what makes you think that it is an authorisation problem in the RIPE DB that made it possible for someone to create them? Cheers, Sander From furio+as at spin.it Mon Nov 17 09:40:05 2014 From: furio+as at spin.it (furio ercolessi) Date: Mon, 17 Nov 2014 09:40:05 +0100 Subject: [anti-abuse-wg] AS43890 In-Reply-To: References: <29441.1416195145@server1.tristatelogic.com> Message-ID: <20141117084005.GA16812@spin.it> On Mon, Nov 17, 2014 at 11:21:23AM +0300, Sander Steffann wrote: > Hi Ronald, > > > It now seems certain to me that the absence of anything even remotely > > approximating proper validation of RIPE route objects is not, in fact, > > a problem which is limited to just inter-RiR situations. Apparently, > > RIPE member LIRs can just as easily hijack the IP blocks of other > > RIPE members as they can in the case of IP blocks belonging to parties > > in other regions. > > I don't think so... > > To be able to create the route object > > route: 188.229.1.0/24 > descr: Netserv-Client > origin: AS43890 > mnt-by: NETSERV-MNT > source: RIPE > > Authorisation from both the address block > > inetnum: 188.229.0.0 - 188.229.63.255 > netname: LTE-4G > descr: new service for data > country: IR > admin-c: RL7844-RIPE > tech-c: RL7844-RIPE > status: ASSIGNED PA > mnt-by: MCCI-MNT > source: RIPE > > and the AS number > > aut-num: AS43890 > as-name: NETSERV-AS > descr: Netserv Consult SRL > [...] > org: ORG-SNCS6-RIPE > status: ASSIGNED > mnt-by: NETSERV-MNT > mnt-by: RIPE-NCC-END-MNT > mnt-routes: NETSERV-MNT > source: RIPE > > is required. So the route cannot be created unless MCCI-MNT and NETSERV-MNT both authorise it. The assignment of 188.229.0.0/17 to mci.ir is relatively recent, probably issued: changed: hostmaster at ripe.net 20141027 Previously it was inetnum: 188.229.0.0 - 188.229.127.255 netname: RO-NETSERV-20090729 descr: Netserv Consult SRL country: RO org: ORG-NCS8-RIPE admin-c: MINC-RIPE tech-c: NSC-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: NETSERV-MNT mnt-routes: NETSERV-MNT mnt-domains: NETSERV-MNT remarks: ------------------------------------ remarks: | Abuse e-mail: abuse at netserv.ro | remarks: | Support e-mail: support at netserv.ro | remarks: | Support phone: 4-0745888222 | remarks: ------------------------------------ and it indeed appeared to be leased to snowshoe spammers in its entirety. Similarly, inetnum: 31.2.128.0 - 31.2.255.255 netname: RO-NETSERV-20110405 descr: NETSERV CONSULT SRL country: RO org: ORG-NCS8-RIPE admin-c: MINC-RIPE tech-c: NSC-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: NETSERV-MNT mnt-routes: NETSERV-MNT mnt-domains: NETSERV-MNT remarks: ------------------------------------ remarks: | Abuse e-mail: abuse at netserv.ro | remarks: | Support e-mail: support at netserv.ro | remarks: | Support phone: 4-0745888222 | remarks: ------------------------------------ inetnum: 46.51.0.0 - 46.51.127.255 netname: RO-NETSERV-20100727 descr: Netserv Consult SRL country: RO org: ORG-NCS8-RIPE admin-c: MINC-RIPE tech-c: NSC-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: NETSERV-MNT mnt-routes: NETSERV-MNT mnt-domains: NETSERV-MNT remarks: ------------------------------------ remarks: | Abuse e-mail: abuse at netserv.ro | remarks: | Support e-mail: support at netserv.ro | remarks: | Support phone: 4-0745888222 | remarks: ------------------------------------ inetnum: 95.64.0.0 - 95.64.127.255 netname: RO-NETSERV-20081023 descr: Netserv Consult SRL country: RO org: ORG-NCS8-RIPE admin-c: MINC-RIPE tech-c: NSC-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: NETSERV-MNT mnt-routes: NETSERV-MNT mnt-domains: NETSERV-MNT remarks: ------------------------------------ remarks: | Abuse e-mail: abuse at netserv.ro | remarks: | Support e-mail: support at netserv.ro | remarks: | Support phone: 4-0745888222 | remarks: ------------------------------------ inetnum: 164.138.128.0 - 164.138.191.255 netname: RO-NETSERV-20120319 descr: NETSERV CONSULT SRL country: RO org: ORG-NCS8-RIPE admin-c: MINC-RIPE tech-c: NSC-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: NETSERV-MNT mnt-routes: NETSERV-MNT mnt-domains: NETSERV-MNT remarks: ------------------------------------ remarks: | Abuse e-mail: abuse at netserv.ro | remarks: | Support e-mail: support at netserv.ro | remarks: | Support phone: 4-0745888222 | remarks: ------------------------------------ So a possible scenario is that MCI.ir was in real need for IPv4 space, went on the market, found Netserv that had plenty of it unused (sort of) and made a deal with them. furio From gert at space.net Mon Nov 17 09:46:33 2014 From: gert at space.net (Gert Doering) Date: Mon, 17 Nov 2014 09:46:33 +0100 Subject: [anti-abuse-wg] [routing-wg] AS43890 In-Reply-To: <29441.1416195145@server1.tristatelogic.com> References: <29441.1416195145@server1.tristatelogic.com> Message-ID: <20141117084633.GA20482@Space.Net> Hi, On Sun, Nov 16, 2014 at 07:32:25PM -0800, Ronald F. Guilmette wrote: > Based upon the information I am currently looking at (see below) I now > believe that it was perhaps a mistake for myself, and possibly others, > to have become focused on the issue of insuring the correctness and/or > validity of route objects within the RIPE data base only in those cases > where the IP blocks in question are under the dominion of other (non-RIPE) > RiRs. > > It now seems certain to me that the absence of anything even remotely > approximating proper validation of RIPE route objects is not, in fact, > a problem which is limited to just inter-RiR situations. Apparently, > RIPE member LIRs can just as easily hijack the IP blocks of other > RIPE members as they can in the case of IP blocks belonging to parties > in other regions. Well, there's two aspects to it: - hijacking blocks when the upstream ISP builds a BGP prefix filter from the RIPE IRR DB -> this can be done of out-of-region networks but not for in-region networks (unless someone is careless with their password), and something can be done about it by the RIPE NCC (with a mandate from one of these working groups) - hijacking blocks when the upstream ISP just accepts and forwards anything the customer announces by BGP -> this must be stopped at the ISP, and the RIPE NCC can't really do something about it. OTOH, the operator community should apply peer pressure here - as in: "dear ISP, if you continue to announce unfiltered prefixes from your customers, this is violating our AUP and we'll shutdown *your* link to us". > Also, RIPE-resident hijackers can just as easily > place validating route objects for these hijacked RIPE-issued IP blocks > into the RIPE DB as they can for any other hijacked blocks taken from > any other region(s). No... the RIPE DB prevents route: objects for RIPE (NCC-issued) networks by checking the maintainer authentication for inetnum: and aut-num: - so unless the address holder is careless ("pick a 5 character easily guessable password" or "reference a well-known maintainer") it is much harder to do, if not impossible. Now, I hear what you're saying and I look at 188.229.1.0/24 and wonder what has happened, and why "whois --list-versions" isn't showing me the update/creation history for the /24 route... Ah. Now this is an interesting example of "history" in the RIPE database: gert at moebius3:/home/gert$ whois3 --show-version 4 188.229.0.0/17 % Version 4 of object "188.229.0.0 - 188.229.127.255" % This version was a UPDATE operation on 2011-09-07 20:15 % You can use "--list-versions" to get a list of versions for an object. inetnum: 188.229.0.0 - 188.229.127.255 netname: RO-NETSERV-20090729 descr: Netserv Consult SRL ... mnt-routes: NETSERV-MNT so, that /17 had, at some point in time, mnt-routes: pointing to NETSERV-MNT. gert at moebius3:/home/gert$ whois3 --show-version 5 188.229.0.0/17 % Version 5 (current version) of object "188.229.0.0 - 188.229.127.255" % This version was a UPDATE operation on 2014-10-27 15:06 % You can use "--list-versions" to get a list of versions for an object. inetnum: 188.229.0.0 - 188.229.127.255 netname: IR-MCI-20090729 descr: Mobile Communication Company of Iran PLC ... mnt-routes: MCCI-MNT So, in October 2014, the entry was changed to "mnt-routes: MCCI-MNT", which prevents creating of route: objects unless you have the proper auth codes. Now, looking at the route: route: 188.229.1.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT changed: ripe at netserv.ro.REMOVE 20130820 source: RIPE ... it claims to have been created in the time between (changed: is not authoritative, but in this case looks plausible). Checking object versions 1-4, it seems that this netblock was originally given to Netserv, and then either sold to Iran, or withdrawn by the NCC and reallocated to Iran (the published transfer statistics would clarify this), but when that happened, the route: objects were not removed - so, even when that network was no longer with Netserv, their route: objects were still there. This should not happen, of course, but it's not a technical weakness in the RIPE DB (*phew*) but human mistake. MCCI should really, really clean up all route objects that cover parts of their address space but point to other origin ASes. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From cedric at gn.apc.org Mon Nov 17 09:53:32 2014 From: cedric at gn.apc.org (Cedric Knight) Date: Mon, 17 Nov 2014 08:53:32 +0000 Subject: [anti-abuse-wg] AS43890 In-Reply-To: References: <29441.1416195145@server1.tristatelogic.com> Message-ID: <5469B78C.4050304@gn.apc.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Apologies for wading into something that isn't my area, but I just noticed Friday's story on the Register: http://www.theregister.co.uk/2014/11/14/dormant_web_space_ripe_for_hijacking/ On 17/11/14 08:21, Sander Steffann wrote: > Hi Ronald, > >> It now seems certain to me that the absence of anything even >> remotely approximating proper validation of RIPE route objects is >> not, in fact, a problem which is limited to just inter-RiR >> situations. Apparently, RIPE member LIRs can just as easily >> hijack the IP blocks of other RIPE members as they can in the >> case of IP blocks belonging to parties in other regions. > > I don't think so... > As a routing newbie, I'd appreciate clarification on what exactly *is* different between the case where the inetnum and the ASN are both allocated by RIPE, and an "inter-RIR" route. And *should* anything be different? > To be able to create the route object > > route: 188.229.1.0/24 descr: Netserv-Client > origin: AS43890 mnt-by: NETSERV-MNT source: > RIPE > > Authorisation from both the address block > > inetnum: 188.229.0.0 - 188.229.63.255 netname: > LTE-4G descr: new service for data country: IR > admin-c: RL7844-RIPE tech-c: RL7844-RIPE status: > ASSIGNED PA mnt-by: MCCI-MNT source: RIPE > > and the AS number > > aut-num: AS43890 as-name: NETSERV-AS descr: > Netserv Consult SRL [...] org: ORG-SNCS6-RIPE status: > ASSIGNED mnt-by: NETSERV-MNT mnt-by: > RIPE-NCC-END-MNT mnt-routes: NETSERV-MNT source: > RIPE > > is required. So the route cannot be created unless MCCI-MNT and > NETSERV-MNT both authorise it. Such has been my limited experience with administering the RIPEdb: the object isn't published until identical ones are added by the maintainer of the netblock and the maintainer of the ASN. So is not the RIPE database of prefixes itself relatively secure even without RPKI? Do we think the authorisation for MCCI-MNT has been compromised? Is the absence of a "mnt-routes" attribute in the netblock significant? And even without this object: % Information related to '188.229.16.0/24AS43890' route: 188.229.16.0/24 descr: Netserv-Client origin: AS43890 mnt-by: NETSERV-MNT source: RIPE # Filtered What is to prevent AS43890 (or something claiming to be AS43890) advertising this prefix via BGP? What action *can* RIPE take? > I understand that the route objects look a little weird, but what > makes you think that it is an authorisation problem in the RIPE DB > that made it possible for someone to create them? > > Cheers, Sander Thanks for everyone's work on this, and for future clarifications. Back to lurking... - -- All best wishes, Cedric Knight -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUabeMAAoJEN5s/jLcInyImj8P/2O99AajMeIW9t8t/BSaP6lu HKV2MgnICF1iAHrizENXLNm1WxwwO8I2EJrw1PDO7KsDoUfe2QoZd1IZf5RrzLH/ qWn8fBTWNeTY/n6hpEAhbVOjKfhM+iFbqEEyWkCQr/5kZGZDiJruFWDVABoFqv8S pw646gjoUyUJgDtdP1il3b73QCZLF26tElRdce0YA2XfGmNHTc1IYYPHyRXtVXvq DfqdDeadLte3AkN2AQPPiSYoAJPnxIqer+GwW5+wP+54PoHhDISKQuZK5l1JGj7O wwiof4fxiRWNEQybrrQ8kJKjwDijfwgzy5vDcCWvg5/s2FWNYU2twGBcl8XMu8HM TBzW3A6PCFTqeLtqctNHmLDlDozGiYRp8L4Nebsw7wIu2Meo1jycBUpjzC2+ukOY cgv8T6IfqgCkge3bf48fqs54QRiE/dROtZAiH4JLg9aKnr8UbNGAtEZMOAmKmwxl lOesKf/e8cUyVKFKEJwkT/xATOjGFHYsIgMv2sLNyh9kbffkbP5s7w1LDihMnCgW UEEa6+35PRXZxd5IdUpCElScVxB0zskihzIz0tCHhVEXNza50Gb56z0aMOO0yU3l JZFM5kyFxsjTy2LY5Ce6cVos/1XyUOu4wLVQ89uXVnsfrJiEZ8Ils21fUneFfeLn THtpD4DQZsxVeegcaCP2 =DoVE -----END PGP SIGNATURE----- From gert at space.net Mon Nov 17 10:56:41 2014 From: gert at space.net (Gert Doering) Date: Mon, 17 Nov 2014 10:56:41 +0100 Subject: [anti-abuse-wg] [routing-wg] AS43890 In-Reply-To: <20141117095309.GG572@hanna.local> References: <29441.1416195145@server1.tristatelogic.com> <20141117084633.GA20482@Space.Net> <20141117095309.GG572@hanna.local> Message-ID: <20141117095641.GD28745@Space.Net> Hi, On Mon, Nov 17, 2014 at 10:53:09AM +0100, Job Snijders wrote: > > Now, I hear what you're saying and I look at 188.229.1.0/24 and wonder > > what has happened, and why "whois --list-versions" isn't showing me the > > update/creation history for the /24 route... > > You need to query as following to retrieve the history of route objects: > > $ whois -h whois.ripe.net -- '--list-versions 188.229.1.0/24AS43890' Ah! Thanks for that. > > changed: ripe at netserv.ro.REMOVE 20130820 > > source: RIPE > > > > ... it claims to have been created in the time between (changed: is not > > authoritative, but in this case looks plausible). > > The history lists: "1 2014-05-12 18:23 ADD/UPD" So the changed: is bogus, but the time frame still matches (route: created in May 2014, netblock transferred in October 2014). So I'll call this "operator error". Plus maybe "bad advice by the broker coaching the transfer"... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From Piotr.Strzyzewski at polsl.pl Mon Nov 17 12:14:04 2014 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Mon, 17 Nov 2014 12:14:04 +0100 Subject: [anti-abuse-wg] AS43890 In-Reply-To: <29441.1416195145@server1.tristatelogic.com> References: <29441.1416195145@server1.tristatelogic.com> Message-ID: <20141117111404.GF17763@hydra.ck.polsl.pl> On Sun, Nov 16, 2014 at 07:32:25PM -0800, Ronald F. Guilmette wrote: > 31.2.128.0/17 > 46.51.0.0/17 > 95.64.0.0/17 > 164.138.128.0/18 > 188.229.0.0/17 > > Prior to AS197207's decision to begin announcing the above routes (which > they did, starting on Oct. 25th), it appears that the proprietors of > AS43890, a Romanian ISP and RIPE LIR in good standing, apparently elected > to announce their own set of routes to some or all of the above Iranian > IP blocks, using lots and lots of little deaggregated /24 announcements > to do so. Try to compare: ftp://ftp.ripe.net:/ripe/stats/2014/delegated-ripencc-20141026.bz2 with ftp://ftp.ripe.net:/ripe/stats/2014/delegated-ripencc-20141027.bz2 looking for a change apply to 188.229.0.0/17 instead of drawing some (most probably) invalid conclusions. This page should also be very helpful: http://www.ripe.net/lir-services/resource-management/ipv4-transfers/table-of-transfers Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From job at instituut.net Mon Nov 17 10:53:09 2014 From: job at instituut.net (Job Snijders) Date: Mon, 17 Nov 2014 10:53:09 +0100 Subject: [anti-abuse-wg] [routing-wg] AS43890 In-Reply-To: <20141117084633.GA20482@Space.Net> References: <29441.1416195145@server1.tristatelogic.com> <20141117084633.GA20482@Space.Net> Message-ID: <20141117095309.GG572@hanna.local> On Mon, Nov 17, 2014 at 09:46:33AM +0100, Gert Doering wrote: > > Also, RIPE-resident hijackers can just as easily place validating > > route objects for these hijacked RIPE-issued IP blocks into the RIPE > > DB as they can for any other hijacked blocks taken from any other > > region(s). > > No... the RIPE DB prevents route: objects for RIPE (NCC-issued) networks > by checking the maintainer authentication for inetnum: and aut-num: - so > unless the address holder is careless ("pick a 5 character easily guessable > password" or "reference a well-known maintainer") it is much harder to do, > if not impossible. > > Now, I hear what you're saying and I look at 188.229.1.0/24 and wonder > what has happened, and why "whois --list-versions" isn't showing me the > update/creation history for the /24 route... You need to query as following to retrieve the history of route objects: $ whois -h whois.ripe.net -- '--list-versions 188.229.1.0/24AS43890' > Now, looking at the route: > > route: 188.229.1.0/24 > descr: Netserv-Client > origin: AS43890 > mnt-by: NETSERV-MNT > changed: ripe at netserv.ro.REMOVE 20130820 > source: RIPE > > ... it claims to have been created in the time between (changed: is not > authoritative, but in this case looks plausible). The history lists: "1 2014-05-12 18:23 ADD/UPD" Kind regards, Job From rfg at tristatelogic.com Mon Nov 17 22:09:56 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 17 Nov 2014 13:09:56 -0800 Subject: [anti-abuse-wg] AS43890 In-Reply-To: Message-ID: <46539.1416258596@server1.tristatelogic.com> In message , Sander Steffann wrote: >> It now seems certain to me that the absence of anything even remotely >> approximating proper validation of RIPE route objects is not, in fact, >> a problem which is limited to just inter-RiR situations. Apparently, >> RIPE member LIRs can just as easily hijack the IP blocks of other >> RIPE members as they can in the case of IP blocks belonging to parties >> in other regions. > >I don't think so... You're right, and I apologize to everyone for the false alarm. I made a mistake. It's that simple. I looked at the wrong changed: field and concluded that the Iranians had had the containing block (188.229.0.0/17) since 20120905. But now I see that that was incorrect, and the Iranians had most probably only been assigned this block very very recently, e.g. 20141028. Obviously, that changes the analysis completely. There was no hijacking here. None at all. I apologize that I misspoke. That having been said, the fact that all of those 61 now-clearly-stale route objects remain in the data base is, I would say, rather obviously un-good. I understand that it was, it the first instance, the responsibility of netserv.ro to have removed those, but clearly, they didn't. Perhaps we could (or should) talk about some automated procedures that might automagically remove such bogus/stale cruft, even in the absence of prompt action by the parties who created the object in the first place. Regards, rfg From rfg at tristatelogic.com Mon Nov 17 22:16:08 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 17 Nov 2014 13:16:08 -0800 Subject: [anti-abuse-wg] [routing-wg] AS43890 In-Reply-To: <20141117084633.GA20482@Space.Net> Message-ID: <46603.1416258968@server1.tristatelogic.com> In message <20141117084633.GA20482 at Space.Net>, Gert Doering wrote: >MCCI should really, really clean up all route objects that cover parts >of their address space but point to other origin ASes. Wait, so you are saying that the *Iranians* should be responsible for cleaning up the mess that was left behind by their predecessors, i.e. the folks who had the 188.229.0.0/17 block before the Iranians did?? Can they even remove those route objects, given that they didn't even create them in the first place? Can any arbitrary RIPE member remove route objects that were created by any other RIPE member? Regards, rfg From gert at space.net Mon Nov 17 22:22:34 2014 From: gert at space.net (Gert Doering) Date: Mon, 17 Nov 2014 22:22:34 +0100 Subject: [anti-abuse-wg] [routing-wg] AS43890 In-Reply-To: <46603.1416258968@server1.tristatelogic.com> References: <20141117084633.GA20482@Space.Net> <46603.1416258968@server1.tristatelogic.com> Message-ID: <20141117212234.GA28745@Space.Net> Hi, On Mon, Nov 17, 2014 at 01:16:08PM -0800, Ronald F. Guilmette wrote: > In message <20141117084633.GA20482 at Space.Net>, > Gert Doering wrote: > > >MCCI should really, really clean up all route objects that cover parts > >of their address space but point to other origin ASes. > > Wait, so you are saying that the *Iranians* should be responsible for > cleaning up the mess that was left behind by their predecessors, i.e. > the folks who had the 188.229.0.0/17 block before the Iranians did?? Well, it should be part of the purchase contract - "we buy this block under the condition that... and only pay if this is all fulfilled". In any case it is partly their responsibility to check that there is nothing lingering. > Can they even remove those route objects, given that they didn't even > create them in the first place? > > Can any arbitrary RIPE member remove route objects that were created > by any other RIPE member? Generally speaking, no. Routes that point to parts of *your* address space, you can remove, if I remember right - because normally you need to approve the creation anyway (by authorizing the update). I need to find the flow chart on the RIPE web site that precisely describes which authorization is checked where, but if I remember right, for deletion, the "mnt-routes:" (fallback to mnt-by: if no mnt-routes:) authorization on the inetnum is sufficient for removal. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From rfg at tristatelogic.com Mon Nov 17 22:55:10 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 17 Nov 2014 13:55:10 -0800 Subject: [anti-abuse-wg] RIPE WHOIS blocked Message-ID: <46951.1416261310@server1.tristatelogic.com> Apparently, somebody @ RIPE NCC thinks that I have been too curious of late. How long should it take for this error to go away? ============================================================================= % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf %ERROR:201: access denied for 69.62.255.118 % % Queries from your IP address have passed the daily limit of controlled objects. % Access from your host has been temporarily denied. % For more information, see % http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-201-access-denied % This query was served by the RIPE Database Query Service version 1.76 (DB-2) ============================================================================= I have already written to ripe-dbm at ripe.net asking about this and have received no reply. And anyway, can anyone here explain to me what the point is of limiting WHOIS queries based on the source IP address? As far as I can see, this only has the effect of slowing down or blocking the work of legitimate researchers, such as myself. Anybody who knows anything about the Internet should know that an IP-address based throttling system would be almost entirely ineffective against anyone who was seriously determined to perform bulk harvesting of the RIPE data base via port 43 (or via port 80 for that matter). It seems that I am being slowed down, blocked, and penalized for the sin of having a static IP address, even while any other fool on the planet who has a dynamically-assigned broadband IP, or even a dial-up line, and who knows how to disconnect an reconnect can easily slurp all of the RIPE data they want, with no real limits. In what universe is this non-stupid? More to the point, who is it, specifically, within RIPE NCC, that has the authority to fix this? Regards, rfg P.S. More stupidity: Based on the text at the URL provided in the error mesage (see above) the goal of the rate limiting seems to be to prevent harvesters from collecting too much "contact information". OK. Fine. But the text on that web page also says that using the -r option with the WHOIS queries will prevent such contact information from being returned, thus eliminating the issue... or so one would think. But why then is it the case that once my IP address has hit its head against this daily limit, I am not even allowed anymore to even make any more ``safe'' queries with the -r option? I am now locked out completely. Why? Sigh. I guess that I need to go and drag my old 96Kb modem down out of the closet, dust it off, and get myself a free dial-up AOL account so that I can work around all of this stupidity. From fredrik at resilans.se Mon Nov 17 23:00:08 2014 From: fredrik at resilans.se (Fredrik Widell) Date: Mon, 17 Nov 2014 23:00:08 +0100 (CET) Subject: [anti-abuse-wg] RIPE WHOIS blocked In-Reply-To: <46951.1416261310@server1.tristatelogic.com> References: <46951.1416261310@server1.tristatelogic.com> Message-ID: On Mon, 17 Nov 2014, Ronald F. Guilmette wrote: Use the -r flag for your queries to avoid beeing blocked, you have requested to many person-objects probably. > > > Apparently, somebody @ RIPE NCC thinks that I have been too curious of late. > > How long should it take for this error to go away? > > ============================================================================= > % This is the RIPE Database query service. > % The objects are in RPSL format. > % > % The RIPE Database is subject to Terms and Conditions. > % See http://www.ripe.net/db/support/db-terms-conditions.pdf > > %ERROR:201: access denied for 69.62.255.118 > % > % Queries from your IP address have passed the daily limit of controlled objects. > % Access from your host has been temporarily denied. > % For more information, see > % http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-201-access-denied > > % This query was served by the RIPE Database Query Service version 1.76 (DB-2) > ============================================================================= > > > I have already written to ripe-dbm at ripe.net asking about this and have > received no reply. > > And anyway, can anyone here explain to me what the point is of limiting > WHOIS queries based on the source IP address? > > As far as I can see, this only has the effect of slowing down or blocking > the work of legitimate researchers, such as myself. Anybody who knows > anything about the Internet should know that an IP-address based throttling > system would be almost entirely ineffective against anyone who was seriously > determined to perform bulk harvesting of the RIPE data base via port 43 > (or via port 80 for that matter). > > It seems that I am being slowed down, blocked, and penalized for the sin > of having a static IP address, even while any other fool on the planet > who has a dynamically-assigned broadband IP, or even a dial-up line, > and who knows how to disconnect an reconnect can easily slurp all of > the RIPE data they want, with no real limits. > > In what universe is this non-stupid? > > More to the point, who is it, specifically, within RIPE NCC, that has > the authority to fix this? > > > Regards, > rfg > > > P.S. More stupidity: Based on the text at the URL provided in the > error mesage (see above) the goal of the rate limiting seems to be to > prevent harvesters from collecting too much "contact information". > OK. Fine. But the text on that web page also says that using the > -r option with the WHOIS queries will prevent such contact information > from being returned, thus eliminating the issue... or so one would > think. > > But why then is it the case that once my IP address has hit its head > against this daily limit, I am not even allowed anymore to even make > any more ``safe'' queries with the -r option? I am now locked out > completely. Why? > > Sigh. I guess that I need to go and drag my old 96Kb modem down out > of the closet, dust it off, and get myself a free dial-up AOL account > so that I can work around all of this stupidity. > > > -- Mvh Fredrik Widell Resilans AB http://www.resilans.se/ mail: info at resilans.se , fredrik at resilans.se From aawg at c4inet.net Mon Nov 17 23:41:39 2014 From: aawg at c4inet.net (Sascha Luck [ml]) Date: Mon, 17 Nov 2014 22:41:39 +0000 Subject: [anti-abuse-wg] RIPE WHOIS blocked In-Reply-To: <46951.1416261310@server1.tristatelogic.com> References: <46951.1416261310@server1.tristatelogic.com> Message-ID: <20141117224139.GA91687@cilantro.c4inet.net> On Mon, Nov 17, 2014 at 01:55:10PM -0800, Ronald F. Guilmette wrote: >% Queries from your IP address have passed the daily limit of controlled objects. >% Access from your host has been temporarily denied. >% For more information, see >% >http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-201-access-denied This is a limit on "person:" objects, NCC's idea of data protection. Don't think you'd like my solution for this though, I wouldn't allow anyone who isn't a) identifiable and b) contracted access to personally identifying data. I also believe you accessing this constitutes an export to a non-EU country, something not allowed under the EU DPD. (not your problem but the NCC's) rgds, Sascha Luck From rfg at tristatelogic.com Mon Nov 17 23:51:50 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Mon, 17 Nov 2014 14:51:50 -0800 Subject: [anti-abuse-wg] RIPE WHOIS blocked In-Reply-To: <20141117224139.GA91687@cilantro.c4inet.net> Message-ID: <47595.1416264710@server1.tristatelogic.com> In message <20141117224139.GA91687 at cilantro.c4inet.net>, "Sascha Luck [ml]" wrote: >On Mon, Nov 17, 2014 at 01:55:10PM -0800, Ronald F. Guilmette wrote: >>% Queries from your IP address have passed the daily limit of controlled obje >cts. >>% Access from your host has been temporarily denied. >>% For more information, see >>% >>http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-20 >1-access-denied > >This is a limit on "person:" objects, NCC's idea of data >protection. Apparently. >Don't think you'd like my solution for this though, I wouldn't >allow anyone who isn't a) identifiable and b) contracted access >to personally identifying data. I would be perfectly OK with (a). In fact, accessing this service only via individual password-protected accounts seems to me to be the only rational way to _actually_ protect the data from mass harvesting. Regarding (b) I would be OK with that too, as long as the contract in question required me to pay only zero dollars... er... I mean zero euros. Regards, rfg From celexi at bytenix.net Tue Nov 18 00:01:24 2014 From: celexi at bytenix.net (Sara Borges) Date: Mon, 17 Nov 2014 23:01:24 +0000 Subject: [anti-abuse-wg] RIPE WHOIS blocked In-Reply-To: <47595.1416264710@server1.tristatelogic.com> References: <20141117224139.GA91687@cilantro.c4inet.net> <47595.1416264710@server1.tristatelogic.com> Message-ID: I remember someone having this issue last year and as far i remember he was not able to get ripe to unblock him so i think you are out of luck. On Mon, Nov 17, 2014 at 10:51 PM, Ronald F. Guilmette wrote: > > In message <20141117224139.GA91687 at cilantro.c4inet.net>, > "Sascha Luck [ml]" wrote: > > >On Mon, Nov 17, 2014 at 01:55:10PM -0800, Ronald F. Guilmette wrote: > >>% Queries from your IP address have passed the daily limit of controlled > obje > >cts. > >>% Access from your host has been temporarily denied. > >>% For more information, see > >>% > >> > http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-20 > >1-access-denied > > > >This is a limit on "person:" objects, NCC's idea of data > >protection. > > Apparently. > > >Don't think you'd like my solution for this though, I wouldn't > >allow anyone who isn't a) identifiable and b) contracted access > >to personally identifying data. > > I would be perfectly OK with (a). In fact, accessing this service only > via individual password-protected accounts seems to me to be the only > rational way to _actually_ protect the data from mass harvesting. > > Regarding (b) I would be OK with that too, as long as the contract in > question required me to pay only zero dollars... er... I mean zero euros. > > > Regards, > rfg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Tue Nov 18 11:00:36 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 18 Nov 2014 11:00:36 +0100 Subject: [anti-abuse-wg] [routing-wg] AS43890 In-Reply-To: <20141117212234.GA28745@Space.Net> References: <20141117084633.GA20482@Space.Net> <46603.1416258968@server1.tristatelogic.com> <20141117212234.GA28745@Space.Net> Message-ID: <546B18C4.1050709@CC.UniVie.ac.at> Gert Doering wrote: > Hi, [...] >>Can any arbitrary RIPE member remove route objects that were created >>by any other RIPE member? > > > Generally speaking, no. Generally speaking, in order to delete an objecct, you need the same (set of) credentials you would need to create or modify the object. As you correctly point out, there are a couple of exceptions to prevent dead- lock situations when one party fails to cooperate. Removing a route object is one of those, iirc; deleting a revDNS delegation entry is another. > Gert Doering > -- NetMaster Wilfried From Woeber at CC.UniVie.ac.at Tue Nov 18 11:24:23 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 18 Nov 2014 11:24:23 +0100 Subject: [anti-abuse-wg] RIPE WHOIS blocked In-Reply-To: <46951.1416261310@server1.tristatelogic.com> References: <46951.1416261310@server1.tristatelogic.com> Message-ID: <546B1E57.1030504@CC.UniVie.ac.at> Ronald F. Guilmette wrote: > Apparently, somebody @ RIPE NCC thinks that I have been too curious of late. s/somebody/something/ :-) > > How long should it take for this error to go away? About a day, I guess, unless you continue to hammer along... [...] > And anyway, can anyone here explain to me what the point is of limiting > WHOIS queries based on the source IP address? Some sort of (weak, we all know,) protection of mass harvesting of potentially personal data, *and* some sort of protection against run-away scripts from the same source. This is a pretty old mechanism and its shortcomings are known. [...] > More to the point, who is it, specifically, within RIPE NCC, that has > the authority to fix this? No one. And please stop accusing the NCC folks of stupidity and other useless stuff! Coming forward with proposals for removing or modifying the mechanisms imho would be the responsibility of the Community, either in AA-WG and/or DB-WG or maybe Services. IIRC, we had a brief discussion a while ago in DB-WG, regarding a more useful(?) configuration that would still honour resource queries *not* asking (implicitly or explicitly) for contact information or person objects. > Regards, > rfg Wilfried From eshryane at ripe.net Tue Nov 18 12:44:33 2014 From: eshryane at ripe.net (Edward Shryane) Date: Tue, 18 Nov 2014 12:44:33 +0100 Subject: [anti-abuse-wg] RIPE WHOIS blocked Message-ID: Hi Ronald, After looking into legal requirements for protection of personal data in RIPE NCC's service region, our community decided that there should be a limit on the number of queries with personal data served to each IP Address. Person and role objects are considered to contain personal data (email address, phone number(s), postal address), and queries for these objects are subject to a daily limit. Once this daily limit for querying personal data is reached, the IP address is temporarily blocked for the rest of that day. If an IP address repeatedly reaches its daily limit, then it is permanently blocked. By default when querying whois, related objects are also returned (including person and role objects). The '-r' flag can be used to not return related objects, or the '--no-personal' flag to not return person or role objects. For bulk access to the RIPE Database, split files (per object type) are published on the RIPE FTP site: ftp://ftp.ripe.net/ripe/dbase/split/ Regards, Ed Shryane RIPE NCC > > > Apparently, somebody @ RIPE NCC thinks that I have been too curious of late. > > How long should it take for this error to go away? > > ============================================================================= > % This is the RIPE Database query service. > % The objects are in RPSL format. > % > % The RIPE Database is subject to Terms and Conditions. > % See http://www.ripe.net/db/support/db-terms-conditions.pdf > > %ERROR:201: access denied for 69.62.255.118 > % > % Queries from your IP address have passed the daily limit of controlled objects. > % Access from your host has been temporarily denied. > % For more information, see > % http://www.ripe.net/data-tools/db/faq/faq-db/why-did-you-receive-the-error-201-access-denied > > % This query was served by the RIPE Database Query Service version 1.76 (DB-2) > ============================================================================= > > > I have already written to ripe-dbm at ripe.net asking about this and have > received no reply. > > And anyway, can anyone here explain to me what the point is of limiting > WHOIS queries based on the source IP address? > > As far as I can see, this only has the effect of slowing down or blocking > the work of legitimate researchers, such as myself. Anybody who knows > anything about the Internet should know that an IP-address based throttling > system would be almost entirely ineffective against anyone who was seriously > determined to perform bulk harvesting of the RIPE data base via port 43 > (or via port 80 for that matter). > > It seems that I am being slowed down, blocked, and penalized for the sin > of having a static IP address, even while any other fool on the planet > who has a dynamically-assigned broadband IP, or even a dial-up line, > and who knows how to disconnect an reconnect can easily slurp all of > the RIPE data they want, with no real limits. > > In what universe is this non-stupid? > > More to the point, who is it, specifically, within RIPE NCC, that has > the authority to fix this? > > > Regards, > rfg > > > P.S. More stupidity: Based on the text at the URL provided in the > error mesage (see above) the goal of the rate limiting seems to be to > prevent harvesters from collecting too much "contact information". > OK. Fine. But the text on that web page also says that using the > -r option with the WHOIS queries will prevent such contact information > from being returned, thus eliminating the issue... or so one would > think. > > But why then is it the case that once my IP address has hit its head > against this daily limit, I am not even allowed anymore to even make > any more ``safe'' queries with the -r option? I am now locked out > completely. Why? > > Sigh. I guess that I need to go and drag my old 96Kb modem down out > of the closet, dust it off, and get myself a free dial-up AOL account > so that I can work around all of this stupidity. > From eshryane at ripe.net Tue Nov 18 13:11:00 2014 From: eshryane at ripe.net (Edward Shryane) Date: Tue, 18 Nov 2014 13:11:00 +0100 Subject: [anti-abuse-wg] [routing-wg] AS43890 Message-ID: <164B24C8-CC1E-4A51-BCC3-399237C1FB4F@ripe.net> Hello, Correct, here is a nice RIPE Labs article explaining those exceptions: https://labs.ripe.net/Members/denis/reclaim-functionality-for-resource-holders Also, in case of transfer of holder-ship, as long as a user has access to maintainer password, or can recover it using the standard password recovery -meaning they are the rightful holder of the resource- they should be able to follow above mentioned procedure. Regards, Ed Shryane RIPE NCC > > Gert Doering wrote: > >> Hi, > [...] >>> Can any arbitrary RIPE member remove route objects that were created >>> by any other RIPE member? >> >> >> Generally speaking, no. > > Generally speaking, in order to delete an objecct, you need the same (set of) > credentials you would need to create or modify the object. > > As you correctly point out, there are a couple of exceptions to prevent dead- > lock situations when one party fails to cooperate. Removing a route object is > one of those, iirc; deleting a revDNS delegation entry is another. > >> Gert Doering >> -- NetMaster > > Wilfried > > From rfg at tristatelogic.com Tue Nov 18 20:25:52 2014 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 18 Nov 2014 11:25:52 -0800 Subject: [anti-abuse-wg] RIPE WHOIS blocked In-Reply-To: Message-ID: <57815.1416338752@server1.tristatelogic.com> In message , Edward Shryane wrote: >Once this daily limit for querying personal data is reached, the IP >address is temporarily blocked for the rest of that day. If an IP >address repeatedly reaches its daily limit, then it is permanently >blocked. > >By default when querying whois, related objects are also returned >(including person and role objects). The '-r' flag can be used to not >return related objects, or the '--no-personal' flag to not return person >or role objects. Thanks for your response. Would you agree that _even after_ some IP address has "reached its daily limit", that there is no real point in blocking further queries which _do_ use the -r option? >For bulk access to the RIPE Database, split files (per object type) are >published on the RIPE FTP site: ftp://ftp.ripe.net/ripe/dbase/split/ Thank you. I didn't know about this resource and it should be most helpful, going forward. I'm just curious though... Where might I find brief descriptions of what's in each of the files at the above URL? The contents of many/most of the files in that directory are really obvious, like ripe.db.aut-num.gz and ripe.db.inetnum.gz. But others are less so. For example, what's the difference between three three: -rw-r--r-- 1 ftp ftp 28491 Nov 18 00:26 ripe.db.as-block.gz -rw-r--r-- 1 ftp ftp 1610549 Nov 18 00:26 ripe.db.as-set.gz -rw-r--r-- 1 ftp ftp 7248902 Nov 18 00:26 ripe.db.aut-num.gz Reards, rfg P.S. I' sure that I will derive hours of enjoyment from the contents of the ripe.db.poem.gz file. So thanks for that too. I had no idea that RIPE members were so... um... literary. From Woeber at CC.UniVie.ac.at Tue Nov 18 21:16:53 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 18 Nov 2014 21:16:53 +0100 Subject: [anti-abuse-wg] RIPE WHOIS blocked In-Reply-To: <57815.1416338752@server1.tristatelogic.com> References: <57815.1416338752@server1.tristatelogic.com> Message-ID: <546BA935.9090002@CC.UniVie.ac.at> Ronald F. Guilmette wrote: > ... For example, what's the difference between three three: > > -rw-r--r-- 1 ftp ftp 28491 Nov 18 00:26 ripe.db.as-block.gz > -rw-r--r-- 1 ftp ftp 1610549 Nov 18 00:26 ripe.db.as-set.gz > -rw-r--r-- 1 ftp ftp 7248902 Nov 18 00:26 ripe.db.aut-num.gz My 1st "wild guess" would be: - aut-num: individual AS numbers - as-block: a contiguous set of AS numbers starting with AS-a through AS-b - as-set: a list/enumeration of AS numbers (for which the same routing policy should be applied). Some of that stuff has been devised in the framework of RPSL (IETF RFCs some 15 years ago), but the implementations these days is no longer fully in line with those doc.s and have never been complete - unfortunately. -W From Woeber at CC.UniVie.ac.at Tue Nov 18 21:32:52 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 18 Nov 2014 21:32:52 +0100 Subject: [anti-abuse-wg] RIPE WHOIS blocked In-Reply-To: <57815.1416338752@server1.tristatelogic.com> References: <57815.1416338752@server1.tristatelogic.com> Message-ID: <546BACF4.2040102@CC.UniVie.ac.at> Just because I myself didn't realize how old some of that stuff really is by now, aunty Googlova came back with a well-seasoned link from 2001 for AS-set: http://archive.apnic.net/meetings/12/docs/db3-apnic12-andrei.ppt Read with a grain of salt, and enjoy ;-) -W