On 25 June 2015 at 21:42, Job Snijders <job@instituut.net> wrote:
On Thu, Jun 25, 2015 at 09:33:44PM +0200, George Michaelson wrote:
For your information, APNIC Hostmasters have moved to a mode of operation where for inetnum owners where the AS holder is not the same person, and a request is lodged with helpdesk for assistance, the hostmasters manually override and create the object for the inetnum holder, only removing it if an AS holder objects. The inetnum holder needs to be recognised in our systems.
Its a hand-mediated inetnum-only route object. Previous practice was to wait for explicit approval from the AS holder. Now, its created first, and withdrawn if there is an objection.
There have been no complaints. APNIC HM are considering portal changes and other process work to automate this.
What is the benefit of the hand-mediation?
Or is that just an artifact
of the software implementation?
Its an artefact of the s/w implementation. I imagine once they work out how to do this in the portal, this will be changed.
Does APNIC send a notification to the AS holder that an object was created in which they were referenced?
Yes. The following template is used: ====== Dear (ASN custodian), This is to inform you that the following route/route6 object has been registered in the APNIC Whois Database with your AS number referenced in the "origin" attribute. --- insert route object --- The IP addresses holder has asked that APNIC help register this route object in the APNIC Whois database. If you believe your AS number should not be referenced as the "origin" in this route object, please contact us by replying to this email. Kind Regards, ====== cheers -George
Kind regards,
Job
Thanks for sharing your experiences George. I'm curious to hear from our Community about what they think about this mode of operation; simply create the route object on the inetnum holder's authorisation alone, inform the ASN holder that it was created and only remove the object if they object. It would simplify the authorisation model tremendously and save a lot of frustration and customer support tickets. Seeing that APNIC has positive experiences, would our Community support such an approach considering the up and downsides? Cheers, Alex
On 26 Jun 2015, at 06:43, George Michaelson <ggm@apnic.net> wrote:
On 25 June 2015 at 21:42, Job Snijders <job@instituut.net> wrote: On Thu, Jun 25, 2015 at 09:33:44PM +0200, George Michaelson wrote:
For your information, APNIC Hostmasters have moved to a mode of operation where for inetnum owners where the AS holder is not the same person, and a request is lodged with helpdesk for assistance, the hostmasters manually override and create the object for the inetnum holder, only removing it if an AS holder objects. The inetnum holder needs to be recognised in our systems.
Its a hand-mediated inetnum-only route object. Previous practice was to wait for explicit approval from the AS holder. Now, its created first, and withdrawn if there is an objection.
There have been no complaints. APNIC HM are considering portal changes and other process work to automate this.
What is the benefit of the hand-mediation? Or is that just an artifact of the software implementation?
Its an artefact of the s/w implementation. I imagine once they work out how to do this in the portal, this will be changed.
Does APNIC send a notification to the AS holder that an object was created in which they were referenced?
Yes. The following template is used:
======
Dear (ASN custodian), This is to inform you that the following route/route6 object has been registered in the APNIC Whois Database with your AS number referenced in the "origin" attribute.
--- insert route object ---
The IP addresses holder has asked that APNIC help register this route object in the APNIC Whois database.
If you believe your AS number should not be referenced as the "origin" in this route object, please contact us by replying to this email.
Kind Regards,
======
cheers
-George
Kind regards,
Job
On Thu, Jul 02, 2015 at 11:42:12AM +0200, Alex Band wrote:
Thanks for sharing your experiences George.
I'm curious to hear from our Community about what they think about this mode of operation; simply create the route object on the inetnum holder's authorisation alone, inform the ASN holder that it was created and only remove the object if they object.
It would simplify the authorisation model tremendously and save a lot of frustration and customer support tickets.
Seeing that APNIC has positive experiences, would our Community support such an approach considering the up and downsides?
Works for me. It's within the authority of the prefix holder to decide whom to allow to advertise the prefix. If the ASN holder doesn't want to advertise it, don't. Out of interest, do you propose to automate the removal of disputed route: objects? How would that be authorised if maintained solely by the inetnum: maintainer? rgds, Sascha Luck
On Jul 2, 2015, at 12:05 PM, Sascha Luck [ml] <dbwg@c4inet.net> wrote:
On Thu, Jul 02, 2015 at 11:42:12AM +0200, Alex Band wrote:
Thanks for sharing your experiences George.
I'm curious to hear from our Community about what they think about this mode of operation; simply create the route object on the inetnum holder's authorisation alone, inform the ASN holder that it was created and only remove the object if they object.
It would simplify the authorisation model tremendously and save a lot of frustration and customer support tickets.
Seeing that APNIC has positive experiences, would our Community support such an approach considering the up and downsides?
Works for me. It's within the authority of the prefix holder to decide whom to allow to advertise the prefix. If the ASN holder doesn't want to advertise it, don't.
Out of interest, do you propose to automate the removal of disputed route: objects? How would that be authorised if maintained solely by the inetnum: maintainer?
The same authorisation that is currently required to do pre-approval of the ASN side of route object creation, could be used to allow 'post-deletion'. I.e. even though there would be no mnt-by for the ASN holder, they would be able to delete the object provided they have access to the relevant aut-num maintainer (mnt-by, mnt-routes). This way the ASN holder could use existing APIs and web-updates to delete the object in response to the notification of the route object creation (we can easily include a link to web updates). ASNs that want to be more restrictive could even automate querying the database for route objects with their ASN in the "origin:" and delete unwanted objects they find. Regards, Tim Bruijnzeels
rgds, Sascha Luck
The same authorisation that is currently required to do pre-approval of the ASN side of route object creation, could be used to allow 'post-deletion'.
i worry that this is not gonna age well. cruft is going to be ever- increasing.
I.e. even though there would be no mnt-by for the ASN holder, they would be able to delete the object provided they have access to the relevant aut-num maintainer (mnt-by, mnt-routes).
just to kludge it up a bit more, send 'em a time-limited token with the approval message randy
Hi, On Thu, Jul 02, 2015 at 11:42:12AM +0200, Alex Band wrote:
I'm curious to hear from our Community about what they think about this mode of operation; simply create the route object on the inetnum holder's authorisation alone, inform the ASN holder that it was created and only remove the object if they object.
Would work for me... Gert -- 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
-----Original Message----- From: Alex Band on Thursday, July 02, 2015 11:42 AM
Thanks for sharing your experiences George.
I'm curious to hear from our Community about what they think about this mode of operation; simply create the route object on the inetnum holder's authorisation alone, inform the ASN holder that it was created and only remove the object if they object.
It would simplify the authorisation model tremendously and save a lot of frustration and customer support tickets.
Seeing that APNIC has positive experiences, would our Community support such an approach considering the up and downsides?
We definitely would support this simplified authorization method. Our primary concern is that it would make polluting the database even easier which might be abuse e.g. to attack (DoS) filter generation tools/access list memory limits. But as this could be done with the current database anyway, we don't think it will be a problem. The big advantage we see is that it would make the creation of route objects with inetnum/origin combinations from different RIRs easier. Once more RIRs adopt this simple authorization model access to their address space via RIPE-NCC-RPSL-MNT should be prevented. That would improve security in the long run. Best Regards, Frederik Kriewitz NYNEX satellite OHG
On Thu, Jul 02, 2015 at 11:42:12AM +0200, Alex Band wrote:
Thanks for sharing your experiences George.
I'm curious to hear from our Community about what they think about this mode of operation; simply create the route object on the inetnum holder's authorisation alone, inform the ASN holder that it was created and only remove the object if they object.
It would simplify the authorisation model tremendously and save a lot of frustration and customer support tickets.
Seeing that APNIC has positive experiences, would our Community support such an approach considering the up and downsides?
I support this direction and style of operation. The philosophy that an inetnum holder can unilaterally grant the right to announce a prefix to any ASN makes sense to me, probably is more intuitive to most. Kind regards, Job
On Thu, Jul 02, 2015 at 11:42:12AM +0200, Alex Band wrote:
I'm curious to hear from our Community about what they think about this mode of operation; simply create the route object on the inetnum holder's authorisation alone, inform the ASN holder that it was created and only remove the object if they object.
I support this direction and style of operation. The philosophy that an inetnum holder can unilaterally grant the right to announce a prefix to any ASN makes sense to me, probably is more intuitive to most.
folk seem to be gliding over the last clause in alex's paragraph. are you agreeing with it? i think i am inclined to agree, given the use of peval(as-set:) to get the transitive closure of a peer's prefixes. but it makes me wonder about my use of as-set:s. randy
* Alex Band <alexb@ripe.net> [2015-07-02 11:45]:
Thanks for sharing your experiences George.
I'm curious to hear from our Community about what they think about this mode of operation; simply create the route object on the inetnum holder's authorisation alone, inform the ASN holder that it was created and only remove the object if they object.
It would simplify the authorisation model tremendously and save a lot of frustration and customer support tickets.
Hello Alex, I would support that. Could there be a mechanism to block "repeat offenders" from creating route: objects with my AS? I'm just envisioning an "edit war" of people adding a route object and me requesting it to be removed. Or am I just too paranoid/pesimistic? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
participants (9)
-
Alex Band -
Frederik Kriewitz -
George Michaelson -
Gert Doering -
Job Snijders -
Randy Bush -
Sascha Luck [ml] -
Sebastian Wiesinger -
Tim Bruijnzeels