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
Moving this to the routing wg list only to minimise noise. Also Subject change to reflect the topic. On 09 Jun 2014, at 15:53, 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.
This sounds like a reasonable thing to do to me. In fact, now that this has been mentioned it does sound like an obvious thing and I wonder what took the hostile aut-num’s so long to subvert the intent of the those fields. Joao
Hi, On Mon, Jun 09, 2014 at 04:11:35PM +0200, João Damas wrote:
This sounds like a reasonable thing to do to me. In fact, now that this has been mentioned it does sound like an obvious thing and I wonder what took the hostile aut-num?s so long to subvert the intent of the those fields.
+1 - useful feature to have, quite likely threat unless someone's filter scripts actually check not only the export policy/as-set values presented by a customer but also the export policy of the ASes presented. Which, I think, most tools won't do. 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 (0)89/32356-444 USt-IdNr.: DE813185279
On Mon, Jun 09, 2014 at 04:11:35PM +0200, João Damas wrote:
On 09 Jun 2014, at 15:53, Hank Nussbacher <hank@efes.iucc.ac.il> 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?
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.
This sounds like a reasonable thing to do to me. In fact, now that this has been mentioned it does sound like an obvious thing and I wonder what took the hostile aut-num’s so long to subvert the intent of the those fields.
I think some notification feature would be nice to have, but we need to figure out what and when we expect notifications. I propose we dub the attribute for nice alignment with existing attributes: notify-on-ref: <email-address> optional, multi-valued Questions: - do you want a notification each time an object is updated and has a reference to your object? - or do you only want notifications when a reference inititally is added to an object? (spares you a daily mailbomb for daily updated objects) - do you want a notification when the reference is removed from an object? - In what classes do you want to set a notify-on-ref attribute? (I think initially aut-num, as-set, rs-set) - do we want the notify-on-ref email addresses to be set to unread@ripe.net upon NRTM/ftp export? Regarding authorisation, for me requiring authorisation to reference a given object is a bridge too far at this point in time. Quite some operators automatically generate an autnum, route-sets & as-sets on a daily basis to reject their policy, and I don't see an easy way to make this a painless adventure. Let's first do notifications and based on those experiences look further. ok? Kind regards, Job
At 11:25 10/06/2014 +0000, Job Snijders wrote:
I propose we dub the attribute for nice alignment with existing attributes:
notify-on-ref: <email-address> optional, multi-valued
Works for me.
Questions:
- do you want a notification each time an object is updated and has a reference to your object?
No.
- or do you only want notifications when a reference inititally is added to an object? (spares you a daily mailbomb for daily updated objects)
Yes.
- do you want a notification when the reference is removed from an object?
Yes.
- In what classes do you want to set a notify-on-ref attribute? (I think initially aut-num, as-set, rs-set)
Agree.
- do we want the notify-on-ref email addresses to be set to unread@ripe.net upon NRTM/ftp export?
No opinion.
Regarding authorisation, for me requiring authorisation to reference a given object is a bridge too far at this point in time. Quite some operators automatically generate an autnum, route-sets & as-sets on a daily basis to reject their policy, and I don't see an easy way to make this a painless adventure. Let's first do notifications and based on those experiences look further. ok?
Yup. -Hank
Kind regards,
Job
Hi Job,
I think some notification feature would be nice to have, but we need to figure out what and when we expect notifications.
I propose we dub the attribute for nice alignment with existing attributes:
notify-on-ref: <email-address> optional, multi-valued
Questions:
- do you want a notification each time an object is updated and has a reference to your object?
Strong no
- or do you only want notifications when a reference inititally is added to an object? (spares you a daily mailbomb for daily updated objects)
Yes
- do you want a notification when the reference is removed from an object?
Yes
- In what classes do you want to set a notify-on-ref attribute? (I think initially aut-num, as-set, rd-set)
Ack
- do we want the notify-on-ref email addresses to be set to unread@ripe.net upon NRTM/ftp export?
No strong opinion on this one. I would say yes, unless someone comes up with a reason not to.
Regarding authorisation, for me requiring authorisation to reference a given object is a bridge too far at this point in time. Quite some operators automatically generate an autnum, route-sets & as-sets on a daily basis to reject their policy, and I don't see an easy way to make this a painless adventure. Let's first do notifications and based on those experiences look further. ok?
Yes, that sounds reasonable. Needing authorisation to be allowed to put information in the policy sounds like a good way to discourage people from updating/using them altogether. Let's not make things more difficult unless we really need to. Cheers! Sander
I propose we dub the attribute for nice alignment with existing attributes:
notify-on-ref: <email-address> optional, multi-valued
Questions:
- do you want a notification each time an object is updated and has a reference to your object? No - or do you only want notifications when a reference inititally is added to an object? (spares you a daily mailbomb for daily updated objects) Yes - do you want a notification when the reference is removed from an object? Yes - In what classes do you want to set a notify-on-ref attribute? (I think initially aut-num, as-set, rs-set) Agree - do we want the notify-on-ref email addresses to be set to unread@ripe.net upon NRTM/ftp export? Ok Andreas Larsen IP-Only AB | Postadress: 753 81 UPPSALA | Besöksadress Uppsala: S:t Persg 6 Besöksadress Stockholm: N Stationsg 69 | Vxl: +46 18 843 10 00 | Mobil +46 70 843 10 56 www.ip-only.se
10 jun 2014 kl. 13:25 skrev Job Snijders <job@instituut.net>:
On Mon, Jun 09, 2014 at 04:11:35PM +0200, João Damas wrote:
On 09 Jun 2014, at 15:53, Hank Nussbacher <hank@efes.iucc.ac.il> 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?
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.
This sounds like a reasonable thing to do to me. In fact, now that this has been mentioned it does sound like an obvious thing and I wonder what took the hostile aut-num’s so long to subvert the intent of the those fields.
I think some notification feature would be nice to have, but we need to figure out what and when we expect notifications.
I propose we dub the attribute for nice alignment with existing attributes:
notify-on-ref: <email-address> optional, multi-valued
Questions:
- do you want a notification each time an object is updated and has a reference to your object?
- or do you only want notifications when a reference inititally is added to an object? (spares you a daily mailbomb for daily updated objects)
- do you want a notification when the reference is removed from an object?
- In what classes do you want to set a notify-on-ref attribute? (I think initially aut-num, as-set, rs-set)
- do we want the notify-on-ref email addresses to be set to unread@ripe.net upon NRTM/ftp export?
Regarding authorisation, for me requiring authorisation to reference a given object is a bridge too far at this point in time. Quite some operators automatically generate an autnum, route-sets & as-sets on a daily basis to reject their policy, and I don't see an easy way to make this a painless adventure. Let's first do notifications and based on those experiences look further. ok?
Kind regards,
Job
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 (11)
-
Andreas Larsen -
Dimitri I Sidelnikov -
Gert Doering -
Hank Nussbacher -
Hannigan, Martin -
Jens Ott - Opteamax GmbH -
Job Snijders -
João Damas -
Nick Hilliard -
Opteamax RIPE-Team -
Sander Steffann