Re: ripe-list Digest, Vol 168, Issue 2

Hi, Andrew Campling <andrew.campling@419.consulting> writes:
Irrespective of any view regarding rights holders, the lack of effective KYC procedures is also a problem in combating both malicious and illegal content
Know Your Customer does require that someone IS their customer, right? Which in very many cases will not be the case for resource users and RIPE. In cases of someone using "fallow" resources without authorization by the formal resource holder, would you also blame the RIPE database for having incorrect info? Let me point out that even a "bulletproof" hoster will not beam their packets onto the Internet but will be connected to an uplink or uplinks, which ought to be readily traceable with a plain traceroute until you find the closest-to-them entity you can identify and that picks up their phones, which likely have a contract either with the hoster or their provider (and maybe even an acceptable use policy). Following that scavenger-hunt wise is sure more work than just looking it up in a phone book (RIR database), but the likelihood of finding entities whose customers the sought-after parties are is distinctly better. Kind regards, Petra Zeidler —————————————————————————— Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR) Deutsches Fernerkundungsdatenzentrum | DFD-INF | Oberpfaffenhofen, Münchener Str. 20 | 82234 Weßling Petra Zeidler Telefon +49 8153 28 4295 | Telefax +49 8153 28 1448 | petra.zeidler@dlr.de | http://www.dlr.de/eoc ----------------------------------------------------------------------

Petra.Zeidler--- via ripe-list <ripe-list@ripe.net> wrote: > Andrew Campling <andrew.campling@419.consulting> writes: >> Irrespective of any view regarding rights holders, the lack of >> effective KYC procedures is also a problem in combating both malicious >> and illegal content > Know Your Customer does require that someone IS their customer, right? > Which in very many cases will not be the case for resource users and > RIPE. > In cases of someone using "fallow" resources without authorization by > the formal resource holder, would you also blame the RIPE database for > having incorrect info? Isn't this why the RIRs send out these yearly reminders to verify contact info? > Let me point out that even a "bulletproof" hoster will not beam their > packets onto the Internet but will be connected to an uplink or > uplinks, which ought to be readily traceable with a plain traceroute > until you find the closest-to-them entity you can identify and that > picks up their phones, which likely have a contract either with the > hoster or their provider (and maybe even an acceptable use > policy). Following that scavenger-hunt wise is sure more work than just > looking it up in a phone book (RIR database), but the likelihood of > finding entities whose customers the sought-after parties are is > distinctly better. It's clear from many interactions with canadian federal bureaucrats that such a proceedure, while obvious to us, is not at all obvious to them. Even *internally* they have no idea that it is possible to do. (Unicast me) My opinion: we (the RIR community), can do better. There is some give and take with law enforcemenet, and this is a place where we can give a bit more. We do that in order to keep them from thinking they have to take things, like end to end encryption. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Petra.Zeidler--- via ripe-list <ripe-list@ripe.net> wrote:
In cases of someone using "fallow" resources without authorization by the formal resource holder, would you also blame the RIPE database for having incorrect info? Isn't this why the RIRs send out these yearly reminders to verify contact info?
You are smallACME corp and have an assignment of a.b.c/23 that you only use internally, for a VPN with partners (which used to be a legit reason to get public IP space) and that you don't (have) announce(d) on the Internet. Meanwhile Baddie Inc has seen that there is an assignment that is not in use on the Internet, and announces and uses it for questionable things. If RIPE asks you (smallACME corp) if you are the user of a.b.c/23 and if contacts etc.pp. are correct, you answer yes. Yet for the purposes of someone looking for who is using a.b.c/23 on the Internet, the database entries are wrong. Is that the databases fault? (I had something like that ~25 years ago; if there hadn't been an abuse complaint to my then employer as responsible LIR, no-one would have noticed, the space was PI. Getting the unauthorized use to stop wasn't trivial.) Kind regards, Petra Zeidler —————————————————————————— Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR) Deutsches Fernerkundungsdatenzentrum | DFD-INF | Oberpfaffenhofen, Münchener Str. 20 | 82234 Weßling Petra Zeidler Telefon +49 8153 28 4295 | Telefax +49 8153 28 1448 | petra.zeidler@dlr.de | http://www.dlr.de/eoc

<Petra.Zeidler@dlr.de> wrote: > Meanwhile Baddie Inc has seen that there is an assignment that is not > in use on the Internet, and announces and uses it for questionable > things. That's just hijacking. That's what RPKI is about. If Baddie Inc. got a transit provider to accept it, and didn't do RPKI, and the provider didn't demand a letter of authorization, then really, it's on the transit provider. > Yet for the purposes of someone looking for who is using a.b.c/23 on > the Internet, the database entries are wrong. > Is that the databases fault? Owner of a.b.c/23 ought to have routing objects, ROA, etc. that says that nobody is authorized to route it. The database is correct, and the complaint should be acted upon by doing something. This where the poorly monitored contact address matters so much. <Petra.Zeidler@dlr.de> wrote: > You are smallACME corp and have an assignment of a.b.c/23 that you only > use internally, for a VPN with partners (which used to be a legit > reason to get public IP space) {ps: and a reason why I think IPv6 space still needs to be easier. Or ULA-Central. VPNs can leak..} -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
participants (2)
-
Michael Richardson
-
Petra.Zeidler@dlr.de