Hierarchical authorisation failed, request forwarded to maintaine r ???
Hi all, can somebody tell me why this update failed? inet-num maintainer is NONE and AS maintainer is ours ! This is an ARIN /16 network, but the /22 part of it is announced in the RIPE region.. thanks for your help!! Marcus Ruchti New FAILED: [route] 143.58.120.0/22 Hierarchical authorisation failed, request forwarded to maintainer. route: 143.58.120.0/22 descr: MAYER, BROWN, ROWE & MAW GAEDERTZ descr: ***routed per request*** origin: AS8220 mnt-by: DE-COLT-MNT changed: markb@de.colt.net 20020813 source: RIPE inetnum: 0.0.0.0 - 255.255.255.255 netname: IANA-BLK descr: The whole IPv4 address space country: NL admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED remarks: The country is really worldwide. remarks: This address space is assigned at various other places in remarks: the world and might therefore not be in the RIPE database. mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT changed: bitbucket@ripe.net 20010529 changed: bitbucket@ripe.net 20020625 source: RIPE route: 143.58.120.0/22 descr: MBRG-FFM origin: AS3320 mnt-by: DTAG-RR changed: mbt@nic.dtag.de 20020619 source: RIPE route: 143.58.120.0/23 descr: MBRG-FFM origin: AS8354 notify: info@twinwave.net mnt-by: TWINWAVE-MNT changed: g.cipollone@twinwave.net 20020417 source: RIPE role: Internet Assigned Numbers Authority address: see http://www.iana.org. e-mail: bitbucket@ripe.net admin-c: IANA1-RIPE tech-c: IANA1-RIPE nic-hdl: IANA1-RIPE remarks: For more information on IANA services remarks: go to IANA web site at http://www.iana.org. mnt-by: RIPE-NCC-MNT changed: bitbucket@ripe.net 20010411 source: RIPE Marcus Ruchti Internet Systemingenieur mailto:marcus.ruchti@colt.de COLT TELECOM GmbH Herriotstr. 4 D-60528 Frankfurt Fon: +49 (0) 69 / 5 66 06 - 6351 Fax: +49 (0) 69 / 5 66 06 - 6350
Marcus Ruchti, The problem is that there is an existing route object: route: 143.58.120.0/22 descr: MBRG-FFM origin: AS3320 mnt-by: DTAG-RR changed: mbt@nic.dtag.de 20020619 source: RIPE Most objects are uniquely identified by the first attribute, or "route:" in this case. However, you must include the "origin:" attribute for a route object. So this is: route: 143.58.120.0/22 origin: AS3320 The object you are trying to create will be: route: 143.58.120.0/22 origin: AS8220 Because the "origin:" is different, this is a new route. You must either: 1. Delete the old route and then create the new one. 2. Authorise the creation via both the DTAG-RR and DE-COLT-MNT maintainers (DTAG-RR from the old route, and DE-COLT-MNT from the new route). If you do not have authorisation to do this, you'll have to coordinate with the DTAG-RR maintainer. If this maintainer is unresponsive, please contact RIPE DBM at <ripe-dbm@ripe.net>. The rules for route creation can be seen here: http://www.ripe.net/ripencc/faq/database/route-creation-checks.html Note that, in general, questions about specific operations should be sent to either the mailing list <db-help@ripe.net> or the role account <ripe-dbm@ripe.net>. Good luck! -- Shane Kerr RIPE NCC On 2002-10-11 15:00:17 +0200, Marcus.Ruchti@colt.de wrote:
Hi all,
can somebody tell me why this update failed?
inet-num maintainer is NONE and AS maintainer is ours !
This is an ARIN /16 network, but the /22 part of it is announced in the RIPE region..
thanks for your help!!
Marcus Ruchti
New FAILED: [route] 143.58.120.0/22 Hierarchical authorisation failed, request forwarded to maintainer. route: 143.58.120.0/22 descr: MAYER, BROWN, ROWE & MAW GAEDERTZ descr: ***routed per request*** origin: AS8220 mnt-by: DE-COLT-MNT changed: markb@de.colt.net 20020813 source: RIPE
inetnum: 0.0.0.0 - 255.255.255.255 netname: IANA-BLK descr: The whole IPv4 address space country: NL admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED remarks: The country is really worldwide. remarks: This address space is assigned at various other places in remarks: the world and might therefore not be in the RIPE database. mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-NONE-MNT changed: bitbucket@ripe.net 20010529 changed: bitbucket@ripe.net 20020625 source: RIPE
route: 143.58.120.0/22 descr: MBRG-FFM origin: AS3320 mnt-by: DTAG-RR changed: mbt@nic.dtag.de 20020619 source: RIPE
route: 143.58.120.0/23 descr: MBRG-FFM origin: AS8354 notify: info@twinwave.net mnt-by: TWINWAVE-MNT changed: g.cipollone@twinwave.net 20020417 source: RIPE
role: Internet Assigned Numbers Authority address: see http://www.iana.org. e-mail: bitbucket@ripe.net admin-c: IANA1-RIPE tech-c: IANA1-RIPE nic-hdl: IANA1-RIPE remarks: For more information on IANA services remarks: go to IANA web site at http://www.iana.org. mnt-by: RIPE-NCC-MNT changed: bitbucket@ripe.net 20010411 source: RIPE
Marcus Ruchti Internet Systemingenieur
mailto:marcus.ruchti@colt.de COLT TELECOM GmbH Herriotstr. 4 D-60528 Frankfurt Fon: +49 (0) 69 / 5 66 06 - 6351 Fax: +49 (0) 69 / 5 66 06 - 6350
Hi Shane, On Mon, Oct 14, 2002 at 10:23:14AM +0200, Shane Kerr wrote:
The rules for route creation can be seen here:
http://www.ripe.net/ripencc/faq/database/route-creation-checks.html
Why can't the robot give a specific reply, WHICH authorization(s) failed? Best regards, Daniel
On 2002-10-14 10:28:59 +0200, Daniel Roesen wrote:
Hi Shane,
On Mon, Oct 14, 2002 at 10:23:14AM +0200, Shane Kerr wrote:
The rules for route creation can be seen here:
http://www.ripe.net/ripencc/faq/database/route-creation-checks.html
Why can't the robot give a specific reply, WHICH authorization(s) failed?
It should, and in fact we are working on a restructuring of the robot that does this processing right now. One of the goals of that project is to provide more helpful results to users, including a full transaction report of which objects were checked for authorisation and which ones passed and failed. -- Shane Kerr RIPE NCC
On Mon, Oct 14, 2002 at 10:38:28AM +0200, Shane Kerr wrote:
It should, and in fact we are working on a restructuring of the robot that does this processing right now. One of the goals of that project is to provide more helpful results to users, including a full transaction report of which objects were checked for authorisation and which ones passed and failed.
Thanks, excellent! Best regards, Daniel
Hi, On Mon, Oct 14, 2002 at 10:23:14AM +0200, Shane Kerr wrote:
Most objects are uniquely identified by the first attribute, or "route:" in this case. However, you must include the "origin:" attribute for a route object. So this is:
route: 143.58.120.0/22 origin: AS3320
The object you are trying to create will be:
route: 143.58.120.0/22 origin: AS8220
Shane, your explanation is confusing me. There are other examples with "same route, different origin AS" in the RIPE-DB (check 194.97.0.0/16), which is sometimes necessary while migrating a network to a new origin AS. So the database should permit entry of this *new* object, instead of checking for modification permission on the *existing* object. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48282 (47686) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On 2002-10-14 10:37:37 +0200, Gert Doering wrote:
Hi,
On Mon, Oct 14, 2002 at 10:23:14AM +0200, Shane Kerr wrote:
Most objects are uniquely identified by the first attribute, or "route:" in this case. However, you must include the "origin:" attribute for a route object. So this is:
route: 143.58.120.0/22 origin: AS3320
The object you are trying to create will be:
route: 143.58.120.0/22 origin: AS8220
Shane, your explanation is confusing me. There are other examples with "same route, different origin AS" in the RIPE-DB (check 194.97.0.0/16), which is sometimes necessary while migrating a network to a new origin AS.
So the database should permit entry of this *new* object, instead of checking for modification permission on the *existing* object.
We currently implement RPSS, as best we understand it. I think the idea is that if there is a route object in the database, then it's creation has been authorised, and that it represents an actual route announcement. If somebody else starts advertising either the same IP space with a different origin, or a more specific route then it will affect traffic to the existing origin, so they should approve the creation. Given this explanation, do you still think that the database should permit the creation of the new object? The reality is that route checking is not 100% clear in the RPSS document, RFC 2725. For instance, when creating a route it is possible to have multiple parent routes with the same prefix, and it is not specified what the behaviour is. I believe it was decided not to look at this too carefully because some people in the IETF have decided that advertising the same prefix from multiple origin AS numbers is bad, and the authors of the document wanted to avoid a flame-war or even having the document rejected over this issue. -- Shane Kerr RIPE NCC
Hi, On Mon, Oct 14, 2002 at 10:50:00AM +0200, Shane Kerr wrote:
Shane, your explanation is confusing me. There are other examples with "same route, different origin AS" in the RIPE-DB (check 194.97.0.0/16), which is sometimes necessary while migrating a network to a new origin AS.
So the database should permit entry of this *new* object, instead of checking for modification permission on the *existing* object.
We currently implement RPSS, as best we understand it.
I won't claim that I understand RPSS, but I claim to have observed actual practice :-)
I think the idea is that if there is a route object in the database, then it's creation has been authorised, and that it represents an actual route announcement. If somebody else starts advertising either the same IP space with a different origin, or a more specific route then it will affect traffic to the existing origin, so they should approve the creation.
Given this explanation, do you still think that the database should permit the creation of the new object?
Yes. I think that the creation of the new route: should NOT check the authorization on any existing route: objects, but should check mnt-routes: on the corresponding/encompassing inetnum: and on the AS-Object. "Unauthorized routes" should be sufficiently prevented by the inetnum: check. Yes, I am aware that this doesn't work for inetnum:s registered in a different database, unless distributed rps-auth is implemented. I do not have a proposal how to solve this in the mean time. [..]
The reality is that route checking is not 100% clear in the RPSS document, RFC 2725. For instance, when creating a route it is possible to have multiple parent routes with the same prefix, and it is not specified what the behaviour is. I believe it was decided not to look at this too carefully because some people in the IETF have decided that advertising the same prefix from multiple origin AS numbers is bad, and the authors of the document wanted to avoid a flame-war or even having the document rejected over this issue.
I agree with them - I think multiple different origin ASes *are* bad. Nevertheless migration of routes happen (think of "address space already allocated, AS number still in queue" or "address space already being used, but BGP not yet fully working at customer's site"). Sometimes, there might be other good reasons for multiple route: objects. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48282 (47686) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, Gert Doering wrote: [...]
We currently implement RPSS, as best we understand it.
I won't claim that I understand RPSS, but I claim to have observed actual practice :-)
I think the idea is that if there is a route object in the database, then it's creation has been authorised, and that it represents an actual route announcement. If somebody else starts advertising either the same IP space with a different origin, or a more specific route then it will affect traffic to the existing origin, so they should approve the creation.
Given this explanation, do you still think that the database should permit the creation of the new object?
Yes. I think that the creation of the new route: should NOT check the authorization on any existing route: objects, but should check mnt-routes: on the corresponding/encompassing inetnum: and on the AS-Object.
"Unauthorized routes" should be sufficiently prevented by the inetnum: check.
I personally agree with you. There are a few reasons why it should be done the way you described. Unfortunately, that is definitely not what RFC2725 specifies. In order to change the behaviour we probably have to bring this up at IETF and update the spec.
Yes, I am aware that this doesn't work for inetnum:s registered in a different database, unless distributed rps-auth is implemented. I do not have a proposal how to solve this in the mean time.
We are working on such proposal, which is less complex than rps-dist. We discussed this with other RIRs as they are store authoritative information about address allocations. [...] Regards, Andrei Robachevsky RIPE NCC
On Mon, Oct 14, 2002 at 10:37:37AM +0200, Gert Doering wrote:
Shane, your explanation is confusing me. There are other examples with "same route, different origin AS" in the RIPE-DB (check 194.97.0.0/16), which is sometimes necessary while migrating a network to a new origin AS.
Yes, and this needs authorization from both ASN maintainers. The usual way is to have ISP2 send an PGP-signed route object to ISP1 which then sends it with his additional PGP signature to RIPE. Worked several times for us.
So the database should permit entry of this *new* object, instead of checking for modification permission on the *existing* object.
No. Because that allows hijacking under some circumstances. Regards, Daniel
Hi, On Mon, Oct 14, 2002 at 10:51:15AM +0200, Daniel Roesen wrote:
On Mon, Oct 14, 2002 at 10:37:37AM +0200, Gert Doering wrote:
Shane, your explanation is confusing me. There are other examples with "same route, different origin AS" in the RIPE-DB (check 194.97.0.0/16), which is sometimes necessary while migrating a network to a new origin AS.
Yes, and this needs authorization from both ASN maintainers.
Why? If you have authoritation from the owner of the inetnum:, that should be sufficient. [..]
So the database should permit entry of this *new* object, instead of checking for modification permission on the *existing* object. No. Because that allows hijacking under some circumstances.
No. The inetnum:/mnt-routes: check prevent hijacking (if the inetnum: is in the same database - if not, the check on the route: object doesn't prevent putting a competing route: object into some other IRR DB). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 48282 (47686) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (5)
-
Andrei Robachevsky -
Daniel Roesen -
Gert Doering -
Marcus.Ruchti＠colt.de -
Shane Kerr