Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources
Dear all, at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in RIPE Database objects, namely the routing policy attributes of autnum and as-set objects. The observed consensus during the meeting was that: - the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data. - the RIPE NCC will inform the maintainer of the object containing the obsolete reference about this reference. The RIPE NCC will also offer support to the maintainer to delete the reference; - the RIPE NCC will start re-assigning referenced AS numbers once the unreferenced pool of 16-bit AS numbers has been exhausted. We would like to close the issue and be able to provide clear guidance to the RIPE NCC so we would like to get confirmation for this outcome also from the working group mailing lists. This is not a policy issue: the re-allocation of recovered ASNs was dealt with by the APWG, the current issue is related to alterations to RIPE Database objects that reference the resources subject to re-allocation. We propose a 15 day comment period, ending June 24th 2014. Sander Steffann, Gert Döring, Rob Evans, João Damas
On 09/06/2014 13:49, João Damas wrote:
The observed consensus during the meeting was that:
- the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data. - the RIPE NCC will inform the maintainer of the object containing the obsolete reference about this reference. The RIPE NCC will also offer support to the maintainer to delete the reference; - the RIPE NCC will start re-assigning referenced AS numbers once the unreferenced pool of 16-bit AS numbers has been exhausted.
wfm. Nick
On Mon, Jun 09, 2014 at 02:49:33PM +0200, João Damas wrote:
at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in RIPE Database objects, namely the routing policy attributes of autnum and as-set objects.
The observed consensus during the meeting was that:
- the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data. - the RIPE NCC will inform the maintainer of the object containing the obsolete reference about this reference. The RIPE NCC will also offer support to the maintainer to delete the reference; - the RIPE NCC will start re-assigning referenced AS numbers once the unreferenced pool of 16-bit AS numbers has been exhausted.
We would like to close the issue and be able to provide clear guidance to the RIPE NCC so we would like to get confirmation for this outcome also from the working group mailing lists. This is not a policy issue: the re-allocation of recovered ASNs was dealt with by the APWG, the current issue is related to alterations to RIPE Database objects that reference the resources subject to re-allocation. We propose a 15 day comment period, ending June 24th 2014.
I like it. Kind regards, Job
On Jun 9, 2014, at 9:09 AM, Job Snijders <job@instituut.net> wrote:
On Mon, Jun 09, 2014 at 02:49:33PM +0200, João Damas wrote:
at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in RIPE Database objects, namely the routing policy attributes of autnum and as-set objects.
The observed consensus during the meeting was that:
- the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data. - the RIPE NCC will inform the maintainer of the object containing the obsolete reference about this reference. The RIPE NCC will also offer support to the maintainer to delete the reference; - the RIPE NCC will start re-assigning referenced AS numbers once the unreferenced pool of 16-bit AS numbers has been exhausted.
We would like to close the issue and be able to provide clear guidance to the RIPE NCC so we would like to get confirmation for this outcome also from the working group mailing lists. This is not a policy issue: the re-allocation of recovered ASNs was dealt with by the APWG, the current issue is related to alterations to RIPE Database objects that reference the resources subject to re-allocation. We propose a 15 day comment period, ending June 24th 2014.
Same, this works. Best, -M<
At 14:49 09/06/2014 +0200, João Damas wrote:
Dear all, at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in RIPE Database objects, namely the routing policy attributes of autnum and as-set objects.
The observed consensus during the meeting was that:
- the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data.
On a related matter, is it possible currently to setup my aut-num that if anyone adds my autnum to their import/export/as-set objects I would receive a notification about it? Currently the "notify" field only informs me of changes to the specific aut-num, not people who reference my aut-num w/o my permission? If this is not feasible with the system today, would it be possible to add this feature? I'll explain the rationale: we have recently discovered that hostile aut-num's that intend to perform a BGP hijack, will add the victims aut-num to their routing policy or to their unsuspecting upstream. This policy is then picked up as legitimate and propogated. By having a "notify-on-policy" email address field, I would be able to quickly see who is planning on hijacking my IP ranges. Comments? Thanks, Hank
On 9. Juni 2014 15:53:15 MESZ, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
At 14:49 09/06/2014 +0200, João Damas wrote:
Dear all, at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in
RIPE Database objects, namely the routing policy attributes of autnum and as-set objects.
The observed consensus during the meeting was that:
- the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data.
On a related matter, is it possible currently to setup my aut-num that if anyone adds my autnum to their import/export/as-set objects I would receive a notification about it? Currently the "notify" field only informs me of changes to the specific aut-num, not people who reference my aut-num w/o my permission?
If this is not feasible with the system today, would it be possible to add this feature? I'll explain the rationale: we have recently discovered that hostile aut-num's that intend to perform a BGP hijack, will add the victims aut-num to their routing policy or to their unsuspecting upstream. This policy is then picked up as legitimate and propogated. By having a "notify-on-policy" email address field, I would be able to quickly see who is planning on hijacking my IP ranges.
Comments?
I fully support your point. I also observed what you told here. Therefore we enhanced our Prefixlist-Generator doing counter-checks if an import statement also have a corresponding export - statement. Result is, that the prefixlist generation takes about 10 times longer, our caching database grew by factor eight (as we now also need to cache autnum objects of child- and grandchild-objects) ... So a "notify-on-policy" - how you called it - would be very appreciated! BR Jens
Thanks, Hank
!DSPAM:637,5395bdec188062364380171!
-- Jens Ott Opteamax GmbH Simrockstr. 4G 53619 Rheinbreitbach Tel. +49 2224 969500 Email: jo@opteamax.de
-------- Ursprüngliche Nachricht -------- Von: Jens Ott - Opteamax GmbH <jo@opteamax.de> Gesendet: 9. Juni 2014 16:20:54 MESZ An: Hank Nussbacher <hank@efes.iucc.ac.il>, "João Damas" <joao@bondis.org>, routing-wg@ripe.net, address-policy-wg@ripe.net Betreff: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources On 9. Juni 2014 15:53:15 MESZ, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
At 14:49 09/06/2014 +0200, João Damas wrote:
Dear all, at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in
RIPE Database objects, namely the routing policy attributes of autnum and as-set objects.
The observed consensus during the meeting was that:
- the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data.
On a related matter, is it possible currently to setup my aut-num that if anyone adds my autnum to their import/export/as-set objects I would receive a notification about it? Currently the "notify" field only informs me of changes to the specific aut-num, not people who reference my aut-num w/o my permission?
If this is not feasible with the system today, would it be possible to add this feature? I'll explain the rationale: we have recently discovered that hostile aut-num's that intend to perform a BGP hijack, will add the victims aut-num to their routing policy or to their unsuspecting upstream. This policy is then picked up as legitimate and propogated. By having a "notify-on-policy" email address field, I would be able to quickly see who is planning on hijacking my IP ranges.
Comments?
I fully support your point. I also observed what you told here. Therefore we enhanced our Prefixlist-Generator doing counter-checks if an import statement also have a corresponding export - statement. Result is, that the prefixlist generation takes about 10 times longer, our caching database grew by factor eight (as we now also need to cache autnum objects of child- and grandchild-objects) ... So a "notify-on-policy" - how you called it - would be very appreciated! BR Jens
Thanks, Hank
!DSPAM:637,5395bdec188062364380171!
-- Jens Ott Opteamax GmbH Simrockstr. 4G 53619 Rheinbreitbach Tel. +49 2224 969500 Email: jo@opteamax.de
On 09/06/2014 14:53, Hank Nussbacher wrote:
On a related matter, is it possible currently to setup my aut-num that if anyone adds my autnum to their import/export/as-set objects I would receive a notification about it? Currently the "notify" field only informs me of changes to the specific aut-num, not people who reference my aut-num w/o my permission?
+1 I'd also like to see when someone includes my autnums or as-sets in their as-sets. This has clobbered me in the past with highly unwelcome changes to production traffic flows. Nick
I support it. 09.06.2014 16:49, João Damas пишет:
Dear all, at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in RIPE Database objects, namely the routing policy attributes of autnum and as-set objects.
The observed consensus during the meeting was that:
- the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data. - the RIPE NCC will inform the maintainer of the object containing the obsolete reference about this reference. The RIPE NCC will also offer support to the maintainer to delete the reference; - the RIPE NCC will start re-assigning referenced AS numbers once the unreferenced pool of 16-bit AS numbers has been exhausted.
We would like to close the issue and be able to provide clear guidance to the RIPE NCC so we would like to get confirmation for this outcome also from the working group mailing lists. This is not a policy issue: the re-allocation of recovered ASNs was dealt with by the APWG, the current issue is related to alterations to RIPE Database objects that reference the resources subject to re-allocation. We propose a 15 day comment period, ending June 24th 2014.
Sander Steffann, Gert Döring, Rob Evans, João Damas
-- Kind regards, --- D.Sidelnikov
participants (7)
-
Dimitri I Sidelnikov -
Hank Nussbacher -
Hannigan, Martin -
Jens Ott - Opteamax GmbH -
Job Snijders -
João Damas -
Nick Hilliard -
Opteamax RIPE-Team