Article on spammers and their infrastructure
http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-... It this something new ? The article seems to mix various issues together. And this would seem highly inefficient to me compared to traditional botnets (renting your own rack for a botnet doesn't really make sense :) Comments ?
On Tue, 22 Dec 2009, Phil Regnauld wrote:
http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-...
It this something new ? The article seems to mix various issues together. And this would seem highly inefficient to me compared to traditional botnets (renting your own rack for a botnet doesn't really make sense :)
Comments ?
Sounds like a snowshoe setup to me. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
With the added refinement of spammer / botmaster controlled LIRs .. after spammer / botmaster controlled registrars. I did wonder sometimes how some snowshoe spammers could keep acquiring a series of /20 to /15 sized CIDRs over the past year or two. On Tue, Dec 22, 2009 at 6:38 PM, Tony Finch <dot@dotat.at> wrote:
Sounds like a snowshoe setup to me.
Tony.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On Tue, 22 Dec 2009, Phil Regnauld wrote:
http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-...
It this something new ? The article seems to mix various issues together. And this would seem highly inefficient to me compared to traditional botnets (renting your own rack for a botnet doesn't really make sense :)
I don't see how going to jump.ro, getting a bunch of IP assignments, and then setting those IPs up on a server or few servers in the US = "attackers buying own data centers". I am curious how both jump.ro and the other RIPE region LIRs involved in assigning the space and the US based networks that have been involved routing it justify assigning/routing "Assigned PA" space to "customers" who only use that space in their US operations (which in the cases I've seen have primarily been high volume email deployment). According to http://www.ripe.net/ripe/docs/ipv4-policies.html ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. Should US based networks be willing to route RIPE "ASSIGNED PA" space customers provide? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Tue, Dec 22, 2009 at 4:24 PM, Jon Lewis <jlewis@lewis.org> wrote:
Should US based networks be willing to route RIPE "ASSIGNED PA" space customers provide?
this is an interesting question, which when I worked for an ISP I always wondered about. In fact, when we'd see solely based US customers asking for this sort of thing it often meant shortly there after we'd see complaints of TOS/AUP violations. There doesn't seem to be a hard/fast rule about this though (the 'is it right to permit this activity'), but there sure is quite a bit of it going on, eh? -Chris
Christopher Morrow wrote:
On Tue, Dec 22, 2009 at 4:24 PM, Jon Lewis <jlewis@lewis.org> wrote:
Should US based networks be willing to route RIPE "ASSIGNED PA" space customers provide?
Are any of your customers multinationals?
this is an interesting question, which when I worked for an ISP I always wondered about. In fact, when we'd see solely based US customers asking for this sort of thing it often meant shortly there after we'd see complaints of TOS/AUP violations. There doesn't seem to be a hard/fast rule about this though (the 'is it right to permit this activity'), but there sure is quite a bit of it going on, eh?
Last two companies I have worked with, through a combination of organic growth, aquistion and partnership have a rather complex mix of PA, Legacy, RIR assignments in 4 regions, LIR assignments, and so forth. it would be fairly normal in the course of service delivery to customers to advertise prefixes obtained in one region in one or more other regions. One of these entities has a global IP backbone, the other glues it altogether with vpns, appart from scale they're not really that different.
-Chris
On Tue, 22 Dec 2009, Joel Jaeggli wrote:
Should US based networks be willing to route RIPE "ASSIGNED PA" space customers provide?
Are any of your customers multinationals?
They may be. I don't agree that it's relevant. You can disagree with the RIPE wording or with RIPE policies, or maybe I'm misinterpreting ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. My interpretation of the above is ASSIGNED PA is the equivalent of my assigning IP space to a customer who either buys transit (connectivity) from us or colo's or buys server hosting from us where they will use that IP space. We don't simply lease out IP space for "customers" to use as they please on other networks. We do have customers who are multihomed to whom we've assigned IP space, and they announce those IPs via BGP to us and other transit providers. What I've seen recently with jump.ro and other RIPE region LIRs looks like the LIRs are effectively selling/renting (whatever you want to call it) "ASSIGNED PA" IP space to spammers who announce it using single homed ASNs in the US. As an End User in the RIPE region, if you need/want PI space, are you not able to get that directly from RIPE? The previously mentioned page is confusing to me in its coverage of that question. The RIPE NCC no longer allocates PI address space. Consequently, many LIRs do not have PI allocations from which to make PI assignments. If an LIR has an End User that requires PI address space they are able to support them by sending these requests to the RIPE NCC on behalf of the End User. This support includes helping End Users prepare a properly documented request. The RIPE NCC will make PI assignments when justified. RIPE no longer allocates PI space. If an LIR has an End User that requires PI space and the LIR doesn't have any PI left to give out, they can help that End User apply to RIPE. This implies RIPE still does "assign" PI space to end users...and if you need PI IP space and are eligible to deal with RIPE, you should be getting it from them. So, if you're not multihomed with jump.ro as one of your providers, is it appropriate for them to sell you ASSIGNED PA space which you'll use elsewhere? I don't think so. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 22/12/2009 23:36, Jon Lewis wrote:
On Tue, 22 Dec 2009, Joel Jaeggli wrote:
On Tue, Dec 22, 2009 at 4:24 PM, Jon Lewis <jlewis@lewis.org> wrote:
Should US based networks be willing to route RIPE "ASSIGNED PA" space customers provide?
I would argue not and the bofh in me would be inclined to announce more specifics if I saw someone announcing my PA space from another ASN. But I'm more into the ixp sort of thing these days rather than isps.
My interpretation of the above is ASSIGNED PA is the equivalent of my assigning IP space to a customer who either buys transit (connectivity) from us or colo's or buys server hosting from us where they will use that IP space.
ASSIGNED PA space is intended to be announced by the provider which operates the LIR only (i.e. the space is associated with the provider). It's not intended for multihoming, and if you want multihoming space, you need PI address space.
As an End User in the RIPE region, if you need/want PI space, are you not able to get that directly from RIPE?
You can get it directly from the RIPE NCC, but it's more usual to get it via your provider's LIR, the important word being "via". The LIR just passes on your request form. The RIPE NCC is very specific about the language used here. In the context of all RIPE docs and policies, "allocate" means to bulk-delegate resources to a LIR. "assign" is the process of delegating the address space to the end-user, whether that end-user is a customer or the provider itself. So, when the RIPE NCC says:
The RIPE NCC no longer allocates PI address space.
... what they mean is that they no longer delegate bulk blocks of PI address space to LIRs so that the LIR can then assign the address space to end-users. Instead, what happens these days is:
[...]The RIPE NCC will make PI assignments when justified.
i.e. if you want a PI block, you fill out a form, send it to your LIR, who sends it to the RIPE NCC. The NCC will then register the address space to the end-user.
So, if you're not multihomed with jump.ro as one of your providers, is it appropriate for them to sell you ASSIGNED PA space which you'll use elsewhere? I don't think so.
it is completely inappropriate at many levels - imo. Nick
On Tue, Dec 22, 2009 at 7:03 PM, Nick Hilliard <nick@foobar.org> wrote:
On 22/12/2009 23:36, Jon Lewis wrote:
So, if you're not multihomed with jump.ro as one of your providers, is
'multihomed' here could mean: "we have an IPSEC vpn, we need to use globally unique ip space, we may have exit points (and have space routed by other providers from this block), but we'll anchor things here in your datacenter in elbonia, ok?"
it appropriate for them to sell you ASSIGNED PA space which you'll use elsewhere? I don't think so.
'sell you ASSIGNED PA' or 'Assign to you as a customer ASSIGNED PA' ? (cause 'selling ip space' is still officially verboten, eh?)
it is completely inappropriate at many levels - imo.
agreed, it's at least a management headache, and aside from very obvious large multi-nationals (joel's examples) every time I've seen it done it was by 'bad actors'... In fact I think I had a conversation with an install engineer that went something like: "You really thought ip space assigned to a ukranian company in the ukraine was 'ok' for you to route to a customer in tampa, fla??" :( -chris
On 22/12/2009 3:36, "Jon Lewis" <jlewis@lewis.org> wrote: [...]
They may be. I don't agree that it's relevant. You can disagree with the RIPE wording or with RIPE policies, or maybe I'm misinterpreting
ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR.
My interpretation of the above is ASSIGNED PA is the equivalent of my assigning IP space to a customer who either buys transit (connectivity) from us or colo's or buys server hosting from us where they will use that IP space. We don't simply lease out IP space for "customers" to use as they please on other networks.
I am sure that your interpretation was the original intent of the policy text. However, the wording could also be read in a way that allows an LIR to just provide registry services, without providing any connectivity services. Regards, Leo
On Tue, 22 Dec 2009, Leo Vegoda wrote:
ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR.
My interpretation of the above is ASSIGNED PA is the equivalent of my assigning IP space to a customer who either buys transit (connectivity) from us or colo's or buys server hosting from us where they will use that IP space. We don't simply lease out IP space for "customers" to use as they please on other networks.
I am sure that your interpretation was the original intent of the policy text. However, the wording could also be read in a way that allows an LIR to just provide registry services, without providing any connectivity services.
That's one hell of a stretch. Registry services aren't needed if they don't have the IP space, so saying that the service the end user is buying that justifies the IP assignment is 'registration services' is a circular argument. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Dec 24, 2009, at 8:59 AM, Jon Lewis wrote: […]
I am sure that your interpretation was the original intent of the policy text. However, the wording could also be read in a way that allows an LIR to just provide registry services, without providing any connectivity services.
That's one hell of a stretch. Registry services aren't needed if they don't have the IP space, so saying that the service the end user is buying that justifies the IP assignment is 'registration services' is a circular argument.
Of course - but if you wanted to provide services to spammers and their friends it's the sort of stretch you'd find yourself making. Regards, Leo
On Wed, Dec 23, 2009 at 4:24 AM, Joel Jaeggli <joelja@bogus.com> wrote:
Christopher Morrow wrote:
On Tue, Dec 22, 2009 at 4:24 PM, Jon Lewis <jlewis@lewis.org> wrote:
Should US based networks be willing to route RIPE "ASSIGNED PA" space customers provide?
Are any of your customers multinationals?
What would you do if a shell company (the european equivalent of a LLC with a UPS store address) came to you with a large sized PA netblock from out of region, and asked you to route it for them? -- Suresh Ramasubramanian (ops.lists@gmail.com)
I might as well reply to this here. The folks from threatpost had me talk at length about the various issues with doing cybercrime enforcement and how things have changed, and they picked that section for their post. My key point I wanted to hammer home was that most of the modern botnets (and/or malware that has phone home capability) have a much more stable infrastructure, as more and more of the hosting pieces are controlled by the bad guys. In the old days you'd see C&C servers running from popped boxes, but now you're seeing the criminals renting their own servers from xyz datacenter, or worse, buying their own racks/cages and going to an LIR or RIR to get direct IP allocations. They then rent out those allocations to other shell companies (or possibly to other criminals) and handle the abuse notifications on the frontend. Since these data centers have many transit options, nullrouting an ip block at a single ISP hasn't been very effective. And of course, getting an RIR to revoke IP space only happens if you don't pay the bills. A year after allocation the blocks are pretty much burned anyways, so that's not a real barrier. There doesn't even seem to be any policies against intentional fraudulent SWIPing of IP space, or at least, not one that's enforced. The Knujon guys have had some success in the domain space, maybe this could happen in the ip world as well? The only technical statement in there that I think was misinterpreted was the "owning your own ip space makes you an isp" which I clearly didn't mean. It's a quote so I must have said it but it must I think I had some qualifiers in there in that I was talking about the abuse desks at an ISP. If they are the ISP they claim it was a downstream customer and that they've fixed the issue, when really it's their own stuff that they shuffle around. Regards, Alex Lanstein ________________________________________ From: Jon Lewis [jlewis@lewis.org] Sent: Tuesday, December 22, 2009 4:24 PM To: Phil Regnauld Cc: nanog@nanog.org Subject: Re: Article on spammers and their infrastructure On Tue, 22 Dec 2009, Phil Regnauld wrote:
http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-...
It this something new ? The article seems to mix various issues together. And this would seem highly inefficient to me compared to traditional botnets (renting your own rack for a botnet doesn't really make sense :)
I don't see how going to jump.ro, getting a bunch of IP assignments, and then setting those IPs up on a server or few servers in the US = "attackers buying own data centers". I am curious how both jump.ro and the other RIPE region LIRs involved in assigning the space and the US based networks that have been involved routing it justify assigning/routing "Assigned PA" space to "customers" who only use that space in their US operations (which in the cases I've seen have primarily been high volume email deployment). According to http://www.ripe.net/ripe/docs/ipv4-policies.html ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. Should US based networks be willing to route RIPE "ASSIGNED PA" space customers provide? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Dec 22, 2009 at 8:58 PM, Alex Lanstein <ALanstein@fireeye.com> wrote:
I might as well reply to this here. The folks from threatpost had me talk at length about the various issues with doing cybercrime enforcement and how things have changed, and they picked that section for their post.
My key point I wanted to hammer home was that most of the modern botnets (and/or malware that has phone home capability) have a much more stable infrastructure, as more and more of the hosting pieces are controlled by the bad guys.
In the old days you'd see C&C servers running from popped boxes, but now you're seeing the criminals renting their own servers from xyz datacenter, or worse, buying their own racks/cages and going to an LIR or RIR to get direct IP allocations. They then rent out those allocations to other shell companies (or possibly to other criminals) and handle the abuse notifications on the frontend. Since these data centers have many transit options, nullrouting an ip block at a single ISP hasn't been very effective. And of course, getting an RIR to revoke IP space only happens if you don't pay the bills. A year after allocation the blocks are pretty much burned anyways, so that's not a real barrier. There doesn't even seem to be any policies against intentional fraudulent SWIPing of IP space, or at least, not one that's enforced. The Knujon guys have had some success in the domain space, maybe this could happen in the ip world as well?
The only technical statement in there that I think was misinterpreted was the "owning your own ip space makes you an isp" which I clearly didn't mean. It's a quote so I must have said it but it must I think I had some qualifiers in there in that I was talking about the abuse desks at an ISP. If they are the ISP they claim it was a downstream customer and that they've fixed the issue, when really it's their own stuff that they shuffle around.
Not that I need to do so, but I might as well -- I know Alex pretty well, as both a trusted colleague & friend, and he is spot on in his assessment here. If anything, he was mild in his criticizes -- this type of criminal "diversification" has been the standard bat-and-switch method of operation for several years now. The criminals -- especially the professional Eastern Europeans -- have become quite adept in their campaigns of registering domains, obtaining IP address space, hosting facilities, etc., and are quite successful in their criminal endeavors. Folks should not be so obtuse about these activities. It's almost blatantly in-your-face, so to speak. These guys have no fear of retribution. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLMbTTq1pz9mNUZTMRAvd8AJ0b/EY2TtqYKRqzsxxGr9GzG4TElgCgotLP TYjuUwZjUYGRM+WLzwhDHRI= =L6n9 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson <fergdawgster@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Folks should not be so obtuse about these activities. It's almost blatantly in-your-face, so to speak. These guys have no fear of retribution.
no real arguement, but... 'please provide some set of workable solutions' The ARIN meetings (at least) are open, please come and help guide policies. I'm sure RIPE also wouldn't mind a discussion, if there could be some positive policy outcome. -Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Dec 22, 2009 at 10:58 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson <fergdawgster@gmail.com> wrote:
Folks should not be so obtuse about these activities. It's almost blatantly in-your-face, so to speak. These guys have no fear of retribution.
no real arguement, but... 'please provide some set of workable solutions'
First question: Solution(s) for which problem(s)?
The ARIN meetings (at least) are open, please come and help guide policies. I'm sure RIPE also wouldn't mind a discussion, if there could be some positive policy outcome.
Frankly, there simply is not enough hours in the day for what I already do, and trying to add "policy foo" to my laundry list of stuff just isn't going to happen. Many of us have already tried to engage ICANN on domain registration issues (primarily bad registrars and policy cruft), as well as RIRs, etc., to no avail. I've simply given up on trying to make a dent in policy issues because profit trumps everything else, plus -- as I said -- I just have no spare cycles. I have taken a different set of tactics to go after criminal activities... policy stuff doesn't work. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLMcFKq1pz9mNUZTMRAjT1AJ9WqMg2UdT+KofRNxCMoKmIscGG0ACfe9h7 zlj1GwsVogB4xfmPsBYxTZ8= =vBkP -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
On Wed, Dec 23, 2009 at 2:05 AM, Paul Ferguson <fergdawgster@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Dec 22, 2009 at 10:58 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson <fergdawgster@gmail.com> wrote:
Folks should not be so obtuse about these activities. It's almost blatantly in-your-face, so to speak. These guys have no fear of retribution.
no real arguement, but... 'please provide some set of workable solutions'
First question: Solution(s) for which problem(s)?
ideally the 'bad folks get ip space' (which was part of the initial thrust of the thread)
Many of us have already tried to engage ICANN on domain registration issues (primarily bad registrars and policy cruft), as well as RIRs, etc., to no avail.
some headway was made, some more may still come. It's certainly not 'fast' though :(
I've simply given up on trying to make a dent in policy issues because profit trumps everything else, plus -- as I said -- I just have no spare cycles.
If the, for the ip space issue, main problem can't be solved without policy this seems like abdication, no?
I have taken a different set of tactics to go after criminal activities... policy stuff doesn't work.
also good... except that the only real fix for some of this is policy things, I fear. IP-address issues can't get solved without policy changes, which happen today via community consensus. Domain-name issues have to get hammered out from the top down (with some policy that allows registries to impose change on registrars. This DNS issues may also get resolved with action coming from ICANN (hope springs eternal). -Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Dec 22, 2009 at 11:14 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
IP-address issues can't get solved without policy changes, which happen today via community consensus. Domain-name issues have to get hammered out from the top down (with some policy that allows registries to impose change on registrars. This DNS issues may also get resolved with action coming from ICANN (hope springs eternal).
Well, I have to say I'm somewhat pessimistic that ICANN really cares about what security issues evolve from their "policy" failures. If history is any lesson, it should teach us that ICANN cares more about expanding the TLD space to the point where it can be abused infinitely. Having said that, ICANN is not IANA, and the last time I checked, IANA had some measure of influence in the policies that the RIRs operated within... or is that the role of yet another level of obfuscation (policy authority)? I think you see my point... It's just unworkable as things stand, and rife with abuse -- the policy loopholes allow these commercial entities to reap the benefits of huge profits, while allowing criminals to also share in the same benefits. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFLMcYzq1pz9mNUZTMRAlA2AKCF5tVTxd6RCBDjsbti2PEfRjBdoACgwJ8a Z59NZBLXg2oh7+EDI+MQQEU= =zCON -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
On Wed, Dec 23, 2009 at 01:58:47AM -0500, Christopher Morrow wrote:
no real arguement, but... 'please provide some set of workable solutions'
The set of workable solutions at this point looks something like "null routes, firewall rules, blacklist entries" -- in order to deny traffic to and from such locales. I agree just about entirely with Ferg: the policy angle is a dead end. The organizations involved are either clueless or entirely focused on other goals (e.g., profit) at the expense of sound policy. ---Rsk
Rich Kulawiec wrote:
On Wed, Dec 23, 2009 at 01:58:47AM -0500, Christopher Morrow wrote:
no real arguement, but... 'please provide some set of workable solutions'
The set of workable solutions at this point looks something like "null routes, firewall rules, blacklist entries" -- in order to deny traffic to and from such locales.
I agree just about entirely with Ferg: the policy angle is a dead end. The organizations involved are either clueless or entirely focused on other goals (e.g., profit) at the expense of sound policy.
Gosh, there's no way I can create this public good, because someone somewhere will use it in the commission of a crime notwithstanding all the benefits it confers. I'll just throw down props to Paul Samuelson since he's no longer with us and leave it at that.
---Rsk
On Dec 22, 2009, at 11:58 PM, Christopher Morrow wrote:
On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson <fergdawgster@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Folks should not be so obtuse about these activities. It's almost blatantly in-your-face, so to speak. These guys have no fear of retribution.
no real arguement, but... 'please provide some set of workable solutions'
The ARIN meetings (at least) are open, please come and help guide policies. I'm sure RIPE also wouldn't mind a discussion, if there could be some positive policy outcome.
Rather than expecting anti-spam researchers to lobby at ARIN & RIPE meetings, perhaps ARIN & RIPE representatives could visit anti-spam meetings such as MAAWG to ask how they can help? I'd be happy to make some introductions. -- J.D. Falk <jdfalk@returnpath.net> Return Path Inc
JD Great point, I am more than happy to have a couple of people from ARIN or RIPE as guests at the next MAAWG in SFO or the subsequent one in Barcelona. Mike On 12/23/09 1:18 PM, "J.D. Falk" <jdfalk-lists@cybernothing.org> wrote:
On Dec 22, 2009, at 11:58 PM, Christopher Morrow wrote:
On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson <fergdawgster@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Folks should not be so obtuse about these activities. It's almost blatantly in-your-face, so to speak. These guys have no fear of retribution.
no real arguement, but... 'please provide some set of workable solutions'
The ARIN meetings (at least) are open, please come and help guide policies. I'm sure RIPE also wouldn't mind a discussion, if there could be some positive policy outcome.
Rather than expecting anti-spam researchers to lobby at ARIN & RIPE meetings, perhaps ARIN & RIPE representatives could visit anti-spam meetings such as MAAWG to ask how they can help?
I'd be happy to make some introductions.
-- J.D. Falk <jdfalk@returnpath.net> Return Path Inc
Wouldn't that be kind of pointless? ARIN policies are proposed by the public, not ARIN staff or board members. https://www.arin.net/policy/pdp.html Policy proposals may be submitted by anyone in the global Internet community except for members of the ARIN Board of Trustees or the ARIN staff. On Wed, 23 Dec 2009, O'Reirdan, Michael wrote:
JD
Great point, I am more than happy to have a couple of people from ARIN or RIPE as guests at the next MAAWG in SFO or the subsequent one in Barcelona.
Mike
On 12/23/09 1:18 PM, "J.D. Falk" <jdfalk-lists@cybernothing.org> wrote:
On Dec 22, 2009, at 11:58 PM, Christopher Morrow wrote:
On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson <fergdawgster@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Folks should not be so obtuse about these activities. It's almost blatantly in-your-face, so to speak. These guys have no fear of retribution.
no real arguement, but... 'please provide some set of workable solutions'
The ARIN meetings (at least) are open, please come and help guide policies. I'm sure RIPE also wouldn't mind a discussion, if there could be some positive policy outcome.
Rather than expecting anti-spam researchers to lobby at ARIN & RIPE meetings, perhaps ARIN & RIPE representatives could visit anti-spam meetings such as MAAWG to ask how they can help?
I'd be happy to make some introductions.
-- J.D. Falk <jdfalk@returnpath.net> Return Path Inc
---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
I expect the ARIN and RIPE folks may be influential and as such, it could be a good idea for them to attend. Mike ________________________________ From: Jon Lewis [mailto:jlewis@lewis.org] Sent: Thu 12/24/2009 3:13 PM To: O'Reirdan, Michael Cc: J.D. Falk; nanog@nanog.org Subject: Re: Article on spammers and their infrastructure Wouldn't that be kind of pointless? ARIN policies are proposed by the public, not ARIN staff or board members. https://www.arin.net/policy/pdp.html Policy proposals may be submitted by anyone in the global Internet community except for members of the ARIN Board of Trustees or the ARIN staff. On Wed, 23 Dec 2009, O'Reirdan, Michael wrote:
JD
Great point, I am more than happy to have a couple of people from ARIN or RIPE as guests at the next MAAWG in SFO or the subsequent one in Barcelona.
Mike
On 12/23/09 1:18 PM, "J.D. Falk" <jdfalk-lists@cybernothing.org> wrote:
On Dec 22, 2009, at 11:58 PM, Christopher Morrow wrote:
On Wed, Dec 23, 2009 at 1:12 AM, Paul Ferguson <fergdawgster@gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Folks should not be so obtuse about these activities. It's almost blatantly in-your-face, so to speak. These guys have no fear of retribution.
no real arguement, but... 'please provide some set of workable solutions'
The ARIN meetings (at least) are open, please come and help guide policies. I'm sure RIPE also wouldn't mind a discussion, if there could be some positive policy outcome.
Rather than expecting anti-spam researchers to lobby at ARIN & RIPE meetings, perhaps ARIN & RIPE representatives could visit anti-spam meetings such as MAAWG to ask how they can help?
I'd be happy to make some introductions.
-- J.D. Falk <jdfalk@returnpath.net> Return Path Inc
---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Wed, Dec 23, 2009 at 01:58:47AM -0500, Christopher Morrow wrote:
The ARIN meetings (at least) are open, please come and help guide policies. I'm sure RIPE also wouldn't mind a discussion, if there could be some positive policy outcome.
Why should I or anyone else do that? It will cost us, personally, a great deal of time and money and hassle and -- as far as I can tell -- will achieve nothing. Let me explain why I say that. The senior people working in the anti-abuse area aren't hard to find. We hang out on spam-l, or funsec, or in various blogs, and we publish comments/reports/essays pointing out what we observe. (Well, at least some of it. I've learned to keep much of what I find back, as it often reveals too much about my methods. And there's been retaliation from time to time, some of it disruptive and expensive.) If ARIN and/or RIPE and/or ICANN and/or anyone else were truly interested in making a dent in the problem, then they would have already paid attention to our collective work product. And they would have already blacklisted certain individuals/organizations -- permanently -- and revoked all their resources. (I trust everyone is painfully aware than all lesser steps have already failed miserably and will of course fail miserably in the future. This is not a set of problems that can be addressed with half-measures: those are really not worth anyone's time or effort. Even the approach I'm suggesting may well not be sufficient, but it's clearly necessary.) I see no sign that these organizations are taking any such measures, nor any sign that they're even open to the possibility of doing so. Yet this is what must be done if any substantial impact is to be achieved. Bad actors have quite thoroughly gamed the system and have long since provided overwhelming proof that while their tactics may change, their strategy will always be to profit by as much abuse they can possibly manage. They'll never stop, they'll only adapt as old methods cease to work and new ones become available; it's their "career". The only recourse we have is to cut them off for life. ---Rsk
If ARIN and/or RIPE and/or ICANN and/or anyone else were truly interested in making a dent in the problem, then they would have already paid attention to our collective work product.
the rirs, the ietf, the icann, ... each think they are the top of the mountain. we are supposed to come to them and pray. more likely that the itu will come to them and prey. randy
If ARIN and/or RIPE and/or ICANN and/or anyone else were truly interested in making a dent in the problem, then they would have already paid attention to our collective work product.
the rirs, the ietf, the icann, ... each think they are the top of the mountain. we are supposed to come to them and pray. more likely that the itu will come to them and prey.
I thought the ITU is the owner of the mountain or pretends to be... Jorge
Randy Bush <randy@psg.com> writes:
If ARIN and/or RIPE and/or ICANN and/or anyone else were truly interested in making a dent in the problem, then they would have already paid attention to our collective work product.
the rirs, the ietf, the icann, ... each think they are the top of the mountain. we are supposed to come to them and pray. more likely that the itu will come to them and prey.
ARIN (an RIR) does not think in terms of mountains. the staff and company does what members and the elected board and elected advisory council ask. ARIN is a 501(c)(6) and sticks to its knitting, which thus far means no distinguished role in "spammers and their infrastructure" but that could change if someone writes a policy proposal which is adopted after the normal policy development process. please do consider whether ARIN could help with "spammers and their infrastructure" and if so, write a policy draft to that effect. ARIN is responsive to community input, and has well established and well publicized mechanisms for receiving and processing community input. nobody has to come and pray, but likewise, nobody should expect ARIN to look for mission creep opportunities. ARIN will go on doing what the community asks, no less, no more. ARIN has no mechanism, as a company, for "[paying] attention to [your] collective work product". our members, and the public at large who participates in ARIN's policy development process, do that. -- Paul Vixie Chairman, ARIN BoT KI6YSY
One might say the same about the IETF, which Randy likes to lampoon. Not sure how it comes up in this context, as (as Randy loves to remind us) while many operators attend, it is not first-and-foremost an operational community. As to ICANN, I think Rich may be talking about the registries and registrars for their DNS names, but not the agency that coordinates them. At most, ICANN can give them suggestions. And as for addresses, they get them from their local ISPs. What ICANN and many of the registries have in fact done is make an issue of domain name "tasting", which is a means by which some forms of abusers change names rapidly to evade filters. That is a matter of having the fox guard the henhouse, however; the registries make money on names being sold, and "tasting" is a means of making a lot of sales. So while some have good efforts there, not all are motivated to fight abuse. As to addresses, we can point to at least one entire ISP shut down as most of the traffic coming from it was abusive. But for ISPs, it becomes at least in part a matter of the amount of trouble they cause their immediate neighbors. If they can link to other ISPs, who they sell their services too is somewhat opaque to the wider world. And since the abusers are not above "owning" systems, every network has some subset of its subscribers to think about. I agree with your sentiment, Rich, and empathize with your frustration. Writing comments in blogs doesn't get the hard work of tools and policy done, though. You have to take the next step. On Dec 30, 2009, at 8:26 PM, Paul Vixie wrote:
Randy Bush <randy@psg.com> writes:
If ARIN and/or RIPE and/or ICANN and/or anyone else were truly interested in making a dent in the problem, then they would have already paid attention to our collective work product.
the rirs, the ietf, the icann, ... each think they are the top of the mountain. we are supposed to come to them and pray. more likely that the itu will come to them and prey.
ARIN (an RIR) does not think in terms of mountains. the staff and company does what members and the elected board and elected advisory council ask. ARIN is a 501(c)(6) and sticks to its knitting, which thus far means no distinguished role in "spammers and their infrastructure" but that could change if someone writes a policy proposal which is adopted after the normal policy development process.
please do consider whether ARIN could help with "spammers and their infrastructure" and if so, write a policy draft to that effect. ARIN is responsive to community input, and has well established and well publicized mechanisms for receiving and processing community input. nobody has to come and pray, but likewise, nobody should expect ARIN to look for mission creep opportunities. ARIN will go on doing what the community asks, no less, no more. ARIN has no mechanism, as a company, for "[paying] attention to [your] collective work product". our members, and the public at large who participates in ARIN's policy development process, do that. -- Paul Vixie Chairman, ARIN BoT KI6YSY
At the Montevideo ICANN meeting, in August, 2001, I was surprised, and disapointed, that the ISP Constituency had reduced to ... a couple of IP attorneys. So, as a point of departure, were one going to advocate policy which affects ISPs as ISPs, as opposed to ISPs as trademark portfolio managers, one would first have to, as Shakespeare put it, kill all the lawyers. Well, perhaps it would be sufficient to inform the lawyers the ISPs do send, who are nice enough people, that ISPs have operational issues other than protecting their brand portfolios. At the Paris meeting two years ago there was a charming presentation on GNSO constituency voting behavior, which showed that on the order of all the time less noise, the ISP Constituency, voted indistinguishably from the Intellectual Property Constituency. Of course, the same result was shown for the Business Constituency, but there I wouldn't bother to inform the incumbents of the end of their tenure, should real business ever take an interest in policy formation at ICANN. I agree with Fred, IETF has use case requirements such as providing competitors with a means to create standards without risk of competition policy complications, as well as more benign requirements that fit on the backs of tee shirts. Where the chain of delegation Paul mentions, by way of inviting NANOG contributors to do more than suggest ARIN do something, of addresses, and the chain of delegation Fred mentions, commenting on registries, registrars, and the Add Grace Period (AGP) exploit (aka "domain tasting"), or domains, share an anchor is in the IANA function. I've mentioned this previously, the delegation of trust down the BGP bunny trail and the delegation of trust down the DNS bunny trail, are an area where delegation of trust, as a policy issue, is common to both the numbers and the names operators. The back of the envelope for the AGP exploit is that it contributed a substantial part of the 35,000,000 monitized domains registrations. With that assumption, and using the dominant pricing (.COM), this means on the order of $6 to the registries and their operators, on the order of $1 to the registrars, and on the order of $0.20 to ICANN. That is $100m to COM/NET/ORG (VGRS and PIR/Afilias), and $35m to eNom, Moniker, Directi, ... and $6m to ICANN, per year, recurring, for quite a few years to come. NOTE WELL: As a registry operator CORE does not allow, and as a registrar, CORE does not pursue AGP exploits. Where Fred errs is in characterizing the AGP exploit as a means to provide operational agility to spammers. Of course it was used that way, but the entire point of agility is not avoiding a $6 cost of asset, it is having an asset that for some number of weeks, recently days, now hours, which allows each particular exploit to meet its ROI goals. The overwhelming use case for the AGP exploit was to acquire static, recurring revenue resources, monitized by advertizing, and a mature market in these assets exists. Greater agility arises from flux and double flux, exploits of the rapid update property Paul, and I, commented on back in August 2004. In a nutshell, domainers need low cost means to discover low marginal cost to acquire strings exceeding some low multiple of $6/year gross recurring revenue. Spammers (and other rational economic actors, e.g., the Conficker .C rendezvous mechanism author(s)) create value in excess of some low multiple of $6/day non-recurring revenue through arbitrary string registration. Domainers are not the same as spammers, and I've written a draft section here (http://wampum.wabanaki.net/vault/2009/12/005462.html, a contribution to a Bolt techlaw paper in progress) that there is at least one frame of reference other than trademark interest to view domain name speculation as harmful to public policy goals, in particular, IPv4 address exhaustion. I'd be grateful for informed comments on that note. It does take more than writing blog posts, and outcomes are not a given. I am, at year's end, very disappointed in the registries as a constituency, and very disappointed in the registrars as a constituency, and profoundly concerned that the ICANN Board has been successfully mobbed by domainers moving up the food chain to registry applicants. This will either mean "four eyes and more" on deltas to the IANA root become a thing of the past, or applications like the Catalan application in 2004 will be served after the last monitization exploit, and the last brand name, has been stuffed into the anything-for-a-dollar-or-a-laugh root. The only thing remotely "good" to come out of ICANN is bidi (Arabic and Hebew scripts) and Cyrillic and CJK strings, as a presentation layer hack (IDNAbis), as TLDs, enabling root-to-leaf script consistency, for some 40 ccTLD operators and their user bases. The bulk of the 100 or so non-shell registrars [1] were not AGP exploiters, and the CAT, COOP, and MUSEUM registries and their operators, do not pursue secondary revenue exploits. Randy suggests the ITU may prey on ICANN. I'm sorry to say that I see more likelihood of failure of the mostly private system now then I did prior to the transition from the MoU to the AoJ regimes, though not because of any change innate to these as legal regimes, but through institutional capture by private interest, naturally excluding addressing and protocol interests, and unrelated, the executive, Board and some staff preference for large for-profit corporations, possibly linked to status and individual career choices. My New Year's resolution is to spend the first week of the year coding, and to pick up my old OSF RI work, mk++, like knitting, as therapy. Eric CTO, CORE IANA Registrar ID 15 http://iana.org/assignments/registrar-ids/registrar-ids.xhtml operator, .CAT http://iana.org/reports/2005/cat-report-18nov2005.html operator, .MUSEUM http://iana.org/reports/2001/museum-report-30oct01.html [1] shell registrars exist for another exploit, to maximize race contention results for the VGRS drop pool, the acquisition of expired names which have "name" value or residual traffic monitization value. Four companies control 318 US domiciled ICANN accreditations: eNom (116), Directi/PDR (47), Dotster (51), and Snapnames (104). Source: http://www.knujon.com/registrars/ On 12/31/09 12:06 AM, Fred Baker wrote:
One might say the same about the IETF, which Randy likes to lampoon. Not sure how it comes up in this context, as (as Randy loves to remind us) while many operators attend, it is not first-and-foremost an operational community. As to ICANN, I think Rich may be talking about the registries and registrars for their DNS names, but not the agency that coordinates them. At most, ICANN can give them suggestions. And as for addresses, they get them from their local ISPs.
What ICANN and many of the registries have in fact done is make an issue of domain name "tasting", which is a means by which some forms of abusers change names rapidly to evade filters. That is a matter of having the fox guard the henhouse, however; the registries make money on names being sold, and "tasting" is a means of making a lot of sales. So while some have good efforts there, not all are motivated to fight abuse.
As to addresses, we can point to at least one entire ISP shut down as most of the traffic coming from it was abusive. But for ISPs, it becomes at least in part a matter of the amount of trouble they cause their immediate neighbors. If they can link to other ISPs, who they sell their services too is somewhat opaque to the wider world. And since the abusers are not above "owning" systems, every network has some subset of its subscribers to think about.
I agree with your sentiment, Rich, and empathize with your frustration. Writing comments in blogs doesn't get the hard work of tools and policy done, though. You have to take the next step.
On Dec 30, 2009, at 8:26 PM, Paul Vixie wrote:
Randy Bush <randy@psg.com> writes:
If ARIN and/or RIPE and/or ICANN and/or anyone else were truly interested in making a dent in the problem, then they would have already paid attention to our collective work product.
the rirs, the ietf, the icann, ... each think they are the top of the mountain. we are supposed to come to them and pray. more likely that the itu will come to them and prey.
ARIN (an RIR) does not think in terms of mountains. the staff and company does what members and the elected board and elected advisory council ask. ARIN is a 501(c)(6) and sticks to its knitting, which thus far means no distinguished role in "spammers and their infrastructure" but that could change if someone writes a policy proposal which is adopted after the normal policy development process.
please do consider whether ARIN could help with "spammers and their infrastructure" and if so, write a policy draft to that effect. ARIN is responsive to community input, and has well established and well publicized mechanisms for receiving and processing community input. nobody has to come and pray, but likewise, nobody should expect ARIN to look for mission creep opportunities. ARIN will go on doing what the community asks, no less, no more. ARIN has no mechanism, as a company, for "[paying] attention to [your] collective work product". our members, and the public at large who participates in ARIN's policy development process, do that. -- Paul Vixie Chairman, ARIN BoT KI6YSY
While not at all touching the accuracy of knujon's stats with a bargepole, it would be interesting if some process were developed to deaccredit or otherwise kill off the shell registrars .. and the bogus LIRs (which is how the thread started). On Thu, Dec 31, 2009 at 10:02 PM, Eric Brunner-Williams <brunner@nic-naa.net> wrote:
[1] shell registrars exist for another exploit, to maximize race contention results for the VGRS drop pool, the acquisition of expired names which have "name" value or residual traffic monitization value. Four companies control 318 US domiciled ICANN accreditations: eNom (116), Directi/PDR (47), Dotster (51), and Snapnames (104). Source: http://www.knujon.com/registrars/
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On 1/2/10 11:38 PM, Suresh Ramasubramanian wrote:
... it would be interesting if some process were developed to deaccredit or otherwise kill off the shell registrars
Suresh, Why? ICANN accreditation provides the registrar with a right to attempt OT&E with registries, the Verisign operated .com registry in particular, and with that, the right to specify a range of addresses from which the .com registy EPP server must accept connections. That is the asset. Every day "mumble.com" is dropped by the .com registry and every day registrars "race" to register "mumble.com". For some reason "mumble.com" has value not present in "mumble.bar", where "bar" takes on some 20 values other than "com", possibly because "mumble" is a generic or hyphenated concatenation of a generic and some other string, possibly also a generic, possibly because strlen("mumble") is less than 5. If every registrar has the right to a fixed number of connections, or "threads", at the .com registry, then the probability of acquisition of "mumble.com" is 1/N, where N is the number of registrars competing to register "mumble.com". Note that this might not be sufficient to motivate investment in a "secondary market", in the abstract, however the verisign registry, and others, identified the "secondary market" as having high value and attempted to obtain non-random distribution of secondary registrations. Therefore, while the value of "threads" was significantly greater than the cost of ICANN accreditation (a subject of note in its own right), it was a rational economic activity to form registrar legal entities, obtain ICANN accreditation, and rent the "threads" to entities which specialized in the "secondary market", that is, in collecting "back orders" on "mumble.com" from entities seeking to become the registrant of "mumble.com", presumably ranked by value (bids at auction), and execution of registrations for "mumble.com" in a race environment. That's auction to 3pm minus some delta, and race at 3pm minus some epsilon to 3pm plus some epsilon. So, a well-ordered sequence sensor and slots on a roulette wheel. Clearly, the more slots on the roulette wheel, the greater the likelihood of winning. So, the root cause for shell registrars is the value of expired names, and the association of acquisition resources with accreditation. Value arises from (a) strings which can be repurposed economically (I claim that should Qualcom forget to renew "q.com" that "q.com" can be repurposed as something other than a domain name for a communications goods and services vendor), and (b) strings which cannot be repurposed economically, but have some fungible value, aka "traffic". Now, shell registrars are a pain in the ass, not for operational reasons, but because every time someone wants to say something stupid and get away with it they say "<some large number> of registrars". For example, at the ICANN Seoul meeting an unidentified male (in the transcript) who I recall was Dan Halloran, ICANN's Deputy General Counsel, said, while discussing the proposed new gTLD registry agreement (note, it isn't called a contract): "... the central idea is still there that ICANN does retain the right to modify the agreement..." and a minute later "... the point is there's 900 registrars and ... We don't have to go individually and negotiate bilaterally with each registrar." Source, transcript [1]. So the number of shell registrars is offered, by ICANN's DGC, and presumably by ICANN's GC (John Jeffrey) as well, as an absolute bar to contractual distinguishment. Registrars can be "bad" because they fail to pay ICANN (the commonest form of registrar deaccreditation) or because they aren't responsive to email or because they are claimed to be in breech of some specific term in the current accreditation agreement. Other than that, it is ICANN's consistent position of record that registrars cannot be distinguished in contract since the divestiture of Network Solutions (registrar) by Verisign (registry). Now to me (Eric Brunner-Williams, hat=="operator of ICANN accredited registrar #439 and CTO of ICANN accredited registrar #15 and operator of the sponsored gTLD .cat and .museum" registries for their respective ICANN contracted sponsors), the inability to distinguish, in contract, between an application advanced by the RBN and the IRC is ... a pain in the ass. CORE's "business" is socially useful, socially responsible registries, its been our business since Jon Postel and others [2] drew up the IAHC-MOU [3], forming CORE. We'd like to see a contract for .com's clones, where "policy" is completely defined by first $6 offered, and a contract for .cat's kittens, where "policy" is consistent with the language in section 3, subsection 2, of RFC 1591. The IRC contacted CORE (thanks to the ICANN staffer who suggested us to them!) for a .red-{cross,crescent} (Latin and Arabic scripts) but because ICANN won't create contractual constructs now, having done so in the past (the initial 7-10 round was partitioned between what is now called "standard" (biz/info/name/pro) and "sponsored" (aero/coop/museum), and the 2003 round was sponsored), the IRC (and CORE, and all of CORE's other registry partners, from the Provincial Government of Quebec to the Government of the City of Paris) has to wait until ICANN's crafted an evaluation process capable of evaluating every currently imagined scheme the RBN (or any other rational economic actor) puts forward. Oddly enough, this appears to require unbounded time, and naturally enough, someone on NANOG will opine that one or more of, particularly the last item of this list -- {dnssec, ipv6, idns for ccTLDs, new gTLDs (ADH or IDN)} is "a bad thing". As an Indian, I will simply observe that the partition of Indian Countries into "Canada", "US", ... is suboptimal, and the further partition into "native" namespaces under each of the iso3166 associated namespaces is also suboptimal. We could do better, but even if the nsn.us namespace, to pick one well-ignored example, were turned over to me personally, that wouldn't meet all the needs of two of the three tribes I have cultural and/or political association with, which exist "in" both the United States and Canada. That is, I offer the claim that at least one TLD ought to exist, a claim made to Jon prior to the Green and White Papers. I expect the time from request to delegation will be 20 years, assuming the unbounded time requirement becomes bounded in 5 or so years from the present. Shell registrars are not, generally, the source of primary registrations of arbitrarily abusive intent. That problem lies elsewhere and is adequately documented.
.. and the bogus LIRs (which is how the thread started).
This has been a tutorial on why shell registrars are not the source of operational issues that could reasonably be characterized as problems. Problematic use of the DNS exists, but the registrar association is otherwise than to shell registrars. These are different exploits. Eric [1] http://sel.icann.org/meetings/seoul2009/transcript-gtld-registries-constitue... at pages 32 and 33, respectively. [2] ISOC, IANA, IAB, FNC, ITU, INTA, WIPO [3] http://www.gtld-mou.org/
On Sun, Jan 3, 2010 at 10:24 PM, Eric Brunner-Williams <brunner@nic-naa.net> wrote:
On 1/2/10 11:38 PM, Suresh Ramasubramanian wrote:
... it would be interesting if some process were developed to deaccredit or otherwise kill off the shell registrars
Suresh, Why?
My comment was more in the context of this thread's original topic - killing off bogus spam / botnet operations that become registrars (and/or registrar resellers) who buy an outsourced instance of one of the "registrar in a box" services, and are immediately in business. Though, you might want to prevent shell registrars for the same reasons that auctions try to weed out shill bidders. And while it is a rational economic idea for a bidder to game an auction by setting up shills, the auctioneer and the other bidders lose out in the end.
Now, shell registrars are a pain in the ass, not for operational reasons, but because every time someone wants to say something stupid and get away with it they say "<some large number> of registrars".
That too of course. Reminds you of Tammanny Hall sometimes? :)
Shell registrars are not, generally, the source of primary registrations of arbitrarily abusive intent. That problem lies elsewhere and is adequately documented.
Wasn't talking about shell entities setup by various registrars for drop catching and such. Though as I pointed out, those could be weeded out for fairly sensible economic reasons, for the same reasons such practices are discouraged in elections, auctions, rationing systems (like the depression era / WW-II food stamps system) etc. Was talking about totally bogus registrars that are "spammer sets up an LLC, said LLC submits all the paperwork to become a registrar, rents an instance of a DIY registrar service .. and starts doing roaring business with just one customer - the spammer) --srs
The obvious change RIRs could make would be to make sure the contracts they allocate resources under give them the latitude to cancel those contracts if certain boundaries of behavior are breached. YES I REALIZE EASIER SAID THAN DONE. But just as allocation of resources is not a transfer of ownership to the allocatee by the same reasoning cancellation of that allocation for breach of contract is just a withdrawal of said license, not a "taking". What's difficult is establishing a system of reasonable due process within which to assert breaches, particularly given the many jurisdictions involved. ICANN is certainly building a model just like this with the UDRP etc. so perhaps that's something to follow. -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
Barry Shein wrote:
The obvious change RIRs could make would be to make sure the contracts they allocate resources under give them the latitude to cancel those contracts if certain boundaries of behavior are breached.
YES I REALIZE EASIER SAID THAN DONE.
But just as allocation of resources is not a transfer of ownership to the allocatee by the same reasoning cancellation of that allocation for breach of contract is just a withdrawal of said license, not a "taking".
Cool. Then you just have to figure out how to unilaterally withdraw a resource that doesn't have a centralized automated verification system. Taking you out of whois doesn't automatically take you out of people's BGP tables, after all. -Paul
On Dec 31, 2009, at 11:32 AM, Paul Timmins wrote:
Cool. Then you just have to figure out how to unilaterally withdraw a resource that doesn't have a centralized automated verification system. Taking you out of whois doesn't automatically take you out of people's BGP tables, after all.
See http://www.ietf.org/dyn/wg/charter/sidr-charter.html Regards, -drc
From: Paul Timmins [paul@telcodata.us] Cool. Then you just have to figure out how to unilaterally withdraw a resource that doesn't have a centralized automated verification system. Taking you out of whois doesn't automatically take you out of people's BGP tables, after all.
That's step two of the problem - enforcement. Enforcement may seem "hard", but it's impossible without a policy. If there is no policy clearly violated, enforcement cannot happen. Regards, Alex Lanstein
Cool. Then you just have to figure out how to unilaterally withdraw a resource that doesn't have a centralized automated verification system. Taking you out of whois doesn't automatically take you out of people's BGP tables, after all.
That's step two of the problem - enforcement. Enforcement may seem "hard", but it's impossible without a policy. If there is no policy clearly violated, enforcement cannot happen.
You are right, without a policy there is not what to enforce, but on the other hand even with a policy you need somebody with police powers to enforce the policy. Then who do we want (if we do, which I don't believe we do) to play the net-police role ? ICANN ? the RIRs ? the ISPs ? ITU ? X invaders ? three letter agency of your choice ? local law enforcement ? I truly believe that if many service providers (access, domain, hosting, etc) reduce just a notch the profit making greed and start to close some doors for the bad guys we may be able to mitigate some problems. Time for new year resolutions ... Cheers Jorge
participants (21)
-
Alex Lanstein -
Barry Shein -
Christopher Morrow -
David Conrad -
Eric Brunner-Williams -
Fred Baker -
J.D. Falk -
Joel Jaeggli -
Jon Lewis -
Jorge Amodio -
Leo Vegoda -
Nick Hilliard -
O'Reirdan, Michael -
Paul Ferguson -
Paul Timmins -
Paul Vixie -
Phil Regnauld -
Randy Bush -
Rich Kulawiec -
Suresh Ramasubramanian -
Tony Finch