[arin-ppml] Policy Proposal 95: Customer Confidentiality
Rudolph Daniel
rudi.daniel at gmail.com
Fri Jan 29 15:30:35 EST 2010
What I think is at the center of the debate here is : How much information
and what kind of information is to be in the public view. It is not about
whether the information exists. ARIN has the information and a provider has
collected the information and passed it to ARIN.
Now, under what rules and circumstances can/should that information be
accessed and by whom and for what purpose. Disclosure on a need to know
basis is also something I am not not 100% clear on.
If I see an unusual ip on my server, under what circumstances do I need
detailed information on who it is allocated to? And how do I efficiently
access that information if it is not an open public record. If it were on
public record, what level of certainty do I have that the information is
accurate?
If it is not on public record and I give good reason to access it, then the
entity allocated that record has a right to know / have recorded... who
accessed the information and when. Where the information is simply public
view, there is more room for abuse of that information simply because there
are "fewer" controls on what is published.
RD
L mailing list submissions to
> arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
> arin-ppml-request at arin.net
>
> You can reach the person managing the list at
> arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
> 1. Re: Policy Proposal 95: Customer Confidentiality (George Bonser)
> 2. Re: Customer Confidentially and IPv6 (Owen DeLong)
> 3. Re: Customer Confidentially and IPv6 (Leo Bicknell)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 29 Jan 2010 11:23:22 -0800
> From: "George Bonser" <gbonser at seven.com>
> To: "Aaron Wendel" <aaron at wholesaleinternet.net>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 95: Customer Confidentiality
> Message-ID:
> <5A6D953473350C4B9995546AFE9939EE081F74BB at RWC-EX1.corp.seven.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
> >
> > I don't think we're disagreeing per say. I think we're looking at
> this
> > from
> > different angles.
> >
> > There are a couple reasons I chose not to eliminate SWIPs in the
> > proposal;
> > One, it would never fly.
>
> Well, my thought was that anonymous SWIP is the same as no SWIP for all
> practical purposes. The notion was to find some way that SOME of your
> customers could be removed from being trawled via whois (and THAT really
> seems to be the issue, not SWOP itself) but the ones that I believe must
> remain public ... the ones not exclusively under your management ...
> would still have the current registration requirements.
>
> The real fix for this is actually the same as it was for telephones but
> is unworkable for the internet. The fix is to allow a customer, once
> assigned IP addresses, to keep them if they move just like you can keep
> your phone number if you change cellular providers. It would, however,
> cause routing table size explosion and isn't workable with the current
> state of the art. But it would end people trawling your allocated space
> looking for your SWIPs because over time that space would scatter. You
> would no longer have any exclusively allocated space, you would simply
> hand out initial allocations that would, over time, drift to other
> providers and theirs would drift into you.
>
> And I can understand the kind of business intelligence that can be
> obtained from this information. I could trend competitors, see which
> were gaining customers, which were losing customers, etc. And that is,
> I believe, the real problem here. It isn't SWIP per se, it is who has
> access to it and for what reasons. Is it in the interests of the
> community that ARIN provide a resource for commercial entities to
> collect information on each other? Should they have to pay some price
> for that information? Should they be denied access? How would it be
> policed. I believe end users should have quick and ready access to the
> full POC information of people allocated IP addresses. I don't believe
> that marketing departments of competing providers should be leveraging
> that information for their commercial interests.
>
>
> > Plus ARIN still uses SWIP for justification. They don't care who it's
> > assigned to, just that it's assigned.
> >
> > Nothing in my proposal takes away from anything that is already
> > functional.
>
> We disagree here. Yes it does take away from things that are already
> functional. Someone emailed me this morning that they noticed
> unfamiliar email activity on their mail server from one of my IP
> addresses and they wanted to know what it was. They were able to
> quickly and easily determine who was responsible for that IP address
> even though it was not from the block I have directly assigned. They
> were able to quickly locate the contact information for a role account
> that I monitor and we were able to resolve the issue within five
> minutes. Under your scenario, they would probably need to open a
> "ticket" with your abuse process. They would need to get in line behind
> potentially hundreds of other such tickets that got opened that morning
> for other customers of yours. They would need to explain the activity,
> you would then contact me, then there would be back and forth
> communications between me and the other user with you in the middle. It
> increases the chances if miscommunications, misunderstandings, and
> creates more work for everyone involved.
>
> > It simply gives the ISP the ability, along with it's customer, to
> > decide if
> > the address, phone number and e-mail should be displayed. Name is
> > still
> > required.
> >
> > Aaron
>
> All of the above must, in my opinion, be required.
>
> George
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 29 Jan 2010 11:24:05 -0800
> From: Owen DeLong <owen at delong.com>
> To: Bill Sandiford <bill at telnetcommunications.com>
> Cc: "ppml at arin.net" <ppml at arin.net>
> Subject: Re: [arin-ppml] Customer Confidentially and IPv6
> Message-ID: <13657810-8F14-4A67-BE85-CB415B835A7A at delong.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Uh, yeah... OOPS! Yes, the lovely city of Toronto, not Dearborn, MI is
> correct.
>
> Thanks, Bill.
>
> Owen
>
> On Jan 29, 2010, at 11:08 AM, Bill Sandiford wrote:
>
> > I can?t specifically speak for Owen, but at the conclusion of his message
> I believe he meant to say ?Toronto? instead of ?Dearborn?
> >
> > Regards,
> > Bill
> >
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> > Sent: Friday, January 29, 2010 2:05 PM
> > To: Leo Bicknell
> > Cc: ppml at arin.net
> > Subject: Re: [arin-ppml] Customer Confidentially and IPv6
> >
> >
> > Well, what happens in IPv6? In the NRPM today, 6.5.4.4 states "All
> > /56 and larger assignments to end sites are required to be registered".
> > So for instance if the cable modem provider today who provides a
> > single dynamic IP via DHCP and puts none of them in SWIP decides
> > to provide every customer with a /48 (as many want them to do) or
> > even a /56, via DHCP-PD they will be required to put those dynamic
> > assignments into SWIP.
> >
> > Actually, as I interpret the NRPM, they would be required to put the
> > covering prefix of the DHCP pool into SWIP as a DHCP Pool, but,
> > there is no need for the DHCP daemon to update SWIPS.
> >
> > If that isn't the case, you are correct that that area of policy needs
> > work.
> >
> > However, for static persistent assignments of /56s or shorter prefixes
> > to customers, I think it is perfectly reasonable to require SWIP just
> > as we require it for /29 and shorter today. I do not see a need to
> > expand customer anonymity beyond the current residential
> > requirement.
> >
> >
> > So we are at a cross roads where we are poised either to add literally
> > tens of millions of records to SWIP and cause a new dump of customer
> > databases to ARIN; or perhaps we will inadvertently force many ISP's
> > to hand out /60's and /64's to customers so they don't have to deal
> > with putting these customers into WHOIS. I think either would be
> > a disservice to the community.
> >
> > I'm uncertain why they couldn't use /57s even if what you say were
> > true, but, again, I think that transient dynamic assignments are not
> > subject to that requirement.
> >
> > Given IPv4's end game is near I don't really care how SWIP gets
> > applied to IPv4 anymore. It is what it is, and there is no reason
> > to revisit the issue. However, IPv6 fundamentally alters some of
> > the arguments used with respect to who is in the database and how
> > they are listed. I think the AC would be wise to take this proposal
> > and use it to foster a discussion of WHOIS in an IPv6 world. Privacy
> > of residential customers has clearly been an ongoing concern in
> > various policies, and if IPv6 lists whole classes of users that are
> > not listed today then the level of concern will likely skyrocket.
> >
> > I find it interesting that you expressed support for the petition in this
> > case. As I understand it, the petition, if it succeeds will bring this
> > IPv4-only proposal to the floor in Dearborn for adoption discussion.
> >
> >
> > Owen
> >
> >
> >
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20100129/47fe4c97/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Fri, 29 Jan 2010 11:38:38 -0800
> From: Leo Bicknell <bicknell at ufp.org>
> To: ppml at arin.net
> Subject: Re: [arin-ppml] Customer Confidentially and IPv6
> Message-ID: <20100129193838.GA75251 at ussenterprise.ufp.org>
> Content-Type: text/plain; charset="us-ascii"
>
> In a message written on Fri, Jan 29, 2010 at 11:04:47AM -0800, Owen DeLong
> wrote:
> > Actually, as I interpret the NRPM, they would be required to put the
> > covering prefix of the DHCP pool into SWIP as a DHCP Pool, but,
> > there is no need for the DHCP daemon to update SWIPS.
> > If that isn't the case, you are correct that that area of policy needs
> > work.
>
> Based on what is said in sections 6.5.4.4 and 6.5.5 I don't share
> your view. It seems to me the manual is clear, if an ISP assigns
> a /48 to someone then it must be registered via SWIP, with the
> possible caveat of 6.5.5.1 which allows for the customer name to
> be replaced with "Private Customer".
>
> I don't see anything that would make this not true if the assignment
> was done via DHCP-PD.
>
> > However, for static persistent assignments of /56s or shorter prefixes
> > to customers, I think it is perfectly reasonable to require SWIP just
> > as we require it for /29 and shorter today. I do not see a need to
> > expand customer anonymity beyond the current residential
> > requirement.
>
> Let me assume your previous interpretation is right. A /48 assigned
> via DHCP-PD to a cable modem customer (as an example) is not required
> to have a SWIP entry. However, a /48 assigned statically is required
> to have a SWIP entry.
>
> How does that make any sense? What if I make the DHCP-PD "static",
> e.g. enter the MAC and prefix in the DHCP server, so the client
> always gets the same range. Does it now qualify for a SWIP entry?
>
> In IPv4, it's highly likely that a megacorp (GM?) will have something
> larger than a /29, and have a SWIP entry. It's also highly likely
> that a person (residental customer) will have something smaller
> than a /29, and thus not be SWIPed. As IPv4 scarecity continues,
> this is likely to be more true.
>
> In IPv6 that's not so. The megacorp can likely live in a /48. A
> residential customer is just as likely to get the same /48. The
> old probabilities don't apply anymore.
>
> In case my position, in both IPv4 and IPv6 was not clear, I believe
> several things:
>
> * No residential customer should ever have their personal information in
> WHOIS for any reason.
>
> * Contact information in whois should lead to the entity /most likely to
> help/. I am extremely skeptical that putting folks as wide ranging as
> Grandma to many small businesses is going to lead to that result, I
> think in almost all cases their upstream ISP is a better place to go.
>
> * ARIN should devise policies and procedures such that it requires the
> minimum level of effort for an ISP to comply.
>
> Rather than have millions of /29 records in the database, I'd rather see
> records like:
>
> NetRange: 10.15.0.0 - 10.15.31.255
> CIDR: 10.15.0.0/11
> NetName: CableFOO-Chicago-12
> Comment: Statically assigned residential cable modem customers in
> the Chicago area.
> Usage: 212,453 subnets of 262144 in use on 2009-01-29.
>
> OrgAbuseHandle: CableFOO-ABUSE-ARIN
> OrgAbuseName: CableFOO Inc Abuse Department
> OrgAbusePhone: +1 800 4BOTNET
> OrgAbuseEmail: abuse-chiago at cablefoo.com
>
> Where the usage data was updated on some periodic interval, perhaps say
> quarterly.
>
> It protects peoples privacy, provides usage information ARIN needs and
> makes it visable to the community, directs people to contact information
> that is likely to get someone who can help, and greatly reduces the
> burden on the ISP and ARIN to process tons of SWIP templates, 99% of
> which just say "Private Customer" and "Private Residence" anyway.
>
> --
> Leo Bicknell - bicknell at ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 826 bytes
> Desc: not available
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20100129/f979d8d1/attachment.bin
> >
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 55, Issue 65
> *****************************************
>
--
Rudi Daniel
e Business Consultant
http://www.svgpso.org
http://oecstimes.wordpress.com
“The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts.” - Bertrand
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100129/4f448534/attachment.htm>
More information about the ARIN-PPML
mailing list