I am from out of region, and I do not maintain data in the RIPE DB
with a view to configuring routing, or to have my prefix originated. I
am associated with an agency (another RIR) which is not able to be
fully represented inside RIPE DB for logistical reasons but instead
operates as an autonomous, un-related space of IRR/WHOIS in the same
format (RPSL). Users of that service have come to expect that they can
lodge IRR data inside my service, in respect of their prefixes. This
seems reasonable.
And so we enter the problem of 'which DB, which resources, which
region, which authorization, why, how'
I too prefer, that for route: objects, we move to an acceptance that
the ASN holder is not materially bound to announce simply because
there is a route object, the ASN holder is not inherently attacked
because they were not asked, and instead we should be accepting the
INFORMATION that a route object asserts, first class from SIGNED DATA
in a ROA.
(sorry for shouting)
I understand there is a hypothetical risk that FILTER OWNERS are
spammed into a ddos wall of death from the creation of huge numbers of
route: objects not referring to them. But, this is not significantly
different in my mind, to the risk that I take a valid /32 in IPv6,
which I have in eg RIPE and then use the public maintainer to add
2^32-1 sub instances of data which refer to any ASN outside of RIPE,
thus killing the entire WHOIS anyway for anyone. Not a hypothetical
attack. Its a real one. And, by virtue of the maintainer, it exists
now.
I believe that transitionally, moving to prevent the out-of-region AS
thing in RIPE will impact around 350-400 people who currently assert
route: objects depending on this. I believe that is a tractable
problem.
I believe the addition of a tool to emit route: objects from RIPE RPKI
Validator, and possibly the dragon s/w makes this a moot point,
because those prefix holders can create objects in RPKI which replace
that function, trivially.
If the RIPE S/W is modified to stop needing ASN to approve route
objects, then users in my region using my WHOIS will be able to create
route: objects, while we work on persuading them to create ROA
instead.
I know APNIC Helpdesk staff would like to be able to stop recommending
use of un-secured IRR, and having to mediate the conversation between
ASN and INetnum maintainer by hand. They wish to ask if this can be
considered as an operational problem.
-George
On 14 May 2015 at 11:47, Randy Bush <randy(a)psg.com> wrote:
>>> some folk at euro ixen require route objects in ripe's irr. some
>>> folk who get address space from other rirs appear at those euro ixen
>>> and wish to peer.
>>
>> ixps which build route server configurations using ixp manager can
>> apply arbitrary IRR source tags (or combinations) on a per-customer
>> basis.
>
> yes, and peval() and other tools take an IRR instance list. but i have
> enough windmills without tilting at this one. you wanna peer with
> brunhilde, you play by her rules.
>
> when i saddle up rosenantes, it is to get all this to be rpki-based
> origin validation instead.
>
> randy
>
