Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Randy Bush via db-wg]

>> why not go the other, more positive, direction, and identify authorised
>> data with RIPE-AUTH or whatever?  no need to be pejorative.
> 
> s/RIPE-NONAUTH/RIPE-OTHERRIR/

can there be cases where the source is not an rir?  rfc1918 for example?

s/RIPE-NONAUTH/JOB-HATES/  :)

randy

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[George Michaelson via db-wg]

Yes, I would support these changes. Half of the concerns with APNIC
resource management disappears if we cease depending on aut-num
authorization for route objects.

I prefer that ultimately the open maintainer method cease. But a step
along the way is to mark foreign objects clearly, so their status and
role can be understood.

-George

On Tue, Oct 17, 2017 at 9:23 AM, William Sylvester via db-wg
<db-wg@ripe.net> wrote:
>
>
> -- Forwarded message --
> From: William Sylvester <william.sylves...@addrex.net>
> To: Database WG <db-wg@ripe.net>
> Cc:
> Bcc:
> Date: Mon, 16 Oct 2017 23:22:55 +
> Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
> Db-wg members,
>
> Now that there has been substantial discussion on this topic, I wanted to try 
> to bring the conversation back to a more practical and actionable path 
> forward. Clearly this is a topic where there are a lot of opinions. From 
> seeing the discussion and receiving additional feedback, I wanted to point 
> out some re-occurring themes and request a revised proposal for working group 
> consideration.
>
>
> 1) Remove the "origin:" authorization requirement. RIPE is currently the only 
> RIR that requires this, the current implementation creates data concurrency 
> issues across Internet databases by requiring the creation of duplicate 
> autnums.
>
> 2) Flag "route:" objects for non-RIPE-managed space with "source: 
> RIPE-NONAUTH" to identify non-authoritative data.
>
>
> I’d like to seek input from the group;
>
> - Do you feel these options are straight forward and easy to understand?
> - Does this provide a reasonable security posture?
> - Will this make a positive impact for RIPE DB and the greater Internet?
> - Do you support these concepts?
>
>
> Thanks,
> William
> Db-wg co-chair
>
>

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Randy Bush via db-wg]

>>> 2) Flag "route:" objects for non-RIPE-managed space with "source:
>>> RIPE-NONAUTH" to identify non-authoritative data.
>> 
>> why not go the other, more positive, direction, and identify authorised
>> data with RIPE-AUTH or whatever?  no need to be pejorative.
> 
> This is not meant to be pejorative. "RIPE-NONAUTH" was brought up
> because that way we don't touch the majority of objects that actually
> are valid, and belong with RIPE.

ahh, the poor overworked script will have less to do so we will have to
pay it less.  good plan.

> If you have a different suggestion than "RIPE-NONAUTH" I think the group
> would be all ears. "RIPE-2", "RIPE-OTHER", all is fine with me.

for those old enough to remember, RARE

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Job Snijders via db-wg]

On Tue, Oct 17, 2017 at 05:18:55PM +, Randy Bush via db-wg wrote:
> > 2) Flag "route:" objects for non-RIPE-managed space with "source:
> > RIPE-NONAUTH" to identify non-authoritative data.
> 
> why not go the other, more positive, direction, and identify authorised
> data with RIPE-AUTH or whatever?  no need to be pejorative.

This is not meant to be pejorative. "RIPE-NONAUTH" was brought up
because that way we don't touch the majority of objects that actually
are valid, and belong with RIPE.

Since we are brownfielding, I see no other option than to continue using
the historic tag for the main chunk of the database, and split out the
non-authoritative data into a different tag.

If you have a different suggestion than "RIPE-NONAUTH" I think the group
would be all ears. "RIPE-2", "RIPE-OTHER", all is fine with me.

Kind regards,

Job

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Randy Bush via db-wg]

> 2) Flag "route:" objects for non-RIPE-managed space with "source:
> RIPE-NONAUTH" to identify non-authoritative data.

why not go the other, more positive, direction, and identify authorised
data with RIPE-AUTH or whatever?  no need to be pejorative.

randy

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Rob Evans via db-wg]

Hi,

1) Remove the "origin:" authorization requirement. RIPE is currently 
the only RIR that requires this, the current implementation creates 
data concurrency issues across Internet databases by requiring the 
creation of duplicate autnums.


2) Flag "route:" objects for non-RIPE-managed space with "source: 
RIPE-NONAUTH" to identify non-authoritative data.


I support both of those.  I’ll observe that there have been attempts 
to do (1) in the past that have floundered.



3) Consider possible, simple options to allow non RIPE resource
holders to 'approve' (if not authorise) the creation of a foreign
ROUTE object.


I wouldn’t want to lose the ability to make progress on (1) and (2) 
because we end up getting bogged down in the details of (3), which is 
what I fear will happen, so I’d put something like this on the back 
burner for now.


Cheers,
Rob

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[niels=dbwg--- via db-wg]

--- Begin Message ---

* den...@gmail.com (den is) [Tue 17 Oct 2017, 03:02 CEST]:

3) Consider possible, simple options to allow non RIPE resource
holders to 'approve' (if not authorise) the creation of a foreign
ROUTE object.


This is cumbersome in practice already.  Options 1 and 2 would lessen
the administrative load of documenting permission of others to route
prefixes; option 3 wouldn't.


On 17 October 2017 at 01:23, William Sylvester wrote:

1) Remove the "origin:" authorization requirement. RIPE is 
currently the only RIR that requires this, the current 
implementation creates data concurrency issues across Internet 
databases by requiring the creation of duplicate autnums.


2) Flag "route:" objects for non-RIPE-managed space with "source: 
RIPE-NONAUTH" to identify non-authoritative data.


I support these two.  They would make things simpler that I encounter 
frequently.


Regards,


-- Niels.

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Nick Hilliard via db-wg]

--- Begin Message ---
Daniel Shaw via db-wg wrote:
> On 17/10/2017, 03:24, William Sylvester via db-wg typed:
>> > 
>> > 
>> > 1) Remove the "origin:" authorization requirement. RIPE is currently the 
>> > only RIR that requires this, the current implementation creates data 
>> > concurrency issues across Internet databases by requiring the creation of 
>> > duplicate autnums.
>> > 
>> > 2) Flag "route:" objects for non-RIPE-managed space with "source: 
>> > RIPE-NONAUTH" to identify non-authoritative data.
>> > 
>> > 
>> > I’d like to seek input from the group;
>> > 
>> > - Do you feel these options are straight forward and easy to understand?
>> > - Does this provide a reasonable security posture?
>> > - Will this make a positive impact for RIPE DB and the greater Internet?
>> > - Do you support these concepts?
>> > 
> 
> Yes. There isn't really any downside to these. There are clear benefits to 
> both.

Agreed.  This sounds like a sensible thing to do.

Nick

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Erik Bais via db-wg]

--- Begin Message ---
I agree and support both 2 mentioned items.  

Erik Bais 

-Oorspronkelijk bericht-
Van: Job Snijders [mailto:j...@instituut.net] 
Verzonden: dinsdag 17 oktober 2017 9:53
Aan: William Sylvester <william.sylves...@addrex.net>
CC: Database WG <db-wg@ripe.net>
Onderwerp: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

Dear WG, chairs,

On Mon, Oct 16, 2017 at 11:24:14PM +, William Sylvester via db-wg wrote:
> Now that there has been substantial discussion on this topic, I wanted
> to try to bring the conversation back to a more practical and
> actionable path forward. Clearly this is a topic where there are a lot
> of opinions. From seeing the discussion and receiving additional
> feedback, I wanted to point out some re-occurring themes and request a
> revised proposal for working group consideration.
> 
> 1) Remove the "origin:" authorization requirement. RIPE is currently
> the only RIR that requires this, the current implementation creates
> data concurrency issues across Internet databases by requiring the
> creation of duplicate autnums.
> 
> 2) Flag "route:" objects for non-RIPE-managed space with "source:
> RIPE-NONAUTH" to identify non-authoritative data.
> 
> I’d like to seek input from the group;
> 
> - Do you feel these options are straight forward and easy to understand?
> - Does this provide a reasonable security posture?
> - Will this make a positive impact for RIPE DB and the greater Internet?
> - Do you support these concepts?

I fully support executing both action items.

Removal of the "origin:" authorisation step will bring the RIPE IRR in
line with other databases such as APNIC, RADB and as such make use of
the database easier for global organisations. It also aligns with the
practises observed in RPKI.

Flagging "route:/route6:" objects with "RIPE-NONAUTH" when they cover
non-RIPE managed space has many benefits. Setting the "source:" to
represent what the data actually means, we can programmatically analyse
the contents of the RIPE DB and facilitate creation of higher quality
route filters, but also for instance use it as a reputation factor in
spam scoring.

These two options represent what currently is the lowest hanging fruit
to improve in this problem space. Funny enough, neither of these items
makes things more difficult for anyone involved, on the contrary - by
making route: authorisation easier, _and_ showing what is authoritative
data and what is not, we improve the security posture of the RIPE
community.

Kind regards,

Job
--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Erik Bais via db-wg]

--- Begin Message ---
I agree and support both 2 mentioned items.  

Erik Bais

-Oorspronkelijk bericht-
Van: Job Snijders [mailto:j...@instituut.net] 
Verzonden: dinsdag 17 oktober 2017 9:53
Aan: William Sylvester <william.sylves...@addrex.net>
CC: Database WG <db-wg@ripe.net>
Onderwerp: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

Dear WG, chairs,

On Mon, Oct 16, 2017 at 11:24:14PM +, William Sylvester via db-wg wrote:
> Now that there has been substantial discussion on this topic, I wanted
> to try to bring the conversation back to a more practical and
> actionable path forward. Clearly this is a topic where there are a lot
> of opinions. From seeing the discussion and receiving additional
> feedback, I wanted to point out some re-occurring themes and request a
> revised proposal for working group consideration.
> 
> 1) Remove the "origin:" authorization requirement. RIPE is currently
> the only RIR that requires this, the current implementation creates
> data concurrency issues across Internet databases by requiring the
> creation of duplicate autnums.
> 
> 2) Flag "route:" objects for non-RIPE-managed space with "source:
> RIPE-NONAUTH" to identify non-authoritative data.
> 
> I’d like to seek input from the group;
> 
> - Do you feel these options are straight forward and easy to understand?
> - Does this provide a reasonable security posture?
> - Will this make a positive impact for RIPE DB and the greater Internet?
> - Do you support these concepts?

I fully support executing both action items.

Removal of the "origin:" authorisation step will bring the RIPE IRR in
line with other databases such as APNIC, RADB and as such make use of
the database easier for global organisations. It also aligns with the
practises observed in RPKI.

Flagging "route:/route6:" objects with "RIPE-NONAUTH" when they cover
non-RIPE managed space has many benefits. Setting the "source:" to
represent what the data actually means, we can programmatically analyse
the contents of the RIPE DB and facilitate creation of higher quality
route filters, but also for instance use it as a reputation factor in
spam scoring.

These two options represent what currently is the lowest hanging fruit
to improve in this problem space. Funny enough, neither of these items
makes things more difficult for anyone involved, on the contrary - by
making route: authorisation easier, _and_ showing what is authoritative
data and what is not, we improve the security posture of the RIPE
community.

Kind regards,

Job


--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Sander Steffann via db-wg]

--- Begin Message ---
Hi,

Op 17 okt. 2017, om 09:53 heeft Job Snijders via db-wg  het 
volgende geschreven:
> These two options represent what currently is the lowest hanging fruit
> to improve in this problem space. Funny enough, neither of these items
> makes things more difficult for anyone involved, on the contrary - by
> making route: authorisation easier, _and_ showing what is authoritative
> data and what is not, we improve the security posture of the RIPE
> community.

+1

This is low-hanging fruit indeed, and I see no problems with either of them.

Cheers,
Sander


--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Daniel Shaw via db-wg]

--- Begin Message ---
On 11/10/2017, 17:48, Nick Hilliard via db-wg   typed:
> 
> 
> Job Snijders wrote:
>> I think this touches upon an incredibly important question: how do we
>> distinguish between garbage and properly authenticated "route:"
>> objects covering RIPE-managed space?
> 
> and more to the point: are there good reasons and community support for
> continuing not to distinguish between the two.

Quite so. I cannot see any.

Having a flag/label that makes it clear right away how much authentication a 
given route:/rotue6: object has associated with it can only be a good thing.

That doesn't change the existence or creation of any class of object. But 
clearly marking what is what seems a no brainer to me.

Thanks,
Daniel


--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Lu Heng via db-wg]

--- Begin Message ---
Hi Guys:

How about not change any status in BD until we have an automated API to
deal with this.

How about Just simply send an email the the holder in foreign database to
notify them properly.

I think the biggest problem we have here is not foreign route object being
created, but rather they being created without holder’s knowledge.



On Tue, Oct 17, 2017 at 09:03 den is via db-wg <db-wg@ripe.net> wrote:

> 3) Consider possible, simple options to allow non RIPE resource
> holders to 'approve' (if not authorise) the creation of a foreign
> ROUTE object.
>
> cheers
> denis
> co-chair DB WG
>
>
> On 17 October 2017 at 01:23, William Sylvester via db-wg <db-wg@ripe.net>
> wrote:
> >
> >
> > -- Forwarded message --
> > From: William Sylvester <william.sylves...@addrex.net>
> > To: Database WG <db-wg@ripe.net>
> > Cc:
> > Bcc:
> > Date: Mon, 16 Oct 2017 23:22:55 +
> > Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final
> decision?
> > Db-wg members,
> >
> > Now that there has been substantial discussion on this topic, I wanted
> to try to bring the conversation back to a more practical and actionable
> path forward. Clearly this is a topic where there are a lot of opinions.
> From seeing the discussion and receiving additional feedback, I wanted to
> point out some re-occurring themes and request a revised proposal for
> working group consideration.
> >
> >
> > 1) Remove the "origin:" authorization requirement. RIPE is currently the
> only RIR that requires this, the current implementation creates data
> concurrency issues across Internet databases by requiring the creation of
> duplicate autnums.
> >
> > 2) Flag "route:" objects for non-RIPE-managed space with "source:
> RIPE-NONAUTH" to identify non-authoritative data.
> >
> >
> > I’d like to seek input from the group;
> >
> > - Do you feel these options are straight forward and easy to understand?
> > - Does this provide a reasonable security posture?
> > - Will this make a positive impact for RIPE DB and the greater Internet?
> > - Do you support these concepts?
> >
> >
> > Thanks,
> > William
> > Db-wg co-chair
> >
> >
>
> --
--
Kind regards.
Lu
--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[den is via db-wg]

--- Begin Message ---
3) Consider possible, simple options to allow non RIPE resource
holders to 'approve' (if not authorise) the creation of a foreign
ROUTE object.

cheers
denis
co-chair DB WG


On 17 October 2017 at 01:23, William Sylvester via db-wg <db-wg@ripe.net> wrote:
>
>
> -- Forwarded message --
> From: William Sylvester <william.sylves...@addrex.net>
> To: Database WG <db-wg@ripe.net>
> Cc:
> Bcc:
> Date: Mon, 16 Oct 2017 23:22:55 +
> Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
> Db-wg members,
>
> Now that there has been substantial discussion on this topic, I wanted to try 
> to bring the conversation back to a more practical and actionable path 
> forward. Clearly this is a topic where there are a lot of opinions. From 
> seeing the discussion and receiving additional feedback, I wanted to point 
> out some re-occurring themes and request a revised proposal for working group 
> consideration.
>
>
> 1) Remove the "origin:" authorization requirement. RIPE is currently the only 
> RIR that requires this, the current implementation creates data concurrency 
> issues across Internet databases by requiring the creation of duplicate 
> autnums.
>
> 2) Flag "route:" objects for non-RIPE-managed space with "source: 
> RIPE-NONAUTH" to identify non-authoritative data.
>
>
> I’d like to seek input from the group;
>
> - Do you feel these options are straight forward and easy to understand?
> - Does this provide a reasonable security posture?
> - Will this make a positive impact for RIPE DB and the greater Internet?
> - Do you support these concepts?
>
>
> Thanks,
> William
> Db-wg co-chair
>
>

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[William Sylvester via db-wg]

--- Begin Message ---
Db-wg members,

Now that there has been substantial discussion on this topic, I wanted to try 
to bring the conversation back to a more practical and actionable path forward. 
Clearly this is a topic where there are a lot of opinions. From seeing the 
discussion and receiving additional feedback, I wanted to point out some 
re-occurring themes and request a revised proposal for working group 
consideration.


1) Remove the "origin:" authorization requirement. RIPE is currently the only 
RIR that requires this, the current implementation creates data concurrency 
issues across Internet databases by requiring the creation of duplicate autnums.

2) Flag "route:" objects for non-RIPE-managed space with "source: RIPE-NONAUTH" 
to identify non-authoritative data.


I’d like to seek input from the group;

- Do you feel these options are straight forward and easy to understand?
- Does this provide a reasonable security posture?
- Will this make a positive impact for RIPE DB and the greater Internet?
- Do you support these concepts?


Thanks,
William
Db-wg co-chair

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Job Snijders via db-wg]

--- Begin Message ---
On Wed, Oct 11, 2017 at 03:00:55PM +0100, Sascha Luck [ml] wrote:
> On Wed, Oct 11, 2017 at 02:46:54PM +0100, Nick Hilliard via db-wg wrote:
> > Job Snijders wrote:
> > > I think this touches upon an incredibly important question: how do
> > > we distinguish between garbage and properly authenticated "route:"
> > > objects covering RIPE-managed space?
> > 
> > and more to the point: are there good reasons and community support
> > for continuing not to distinguish between the two.
> 
> Well, distinguishing in the irrdb is one thing, but how would you
> distinguish between them in RealLife(tm)? It's not like you can
> not route/accept a cross-RIR route: object (at least not without
> Breaking The Internet)

Some people may make a choice to ignore objects with source
RIPE-NONAUTH, or some may let other sources have precedence over
RIPE-NONAUTH. I can also imagine improvements to abuse handling systems
which now know that they might need to take the route with a grain of
salt. We'll see what innovation is possible!

> Also, what would the distinguisher be for eg. a route: with
> prefix from RIPE and ASN from ARIN? RIPE-PARTIALLY-AUTHENTICATED?

Just "source: RIPE" - because it is authenticated following the chain
from RIPE to inetnum holder to mnt-by/mnt-routes. That the ASN comes
from ARIN (or wherever) is irrelevant, just like with RPKI.

Kind regards,

Job

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[George Michaelson via db-wg]

--- Begin Message ---
I think its time to stop disrespecting external source of authority on
this. You argued for a position based on the desire of RIPE entities
needing to import foreign objects into their RPSL But you did not
address the far larger body of people who are exposed to risks from
the public maintainer and foreign object model, which we know is
causing problems. I have presented three times on this at RIPE
meetings in Dublin, Bucharest and Amsterdam pointing out that APNIC
helpdesk and hostmaster are mediating calls from members who are
concerned at how their ASN wound up in the RIPE RPSL. I also spoke
recently at the APNIC services meeting to this, calling for a bit more
dialogue on what we want to do.

Lets build an ecology which can handle disparate sources, and stop
demanding a bogus security model. The open maintainer is yesterdays
man.

a) Move the non-local stuff to another source and be explicit its an
import to allow people to discriminate. We should do this irrespective
of any other work: its not in RIPE data management, its not part of
RIPE authoritative statements. A declaration of intent through an open
maintainer is functionally indistinguishable from a lie.

b) We can think about ROA. There is no permission from the origin-as
to be referred to in a ROA, and we know that people regard the ROA as
semantically in the same space as the route: object which demands the
aut-num import. So we have a clear signal that routing praxis is now
not that concerned with ASN authority to be cited in origin-AS. If you
remove the dependency on aut-num maintainer, you will removed the
dependency on foreign object import. The validity of authority over
the aut-num can be understood from its appropriate RIR or NIR
declaration, as an imported source.

-George

On Wed, Oct 11, 2017 at 8:06 AM, Job Snijders via db-wg <db-wg@ripe.net> wrote:
>
>
> -- Forwarded message --
> From: Job Snijders <j...@instituut.net>
> To: "Carlos M. Martinez" <carlosm3...@gmail.com>, "Sascha Luck [ml]" 
> <d...@c4inet.net>
> Cc: Database WG <db-wg@ripe.net>, denis walker <ripede...@yahoo.co.uk>
> Bcc:
> Date: Wed, 11 Oct 2017 15:06:04 +
> Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?
>
> On Wed, 11 Oct 2017 at 16:52, Sascha Luck [ml] via db-wg <db-wg@ripe.net> 
> wrote:
>>
>> On Wed, Oct 11, 2017 at 11:30:06AM -0300, Carlos M. Martinez wrote:
>> >IMHO, any idea that starts with “Let´s create a central X” is doomed from 
>> >the start.
>> >
>> >We must think along other lines.
>>
>> Maybe "central" was the wrong word to use. Think a DB that every
>> RIR provides a copy of and authenticates the bits that "belong"
>> to it. This would even be necessary to avoid compromise.
>> One could pick the copy to use for filter generation or even
>> query them all and implement a majority decision if there are
>> discrepancies.
>> Of course it would require all RIRs to use the same RPSL format
>> but that appears more of a political than a technical problem.
>
>
>
> We already have that “central IRR” in the form of the likes of the RADB Whois 
> server. RIPE’s data is the odd one out here.
>
> RIPE is the _only_ IRR source where we cannot differentiate between 
> authenticated data and non-authenticated data.
>
> For all other sources we know that either the route objects have been 
> authenticated against the inetnum’s specified maintainer (APNIC, AFRINIC, 
> JPIRR) or is entirely without such verification (ARIN, NTTCOM, ALTDB, RADB 
> itself, etc).
>
> The value of the data in the RIPE DB would significantly increase if this 
> difference is shown.
>
> Kind regards,
>
> Job
>
>

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Job Snijders via db-wg]

--- Begin Message ---
On Wed, 11 Oct 2017 at 16:52, Sascha Luck [ml] via db-wg 
wrote:

> On Wed, Oct 11, 2017 at 11:30:06AM -0300, Carlos M. Martinez wrote:
> >IMHO, any idea that starts with “Let´s create a central X” is doomed from
> the start.
> >
> >We must think along other lines.
>
> Maybe "central" was the wrong word to use. Think a DB that every
> RIR provides a copy of and authenticates the bits that "belong"
> to it. This would even be necessary to avoid compromise.
> One could pick the copy to use for filter generation or even
> query them all and implement a majority decision if there are
> discrepancies.
> Of course it would require all RIRs to use the same RPSL format
> but that appears more of a political than a technical problem.



We already have that “central IRR” in the form of the likes of the RADB
Whois server. RIPE’s data is the odd one out here.

RIPE is the _only_ IRR source where we cannot differentiate between
authenticated data and non-authenticated data.

For all other sources we know that either the route objects have been
authenticated against the inetnum’s specified maintainer (APNIC, AFRINIC,
JPIRR) or is entirely without such verification (ARIN, NTTCOM, ALTDB, RADB
itself, etc).

The value of the data in the RIPE DB would significantly increase if this
difference is shown.

Kind regards,

Job

>
--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Sascha Luck [ml] via db-wg]

--- Begin Message ---

On Wed, Oct 11, 2017 at 11:30:06AM -0300, Carlos M. Martinez wrote:

IMHO, any idea that starts with ???Let??s create a central X??? is doomed from 
the start.

We must think along other lines.


Maybe "central" was the wrong word to use. Think a DB that every
RIR provides a copy of and authenticates the bits that "belong"
to it. This would even be necessary to avoid compromise. 
One could pick the copy to use for filter generation or even

query them all and implement a majority decision if there are
discrepancies.
Of course it would require all RIRs to use the same RPSL format
but that appears more of a political than a technical problem.

cheers,
Sascha Luck


--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Carlos M. Martinez via db-wg]

--- Begin Message ---
IMHO, any idea that starts with “Let´s create a central X” is 
doomed from the start.


We must think along other lines.

/Carlos

On 11 Oct 2017, at 11:21, Sascha Luck [ml] via db-wg wrote:


From: Sascha Luck [ml] <d...@c4inet.net>

To: denis walker <ripede...@yahoo.co.uk>

Cc: Database WG <db-wg@ripe.net>

					Subject: Re: [db-wg] Foreign ROUTE objects in RIPE Database - 
final decision?


Date: October 11, 2017 at 11:21 AM




On Mon, Oct 09, 2017 at 02:49:39PM +0100, denis walker via db-wg 
wrote:



Question - Should the RIPE Database allow creation of ROUTE objects 
for non RIPE resources?



Is an option D: create a central IRRDB with authentication hooks
into all RIRs completely out of the question? It certainly sounds
like the technologically most elegant answer. Modulo legacy
resources, no unauthenticated irrdb objects should then have to
exist. The trust root could be shared between the RIRs as is
seemingly done with RPKI these days...

cheers,
Sascha Luck


--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Nick Hilliard via db-wg]

--- Begin Message ---
Sascha Luck [ml] wrote:
> How does this fact falsify the fact that cross-RIR route: objects
> exist? Those have to be in *some* irrdb and as long as a
> cross-RIR irrdb doesn't exist, part of the data will be
> non-authenticated...

it doesn't say anything about cross-RIR route: objects, and you're
correct to point out that parsing IRRDB objects is difficult to do well.

There are a couple of different approaches which we have found to work
reasonably well in practice.  One is to use whois.radb.net and carefully
specify the source: list.  Another would be to run your own private
whois server and get NTRM copies of the IRRDBs that you're interested in.

Another still (the version used in recent versions of IXP Manager) is to
poll the IRRDBs for the list of objects you're interested in, then
select them in a local db of some form. This gives very high
performance, high flexibility / functionality, but comes at a cost of
more coding.

Defaulting to using whois.radb.net is a reasonable compromise, but it
has its limitations.

In other words, removing foreign route objects from any specific irrdb
doesn't change any requirements for your irrdb code, because if you're
pulling in irrdb prefix lists from arbitrary ASNs, there is already a
requirement to poll multiple irrdbs.

If your irrdb polling mechanism doesn't handle this, and doesn't support
the option to have per-peer IRRDB policies (for both whois servers and
source: specifications), it will break.  We tried it and ran that
particular boat up on the rocks.

Nick


--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Randy Bush via db-wg]

--- Begin Message ---
> Also, what would the distinguisher be for eg. a route: with prefix
> from RIPE and ASN from ARIN?

thanks to the inability to inter-region transfer as-nums, that is
exactly my situation :)

randy

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Sascha Luck [ml] via db-wg]

--- Begin Message ---

On Wed, Oct 11, 2017 at 02:46:54PM +0100, Nick Hilliard via db-wg wrote:

Job Snijders wrote:

I think this touches upon an incredibly important question: how do we
distinguish between garbage and properly authenticated "route:"
objects covering RIPE-managed space?


and more to the point: are there good reasons and community support for
continuing not to distinguish between the two.


Well, distinguishing in the irrdb is one thing, but how would you
distinguish between them in RealLife(tm)? It's not like you can
not route/accept a cross-RIR route: object (at least not without
Breaking The Internet)
Also, what would the distinguisher be for eg. a route: with
prefix from RIPE and ASN from ARIN? RIPE-PARTIALLY-AUTHENTICATED?  


cheers,
Sascha Luck

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Randy Bush via db-wg]

--- Begin Message ---
 Question - Should the RIPE Database allow creation of ROUTE objects
 for non RIPE resources?
>> 
>> yes
> 
> then how can we use the traditional irrdb to distinguish between address
> blocks which have been authenticated by the ripe ncc and those which
> have not.

as you said, it would be good to have an strongly authenticated
ownership which could assert routing.  try the rpki; works across
all regions.

a least it's a more credible argument than thinking encouraging ipv4
run-out will increase ipv6, as opposed to nat, uptake. < dripping
sarcasm >

randy

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Nick Hilliard via db-wg]

--- Begin Message ---
Randy Bush via db-wg wrote:
>> > Question - Should the RIPE Database allow creation of ROUTE objects
>> > for non RIPE resources?
> 
> yes

then how can we use the traditional irrdb to distinguish between address
blocks which have been authenticated by the ripe ncc and those which
have not.

Nick


--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Randy Bush via db-wg]

--- Begin Message ---
> But this time we do need numbers.

voting, eh?

> Question - Should the RIPE Database allow creation of ROUTE objects
> for non RIPE resources?

yes

randy

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Lu Heng via db-wg]

--- Begin Message ---
On Tue, Oct 10, 2017 at 18:33 Sander Steffann via db-wg 
wrote:

> Hi,
>
> > In any case, given that we have no proper global registry, and we have
> > lots of cross-region routes ("addresses from RIR A, AS number from RIR
> B"),
> > we need to find a way to document these properly.
>
> My preference would be to start such a global registry. I would love it if
> at least RIPE, APNIC and AFRINIC (who all use very similar data models
> IIRC) could combine databases. Having separate (but in reality partially
> overlapping) databases for a global resource will always result in
> discussions like we have had over the last two+ years IMHO. Let's make an
> effort to form a single point of reference.
>
+1

>
> Cheers,
> Sander
>
>
> --
--
Kind regards.
Lu
--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Sander Steffann via db-wg]

--- Begin Message ---
Hi,

> In any case, given that we have no proper global registry, and we have
> lots of cross-region routes ("addresses from RIR A, AS number from RIR B"),
> we need to find a way to document these properly.

My preference would be to start such a global registry. I would love it if at 
least RIPE, APNIC and AFRINIC (who all use very similar data models IIRC) could 
combine databases. Having separate (but in reality partially overlapping) 
databases for a global resource will always result in discussions like we have 
had over the last two+ years IMHO. Let's make an effort to form a single point 
of reference.

Cheers,
Sander


--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Nick Hilliard via db-wg]

--- Begin Message ---
Sascha Luck [ml] via db-wg wrote:
> Not allowing
> "foreign" resources in the ripedb denies the reality that there
> will always be RIPE-allocated prefixes originated from
> non-RIPE-assigned ASNs and vice versa.

Not true - you can easily run a whois query on whois.radb.net specifying
multiple sources, including RIPE:

% bgpq3 -S RIPE,APNIC,LACNIC AS-FOO

In fact, there is no way of writing a functioning irrdb querier which
can't handle specifying arbitrary irrdb source: options on a per-ASN basis.

Nick

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Gert Doering via db-wg]

--- Begin Message ---
Hi,

On Mon, Oct 09, 2017 at 03:48:43PM +0200, denis walker via db-wg wrote:
> Question - Should the RIPE Database allow creation of ROUTE objects for non 
> RIPE resources?

I wonder if this is the right question to ask, or we should step back
and ask the question

   what can we do to provide a secure routing registry where people
   can document "this prefix will be announced by that AS" in a way
   that is a) strongly authenticated (= only the current holder of the
   address space can create such a route: object), and b) easy to use
   for people building filters (= not having to walk 5 different IRRDBs
   to find the set of prefixes announced by a possible customer)?

instead?  A, B or C may be a consequence of this.


In any case, given that we have no proper global registry, and we have
lots of cross-region routes ("addresses from RIR A, AS number from RIR B"),
we need to find a way to document these properly.

From a user perspective, I like to have all route: objects for my customers
in a single place (RIPE BD, that is), so for me, "A" would be most convenient
- but we need to add some sort of cross-RIR authentication layer.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AGVorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279


signature.asc
Description: PGP signature
--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Hank Nussbacher via db-wg]

--- Begin Message ---
On 09/10/2017 18:22, denis walker via db-wg wrote:

C


-Hank


--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Alexander Stranzky via db-wg]

--- Begin Message ---
personal opinion: I don't care as a programmer.

company's opinion: A - all our network resources are routed solely
through our RIPE-AutNum.


-- 
velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * D-63452 Hanau
Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588
Tel: +49 6181 1898119 * http://www.velia.net
Follow us on twitter: https://twitter.com/velia_net

--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Clement Cavadore via db-wg]

--- Begin Message ---
Hello Denis, WG

On Mon, 2017-10-09 at 15:49 +0200, denis walker via db-wg wrote:
> A: Yes the RIPE Database should allow creation of ROUTE objects for
> non RIPE resources. If this is the answer then we can look at how to
> make the data more trusting in the short term (and there may be ways
> to do that).

That one, but with a *strong* enhancement on a trust model for such
objects. We just cannot simply allow non-ripe route objects to be
inserted in the db without any legitimity checks.

-- 
Clément Cavadore


--- End Message ---

Re: [db-wg] Foreign ROUTE objects in RIPE Database - final decision?

[Lu Heng via db-wg]

--- Begin Message ---
A

On Mon, Oct 9, 2017 at 21:48 denis walker via db-wg  wrote:

> Colleagues
>
> This has been discussed many times with many views expressed. We are sure
> lots of you are bored with commenting on this issue. Unfortunately no
> consensus has yet been found. So we would like to take it back to the basic
> question and see if we can get a conclusive answer. This is not a question
> specifically about the Afrinic homing project. It's a more general question
> about the RIPE Database providing this 'feature'. Even if you have
> commented before, please do so once more so we can get a definitive answer
> to this question. I know there is a tendency to say nothing if someone else
> has made the point you support. But this time we do need numbers. So even
> if what you are thinking has been said, please at least add a +1 so we know
> you also agree with that point.
>
> Question - Should the RIPE Database allow creation of ROUTE objects for
> non RIPE resources?
>
> We see three most likely answers to this question. Each possible answer
> does have consequences.
>
> A: Yes the RIPE Database should allow creation of ROUTE objects for non
> RIPE resources. If this is the answer then we can look at how to make the
> data more trusting in the short term (and there may be ways to do that).
>
> B: No the RIPE Database should not allow creation of ROUTE objects for any
> non RIPE resource. If this is the answer then maybe we need to look at a
> project to remove all non RIPE resource related ROUTE(6)/AUT-NUM objects
> from the RIPE Database and disable the feature. But that needs to look at
> what to do with ROUTE objects for prefixes from one region and ASNs from a
> different region.
>
> C: Just leave things as they are. Don't promote the service but no
> projects to remove any data from the RIPE Database either. Just drift along
> on the principle "if it ain't broken, don't fix it". This also means
> document this as the answer to this question and no more discussions. Of
> course any problems associated with this feature don't go away.
>
>
> I will briefly review the discussions over the last 2 years:
>
> At the update given at RIPE 72 for the removal of the data starting with
> the Afinic homing project, there was no consensus and a call for more
> comments on the mailing list. A discussion continued on the mailing list
> until October. There was both support and opposition to removing these
> objects from the RIPE Database. One point raised during this discussion
> regarding the Afrinic homing project was, "I believe that what is needed
> here most of all is a clear message from both communities that it is
> desirable to have the ROUTE(6) objects for AFRINIC space in the AFRINIC IRR
> where the registered resource holders can properly authorise objects." No
> one has yet referred to a declared consensus of opinion by the Afrinic
> community to the removal of these objects from the RIPE Database. Also
> during this discussion Afrinic said that they have not yet worked out all
> the fine details of the proposed move of this data. Several issues were
> raised on the technicalities of moving this data and it was said in the
> discussion that no one has yet even done the analysis to see if any of
> these conditions exist (like duplicate, but different data in both
> databases).
>
> At the update given at RIPE 73, there was still no consensus. The RIPE NCC
> and Afrinic were asked to do a check on what could go wrong and who members
> could contact in the event of things going wrong. This doesn't seem to have
> been done. The RIPE NCC suggested they may be able to produce a video or
> webinar about the transfer. This doesn't seem to have been done either. The
> call was again made that both the RIPE and Afrinic communities re-state
> that they both want this project to go forward. That has not happened. It
> was said that Afrinic is the first of many RIRs that may want data
> transferred out of the RIPE Database. Is it the RIRs or the communities
> that want this? The only question raised in the meeting was opposed to the
> transfer. No discussion followed on the mailing list.
>
> At RIPE 74 there was no update on this issue.
>
> The next discussion wasn't until July 2017. In this discussion there was
> mention of developing a global IRR database with a couple of supporters. We
> all know such ideas often take years to be agreed on, designed and
> implemented as a practical solution. We want to answer this question in
> relation to the situation today. There were some pointers made back to
> previous mailing list discussions, but nothing else new was said.
>
> cheers
> denis
> co-chair DB WG
>
-- 
--
Kind regards.
Lu
--- End Message ---