Ok. I've been advised to post to both by someone from the NCC, but I'll try to keep db-wg out of most of the discussion now.
| 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 On Mon, Nov 5, 2018 at 5:34 PM Job Snijders <[email protected]> wrote: > > 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 > >
