Re: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs
Sanity checking upon submitting to the DB could prevent this. My 2c, Andreas Schachtner Send via mobile device. Please excuse brevity, typos and the funny spelling checker in particular. Gert Doering <gert@space.net> schrieb:
Hi,
On Wed, Jun 26, 2013 at 06:40:21PM +0200, Opteamax GmbH - RIPE-Team wrote:
Actually I don't really understand the problem. If the ASN is back in the pool, this reads for me "it shall no longer appear in the routing table". This includes for me that any object referencing this ASN is illegal by definition. So these illegal objects may not exist and *must* be removed asap from the DB. After removing all illegal objects, they should stay in some "grace-period" - let's say 3 month - and then there should be no problem reallocating the asn.
The database currently has no mechanics to prevent someone from entering an import/export line that says:
aut-num: AS100000 remarks: have fun with Jens export: to AS5539 announce AS48200
which is exactly that sort of reference that would currently keep the NCC from reallocating AS48200 (assuming that one were free).
Auto-cleaning the route: objects still referencing AS48200 is fairly easy, but auto-cleaning export/import policies and AS-SET objects is harder, especially as people might have the aut-num: object in question on file, just change stuff locally, and then re-send it when they have changes, overriding the cleaned-up object in the database...
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 06/27/13 01:52, Andreas Schachtner wrote:
Sanity checking upon submitting to the DB could prevent this.
And it's the main problem that we should talk. But not about removing some references to the objects that doesn't exists The lack of sanity check for the corresponding fields during database updates - is the root of the problem. +1
Auto-cleaning the route: objects still referencing AS48200 is fairly easy, but auto-cleaning export/import policies and AS-SET objects is harder, especially as people might have the aut-num: object in question on file, just change stuff locally, and then re-send it when they have changes, overriding the cleaned-up object in the database...
-- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.ne
Hi, On Thu, Jun 27, 2013 at 09:51:56AM +0300, Andrey Semenchuk wrote:
On 06/27/13 01:52, Andreas Schachtner wrote:
Sanity checking upon submitting to the DB could prevent this.
And it's the main problem that we should talk. But not about removing some references to the objects that doesn't exists The lack of sanity check for the corresponding fields during database updates - is the root of the problem.
It's not the *root* of the problem, but just one aspect (when the AS number is returned, all references to it are perfectly fine, up to that point) - and even then, you can't really solve the whole issue with technical means. Consider this: AS X is returned AS Y references it, database object is changed by NCC to remove reference to X <two month pass> AS X is reassigned to someone else AS Y sends an update to it's aut-num: object, restoring the reference to X now what - is this "illegal" because it's "an old reference", or should this be permitted, because it's really referencing to "the new holder of X"? (we can't know, so technical "blocking" of references to X will do the wrong thing in half the cases...) So, speaking as router admin, my preference is to - inform holders of objects with dangling references (admin-c, tech-c) - if nothing changes in, say, two weeks, inform LIR contacts as well - two weeks later, if the object is still referencing stale ASes, change object in DB, and again inform admin-c, tech-c, LIR contact - reassign the no longer referenced AS (speaking for myself and my routers, not speaking as WG chair) Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Gert Doering <gert@space.net> schrieb:
Hi,
On Thu, Jun 27, 2013 at 09:51:56AM +0300, Andrey Semenchuk wrote:
On 06/27/13 01:52, Andreas Schachtner wrote:
Sanity checking upon submitting to the DB could prevent this.
And it's the main problem that we should talk. But not about removing
some references to the objects that doesn't exists The lack of sanity check for the corresponding fields during database
updates - is the root of the problem.
It's not the *root* of the problem, but just one aspect (when the AS number is returned, all references to it are perfectly fine, up to that point) - and even then, you can't really solve the whole issue with technical means.
Consider this:
AS X is returned AS Y references it, database object is changed by NCC to remove reference to X <two month pass> AS X is reassigned to someone else AS Y sends an update to it's aut-num: object, restoring the reference to X
now what - is this "illegal" because it's "an old reference", or should this be permitted, because it's really referencing to "the new holder of X"? (we can't know, so technical "blocking" of references to X will do the wrong thing in half the cases...)
The sanity check could and should check if the inverse exists. And any import in aut-num X for asn Y that has no export in aut-num Y within 2 days has to be treated as illegal and removed, notifying the holder. And as some people only react when it hurts, I would even charge the removal if it happens more than once ... Also exports/imports as for example seen in aut-num 3320 (from any import any; to any export any) should be treated as illegal! Jens
So, speaking as router admin, my preference is to
- inform holders of objects with dangling references (admin-c, tech-c) - if nothing changes in, say, two weeks, inform LIR contacts as well - two weeks later, if the object is still referencing stale ASes, change object in DB, and again inform admin-c, tech-c, LIR contact
- reassign the no longer referenced AS
(speaking for myself and my routers, not speaking as WG chair)
Gert Doering -- Operator
-- Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel. +49 2224 969500 Email: jo@opteamax.de HRB 23144, AG Montabaur
On 06/27/13 10:59, Gert Doering wrote:
Hi,
On Thu, Jun 27, 2013 at 09:51:56AM +0300, Andrey Semenchuk wrote:
On 06/27/13 01:52, Andreas Schachtner wrote:
Sanity checking upon submitting to the DB could prevent this. And it's the main problem that we should talk. But not about removing some references to the objects that doesn't exists The lack of sanity check for the corresponding fields during database updates - is the root of the problem. It's not the *root* of the problem, but just one aspect (when the AS number is returned, all references to it are perfectly fine, up to that point) - and even then, you can't really solve the whole issue with technical means.
Consider this:
AS X is returned AS Y references it, database object is changed by NCC to remove reference to X <two month pass> AS X is reassigned to someone else AS Y sends an update to it's aut-num: object, restoring the reference to X
now what - is this "illegal" because it's "an old reference", or should this be permitted, because it's really referencing to "the new holder of X"? Reference to any object is not the "old reference" or the "new reference" - it's the "the only one valid reference".
Anytime End User that holds AS Y can add reference to AS Y. And it's not the problem of reassigning ASNs: until this information is not checked by RIPE's software (for example - like adding origin field to the route object) - any user will can add reference to any ASN (but for the assigned ASNs only). It's the separate question: how to prevent users to add references to objects that shouldn't be referenced by this object. It may be done by checking cross-references from the referenced and referencing objects for example. But it's not the question to ASN reassignment process
So, speaking as router admin, my preference is to
- inform holders of objects with dangling references (admin-c, tech-c) - if nothing changes in, say, two weeks, inform LIR contacts as well - two weeks later, if the object is still referencing stale ASes, change object in DB, and again inform admin-c, tech-c, LIR contact
- reassign the no longer referenced AS And your proposal is inconsistent with your example: the End User still can "restore reference to AS X inside AS Y object description during updating aut-num object"
-- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
Hi, On Thu, Jun 27, 2013 at 11:53:46AM +0300, Andrey Semenchuk wrote:
So, speaking as router admin, my preference is to
- inform holders of objects with dangling references (admin-c, tech-c) - if nothing changes in, say, two weeks, inform LIR contacts as well - two weeks later, if the object is still referencing stale ASes, change object in DB, and again inform admin-c, tech-c, LIR contact
- reassign the no longer referenced AS
And your proposal is inconsistent with your example: the End User still can "restore reference to AS X inside AS Y object description during updating aut-num object"
Indeed. I want a light-weight process that can be implemented while it's still relevant (aka "we still have 16 bit ASNs to worry about"). The more heavyweight "full database consistency cross-check, including references to AS numbers that are not from the RIPE region(!)" needs to very carefully considered - if we make it too complicated to register policy, people will just stop doing so, and what have we gained then? Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Indeed. I want a light-weight process that can be implemented while it's still relevant (aka "we still have 16 bit ASNs to worry about"). If ASN assigned by RIPE and used by the End User according with RIPE's
On 06/27/13 13:22, Gert Doering wrote: policy - it's nothing to worry about. If ASN returned to the pool - it's nothing to worry about too: we can't worry about something that does not exists (ASN does not assigned).
The more heavyweight "full database consistency cross-check, including references to AS numbers that are not from the RIPE region(!)" needs to very carefully considered - if we make it too complicated to register policy, people will just stop doing so, and what have we gained then? And this part of your opinion I fully support - we shouldn't make any complicated solutions for the simple task: If the ASN assigned - the ASN holder may use it. If the ASN does not assigned (or was assigned but was returned to the pool) - any reference that violates this should be deleted. And it's not the RIPE or community problem
-- Best wishes, Andrey Semenchuk Trifle Internet Service Provider (056) 731-99-11 www.trifle.net
participants (4)
-
Andreas Schachtner -
Andrey Semenchuk -
Gert Doering -
Opteamax GmbH - RIPE-Team