This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[routing-wg] AS201640
- Previous message (by thread): [routing-wg] AS201640
- Next message (by thread): [routing-wg] AS201640
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ronald F. Guilmette
rfg at tristatelogic.com
Sun Nov 9 20:48:36 CET 2014
In message <CAA=nHSKbOHc7vSk5O+oPQ8459HyCk=t8pY8CZbHx+yhBE1tFkQ at mail.gmail.com> George Michaelson <ggm at apnic.net> wrote: >the easy to use solution is to require external data to be signed by RPKI >certificates from another RIR's system. > >1) its time limited: all signed objects have a lifetime >2) its secure (as secure as PKI) >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. > >Thats pretty much what I said to the microphone of the routing wg meeting. Sounds good to me! Could it be made to happen, um, yesterday? Regards, rfg P.S. I'm still a bit befuddled by what happened in this case. Would it be a fair characterization to say that what AS201640 has done in this case is to exploit a kind of loophole which is uniquely present only when the hijacker/squatter AS is registered in one RiR and the IP blocks that are being hijacked/squatted are registered in a different RiR? Also, could this scenario have been replicated if the origin AS had been registered in/by ARIN, APNIC, LACNIC, or AFRINIC, rather than RIPE? If so, then a proper sort of fix will necessarily involve all five RiRs, no?
- Previous message (by thread): [routing-wg] AS201640
- Next message (by thread): [routing-wg] AS201640
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]