Hi Winfried, if OLD-ISP updates his objects as follows it also will work: route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT mnt-routes: NEW-ISP-MNT source: RIPE # Filtere In this case there is no need for OLD-ISP to insert mnt-by, mnt-routes is sufficient. We often create objects like this. best regards Hermann Ihler _________________________________________ Deutsche Telekom T-Com Headquarters Network Information Center Ammerlaender Heerstrasse 138 DE 26129 Oldenburg +49 441 234 - 4582 (phone) +49 441 234 - 4589 (fax) E-Mail: Hermann.ihler@t-com.net -----Ursprüngliche Nachricht----- Von: Winfried Haug [mailto:wh@germany.com] Gesendet: Mittwoch, 5. April 2006 07:40 An: db-wg@ripe.net Betreff: [db-wg] Adding route objects Hello, we would like to ask the db-wg working group to change the behavior of adding route objects to the ripe database. I had a discussion with someone from ripe during the routing registry course and he told me that ripe could change the way how route objects can be created but this must be decided by the db-wg. We need route-objects for proper routing via bgp4. As customers may change their upstream they need for a certain amount of time more than one route object. The creating of this new route object failes if the old isp does not respond. Let me give you the following example: inetnum: 192.168.230.0 - 192.168.231.255 netname: DUMMY-NET descr: Customer GmbH country: DE org: ORG-AAAAA-RIPE admin-c: AA1 tech-c: AA1 status: ASSIGNED PI mnt-by: RIPE-NCC-HM-PI-MNT mnt-by: CUSTOMER-MNT mnt-by: NEW-ISP-MNT mnt-lower: RIPE-NCC-HM-PI-MNT mnt-routes: OLD-ISP1-MNT mnt-routes: OLD-ISP2-MNT mnt-routes: NEW-ISP-MNT mnt-domains: OLD-ISP1-MNT mnt-domains: OLD-ISP2-MNT mnt-domains: NEW-ISP-MNT source: RIPE # Filtered route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT source: RIPE # Filtered we want now add this object parallel to the existing one: route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS5678 mnt-by: NEW-ISP-MNT source: RIPE # Filtered but fail because: not authenticated by: OLD-ISP1-MNT Thus if OLD-ISP doesnt want for whatever reason help the customer it seems to be that he can block new route objects. This is stupid and can as i know only solved with the help of ripe ncc. It seems to work only if the old isp changed his route object: route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT source: RIPE # Filtered to route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT mnt-by: NEW-ISP-MNT source: RIPE # Filtered I think the owner of the network (inetnum object) should be able to create route objects for his IPs. This would solve the problem. Currently he cant do this because the AS does not have his Maintainer i doubt large ISPs want even for a short period customer maintainer in their AS. To avoid abuse, the db should prevent to alter or create route-objects if there is no maintainer in the inetnum object. If the db will accept new route objects created by those who are maintainer in the inetnum object, the customer can do this without help of the old isp or ripe ncc. Could we have some input and comments from the working group ? Winfried Haug --- Headlight Housing Factory | Rechenzentrum: Azenbergstrasse 35 | Neue Bruecke 8 D-70174 Stuttgart | D-70173 Stuttgart Fon: +49 711 2840 0 | e-mail: wh@headlight.de Fax: +49 711 2840 999 | http://www.headlight.de
Hi, On Wed, Apr 05, 2006 at 08:28:29AM +0200, Ihler, Hermann wrote:
if OLD-ISP updates his objects as follows it also will work:
But that's winfried's point: the old ISP need to actively enable creation of the new route object.
From my gut feeling, I'd say that for route object creation, it should be sufficient if you have authenticated against the maintainer of the inetnum (mnt-by/mnt-routes) and against the maintainer of the new AS.
The old AS might be bankcrupt, not cooperative, or whatever... I'm sure I'm overlooking something, which would explain why it is the way it is...? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Wed, Apr 05, 2006 at 12:32:58PM +0200, Gert Doering wrote:
From my gut feeling, I'd say that for route object creation, it should be sufficient if you have authenticated against the maintainer of the inetnum (mnt-by/mnt-routes) and against the maintainer of the new AS.
I support this proposal.
I'm sure I'm overlooking something, which would explain why it is the way it is...?
Good question, I'm also trying to come up with a good reason... and I guess the one who designed this auth scheme had something in mind... Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
A couple of quick comments <disclaimer> I didn't read through all the reasoning in detail yet, due to lack of time </disclaimer> Daniel Roesen wrote:
On Wed, Apr 05, 2006 at 12:32:58PM +0200, Gert Doering wrote:
From my gut feeling, I'd say that for route object creation, it should be sufficient if you have authenticated against the maintainer of the inetnum (mnt-by/mnt-routes) and against the maintainer of the new AS.
I support this proposal.
I'm sure I'm overlooking something, which would explain why it is the way it is...?
One of the basic intentions was to have (a set of tools that allows to maintain) a routing registry that matches "reality" as close as possible. Looking at the situation from a routing perspective, you need cooperation form both the old and the new ISP in real life. Asking a 3rd party to remove a route object from the DB does not necessarily mean that the "old" announcement is going to disappear. The old ISP may still advertise the prefix! Of course some ISPs may filter according to the RR (and maybe ignore the "old" stuff, but others might not. What I do not undertstand fully right now is the potential impact on the operation of configuration tools if they start to see more than 1 origin entry for a particular prefix from diferent ASes. I also have to still think through the security aspect of _indiscriminately_ allowing the creation or deletion of DB objects without consent/cooperation of the parties involved. I presume the NCC does some sanity checking before honouring "manual" requests?
Good question, I'm also trying to come up with a good reason... and I guess the one who designed this auth scheme had something in mind...
While I do not at all object to revisit this problem (may I suggest to take it through Routing and/or Address-Policy firts?) my _feeling_ is that we won't see a much better machinery by bending the DB code left and right, but rather by trying to make progress in developing and properly deploying (some sort of) Routing Layer Security? Some of the prerequisites are already being developed.
Best regards, Daniel
Wilfried.
Hello Wilfred,
One of the basic intentions was to have (a set of tools that allows to maintain) a routing registry that matches "reality" as close as possible.
Looking at the situation from a routing perspective, you need cooperation form both the old and the new ISP in real life. Asking a 3rd party to remove a route object from the DB does not necessarily mean that the "old" announcement is going to disappear. The old ISP may still advertise the prefix!
Well there are many reasons for the new isp beeing uable to place a route object in the database: - old isp has merged -> lack of know how - old isp is unwilling -> customer cant change his isp - old isp is overloaded -> takes 4-6 weeks until route-object is updated *IF* the old ISP is willing to help, the current procedure is fine. The main problem is to install an additional route object NOT to delete the old one. For some time both route objects could be necessary.
Of course some ISPs may filter according to the RR (and maybe ignore the "old" stuff, but others might not.
You need to have a route-object for proper routing. A "dead" routing-object doesnt cause much trouble.
What I do not undertstand fully right now is the potential impact on the operation of configuration tools if they start to see more than 1 origin entry for a particular prefix from diferent ASes.
normally Upstream XY creates once per night his prefix-filters. If he gets an announcement of a customer without proper route-object he ignores it. -> no routing object no ip :-) There are *many* cases where two or more route objects for the *same* network exist. I dont know of any problem with that situation.
I also have to still think through the security aspect of _indiscriminately_ allowing the creation or deletion of DB objects without consent/cooperation of the parties involved.
Well if you own a house you as a owner wants to be able to change the keys if necessary ? The owner of the inetnum-object has lower rights than the first isp who installed a route object. Beside Ripe NCC the Maintainer in the inetobject should be able to modify all objects tied to his inetnum. This is mainly the inetobject itself and the route-objects.
While I do not at all object to revisit this problem (may I suggest to take it through Routing and/or Address-Policy firts?) my _feeling_ is that we won't see a much better machinery by bending the DB code left and right, but rather by trying to make progress in developing and properly deploying (some sort of) Routing Layer Security?
According to the ripe they need input from the db-wg to do this. It not too much additional code to developp, it is rather a other way to check whether a maintainer is authenticated to create/delete a route object or not. Winfried Haug --- Headlight Housing Factory | Rechenzentrum: Azenbergstrasse 35 | Neue Bruecke 8 D-70174 Stuttgart | D-70173 Stuttgart Fon: +49 711 2840 0 | e-mail: wh@headlight.de Fax: +49 711 2840 999 | http://www.headlight.de
On Apr 05, "Wilfried Woeber, UniVie/ACOnet" <Woeber@CC.UniVie.ac.at> wrote:
What I do not undertstand fully right now is the potential impact on the operation of configuration tools if they start to see more than 1 origin entry for a particular prefix from diferent ASes. There is no impact: filters generators ask the IRR for "all prefixes announced by a specific ASN", so an additional route object will at worst cause the prefix to be left in the filter for the old ISP.
-- ciao, Marco
Hi, Gert Doering asked: [...]
I'm sure I'm overlooking something, which would explain why it is the way it is...?
As far as I know current behaviour is the implementation of the RFC 2725 (Routing Policy System Security). According to it the order of checking the authorisation is as follows: exact match route less specific route exact match inetnum less specific inetnum In Winfried's case it fails on the exact match route and doesn't continue further. I am not sure why the checks are like this, may only note that the spec was developed ~8 years ago and reflects last century view on the routing system. And Wilfried Woeber commented:
While I do not at all object to revisit this problem (may I suggest to take it through Routing and/or Address-Policy firts?) my _feeling_ is that we won't see a much better machinery by bending the DB code left and right, but rather by trying to make progress in developing and properly deploying (some sort of) Routing Layer Security?
Some of the prerequisites are already being developed.
There was a second SIDR BOF at the IETF 65. One of the concepts that was presented there was a so-called ROA (Route Origination Authorisation ?) - a digitally signed data structure that allows an address space holder to authorise one or more ASes to originate [part of] the space. (Provided that the holdership of the address space can be validated through the certification chain up to an RIR or the IANA). This ROA is very much the same as the collection of the route objects with different origin AS'es for the same prefix, being only authorised by the maintainer of the address space. Regards, Andrei Robachevsky RIPE NCC
participants (7)
-
Andrei Robachevsky -
Daniel Roesen -
Gert Doering -
Ihler, Hermann -
md＠Linux.IT -
Wilfried Woeber, UniVie/ACOnet -
Winfried Haug