You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

Database Working Group

Threaded
Collapse

[db-wg] RIPE DB Route Object fails creation

Sascha E. Pollok

2020-06-11 01:31:02 CET

Dear friendly DB people,

here is a problem I don't find easy to solve. Would you assist me in understanding the
constraints?

Customer has a /22 network 194.76.156.0/22 with the proper inetnum object. The inetnum
objects has a mnt-by: IPHH-NOC and mnt-routes: IPHH-NOC.

A route object exists but with a different maintainer:

route:          194.76.156.0/22
descr:          CMELCHERS-QSC-NET
descr:          via Plusnet
origin:         AS20676
mnt-by:         PLUSNET-NOC     <<<---- not IPHH-NOC

We are now trying to create an additional route object for a different ASN:

route:          194.76.156.0/22
descr:          C. Melchers via MEKO-S
origin:         AS207630
mnt-by:         IPHH-NOC    <<<--- This is the maintainer in the inetnum object
source:         RIPE

The RIPE DB refuses the update:

Create FAILED: [route] 194.76.156.0/24AS207630
route:          194.76.156.0/24
descr:          C. Melchers via MEKO-S
descr:          belongs to 194.76.156.0/22
origin:         AS207630
mnt-by:         IPHH-NOC
source:         RIPE
***Error:   Authorisation for [route] 194.76.156.0/22AS20676 failed
            using "mnt-by:"
            not authenticated by: PLUSNET-NOC

So the DB expects the maintainer from the other route object. But I don't understand why
the mnt-routes in the inetnum-object doesnt give preference over the maintainer on a
different route-object.

Anyone who could share their honest opinion?

Cheers
Sascha

ripedenis@yahoo.co.uk

2020-06-11 04:26:29 CET

 Hi Sascha
If there is an existing, exact matching ROUTE object the creation of the new ROUTE object must be authorised by the existing object. There is a flow chart here explaining the sequence of checks:https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/route-object-creation-flowchart.pdf

If you want to 'replace' the existing ROUTE object the maintainer of the less specific INETNUM allocation object can delete the existing ROUTE object using the authorisation of the allocation object. This is explained here:https://www.ripe.net/manage-ips-and-asns/db/support/managing-route-objects-in-the-irr#4--reclaiming-access-to-blocking-route-objects

cheersdenis
co-chair DB-WG


    On Thursday, 11 June 2020, 01:31:36 CEST, Sascha E. Pollok via db-wg <db-wg _at_ ripe _dot_ net> wrote:  
 
 Dear friendly DB people,

here is a problem I don't find easy to solve. Would you assist me in understanding the
constraints?

Customer has a /22 network 194.76.156.0/22 with the proper inetnum object. The inetnum
objects has a mnt-by: IPHH-NOC and mnt-routes: IPHH-NOC.

A route object exists but with a different maintainer:

route:          194.76.156.0/22
descr:          CMELCHERS-QSC-NET
descr:          via Plusnet
origin:        AS20676
mnt-by:        PLUSNET-NOC    <<<---- not IPHH-NOC

We are now trying to create an additional route object for a different ASN:

route:          194.76.156.0/22
descr:          C. Melchers via MEKO-S
origin:        AS207630
mnt-by:        IPHH-NOC    <<<--- This is the maintainer in the inetnum object
source:        RIPE

The RIPE DB refuses the update:

Create FAILED: [route] 194.76.156.0/24AS207630
route:          194.76.156.0/24
descr:          C. Melchers via MEKO-S
descr:          belongs to 194.76.156.0/22
origin:        AS207630
mnt-by:        IPHH-NOC
source:        RIPE
***Error:  Authorisation for [route] 194.76.156.0/22AS20676 failed
            using "mnt-by:"
            not authenticated by: PLUSNET-NOC

So the DB expects the maintainer from the other route object. But I don't understand why
the mnt-routes in the inetnum-object doesnt give preference over the maintainer on a
different route-object.

Anyone who could share their honest opinion?

Cheers
Sascha

  
User Image

Tom Hill

2020-06-11 14:28:16 CET

Hello,

On 11/06/2020 03:26, ripedenis--- via db-wg wrote:
> If there is an existing, exact matching ROUTE object the creation of the
> new ROUTE object must be authorised by the existing object. There is a
> flow chart here explaining the sequence of checks:
> https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/route-object-creation-flowchart.pdf

This comes up a lot, particularly with PI space. It confused the hell
out of me when I first had to decipher that flow chart, and I realised
recently that I hadn't looked at it for long enough that it had once
again fallen out of my head.

> ***Error:   Authorisation for [route] 194.76.156.0/22AS20676 failed
>             using "mnt-by:"
>             not authenticated by: PLUSNET-NOC

Could we reduce the confusion, and/or spread some more clue, by being
more specific with this error? e.g.

Authorisation for [blah] failed using "mnt-by:"
 - matching route object already exists
 - not authenticated by: PLUSNET-NOC


Regards,

-- 
Tom

User Image

Gert Doering

2020-06-11 15:27:43 CET

Hi,

On Thu, Jun 11, 2020 at 01:28:16PM +0100, Tom Hill via db-wg wrote:
> On 11/06/2020 03:26, ripedenis--- via db-wg wrote:
> > ***Error:   Authorisation for [route] 194.76.156.0/22AS20676 failed
> >             using "mnt-by:"
> >             not authenticated by: PLUSNET-NOC
> 
> Could we reduce the confusion, and/or spread some more clue, by being
> more specific with this error? e.g.
> 
> Authorisation for [blah] failed using "mnt-by:"
>  - matching route object already exists
>  - not authenticated by: PLUSNET-NOC

And, while at it, can someone enlighten me why this is actually a
desirable characteristic?

If the owner of the inetnum and the owner of the aut-num agree about
the creation of a new route: object, why is the owner of an existing
route: object relevant?

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

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

Job Snijders

2020-06-11 15:30:23 CET

On 11/06/2020 03:26, ripedenis--- via db-wg wrote:
> If there is an existing, exact matching ROUTE object the creation of the
> new ROUTE object must be authorised by the existing object. There is a
> flow chart here explaining the sequence of checks:
> https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/route-object-creation-flowchart.pdf

Ah - great pointer. thanks.

Denis, do you remember *why* that is the rule?

I don't see a lot of benefit to requiring the existing object to
authorise the creation of a *new* object, when the new object is
authorised by the inetnum (in this case both through mnt-routes: and
mnt-by:).

>>  ***Error:   Authorisation for [route] 194.76.156.0/22AS20676 failed
>>  using "mnt-by:" not authenticated by: PLUSNET-NOC
>
> Could we reduce the confusion, and/or spread some more clue, by being
> more specific with this error? e.g.
>
>    Authorisation for [blah] failed using "mnt-by:"
>     - matching route object already exists
>     - not authenticated by: PLUSNET-NOC

Perhaps instead of an error message, the operation that Sasha tried to
do should just be allowed?

Kind regards,

Job

User Image

Cynthia Revström

2020-06-11 15:42:54 CET

Hi,

I have to agree with Job, I don't see any real benefit to requiring the
existing route's maintainer's authorization if the creation is authorized
by mnt-routes on the inetnum.

- Cynthia

On Thu, Jun 11, 2020 at 3:30 PM Job Snijders via db-wg <db-wg _at_ ripe _dot_ net>
wrote:

> On 11/06/2020 03:26, ripedenis--- via db-wg wrote:
> > If there is an existing, exact matching ROUTE object the creation of the
> > new ROUTE object must be authorised by the existing object. There is a
> > flow chart here explaining the sequence of checks:
> >
> https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/route-object-creation-flowchart.pdf
>
> Ah - great pointer. thanks.
>
> Denis, do you remember *why* that is the rule?
>
> I don't see a lot of benefit to requiring the existing object to
> authorise the creation of a *new* object, when the new object is
> authorised by the inetnum (in this case both through mnt-routes: and
> mnt-by:).
>
> >>  ***Error:   Authorisation for [route] 194.76.156.0/22AS20676 failed
> >>  using "mnt-by:" not authenticated by: PLUSNET-NOC
> >
> > Could we reduce the confusion, and/or spread some more clue, by being
> > more specific with this error? e.g.
> >
> >    Authorisation for [blah] failed using "mnt-by:"
> >     - matching route object already exists
> >     - not authenticated by: PLUSNET-NOC
>
> Perhaps instead of an error message, the operation that Sasha tried to
> do should just be allowed?
>
> Kind regards,
>
> Job
>
>
User Image

Tom Hill

2020-06-11 15:43:29 CET

On 11/06/2020 14:17, Job Snijders wrote:
>>> ***Error:   Authorisation for [route] 194.76.156.0/22AS20676 failed
>>>             using "mnt-by:"
>>>             not authenticated by: PLUSNET-NOC
>> Could we reduce the confusion, and/or spread some more clue, by being
>> more specific with this error? e.g.
>>
>> Authorisation for [blah] failed using "mnt-by:"
>>  - matching route object already exists
>>  - not authenticated by: PLUSNET-NOC
> Perhaps instead of an error message, the operation that Sasha tried to
> do should just be allowed?

Because of the following (stunningly regular) corner case:

1. PI space owner doesn't understand what the implications are of
migrating prefixes between origins/networks, or dual-homing from two
networks

2. New origin/network creates route without the knowledge of the
existing origin/network provider (whom are often different providers)

3. Customer blames existing origin/network for breaking their traffic
routing, whom had no idea anything was going on

Having that route object check at the beginning of the flow chart
ensures that all parties required to provide service, are aware of the
changes to advertisements & can properly prepare their networks/customer
networks, and prevent outages.

If all our customers knew exactly what they were doing, they'd usually
be running their own BGP AS and handling their own announcements,
resilience, and/or migrations.

Regards,

-- 
Tom

Pierre Baume

2020-06-11 16:00:16 CET

Dear Sascha (and Colleagues),

  The error message that you quote is for a /24 (more specific) route, not
the /22 route that you say you're attempting to create.

  I hope that helps.

  Kind regards.

Pierre.


On Thu, Jun 11, 2020 at 1:32 AM Sascha E. Pollok via db-wg <db-wg _at_ ripe _dot_ net>
wrote:

> Dear friendly DB people,
>
> here is a problem I don't find easy to solve. Would you assist me in
> understanding the
> constraints?
>
> Customer has a /22 network 194.76.156.0/22 with the proper inetnum
> object. The inetnum
> objects has a mnt-by: IPHH-NOC and mnt-routes: IPHH-NOC.
>
> A route object exists but with a different maintainer:
>
> route:          194.76.156.0/22
> descr:          CMELCHERS-QSC-NET
> descr:          via Plusnet
> origin:         AS20676
> mnt-by:         PLUSNET-NOC     <<<---- not IPHH-NOC
>
> We are now trying to create an additional route object for a different ASN:
>
> route:          194.76.156.0/22
> descr:          C. Melchers via MEKO-S
> origin:         AS207630
> mnt-by:         IPHH-NOC    <<<--- This is the maintainer in the inetnum
> object
> source:         RIPE
>
> The RIPE DB refuses the update:
>
> Create FAILED: [route] 194.76.156.0/24AS207630
> route:          194.76.156.0/24
> descr:          C. Melchers via MEKO-S
> descr:          belongs to 194.76.156.0/22
> origin:         AS207630
> mnt-by:         IPHH-NOC
> source:         RIPE
> ***Error:   Authorisation for [route] 194.76.156.0/22AS20676 failed
>             using "mnt-by:"
>             not authenticated by: PLUSNET-NOC
>
> So the DB expects the maintainer from the other route object. But I don't
> understand why
> the mnt-routes in the inetnum-object doesnt give preference over the
> maintainer on a
> different route-object.
>
> Anyone who could share their honest opinion?
>
> Cheers
> Sascha
>
>

ripedenis@yahoo.co.uk

2020-06-11 17:16:46 CET

 I have no idea Job. It has been like this for as long as I can remember, maybe at least the last 20 years since we implemented the RPSL version of the RIPE Database.
Tom gave some reasons for it in his reply. The database mechanics simply reflect the policies and practices. There are different options:-error, as it is now-warning that another ROUTE object exists-send notification to existing ROUTE ASN holder-allow creation and do nothing-???
If there is strong feeling that something should be changed or looked at again, maybe you should start a discussion on the best options for these situations on the Routing WG mailing list. The impact of any change is a routing issue. Then come back to DB WG if something needs changing.
cheersdenis
co-chair DB-WG
    On Thursday, 11 June 2020, 15:30:46 CEST, Job Snijders via db-wg <db-wg _at_ ripe _dot_ net> wrote:  
 
 On 11/06/2020 03:26, ripedenis--- via db-wg wrote:
> If there is an existing, exact matching ROUTE object the creation of the
> new ROUTE object must be authorised by the existing object. There is a
> flow chart here explaining the sequence of checks:
> https://www.ripe.net/support/training/material/bgp-operations-and-security-training-course/route-object-creation-flowchart.pdf

Ah - great pointer. thanks.

Denis, do you remember *why* that is the rule?

I don't see a lot of benefit to requiring the existing object to
authorise the creation of a *new* object, when the new object is
authorised by the inetnum (in this case both through mnt-routes: and
mnt-by:).

>>  ***Error:  Authorisation for [route] 194.76.156.0/22AS20676 failed
>>  using "mnt-by:" not authenticated by: PLUSNET-NOC
>
> Could we reduce the confusion, and/or spread some more clue, by being
> more specific with this error? e.g.
>
>    Authorisation for [blah] failed using "mnt-by:"
>    - matching route object already exists
>    - not authenticated by: PLUSNET-NOC

Perhaps instead of an error message, the operation that Sasha tried to
do should just be allowed?

Kind regards,

Job

  
User Image

Rob Evans

2020-06-11 19:07:42 CET

> Denis, do you remember *why* that is the rule?

RFC2725, section 9.9.

He says, retiring to a safe distance... :)

Cheers,
Rob

ripedenis@yahoo.co.uk

2020-06-11 21:21:37 CET

 Hi Rob
RFC2725 only defines the mechanism, which we already know as it still works this way (except for the ASN authorisation). But it does not explain 'why' it is done this way. That was probably discussed in the process of writing RFC2725 :) 
cheersdenis
co-chair DB-WG
    On Thursday, 11 June 2020, 19:08:16 CEST, Rob Evans via db-wg <db-wg _at_ ripe _dot_ net> wrote:  
 
 > Denis, do you remember *why* that is the rule?

RFC2725, section 9.9.

He says, retiring to a safe distance... :)

Cheers,
Rob

  
User Image

Havard Eidnes

2020-06-11 22:16:05 CET

>> Denis, do you remember *why* that is the rule?
>
> RFC2725, section 9.9.
>
> He says, retiring to a safe distance... :)

Heh.

Well, first off, the rule specified in the RFC to require
authentication via the origin aut-num object has been abolished,
so that doesn't apply.

Secondly, is it just me that find the RFC to be sorely lacking in
justification for *why* the maintainer of an exact matching route
object should be used in preference to the inetnum hierarchy
maintainers?  It just says "this will be used first", not why,
neither in section 9.9 nor in appendix C that I can see.

Also, the fact that such a "blocking" route object can be
"forcefully deleted" (via some "special" operation?) based solely
on the inetnum hierarchy maintainers is an indication that this
whole matter hasn't been properly thought through and made
consistent, and this workaround just sounds like a massive kludge
which complicates matters instead of simplifying them.  Also, it
does not exactly help that the error message you get when trying
to add a new route object "could be improved".

Regards,

- Håvard


User Image

Havard Eidnes

2020-06-11 22:30:23 CET

> On 11/06/2020 14:17, Job Snijders wrote:
>>>> ***Error:   Authorisation for [route] 194.76.156.0/22AS20676 failed
>>>>             using "mnt-by:"
>>>>             not authenticated by: PLUSNET-NOC
>>> Could we reduce the confusion, and/or spread some more clue, by being
>>> more specific with this error? e.g.
>>>
>>> Authorisation for [blah] failed using "mnt-by:"
>>>  - matching route object already exists
>>>  - not authenticated by: PLUSNET-NOC
>> Perhaps instead of an error message, the operation that Sasha tried to
>> do should just be allowed?
>
> Because of the following (stunningly regular) corner case:
>
> 1. PI space owner doesn't understand what the implications are of
> migrating prefixes between origins/networks, or dual-homing from two
> networks
>
> 2. New origin/network creates route without the knowledge of the
> existing origin/network provider (whom are often different providers)

Now you lost me.  There is something you're not explicitly saying
here, and that is what negative event occurs when a new route
object with a new origin is registered in the IRR.

The prefix could via this operation be accepted by peers and
upstreams from the new origin AS, through re-generation of filter
lists and installing those on routers.  But as long as the new
origin doesn't actually announce the route, what wrong/unexpected
event would occur?

> 3. Customer blames existing origin/network for breaking their traffic
> routing, whom had no idea anything was going on

Why would simply adding the route object to the IRR break the
customer's routing?  Again, I think there is a pre-condition you
are not stating out loud here, and I think it should be.

Of course, if the new provider doesn't actually have connectivity
to the customer, but still proceeds to announce the route, it's
obvious that will create reachability issues for the customer but
I would not blame the IRR for such utter stupidity in ISP
operations.

> Having that route object check at the beginning of the flow
> chart ensures that all parties required to provide service, are
> aware of the changes to advertisements & can properly prepare
> their networks/customer networks, and prevent outages.

I used to have another perspective, and that is that the
relationship between the customer and the old provider had gone
sour for some reason or other, and that the old provider could
hold the customer hostage by the "blocking" route object.  Then
the "forcefully delete route object via inetnum authorization"
was introduced as an IMHO ugly workaround for this issue.
Besides, going the path from "1 old route object" to "1 new route
object" via a state of "0 matching route objects" doesn't exactly
sound safe to me -- what if filter regeneration somewhere hits in
the time period where there is no matching route object in the
DB?

> If all our customers knew exactly what they were doing, they'd
> usually be running their own BGP AS and handling their own
> announcements, resilience, and/or migrations.

There is some truth to that, but I suspect there's a fair number
of PI holders which don't have their own AS number, and instead
rely on their upstream to originate the route for them.

Regards,

- Håvard