Hi Töma, The concerns you raise seem to be out of scope for the Database Working Group - I'm not sure cross-posting multiple lists will advance the discussion in a meaningful way. Perhaps it would be good to continue the dialogue exclusively in APWG.
Kind regards, Job On Mon, Nov 5, 2018 at 8:38 AM Töma Gavrichenkov via db-wg <[email protected]> wrote: > > Hello WG (both, actually), > > A recent case of a Russian broadband ISP, roughly 6th in size in the > country, exposing the personal data of their individual VIP customers > by posting said data to RIPE DB(*) highlighted an important issue in > RIPE-708, 6.2 "[policies and guidelines for assignments for] Network > Infrastructure and End User Networks"(**). > > To quote: > > > IP addresses used solely for the connection of an End User to a service > > provider (e.g. point-to-point links) are considered part of the service > > provider's infrastructure. These addresses do not have to be registered > > with the End User's contact details but can be registered as part of the > > service provider's internal infrastructure. > > > When an End User has a network using public address space this _must_ be > > registered separately with the contact details of the End User. Where the > > End User is an individual rather than an organisation, the contact > > information of the service provider may be substituted for the End Users. > > (note the "must", we'll soon get back to it) > > While it's out of question that posting individual users' personal > data to RIPE DB is insane, what's interesting is that small business > owners(***), when aware of the leak, seem to also be concerned that > their B2B broadband data contract apparently included a clause they've > missed, and their mobile telephone number is now published to a public > database on the Internet, and, you know, one cannot simply remove an > information from the Internet which is already there. > > But when we try to rely on 6.2 for a definitive advice, we don't get any: > > - There's no definition of what is exactly meant under "point-to-point > links" (PTPL). Some speculate it's a historical term from the times of > PPP/SLIP, meaning just "end-user access links", and, as such, includes > individual and SMB customer links. Other read it as those IPv4 /30s > ASes waste all the time for BGP session establishment, and argue that > what's really meant by PTPL is just the IP addresses never ever > communicating with the world outside of their own local net (BGP > sessions included, SMB access obviously not included). > > (Personally, the second opinion looks more convincing for me, because > this way only those IP addresses which never send or receive packets > from the Internet may lack a proper abuse-c, which makes sense, and I > like when things make sense, so. But at the same time the first > opinion is backed by people I respect.) Anyway, RIPE-708 fails to > provide an answer. > > - Another scary term is "a network using public address space" > (NUPAS). Is IPv4 /32 a network? What about /31? What's "using public > address space" after all, there's no doubt we won't report our usage > of 192.168.0.0/16 to RIPE DB. This sentence was meant to clear our > concerns but it just adds up to them. > > What is also meant to help us but adds to the mess is the RIPE NCC > Local Internet Registry Training Course(****), slides 94-95: > > - Somehow, training material includes more specific definitions and > corner cases (e.g. "points of presence") than the policy does. Is it > only me, or such a thing should never ever happen? A policy training > course must not be different from the policy itself, no matter if the > difference is in being either more strict of more relaxed. If an NCC > trainer just knows more about the subject than is stated in a policy, > they'd better report to the WG first that the policy lacks an > important consideration. > > - However, those definitions don't really clarify what's PTPL and > NUPAS are, too. > > - Slide 95 is even better: it says there's a grey area around. Well, > it might be again only me, but personally I feel very uncomfortable > seeing "must" and "grey area" in the same sentence. If there's a grey > area in an area, it must be "should" there, not "must". > > - There's apparently a border line between "when the End User has a > few addresses out of a larger address block" and "If the End User has > a separate subnet". Now again, (an occasional?) /31 is a subnet or > just a few addresses? Who's going to check ISPs against this strict > ("must") requirement, and how? > > - What if there's a customer with an pizza store (so, an office within > their location) and their own equipment (Mikrotik) connected to a > broadband pool? > > - What if a broadband customer sets up an HTTP server on their > point-to-point link's public v4 address and starts serving whatever > children drug suicide abuse torrents they have. > > All in all, RIPE-708 6.2 is a perfect example of an imperfect policy, > too strict and too vague at the same time. Which is bad, because a) > some ISPs would just prefer to ignore it, no matter the "must", and > would be paying less attention to other "musts" they would encounter > in other policy documents, b) those ISPs who would choose to be > responsible about RIPE DB usage risk losing customers and wouldn't be > able to defend their attitude against the customers, let alone courts, > based on the RIPE DB policy. > > So here are two separate things I propose, and I'd prefer them to be > discussed and evaluated separately: > > 1) Ask the author of LIR training material to provide the WG (both) > with the historical insight on what was meant in 6.2, and how's that > supposed to work. Afterwards, after a heated discussion on the mailing > list (both), make a decision and amend a policy towards either a more > relaxed, or a more constraining fashion, but do either of things > anyway, as there's no SLIP anymore, and such an irresponsible wording > of a policy as it stands today undermines the trust in policy process, > especially in some Eastern European and Northeast countries where > there's hardly any trust even now. > > My personal suggestion is that the only border line that should be > there is between businesses/organizations with public IP addresses, on > one side, and individual users/NAT pools, on the other. If a company > is using a public IP address space for any purpose at all, it must > publish at least an abuse-c contact to a public IP database. Fair > enough IMO. > > 2) Change 6.2 to reflect the fact that the contact information of End > Users who are individuals not MAY, but rather MUST be substituted with > the contact data of the service provider. This perfectly reflects > currently ongoing legislation trends as well as a concern in the > society at large, and also would be seen as a responsible attitude of > an ISP community towards the personal data safety — an attitude the > ISP community hardly used to show before. > > (*) — https://www.bbc.com/russian/news-46083410. Here's a Google > Translate link for your convenience: > https://translate.google.com/translate?sl=ru&tl=en&js=n&u=https%3A%2F%2Fwww.bbc.com%2Frussian%2Fnews-46083410 > > (**) — https://www.ripe.net/publications/docs/ripe-708#62 > > (***) — My definition of a "small business" here might seem too broad, > but if's fully grounded: e.g. Main Directorate for Drugs Control of > the Ministry of Internal Affairs of Russia, as a business, is > definitely not so big; Alfa Bank is a large bank in Russia but Russian > banking system is comparatively small when compared to the rest of the > world; etc. > > (****) — > https://www.ripe.net/support/training/material/lir-training-course/lir-slides.pdf > > | Töma Gavrichenkov > | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 > | mailto: [email protected] > | fb: ximaera > | telegram: xima_era > | skype: xima_era > | tel. no: +7 916 515 49 58 >
