<div dir="ltr">the easy to use solution is to require external data to be signed by RPKI certificates from another RIR's system.<div><br></div><div>1) its time limited: all signed objects have a lifetime</div><div>2) its secure (as secure as PKI)</div><div>3) it doesn't require massive effort to implement: a well formed object can be specified by anyone, and then signed by the prime resource holder using a certificate covering the resources. The receiving side can validate it directly.</div><div><br></div><div>Thats pretty much what I said to the microphone of the routing wg meeting.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 November 2014 08:42, Sander Steffann <span dir="ltr"><<a href="mailto:sander@steffann.nl" target="_blank">sander@steffann.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ronald,<br>
<span class=""><br>
>> Having IP addresses is not a requirement for getting an ASN. There are<br>
>> many legitimate cases where an ASN may be used to announce address space<br>
>> belonging to someone else. For example an ISP announcing address space<br>
>> belonging to its customer. Or a transit provider.<br>
><br>
> OK, that's a good point. But I'm not sure that it fully negates the<br>
> possible value of my question.<br>
><br>
> Everybody is _supposed_ to have working e-mail address contacts in their<br>
> IP allocation records within the WHOIS data bases of the various RiRs,<br>
> yes? So suppose that there had been a protocol in place that required<br>
> an affirmative e-mail response from at least one legitimate IP address<br>
> block registrant (in some/any region) before the allocation of an AS<br>
> number would proceed. Such a protocol would have forestalled the<br>
> situation that we now see with AS201640, would it not?<br>
<br>
</span>It is a possible implementation but one that only has a one-time check. It wouldn't keep track of changes to resources in other regions. The working group asked the RIPE NCC to look into the possibilities and report back to the working group. Let's see if there is a easy to use solution that makes sure we don't import data into our database that then end up being invalid or outdated.<br>
<br>
Cheers,<br>
Sander<br>
<br>
<br>
</blockquote></div><br></div>