Questions about populating RIR with customer information.
Up until recently, we were only providing the RIR database with information about our larger allocations /24 or larger. We have noticed however that many anti-spam organizations such as Spamhaus, and Fiveten will use the lack of information regarding an IP allocation as a blank check to blacklist entire /24s when they are really targeting a single /30 or a /29. As such we are examining publishing information for all allocations in the RIR database (/30s, /29s, etc). My question, mostly is related to the privacy of the customer whom the space is being allocated to. Has anyone ever had an issue where they have published a user's information and the user had an issue with it? Is there some way that we can 'proxy' the information so that it simply states that the /29 has been allocated to a customer but it doesn't provide their contact information? Most of our customers are co-location and dedicated hosting customers and we are simply unsure whether or not there are implications (legal or otherwise) in publishing our customer data in a public RIR database. Does anyone have any thoughts on this? Sorry if this is the wrong place to ask. Thanks, -Drew
Does anyone have any thoughts on this? Sorry if this is the wrong place to ask.
First of all, this strikes me as a legal and policy decision. For the legal aspects you should ask your lawyer or take it up on a legal blog like http://www.groklaw.net For the policy aspects, you really should take it to the RIRs where you have IP allocations. All RIRs operate policy discussion mailing lists. One disturbing thing that I saw in your message is that you seem to be accepting the fact that a so-called anti-spam organization can dictate how you operate your network and what requirements you must meet. I would suggest that this is the wrong way to approach the problem, rather like letting the tail wag the dog. It would be better for you to join an organization like MAAWG http://www.maawg.org/home which is attempting to define best current practices for ISPs. I don't know whether or not they have dealt with this particular issue yet, but it sounds like something that falls under their umbrella. -Michael Dillon
On Aug 1, 2007, at 7:10 AM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
Does anyone have any thoughts on this? Sorry if this is the wrong place to ask.
It would be better for you to join an organization like MAAWG http://www.maawg.org/home which is attempting to define best current practices for ISPs. I don't know whether or not they have dealt with this particular issue yet, but it sounds like something that falls under their umbrella.
There were recent efforts made within ASRG with respect to black-hole lists. The AS, and not the IP address, indicates the responsible entity. For our service, some lists coalesce CIDRs into larger ranges based upon the presences of spam in a majority of the included IP addresses. This process is algorithmic, and not dependent upon other information. We now also offer a service where this "escalation" is not used in less aggressive listings. A customer can now change the active list at any time. : ) Reverse listing information may help in determining whether a CIDR is assigned to DUL only when the ISP is not responsive. For the DUL, the AS is authoritative with respect to what gets listed. As long as there is some communication with ISP, there should never be a problem with this list. We are adding a portal to make this process easier to manage. The other side of this issues is that we tend to deal with complaints from the ISP's customers who often feel their IP address should not be placed into this category. In those cases, these customers must be referred back to their provider, as only their provider is authoritative in this matter. Now that Microsoft joined the MAAWG board, security or operational concerns related to Sender-ID/SPF are being muted. While I admit to being biased about possible DDoS exploits, it is also clear MAAWG is somewhat biased about Sender-ID. : ( -Doug
on Wed, Aug 01, 2007 at 09:47:45AM -0400, Drew Weaver wrote:
Up until recently, we were only providing the RIR database with information about our larger allocations /24 or larger. We have noticed however that many anti-spam organizations such as Spamhaus, and Fiveten will use the lack of information regarding an IP allocation as a blank check to blacklist entire /24s when they are really targeting a single /30 or a /29.
It's not just Spamhaus. How do you expect *anyone* to know whether an abusive customer of yours has a /29 or a /18 unless you *tell us* in rwhois? We happily block large swaths of the network due to failure on the providers' parts to adequately describe the allocation. rDNS scans and guesswork are fine, but it's much better if we can count on the providers' actual assignments as published in rwhois and block the smaller allocations instead.
Is there some way that we can 'proxy' the information so that it simply states that the /29 has been allocated to a customer but it doesn't provide their contact information?
Why on earth would you want to do that? In a world where 90%+ of our inbound mail traffic is abuse, I think accountability trumps privacy. Anyone using those stupid cloaked whois listings is automatic fodder for the filters here. Your right to access my resources ends when you deny me the ability to identify you if I so choose, on evidence of ill intent. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
We always used to put full customer details in RIPE for AS6765 and AS5378. I never had any issues or queries from anybody, they were just told that this is how it is done. -- Leigh Porter Steven Champeon wrote:
on Wed, Aug 01, 2007 at 09:47:45AM -0400, Drew Weaver wrote:
Up until recently, we were only providing the RIR database with information about our larger allocations /24 or larger. We have noticed however that many anti-spam organizations such as Spamhaus, and Fiveten will use the lack of information regarding an IP allocation as a blank check to blacklist entire /24s when they are really targeting a single /30 or a /29.
It's not just Spamhaus. How do you expect *anyone* to know whether an abusive customer of yours has a /29 or a /18 unless you *tell us* in rwhois? We happily block large swaths of the network due to failure on the providers' parts to adequately describe the allocation. rDNS scans and guesswork are fine, but it's much better if we can count on the providers' actual assignments as published in rwhois and block the smaller allocations instead.
Is there some way that we can 'proxy' the information so that it simply states that the /29 has been allocated to a customer but it doesn't provide their contact information?
Why on earth would you want to do that? In a world where 90%+ of our inbound mail traffic is abuse, I think accountability trumps privacy.
Anyone using those stupid cloaked whois listings is automatic fodder for the filters here. Your right to access my resources ends when you deny me the ability to identify you if I so choose, on evidence of ill intent.
On Aug 1, 2007, at 6:47 AM, Drew Weaver wrote:
Up until recently, we were only providing the RIR database with information about our larger allocations /24 or larger. We have noticed however that many anti-spam organizations such as Spamhaus, and Fiveten will use the lack of information regarding an IP allocation as a blank check to blacklist entire /24s when they are really targeting a single /30 or a /29. As such we are examining publishing information for all allocations in the RIR database (/30s, /29s, etc).
Do you run an rwhois server with the allocation information already? If so, you'd have good reason to be aggrieved at blacklists not doing some amount of due diligence (though I think that's the first time I've heard spamhaus and fiveten - the two extremes of professionalism - bundled together). If not, then yes, if there's abusive traffic coming from hosts on your systems you're likely to find the smallest published allocation blocked (for reasons that are generally pretty good decisions operationally on the part of the people who don't want the bad traffic).
My question, mostly is related to the privacy of the customer whom the space is being allocated to. Has anyone ever had an issue where they have published a user's information and the user had an issue with it? Is there some way that we can 'proxy' the information so that it simply states that the /29 has been allocated to a customer but it doesn't provide their contact information?
If you get a reputation for "providing spammers with anonymous SWIPs" you're likely to have more problems with wider blocking, rather than less.
Most of our customers are co-location and dedicated hosting customers and we are simply unsure whether or not there are implications (legal or otherwise) in publishing our customer data in a public RIR database.
Does anyone have any thoughts on this? Sorry if this is the wrong place to ask.
You'd need to ask your contract lawyers about most of that. Cheers, Steve
* Drew Weaver:
Up until recently, we were only providing the RIR database with information about our larger allocations /24 or larger. We have noticed however that many anti-spam organizations such as Spamhaus, and Fiveten will use the lack of information regarding an IP allocation as a blank check to blacklist entire /24s when they are really targeting a single /30 or a /29.
I don't know how this translates to actual blacklist entries, but for submitting complaints, blacklist operators ignore the smaller networks, whether they are in WHOIS or not. I would also expect that if you've got a significant spamming problem, some blacklists will try to entice *you* to do something about it proactively. Overblocking is often used for that purpose.
On 8/1/07, Drew Weaver <drew.weaver@thenap.com > wrote:
Most of our customers are co-location and dedicated hosting customers and we are simply unsure whether or not there are implications (legal or otherwise) in publishing our customer data in a public RIR database.
I would urge against publishing information about a customer in a WHOIS entry without discussing it with that customer first. WHOIS entries can be made without violating anyone's privacy, just be sure you get all necessary verifiable permission; don't just automatically publish information you have already gathered for internal purposes, when it wasn't previously your policy to publish the information. It is up to you as ISP to get the contact information that the customer wants published in WHOIS (maybe it's different from contact information they would use for other matters), at the time re-assignment of the ip addresses is being made, And make sure they know that the listing is going to be publicly viewable. You do have the option of refusing to sign up or renew a customer if they fail to provide good contact information for publication in WHOIS or fail to provide the necessary permission. I suggest you carefully read the policy manual of your applicable RIR. With regard to when you create SWIP or RWHOIS records, and what exactly you put in them. In the ARIN region, whenever an ISP re-assigns a /29 block or larger to a customer, in addition to maintaining documentation of the justification for assignment of the address(es) to the user, the ISP is already be required/supposed to publish that re-assignment is (as a matter of RIR policy) in SWIP or RWHOIS. See more here: http://www.arin.net/policy/nrpm.html#four2372 And it's a good idea to allow people who need a contact for abuse from a machine to go to the party responsibility over it, first, before having to bother you, a provider they happen to be using. Note that ARIN has a "Residential Customer Privacy" policy; for residential customers it is legitimate to substitute the name in your WHOIS response with "Private Customer" and "Private Residence" in place of street address. So I would say there IS some precedant for such a replacement of contact information. You need to check your particular RIR's policy manual to determine whether it is an acceptable practice in your region, to mask contact information for the particular type of customer. -- -J
participants (8)
-
Douglas Otis -
Drew Weaver -
Florian Weimer -
James Hess -
Leigh Porter -
michael.dillon＠bt.com -
Steve Atkins -
Steven Champeon