Re: Repeated Blacklisting / IP reputation
John Curran wrote:
On Sep 8, 2009, at 2:18 PM, JC Dill wrote:
It seems simple and obvious that ARIN, RIPE, et. al. should determine the blacklist state of a reclaimed IP group and ensure that the IP group is usable before re-allocating it.
When IPs are reclaimed, first check to see if the reclaimed IPs are on any readily checked RBL or private blacklist of major ISPs, corporations, universities, etc. If so, work with those groups to get the blocks removed *prior* to reissuing the IPs to a new entity. Before releasing the IPs to a new entity, double check that they are not being blocked (that any promises to remove them from a blacklist were actually fulfilled). Hold the IPs until you have determined that they aren't overly encumbered with prior blacklist blocks due to poor behavior of the previous entity. (The same should be done before allocating out of a new IP block, such as when you release the first set of IPs in a new /8.)
In this case, it's not the RBL's that are the issue; the address block in question isn't on them. It's the ISP's and other firms using manual copies rather than actually following best practices.
It's not that hard to make a list of the major ISPs, corporations, universities (entities with a large number of users), find willing contacts inside each organization (individual or role addresses you can email, and see if the email bounces, and who will reply if the email is received) and run some automated tests to see if the IPs are being blocked. In your follow-up email to me, you said you check "dozens" of RBLs - that is clearly insufficient - probably by an order of magnitude - of the entities you should check with. The number should be "hundreds". A reasonably cluefull intern can provide you with a suitable list in short order, probably less than 1 day, and find suitable contacts inside each organization in a similar time frame - it might take a week total to build a list of ~500 entities and associated email addresses. Because of employee turn-over the list will need to be updated, ~1-10 old addresses purged and replaced with new ones on a monthly basis.
Why isn't this being done now?
Issuing reclaimed IPs is a lot like selling a used car, except that the buyer has no way to "examine" the state of the IPs you will issue them beforehand. Therefore it's up to you (ARIN, RIPE, et. al.) to ensure that they are "just as good" as any other IP block. It is shoddy business to take someone's money and then sneakily give them tainted (used) goods and expect them to deal with cleaning up the mess that the prior owner made, especially when you charge the same rate for untainted goods!
Not applicable in this case, as noted above.
What do you mean, "not applicable"? You take the money and issue IPs. There is no way for the "buyer" to know before hand if the IPs are "tainted" (used) or new. It is up to you (ARIN) to ensure that the goods (IPs) are suitable for the intended use. My analogy is entirely applicable, and I'm amazed you think otherwise.
So, back to the question: could someone explain why they've got copies of the RBL's in their network which don't get updated on any reasonable refresh interval? (weekly? monthly?)
The "why" really isn't at issue - it happens and it's going to keep happening. The question is what are you (ARIN) going to do about it? Give me the serenity to accept the things I cannot change, The courage to change the things I can, And the wisdom to know the difference. You (ARIN et. al.) don't have any ability to change the why. What you can change is how you go about determining if an IP block is suitable for reallocation or not, and what steps you take to repair IP blocks that aren't suitable for reallocation. jc - posted to NANOG since John indicated that he thought his reply to me was going to NANOG as well.
John Curran wrote:
On Sep 8, 2009, at 2:18 PM, JC Dill wrote:
It seems simple and obvious that ARIN, RIPE, et. al. should determine the blacklist state of a reclaimed IP group and ensure that the IP group is usable before re-allocating it.
When IPs are reclaimed, first check to see if the reclaimed IPs are on any readily checked RBL or private blacklist of major ISPs, corporations, universities, etc. If so, work with those groups to get the blocks removed *prior* to reissuing the IPs to a new entity. Before releasing the IPs to a new entity, double check that they are not being blocked (that any promises to remove them from a blacklist were actually fulfilled). Hold the IPs until you have determined that they aren't overly encumbered with prior blacklist blocks due to poor behavior of the previous entity. (The same should be done before allocating out of a new IP block, such as when you release the first set of IPs in a new /8.)
In this case, it's not the RBL's that are the issue; the address block in question isn't on them. It's the ISP's and other firms using manual copies rather than actually following best practices.
It's not that hard to make a list of the major ISPs, corporations, universities (entities with a large number of users), find willing contacts inside each organization (individual or role addresses you can email, and see if the email bounces, and who will reply if the email is received) and run some automated tests to see if the IPs are being blocked. In your follow-up email to me, you said you check "dozens" of RBLs - that is clearly insufficient - probably by an order of magnitude - of the entities you should check with. The number should be "hundreds". A reasonably cluefull intern can provide you with a suitable list in short order, probably less than 1 day, and find suitable contacts inside each organization in a similar time frame - it might take a week total to build a list of ~500 entities and associated email addresses. Because of employee turn-over the list will need to be updated, ~1-10 old addresses purged and replaced with new ones on a monthly basis.
Really? And you expect all these organizations to do ... what? Hire an intern to be permanent liaison to ARIN? Answer queries to whether or not IP space X is currently blocked (potentially at one of hundreds or thousands of points in their system, which corporate security may not wish to share, or even give "some random intern" access to)? Process reports of new ARIN delegations? What are you thinking they're going to do? And why should they care enough to do it?
Why isn't this being done now?
Issuing reclaimed IPs is a lot like selling a used car, except that the buyer has no way to "examine" the state of the IPs you will issue them beforehand. Therefore it's up to you (ARIN, RIPE, et. al.) to ensure that they are "just as good" as any other IP block. It is shoddy business to take someone's money and then sneakily give them tainted (used) goods and expect them to deal with cleaning up the mess that the prior owner made, especially when you charge the same rate for untainted goods!
Not applicable in this case, as noted above.
What do you mean, "not applicable"? You take the money and issue IPs. There is no way for the "buyer" to know before hand if the IPs are "tainted" (used) or new. It is up to you (ARIN) to ensure that the goods (IPs) are suitable for the intended use. My analogy is entirely applicable, and I'm amazed you think otherwise.
WOW. That's a hell of a statement. There is absolutely nothing that ARIN can do if I decide I'm going to have our servers block connections from networks ending in an odd bit. Nobody is in a position to ensure that ANY Internet connection or IP space is "suitable for the intended use." Welcome to the Internet.
So, back to the question: could someone explain why they've got copies of the RBL's in their network which don't get updated on any reasonable refresh interval? (weekly? monthly?)
The "why" really isn't at issue - it happens and it's going to keep happening. The question is what are you (ARIN) going to do about it?
Give me the serenity to accept the things I cannot change, The courage to change the things I can, And the wisdom to know the difference.
You (ARIN et. al.) don't have any ability to change the why. What you can change is how you go about determining if an IP block is suitable for reallocation or not, and what steps you take to repair IP blocks that aren't suitable for reallocation.
So, in addition to just registering IP space, it's also their job to clean it up? I'm sorry, I agree that there's a problem, but this just sounds like it isn't feasible. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Joe Greco wrote:
I'm sorry, I agree that there's a problem, but this just sounds like it isn't feasible.
Some people suffer from the culturally ingrained inability to understand that certain kinds of problems just can't. Be. Solved. And/or they aren't worth solving under present circumstances. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Joe Greco wrote:
John Curran wrote:
On Sep 8, 2009, at 2:18 PM, JC Dill wrote:
It seems simple and obvious that ARIN, RIPE, et. al. should determine the blacklist state of a reclaimed IP group and ensure that the IP group is usable before re-allocating it.
When IPs are reclaimed, first check to see if the reclaimed IPs are on any readily checked RBL or private blacklist of major ISPs, corporations, universities, etc. If so, work with those groups to get the blocks removed *prior* to reissuing the IPs to a new entity. Before releasing the IPs to a new entity, double check that they are not being blocked (that any promises to remove them from a blacklist were actually fulfilled). Hold the IPs until you have determined that they aren't overly encumbered with prior blacklist blocks due to poor behavior of the previous entity. (The same should be done before allocating out of a new IP block, such as when you release the first set of IPs in a new /8.)
In this case, it's not the RBL's that are the issue; the address block in question isn't on them. It's the ISP's and other firms using manual copies rather than actually following best practices.
It's not that hard to make a list of the major ISPs, corporations, universities (entities with a large number of users), find willing contacts inside each organization (individual or role addresses you can email, and see if the email bounces, and who will reply if the email is received) and run some automated tests to see if the IPs are being blocked. In your follow-up email to me, you said you check "dozens" of RBLs - that is clearly insufficient - probably by an order of magnitude - of the entities you should check with. The number should be "hundreds". A reasonably cluefull intern can provide you with a suitable list in short order, probably less than 1 day, and find suitable contacts inside each organization in a similar time frame - it might take a week total to build a list of ~500 entities and associated email addresses. Because of employee turn-over the list will need to be updated, ~1-10 old addresses purged and replaced with new ones on a monthly basis.
Really? And you expect all these organizations to do ... what? Hire an intern to be permanent liaison to ARIN?
I'm expecting ARIN to spend a few staff-hours (utilizing low-cost labor such as an intern) to setup the list for ARIN to use to check the status of returned IPs, and spend a few more staff hours setting up an automated system to utilize the list prior to releasing reclaimed IPs for reallocation. If, when using the list they discover out-dated addresses, spend a moment to find an updated address for that sole network. Most of this can easily be automated once setup - the only things that need to be dealt with by hand would be purging the list of outdated contacts and finding new ones, which shouldn't take much time since it's not a very large list, and many of the contacts would (over time) become role accounts that don't become outdated as often or as easily as personal accounts. Most of this is done by ARIN, not by the organizations they contact. All each organization has to do is permit one employee or role account to be used for IP block testing, and reply to test emails. The effort to setup a role account and autoresponder is minimal.
Answer queries to whether or not IP space X is currently blocked (potentially at one of hundreds or thousands of points in their system, which corporate security may not wish to share, or even give "some random intern" access to)? Process reports of new ARIN delegations? What are you thinking they're going to do? And why should they care enough to do it?
Because if they don't, they are needlessly blocking re-allocated IP addresses, potentially blocking their own users from receiving wanted email. Organizations could (and should) setup a role account and auto-responder for this purpose.
Why isn't this being done now?
Issuing reclaimed IPs is a lot like selling a used car, except that the buyer has no way to "examine" the state of the IPs you will issue them beforehand. Therefore it's up to you (ARIN, RIPE, et. al.) to ensure that they are "just as good" as any other IP block. It is shoddy business to take someone's money and then sneakily give them tainted (used) goods and expect them to deal with cleaning up the mess that the prior owner made, especially when you charge the same rate for untainted goods!
Not applicable in this case, as noted above.
What do you mean, "not applicable"? You take the money and issue IPs. There is no way for the "buyer" to know before hand if the IPs are "tainted" (used) or new. It is up to you (ARIN) to ensure that the goods (IPs) are suitable for the intended use. My analogy is entirely applicable, and I'm amazed you think otherwise.
WOW. That's a hell of a statement. There is absolutely nothing that ARIN can do if I decide I'm going to have our servers block connections from networks ending in an odd bit. 100% correct.
What they *can* do is determine IF the address is currently being blocked *before* they issue it to a new entity.
Nobody is in a position to ensure that ANY Internet connection or IP space is "suitable for the intended use." Welcome to the Internet.
They can (and IMHO should) determine the state it is in before they reallocate it. What happens next is obviously unpredictable but in reality an IP that isn't being blocked today and isn't being used (by anyone) is highly unlikely to be widely blocked between today and the day ARIN releases it for allocation to a new entity. They can hold IPs that are not suitable for re-allocation, or at least make the status of the IPs known to the new entity before asking the entity to take on the IP block, and perhaps offering a fee discount for "tainted" addresses. (Some users may not care if the IPs are "tainted", if, for instance they plan to use the IPs for a DUL pool. I have a friend who gets $5 off his cell phone bill because he has a phone number that starts with 666 - a number that many people prefer to avoid but which works fine for his purposes and he's quite happy to get the discount. :-)
So, back to the question: could someone explain why they've got copies of the RBL's in their network which don't get updated on any reasonable refresh interval? (weekly? monthly?)
The "why" really isn't at issue - it happens and it's going to keep happening. The question is what are you (ARIN) going to do about it?
Give me the serenity to accept the things I cannot change, The courage to change the things I can, And the wisdom to know the difference.
You (ARIN et. al.) don't have any ability to change the why. What you can change is how you go about determining if an IP block is suitable for reallocation or not, and what steps you take to repair IP blocks that aren't suitable for reallocation.
So, in addition to just registering IP space, it's also their job to clean it up?
Who do you propose clean up the mess? The people who made the mess (spammers) won't clean it up. Someone has to clean it up. The IPs are in ARIN's possession now. Why should it become someone else's problem (the entity they allocate it to) to clean it up? They didn't do anything to taint the space, and they request (and expect) to get clean and usable IPs, not tainted IPs. ARIN shouldn't allocate previously allocated IPs until they know the IPs are not widely blocked. Or to *at the very least* ARIN should disclose what they know about the IP space before they make it someone else's problem, and give the requesting entity an option to request a new/clean/unused/unblocked IP block instead.
I'm sorry, I agree that there's a problem, but this just sounds like it isn't feasible.
IMHO passing the problem on to someone else is just plain wrong. It punishes an innocent party, and it doesn't scale. There are other options, better options. In commerce it is a violation of the UCC to knowingly or negligently sell the customer something that the seller knows (or should have known) doesn't serve the customer's stated purpose, and that the customer has no way of knowing (no way to do "due diligence" before completing the sale) is unsuitable for their needs. ARIN's IP registry probably doesn't fall under the aegis of the UCC, but that doesn't excuse the practice. I am not a lawyer, but it doesn't take a law degree to be able to tell right from wrong. Issuing previously-issued and tainted IPs to an entity that requested and is expecting untainted and usable IPs is clearly wrong. How ARIN plans to resolve this can be debated, but NOT solving this and just expecting someone else (the unlucky entity who is issued the tainted IPs) to solve it for them is not an honorable approach. Similarly, asking on NANOG "why do tainted IPs linger on blocklists" isn't going to solve the problem. ARIN can't change the why - what they can change is what ARIN does about it. There are better options - they can make an effort to clean up the IPs prior to reallocation; they can disclose the IP status before reallocation and give an option for a new IP block; or they can simply declare the IPs "toxic" and hold them rather than reallocate them. Giving the customer a dead parrot when they expected a live one (Beautiful Plumage!) is funny only in a Monty Python skit. http://www.youtube.com/watch?v=4vuW6tQ0218 http://www.readnews.com/funny/story3.html jc
JC Dill wrote:
Joe Greco wrote:
Answer queries to whether or not IP space X is currently blocked (potentially at one of hundreds or thousands of points in their system, which corporate security may not wish to share, or even give "some random intern" access to)? Process reports of new ARIN delegations? What are you thinking they're going to do? And why should they care enough to do it?
Because if they don't, they are needlessly blocking re-allocated IP addresses, potentially blocking their own users from receiving wanted email. Organizations could (and should) setup a role account and auto-responder for this purpose.
Perhaps they should, but until there is sufficient pain from their own users complaining about it there is no financial motivation to do so, and therefore many will not. I would guess that there are thousands of individual blocklists to this day blocking some of Sanford Wallace's and AGIS's old netblocks. As for a role account, there is "postmaster". I would think that the best hope in the real world, rather than an autoresponder would be an RFC that clearly defines text accompanying an SMTP rejection notice triggered by a blocklist, detailing the blocklist and contact for removal. Perhaps encouraging those who code MTAs and DNSBL hooks into them to include such in the configuration files would be a good start. This still puts the onus on the sender or inheritor of the tainted netblock, but makes the search less painful and perhaps even somewhat able to be scripted. Note that this thread deals mostly with SMTP issues regarding DNSBLs, as those are the most common trouble point. We should also consider other forms of blocking/filtering of networks reclaimed from former virus/malware/DoS sources. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
With scarcity of IPv4 addresses, organizations are more desperate than ever to receive an allocation. If anything, there's more of a disincentive than ever before for ARIN to spend time on netblock sanitization. I do think that ARIN should inform the new netblock owner if it was previously owned or not. But if ARIN tried to start cleaning up a netblock before releasing it, there would be no end to it. How could they check against the probably hundreds of thousands private blocklist? Frank -----Original Message----- From: JC Dill [mailto:jcdill.lists@gmail.com] Sent: Wednesday, September 09, 2009 5:40 PM To: NANOG list Subject: Re: Repeated Blacklisting / IP reputation <snip> They can (and IMHO should) determine the state it is in before they reallocate it. What happens next is obviously unpredictable but in reality an IP that isn't being blocked today and isn't being used (by anyone) is highly unlikely to be widely blocked between today and the day ARIN releases it for allocation to a new entity. They can hold IPs that are not suitable for re-allocation, or at least make the status of the IPs known to the new entity before asking the entity to take on the IP block, and perhaps offering a fee discount for "tainted" addresses. (Some users may not care if the IPs are "tainted", if, for instance they plan to use the IPs for a DUL pool. I have a friend who gets $5 off his cell phone bill because he has a phone number that starts with 666 - a number that many people prefer to avoid but which works fine for his purposes and he's quite happy to get the discount. :-) <snip> ARIN shouldn't allocate previously allocated IPs until they know the IPs are not widely blocked. Or to *at the very least* ARIN should disclose what they know about the IP space before they make it someone else's problem, and give the requesting entity an option to request a new/clean/unused/unblocked IP block instead. <snip> jc
Frank Bulk wrote:
With scarcity of IPv4 addresses, organizations are more desperate than ever to receive an allocation.
Factual evidence that pi allocation is in fact hard to obtain would be required to support that statement. The fact of the matter is if you have a legitimate application congruent with current policy you'll get your addresses just like you would last year. Now if your business is contingent on the availability of pi addressing resources obviously you have a fiduciary responsibility to address that problem in short order.
If anything, there's more of a disincentive than ever before for ARIN to spend time on netblock sanitization.
This whole thread seems to be about shifting (I.E. by externalizing) the costs of remediation. presumably the entities responsible for the poor reputation aren't likely to pay... So heck, why not ARIN? perhaps because it's absurd on the face of it? how much do my fees go up in order to indemnify ARIN against the cost of a possible future cleanup? how many more staff do they need? Do I have to buy prefix reputation insurance as contingent requirement for a new direct assignment?
I do think that ARIN should inform the new netblock owner if it was previously owned or not.
We've got high quality data extending back through a least 1997 on what prefixes have been advertised in the DFZ, and of course from the ip reputation standpoint it doesn't so much matter if something was assigned, but rather whether it was ever used. one assumes moreover that beyond a certain point in the not too distant future it all will have been previously assigned (owned is the wrong word).
But if ARIN tried to start cleaning up a netblock before releasing it, there would be no end to it. How could they check against the probably hundreds of thousands private blocklist?
Note that they can't insure routability either, though as a community we've gotten used to testing for stale bogon filters.
Frank
-----Original Message----- From: JC Dill [mailto:jcdill.lists@gmail.com] Sent: Wednesday, September 09, 2009 5:40 PM To: NANOG list Subject: Re: Repeated Blacklisting / IP reputation
<snip>
They can (and IMHO should) determine the state it is in before they reallocate it. What happens next is obviously unpredictable but in reality an IP that isn't being blocked today and isn't being used (by anyone) is highly unlikely to be widely blocked between today and the day ARIN releases it for allocation to a new entity.
They can hold IPs that are not suitable for re-allocation, or at least make the status of the IPs known to the new entity before asking the entity to take on the IP block, and perhaps offering a fee discount for "tainted" addresses. (Some users may not care if the IPs are "tainted", if, for instance they plan to use the IPs for a DUL pool. I have a friend who gets $5 off his cell phone bill because he has a phone number that starts with 666 - a number that many people prefer to avoid but which works fine for his purposes and he's quite happy to get the discount. :-)
<snip>
ARIN shouldn't allocate previously allocated IPs until they know the IPs are not widely blocked. Or to *at the very least* ARIN should disclose what they know about the IP space before they make it someone else's problem, and give the requesting entity an option to request a new/clean/unused/unblocked IP block instead.
<snip>
jc
On 9/13/09 12:49 PM, joel jaeggli wrote:
Frank Bulk wrote: []
If anything, there's more of a disincentive than ever before for ARIN to spend time on netblock sanitization.
This whole thread seems to be about shifting (I.E. by externalizing) the costs of remediation. presumably the entities responsible for the poor reputation aren't likely to pay... So heck, why not ARIN? perhaps because it's absurd on the face of it? how much do my fees go up in order to indemnify ARIN against the cost of a possible future cleanup? how many more staff do they need? Do I have to buy prefix reputation insurance as contingent requirement for a new direct assignm
Perhaps ICANN could require registries establish a clearing-house, where at no cost, those assigned a network would register their intent to initiate bulk traffic, such as email, from specific addresses. Such a use registry would make dealing with compromised systems more tractable.
I do think that ARIN should inform the new netblock owner if it was previously owned or not.
We've got high quality data extending back through a least 1997 on what prefixes have been advertised in the DFZ, and of course from the ip reputation standpoint it doesn't so much matter if something was assigned, but rather whether it was ever used. one assumes moreover that beyond a certain point in the not too distant future it all will have been previously assigned (owned is the wrong word).
But if ARIN tried to start cleaning up a netblock before releasing it, there would be no end to it. How could they check against the probably hundreds of thousands private blocklist?
Note that they can't insure routability either, though as a community we've gotten used to testing for stale bogon filters.
The issues created by IPv4 space churn is likely to be dwarfed by eventual adoption of IPv6. Registering intent to initiate bulk traffic, such as with SMTP, could help consolidate the administration of filters, since abuse is often from addresses that network administrators did not intend. A clearing-house approach could reduce the costs of administering filters and better insure against unintentional impediments. This approach should also prove more responsive than depending upon filters embedded within various types of network equipment. By limiting registration to those controlling the network, this provides a low cost means to control use of address space without the need to impose expensive and problematic layer 7 filters that are better handled by the applications. The size of the registered use list is likely to be several orders of magnitude smaller than the typical block list. Exceptions to the use list will be even smaller still. This registry would also supplant the guesswork involved with divining meaning of reverse DNS labels. -Doug
-----Original Message----- From: Douglas Otis [mailto:dotis@mail-abuse.org] Sent: Monday, September 14, 2009 1:41 PM To: joel jaeggli Cc: NANOG list Subject: Re: Repeated Blacklisting / IP reputation, replaced by registered use
On 9/13/09 12:49 PM, joel jaeggli wrote:
Frank Bulk wrote: []
If anything, there's more of a disincentive than ever before for ARIN to spend time on netblock sanitization.
This whole thread seems to be about shifting (I.E. by externalizing) the costs of remediation. presumably the entities responsible for the poor reputation aren't likely to pay... So heck, why not ARIN? perhaps because it's absurd on the face of it? how much do my fees go up in order to indemnify ARIN against the cost of a possible future cleanup? how many more staff do they need? Do I have to buy prefix reputation insurance as contingent requirement for a new direct assignm
Perhaps ICANN could require registries establish a clearing-house, where at no cost, those assigned a network would register their intent to initiate bulk traffic, such as email, from specific addresses. Such a use registry would make dealing with compromised systems more tractable.
If they would just comply with RFC 3514, such a registry would be unnecessary.
This registry would also supplant the guesswork involved with divining meaning of reverse DNS labels.
We could standardize a string to be used in rDNS of dynamic pools, if you want. Lee
On Sep 14, 2009, at 10:40 AM, Douglas Otis wrote:
Perhaps ICANN could require registries establish a clearing-house, where at no cost, those assigned a network would register their intent to initiate bulk traffic, such as email, from specific addresses.
ICANN can't require the RIRs do anything outside of what is specifically mentioned in global addressing policies. If you think this would be valuable and that it would make sense as a global addressing policy, then you should propose it in the RIR policy forums, get consensus amongst the five RIRs and have them forward it to ICANN as a global policy. Regards, -drc
Another one that could be discussed at the ARIN policy bof. Also, Im forwarding this to the ARIN ppml for any further discussion. Cheers Marla -----Original Message----- From: David Conrad [mailto:drc@virtualized.org] Sent: Monday, September 14, 2009 11:44 AM To: Douglas Otis Cc: NANOG list Subject: Re: Repeated Blacklisting / IP reputation, replaced by registered use On Sep 14, 2009, at 10:40 AM, Douglas Otis wrote:
Perhaps ICANN could require registries establish a clearing-house, where at no cost, those assigned a network would register their intent to initiate bulk traffic, such as email, from specific addresses.
ICANN can't require the RIRs do anything outside of what is specifically mentioned in global addressing policies. If you think this would be valuable and that it would make sense as a global addressing policy, then you should propose it in the RIR policy forums, get consensus amongst the five RIRs and have them forward it to ICANN as a global policy. Regards, -drc
Frank Bulk wrote:
With scarcity of IPv4 addresses, organizations are more desperate than ever to receive an allocation. If anything, there's more of a disincentive than ever before for ARIN to spend time on netblock sanitization.
I do think that ARIN should inform the new netblock owner if it was previously owned or not. But if ARIN tried to start cleaning up a netblock before releasing it, there would be no end to it. How could they check against the probably hundreds of thousands private blocklist?
They could implement a process by which they announce to a mailing list of DNSBL providers that a given assignment has been returned to the RIR and that it should be cleansed from all DNSBLs. At this point the RIR has done their due diligence for notifying the blacklist community of the change and the onus is on the DNSBL maintainers to update their records. Of course this does nothing to cleanse the assignment in the hundreds of thousands of MTAs around the world. However this could be a good reason to not blacklist locally (or indefinitely at least) and to instead rely on a DNSBL maintained by people responsible for wiping returned assignments from their records when RIRs give the word. I suppose the mailing list could even be expanded to include mailing list admins if need be so that they could also receive the info and wipe their own internal DNSBLs. The list should be an announcement-only list with only the RIRs being able to post to it in a common and defined format. The announcement should be made as soon as the assignment is returned to the RIR, allowing for the cool off period of time for personal blacklists to catch up to the official ones. I would think that would be a fairly simple process to implement. It's not fool-proof by any means but it's better than doing nothing. It's a thought. Justin
On Mon, Sep 14, 2009 at 2:58 PM, Justin Shore <justin@justinshore.com>wrote:
Frank Bulk wrote:
With scarcity of IPv4 addresses, organizations are more desperate than ever to receive an allocation. If anything, there's more of a disincentive than ever before for ARIN to spend time on netblock sanitization.
I do think that ARIN should inform the new netblock owner if it was previously owned or not. But if ARIN tried to start cleaning up a netblock before releasing it, there would be no end to it. How could they check against the probably hundreds of thousands private blocklist?
They could implement a process by which they announce to a mailing list of DNSBL providers that a given assignment has been returned to the RIR and that it should be cleansed from all DNSBLs.
You mean like this? http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html -M<
Well, I haven't even had coffee yet and... Get the removals: curl -ls http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html | grep Remove | grep -v "<PRE>" Get the additions: mahannig$ curl -ls http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html | grep Add | grep -v "<PRE>" I'm sure someone else could write something far more elegant, but elegance isn't always required. :-) Best, Marty On Mon, Sep 14, 2009 at 10:21 PM, Martin Hannigan <martin@theicelandguy.com>wrote:
On Mon, Sep 14, 2009 at 2:58 PM, Justin Shore <justin@justinshore.com>wrote:
Frank Bulk wrote:
With scarcity of IPv4 addresses, organizations are more desperate than ever to receive an allocation. If anything, there's more of a disincentive than ever before for ARIN to spend time on netblock sanitization.
I do think that ARIN should inform the new netblock owner if it was previously owned or not. But if ARIN tried to start cleaning up a netblock before releasing it, there would be no end to it. How could they check against the probably hundreds of thousands private blocklist?
They could implement a process by which they announce to a mailing list of DNSBL providers that a given assignment has been returned to the RIR and that it should be cleansed from all DNSBLs.
You mean like this?
http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html
-M<
-- Martin Hannigan martin@theicelandguy.com p: +16178216079 Power, Network, and Costs Consulting for Iceland Datacenters and Occupants
Martin Hannigan wrote:
Well, I haven't even had coffee yet and...
Get the removals:
curl -ls http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html | grep Remove | grep -v "<PRE>"
Get the additions:
mahannig$ curl -ls http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html | grep Add | grep -v "<PRE>"
That appears to be it. I've also been told that there is a RSS feed of the same thing. My understanding is that a posting is made to the mailing list or RSS feed when a new subnet is assigned. I'd like to see them do something with the assignment is first returned to ARIN, not months later when the assignment is ready to be handed out again. I think the extra time would help those people that download copies of the DNSBL zone files and manually import them once a week or less often. Lots of place still use the zone files. Personally I prefer to do so too, rather than tie my mail system reliability on an outside source that may or may not tell me when they have problems that affect my service. GoDaddy and their hosted mail service would be a great example since they can't be bothered to update their DNSBL zone files. Their mail admins are using a copy of SORBS that is 3 years old. 3 damn years old. How do I know this? 3 years ago a mistake in a Squid configuration turned one of my services into an open proxy for about a week. Even today mail from that server to a domain with mail hosted at GoDaddy results in a bounce citing the ancient SORBS listing as the reason. Thanks for the pointer. Looks like they've already thought of what I suggested and implemented a solution. I still voice for announcing returned assignment instead of announcing when an old assignment gets reassigned. Thanks Justin
The mailing sent daily contains both. -----Original Message----- From: Justin Shore [mailto:justin@justinshore.com] Sent: Tuesday, September 15, 2009 11:18 AM To: Martin Hannigan Cc: NANOG list Subject: Re: Repeated Blacklisting / IP reputation Martin Hannigan wrote:
Well, I haven't even had coffee yet and...
Get the removals:
curl -ls http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html | grep Remove | grep -v "<PRE>"
Get the additions:
mahannig$ curl -ls http://lists.arin.net/pipermail/arin-issued/2009-September/000270.html | grep Add | grep -v "<PRE>"
That appears to be it. I've also been told that there is a RSS feed of the same thing. My understanding is that a posting is made to the mailing list or RSS feed when a new subnet is assigned. I'd like to see them do something with the assignment is first returned to ARIN, not months later when the assignment is ready to be handed out again. I think the extra time would help those people that download copies of the DNSBL zone files and manually import them once a week or less often. Lots of place still use the zone files. Personally I prefer to do so too, rather than tie my mail system reliability on an outside source that may or may not tell me when they have problems that affect my service. GoDaddy and their hosted mail service would be a great example since they can't be bothered to update their DNSBL zone files. Their mail admins are using a copy of SORBS that is 3 years old. 3 damn years old. How do I know this? 3 years ago a mistake in a Squid configuration turned one of my services into an open proxy for about a week. Even today mail from that server to a domain with mail hosted at GoDaddy results in a bounce citing the ancient SORBS listing as the reason. Thanks for the pointer. Looks like they've already thought of what I suggested and implemented a solution. I still voice for announcing returned assignment instead of announcing when an old assignment gets reassigned. Thanks Justin
participants (13)
-
Aaron Wendel -
Alex Balashov -
Azinger, Marla -
David Conrad -
Douglas Otis -
Frank Bulk -
Jay Hennigan -
JC Dill -
Joe Greco -
joel jaeggli -
Justin Shore -
Lee Howard -
Martin Hannigan