 |
 |
In my experience, since we signed up, they do email us very occasionally to say “Oh we heard such-and-such an IP range is you, can you confirm?” so we can login and say “No, no that hasn’t been our IP range for 10 years, who on earth still has that on file?” --More precisely, we can say “No.” But at least that’s something. It’s… problematic that they’re maintaining ranges for institutions who haven’t signed up. I guess they’re thinking then there’s more incentive to get publishers to come on board, since it is one of those services that will work best if most people are on board, and getting momentum when few people are on board is a challenge. I do really like the idea of the service. I come at this from having to go through the “email/login to ALL the publishers to update IP ranges” about three times in not very many more years, it was painful and I remain traumatised. The idea of just being able to update a single place (or at least a single place for most publishers and a few outliers individually) is really appealing. I note a couple of their publishers are now using the IP Registry’s API to stay updated with IP addresses, which seems like another great development. Maybe it’s worth sending them feedback that if they provide IP addresses for institutions who haven’t signed up, they need to make it clear to publishers that these are non-verified and publishers should always confirm with the institution before making changes. Deborah From: Code for Libraries <[log in to unmask]> On Behalf Of Lolis, John Sent: Saturday, 5 December 2020 12:25 PM To: [log in to unmask] Subject: Re: [CODE4LIB] The IP Registry It seems to me that they have a glaring omission in not notifying a registrant when someone submitted or modified an IP address range for their institution. Seems like a no-brainer to me. As for *publishers* providing IP address ranges to update an institution's IP range, *what are they thinking?* John Lolis Coordinator of Computer Systems 100 Martine Avenue White Plains, NY 10601 tel: 1.914.422.1497 fax: 1.914.422.1452 https://whiteplainslibrary.org/<https://whiteplainslibrary.org> *When you think about it, *all* security is ultimately security by ignorance.* On Fri, 4 Dec 2020 at 18:09, Will Martin <[log in to unmask]<mailto:[log in to unmask]>> wrote: > They portray themselves as offering accurate IP ranges, when what > they've got amounts to some guess-work. They don't really have any way > to catch errors like the Choopa.net example Tom Keays gave, or the > consortium sub-range in mine. Unless, of course, the way they catch > those is to rely on people from the institutions to eventually log in > and correct those for them. > > I'm going to go ahead and update my institutions ranges with them > anyway, because I think I have to. But I'm not going to like them for > it. > > Will > > On 2020-12-04 16:49, Tom Keays wrote: > > A couple of years ago, when I was reviewing the IP set up for Scitation > > for > > my institution, I noticed it included an unfamiliar IP range, > > 216.155.128.000 - 216.155.128.063. This was not the first time I had > > encountered this range (although I don't have a record of what the > > previous > > vendors were where I found it). After spending some time investigating, > > I > > determined that it belonged to an internet hosting company called > > Choopa.net. Definitely a bogus listing for us. > > > > Anyway, when I first set up my account at The IP Registry, they also > > listed > > this range. When I told them about it and asked them how they got it > > and > > explained that it should never have been there in their records, they > > replied, "This IP range was supplied to us by a number of publishers > > who > > are using it to provide access." > > > > I don't really know how this range got listed as being valid for my > > institution. Was it there because individual social engineered > > somebody's > > support team in order to get free access to online resources? I have to > > assume so. I also don't know if The IP Registry got it from the > > e-resource > > vendors and accepted it without question or the vendors got it from > > them, > > again without question. Either way, it made me worry about trusting > > them > > too far. > > > > Tom > > > > On Fri, Dec 4, 2020 at 2:33 PM Jeremiah Kellogg <[log in to unmask]<mailto:[log in to unmask]>> > > wrote: > > > >> Yikes, this does sound like we're being forced into a service whether > >> we > >> want to use it or not. At our institution we're the default owner of > >> a > >> range of IPs we manage on behalf of a public library consortium that > >> we're > >> not actually a part of (so the consortium shouldn't be accessing our > >> databases). The IP registry had grabbed that range of IPs and > >> included > >> them in our profile, but had them pending verification from our > >> institution > >> that we actually owned them before making them available to > >> publishers. I > >> ended up editing that range to exclude the consortium IPs, and then no > >> longer had to verify the remaining range of IPs that were correct. > >> Now > >> that I really think about this, had I not made those edits, our proxy > >> server would have been excluded and we would have faced a situation > >> where > >> our students, faculty and staff were denied access to the services > >> they > >> should be able to access. So we would have faced the opposite problem > >> that > >> you experienced, Will, where people would be denied access rather than > >> given access they shouldn't have. Either way, the only apparent way > >> these > >> problems can be fixed is by signing up with the IP registry and > >> updating > >> things ourselves... and that's kind of underhanded. I'm not sure I'd > >> worry > >> too much about the legalities because it appears vendors, unlike our > >> institutions, participate willingly, and if they're willing to take > >> the > >> ipregistry's word that our IP ranges are accurate that's on them. > >> It's > >> just really frustrating to think that we'd face these kinds of > >> problems due > >> to an outside entity getting things wrong on our behalf, and the only > >> way > >> to fix them is by signing up with them and making corrections. > >> > >> I don't think I mind them selling our improved IP data to vendors > >> because > >> that's the kind of thing most free services need to do to pay the > >> bills > >> these days. I might be putting the work into it, but it's not so much > >> that > >> I feel like I'm putting more in than I'm getting out of it. However, > >> as > >> you point out, Will, there doesn't appear to be a mechanism for opting > >> out > >> of their system, and that really stinks. I haven't dug too deep, but > >> I > >> wonder if there's a way of setting things up with vendors who use that > >> service to stop using it when we make such a request? I think I'm > >> pretty > >> much on the same page as you, Will. It's a great idea for a service, > >> but > >> being forced into it will understandably leave a bad taste in people's > >> mouths, and it also casts a bit of shadow on the service's integrity. > >> I > >> get that participation is important for this kind of thing, but I > >> suspect > >> there are better ways of getting people onboard! > >> > >> On Thu, Dec 3, 2020 at 6:02 PM Will Martin <[log in to unmask]<mailto:[log in to unmask]>> > >> wrote: > >> > >> > I am concerned by the fact that the IP Registry appears to have gone > >> > around figuring out the IP ranges for schools based on public records > >> > from the IANA and a bunch of vendor records. I'm sure that was > >> > difficult, and their site says it took four years. When it was done, > >> > they announced that 58% of IP ranges were wrong, and began selling the > >> > service to vendors and telling them what our IP addresses are based on > >> > their analysis. > >> > > >> > I claimed the account for my institution and discovered that there > were > >> > 26 vendors already pulling my university's IP ranges from the IP > >> > Registry. Unfortunately, the IP ranges were wrong. To name a few > >> > problems: > >> > > >> > 1) They conflated us with another school in the same university > system. > >> > > >> > 2) They could not know that there are a couple of IP ranges that we > >> > prefer to be treated as "off campus" even though they belong to the > >> > University. > >> > > >> > 3) They had no way to know that one particular range of our IPs is > >> > assigned to a library consortium in our state, and used for proxy > >> > servers that serve the other institutions in the university system > plus > >> > several dozen public libraries. > >> > > >> > The third point is critical. By distributing these erroneous IP > ranges > >> > on my school's behalf, without permission, the IP registry has > >> > effectively granted access to 26 of our subscriptions to basically > >> > everyone in my state. We are thus in violation of our license > >> > agreements and will be at risk of legal action by the publishers > until I > >> > can sort this mess out. > >> > > >> > Because this involves multiple institutions -- my own, the broader > >> > university system, the aforementioned library consortium -- I am going > >> > to have to contact and explain the situation to a lot of people, and > >> > spend a lot of time checking and re-checking IP ranges, all in service > >> > of updating the IP Registry's records. > >> > > >> > Then they get to turn around and charge the publishers for my work. > >> > > >> > But frankly, their business model feels like extortion to me. We have > to > >> > verify their records, or there's a chance that our resources will be > >> > accessible to people who should not have access because their analysis > >> > was incorrect. They appear to have engineered a situation that puts > my > >> > institution in potential legal jeopardy, which we can only get out of > by > >> > improving the data that the IP Registry is selling for a profit. > >> > > >> > I am not happy with them. The basic idea -- a centralized repository > of > >> > IP ranges for bulk updating publisher records -- is both sound and > >> > useful. But their business model leaves a bad taste in my mouth. If > I > >> > could, I would opt out of the system. But they do not appear to have > >> > made a mechanism available to do so. > >> > > >> > Will Martin > >> > > >> > Head of Digital Initiatives, Systems and Services > >> > Chester Fritz Library > >> > University of North Dakota > >> > > >> > >> > >> -- > >> Jeremiah Kellogg > >> Systems Librarian > >> Pierce Library > >> Eastern Oregon University > >> [log in to unmask]<mailto:[log in to unmask]> > >> (541) 962-3017 > >> > ________________________________ "The contents of this e-mail (including any attachments) may be confidential and/or subject to copyright. Any unauthorised use, distribution, or copying of the contents is expressly prohibited. If you have received this e-mail in error, please advise the sender by return e-mail or telephone and then delete this e-mail together with all attachments from your system."