APNIC Privacy of customer assignment records - implementation update

Dear colleagues,

This is an important announcement on the implementation of APNIC
approved proposal prop-007-v001 regarding privacy of customer assignment
records. The proposal document, presentation, minutes, and discussion
are available at:

     http://www.apnic.net/docs/policy/proposals/prop-007-v001.html

The APNIC Secretariat will be implementing this proposal on 30 September
2004.

Please note that after this date, customer assignment objects will no
longer be visible in the APNIC Whois Database, unless the APNIC account
holder chooses to make public the customer records for their allocated
address range.

A set of Frequently Asked Questions about this project is now available at:

     http://www.apnic.net/info/faq/privacy-faq.html

If you have any concerns or questions regarding this policy, please
contact the APNIC helpdesk at:

         E-mail: helpdesk@apnic.net
         Phone: +617 3858 3188
         Fax: +617 3858 3199

Regards

Does anyone else find this as offensive as I do?

matt ghali

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo Matt!

Does anyone else find this as offensive as I do?

matt ghali

I think at this point it becomes a matter of "if they're not listed, blacklist them". It could potentially be a huge filter set, but there's so much crap coming from that corner of the globe anyway that this just gives a good, solid, hard fast reason.

Needless to say, I'm joining the list specifically for the purpose of commenting on the above.

-Dan

Dunno if "offensive" is the right word. "Worrisome", definitely. Maybe after I have time to understand it better, it might become offensive.

But that will also depend on how APNIC responds to problems. If Network X has a customer who is a problem, and we can't find out customer's name / e-mail / whatever, then Network X better be responsive. If not, then APNIC better be responsive.

Perhaps this was covered in the docs, I dunno, haven't read them all yet. It definitely was not covered in the FAQ, even though I figured it would be one of the most Frequently Asked Questions....

Oh look.

http://rfc-ignorant.org/policy-ipwhois.php

There you go. They do this, they're in violation of RFC 954.

And there's already a blacklist ready and waiting.

-Dan

Yes.

And worst of all similar proposal is under discussion at ARIN, see
  http://www.arin.net/policy/2004_6.html
So if you don't want the same unaccountability problem for ARIN, join
ppml mail list and let argue against it.

My own view is that this will make it a lot easier for spammers to get
away with their works and easier for them to move from one isp to another.

At the same time reassignment information is used by me and some others
for geographical mapping of ip space and this will make harm this
research activity as well. So if you're involved in something similar
you may want to speak up about it as well.

I guess the thinking is that apnic address space is so widely nullrouted
already, so things cant get any worse.

-Dan

This proposal would be harmful in tracking hack
attacks, ddos attacks and other forms of annoyance,
spyware tracking and things that are beyond the
capability for any agency to handle because of largese

Technical fiefdoms were one of the worries of the 90's
now we are here and that is becoming the direction,
patenting rfc's and the like are harming the very
fabric of the internet and detering the ability to
keep it running.....I am very disappointed

-Henry

>
> > This is an important announcement on the
implementation of APNIC
> > approved proposal prop-007-v001 regarding
privacy of customer assignment
> > records. The proposal document, presentation,
minutes, and discussion
> > are available at:
> >
> >

http://www.apnic.net/docs/policy/proposals/prop-007-v001.html

I guess the answer is yes, but I'm interested to know why.

The proposal (which comes from APNIC members, not from APNIC staff) concerns non-portable addresses assigned to end-users. I don't know about anybody else, but I've never had any luck getting a response from people in that category anyway; it's invariably the upstream ISPs who respond (if anybody does), and there is no suggestion that their contact details will be able to be hidden.

So what difference will it make?

Joe

RFC 954 is a description of how one whois service, "running on the SRI-NIC machine (26.0.0.73 or 10.0.0.51)". How can any other whois service be in violation of that?

Joe

Ok, I'll bite...

I find the idea that an ISP must publish customer information offensive.
There is no reason why a guy who wants to get a T-1 into his house and a /24
to support all the stuff he's doing at home should be forced to publish his
full name and home address to the world (or worse, should have that
information published to the world by his ISP without his knowledge).

Didn't we already have this discussion back when it was about static /32s,
/29s, and the like? And didn't those people get to keep their privacy?

You can always track down the actual registrant and talk to them if you have
a problem, and as has already been pointed out, they're a lot more likely to
respond than the person listed in the assignment record.

Believing that the "spam problem" would be solved if only the source IP
addresses of the spam could be tracked to a physical address is a fallacy
anyway.

Matthew Kaufman
matthew@eeph.com

Ps. The legitimate business reason of trying to keep your customer list
private so your competitors don't spend all day calling your customers
should apply too, but I'm a lot less worried about that than the simple
privacy issues for the end users.

In a message written on Thu, Sep 23, 2004 at 05:56:42PM -0400, Joe Abley wrote:

The proposal (which comes from APNIC members, not from APNIC staff)
concerns non-portable addresses assigned to end-users. I don't know
about anybody else, but I've never had any luck getting a response from
people in that category anyway; it's invariably the upstream ISPs who
respond (if anybody does), and there is no suggestion that their
contact details will be able to be hidden.

There are several proposals in various stages before ARIN and RIPE
about this same issue. APNIC simply beat everyone to the punch, but
most of the other groups are going down the same path.

The interesting case brought by several providers is that some
residential DSL providers are now assigning /29's to end users to
support multiple boxes. In some cases these additional boxes are
service provider boxes to provide value-add services (think, a voice
or video gateway box). This creates the very real situation where
"grandma" is now published in whois.

"grandma" doesn't like the spam, doesn't want to be listed (she
already has an unlisted phone number) and even if her machine is
owned and spewing forth spam contacting her is just going to result
in confusion. To that end the service provider would like to not
list her, protect her privacy, and when people query have only their
block and contact show up so they can field the call and either
block her port, or have a (hopefully more helpful) customer service
person help her clean her infected machine or whatever.

Generally the people who actually work abuse all have a similar report:
end user assignments in whois are worthless. End users fall into one
of two catagories:

1) "grandma", where contacting her is going to get you nowhere because
   they don't know what you're talking about.

2) An abuser (spammer, ddoser, whatever). These people either won't
   respond, or will respond but take no action, in both cases hoping
   to string you along and make you either go away, or at least buy
   some more time while they tie you up dealing with them.

Because of this most of the people dealing with abuse are already
ignoring end user contact information and going straight to the
upstream ISP anyway.

This brings us to why these proposals are getting traction in all the
RIR's. Spending thousands of hours maintaining data that many (most?
nearly all?) of the users say is useless is silly.

Indeed, this is the same thing many of the people who have alredy
responded to this thread have said, only turned on it's head. "I
treat all APNIC data as worthless" easily translates into "APNIC
shouldn't keep the data" when you're one of the people paying the
costs to upkeep the data.

Chicken and egg, or egg and chicken? I'm not really sure. That
said, the current rules basically ensure that at some point in the
future, when everyone needs a /29, everyone on the planet will be
listed in whois. That to me is the truely absurd part. I don't
understand people who think every DSL, and every cable modem user
should be listed in whois /purely by the fact that they have a
couple of static IP addresses/. I can't imagine how that makes
anything better for anyone.

Many people will automatically tie this into another issue, but it
is a separate issue. Upstreams, or more importantly LIR's (in
registry speak) need to have valid contact information and need to
act on complaints. I'm not quite sure how we enforce those
requirements. However, the lack of being able to enforce those
requirements does not make listing everyone any better of a solution.

The truth is, it doesn't even need to be a case of "grandma" listed in the
whois (though that is a legitimate issue these days). If as an ISP, I list
"Bob's Flower Market" (which has a DSL line and IP addresses for every cash
register and order-fulfillment machine) in whois, all that does is:

  A) Cause "Bob's Flower Market" to get spam at the address harvested from
whois, and
  B) Cause people who have issues with virus-infected machines to call Bob
(who doesn't know jack about viruses) instead of calling me (I can remotely
shut him off until I can drive over there with a CD full of anti-virus
software), and
  C) Gives my competition Bob's name and phone number, so they can try to
sell him their DSL service instead. (Imagine the response if you asked any
other local business to post their complete customer list, with the names
and unlisted phone numbers of buyers, on the front door)

What it does NOT do is:
  1) Reduce the amount of virus traffic accountable to Bob (might make it
worse, if people call him instead of me), or
  2) Reduce the amount of spam in the world (probably increases it, at least
from Bob's point of view), or
  3) Make the world a better place to live (there's much better avenues to
pursue if that's your goal)

Matthew Kaufman
matthew@eeph.com

In a message written on Thu, Sep 23, 2004 at 05:56:42PM -0400, Joe Abley wrote:
> The proposal (which comes from APNIC members, not from APNIC staff)
> concerns non-portable addresses assigned to end-users. I don't know
> about anybody else, but I've never had any luck getting a response from
> people in that category anyway; it's invariably the upstream ISPs who
> respond (if anybody does), and there is no suggestion that their
> contact details will be able to be hidden.

There are several proposals in various stages before ARIN and RIPE
about this same issue. APNIC simply beat everyone to the punch, but
most of the other groups are going down the same path.

Going down the path does not mean it'll happen.

The interesting case brought by several providers is that some
residential DSL providers are now assigning /29's to end users to
support multiple boxes. In some cases these additional boxes are
service provider boxes to provide value-add services (think, a voice
or video gateway box). This creates the very real situation where
"grandma" is now published in whois.

"grandma" doesn't like the spam, doesn't want to be listed (she
already has an unlisted phone number) and even if her machine is
owned and spewing forth spam contacting her is just going to result
in confusion. To that end the service provider would like to not
list her, protect her privacy, and when people query have only their
block and contact show up so they can field the call and either
block her port, or have a (hopefully more helpful) customer service
person help her clean her infected machine or whatever.

For ARIN, in case of grandma or any other residentual customer, there
exist "residential customer privacy" policy, so her name need not be listed.

Generally the people who actually work abuse all have a similar report:
end user assignments in whois are worthless. End users fall into one
of two catagories:

1) "grandma", where contacting her is going to get you nowhere because
   they don't know what you're talking about.

2) An abuser (spammer, ddoser, whatever). These people either won't
   respond, or will respond but take no action, in both cases hoping
   to string you along and make you either go away, or at least buy
   some more time while they tie you up dealing with them.

Because of this most of the people dealing with abuse are already
ignoring end user contact information and going straight to the
upstream ISP anyway.

This is not the same thing. What we're talking about is not the record
itself but who is listed as point of contact. And for most small records
the person is not listed as point of contact, the ISP is.

But info about actual customer still makes it possible to correlate multiple
cases of abuse together and it is more difficult for spammers to run from
one ISP to another.

This brings us to why these proposals are getting traction in all the
RIR's. Spending thousands of hours maintaining data that many (most?
nearly all?) of the users say is useless is silly.

But the proposals to hide the information do not change any of that,
ISPs are still REQUIRED to provide all the same information to RIR
they can just hide it from the public.

Chicken and egg, or egg and chicken? I'm not really sure. That
said, the current rules basically ensure that at some point in the
future, when everyone needs a /29, everyone on the planet will be
listed in whois.

That I don't like either. I think ARIN database is overpopulated
by otheless small records and this is a problem both for ARIN and
for those tyring to use the data. But NOT ALL the records are
useless and if we simply let ISPs not report anything at all,
this is even worth.

I actually do have proposal to make on this issue that will:
1. Reduce amount of data in arin whois by not requirying ISPs
    to report each small allocatoin and assignment
2. Keeps data about all small residential and small-business
    customers private out of whois (these represent 90% of all
    assignments)
3. Still keeps records that allow to determine general geographical
    location of service (for those of us mapping the net)
4. Still keeps records for almost all the types of cases where
    abuse and spam does happen.

I'll now take this to ppml for further discussion. I don't have a concrete
proposal text, but basic set of ideas that can be worked on further.

Note that draft-daigle-rfc954bis-01.txt was approved and is
sitting in the RFC Editor's queue. It removes all of the policy
language in RFC 954, but is otherwise the same (and it
will likewise be issued as a Draft Standard, the current
status of RFC 954).
      regards,
        Ted Hardie

The truth is, it doesn't even need to be a case of "grandma"

> listed in the whois (though that is a legitimate issue these
> days). If as an ISP, I list "Bob's Flower Market" (which has
> a DSL line and IP addresses for every cash register and
> order-fulfillment machine) in whois, all that does is:

> A) Cause "Bob's Flower Market" to get spam at the address
> harvested from whois,

Are you talking about email spam or snail-mail here?

> and
> B) Cause people who have issues with virus-infected
> machines to call Bob (who doesn't know jack about viruses)
> instead of calling me (I can remotely shut him off until I
> can drive over there with a CD full of anti-virus software),
> and

So list yourself as the contact (but not the network owner) rather
than him.

There's a world of difference between hiding the whole assignment
(which means that, for example, I can't find out the extent of Bob's
network in order to block the viruses he's spewing without also
affecting traffic from the perfectly clean networks who have the bad
luck to be assigned adjacent IPs) and making the contacts point to
the ISP rather than the customer in cases where the ISP is the only
competent technical contact.

> C) Gives my competition Bob's name and phone number, so
> they can try to sell him their DSL service instead.

Cost of doing business. The operational requirements of the rest of
the network, who _do_ have a substantial interest in being able to
know where one customer network stops and another one starts, and the
identity of the customer if it's a business, outweighs any
inconvenience you might suffer as a result.

> (Imagine the response if you asked any other local business
> to post their complete customer list, with the names and
> unlisted phone numbers of buyers, on the front door)

I don't know about where you are, but where I live it's a legal
requirement for any company to display its registered company name on
every place where it does business. So if you're a provider of, say,
office space, then yes, the complete list of your customers will be on
the front door. (Your introduction of "unlisted phone numbers" into
the argument is of course wholly spurious - the issue of how much
contact info should be listed is a separate one from the issue of
whether the network assignment itself should be listed.)

> What it does NOT do is:
> 1) Reduce the amount of virus traffic accountable to Bob
> (might make it worse, if people call him instead of me), or

But it stops me from reliably blocking Bob's network without affecting
innocent parties who don't have a virus problem but do have adjacent
IPs.

> 2) Reduce the amount of spam in the world (probably
> increases it, at least from Bob's point of view), or

If Bob happens to be a spammer, it makes it harder to block his
networks without affecting innocent bystanders. It makes it harder to
detect that his provider is simply shuffling him around in response to
blocks or complaints. It makes it harder to link up the connections
between otherwise apparently separate spammers or spam gangs.

I see no reason why there should not be some flexibility in the whois
data regarding who is listed as a contact for what purpose, the extent
of information required for listed contacts, etc. But there needs to
be a stronger argument than just vaguely saying "privacy concerns" in
order to justify not listing the extent of the IPs allocated, and the
owner and business address of the recipient of the allocation except
where the allocation is to a residential user.

As for the ARIN proposal 2004-6, I notice that it would have the
effect of essentially nullifying the requirements of the previously
adopted policy 2003-5 (requirements for RWhois servers). That policy
expressly states that reassignment info must be available to the
public and not just to ARIN staff. There is nothing given in the
rationale for 2004-6 to explain why 2003-5 should be summarily
overruled in this way.

So list yourself as the contact (but not the network owner) rather
than him.

I see no reason why there should not be some flexibility in the whois
data regarding who is listed as a contact for what purpose, the extent
of information required for listed contacts, etc.

I proposed a revision to the way whois works that would have been
a compromise between APNIC's delisting and the current chaos. You can read
it at http://www.arin.net/policy/2004_4.html

It would have allowed listing the block itself without identifying
the customer unless the customer was willing to handle their own
abuse issues.

It also would have allowed for researchers to continue to analyze
the Internet deployment in much the same way as before.

As always, ARIN policies come from the members first, so if
people do not want to follow the APNIC precedent but instead
want a more meaningful solution, 2004-4 can be revived by someone
else. It all depends on what gets discussed on the ARIN PPML mailing
list https://www.arin.net/participate/community/mailing_lists/
and what gets discussed at the ARIN meeting.

That means that everyone on this list is wasting their time
discussing this. The discussion should happen on PPML where the
ARIN Advisory Council are obliged to take note of it. Or at
the ARIN meeting itself.

--Michael Dillon