Re: [lir-wg] AS Number Policy
On Tue, 9 Jul 2002, Christopher Sharp wrote:
On Tue, 09 Jul 2002 12:57:46 +0300, Hank Nussbacher <hank@att.net.il> wrote:
At 11:53 AM 09-07-02 +0200, leo vegoda wrote:
1. How long does the community believe it is reasonable to take to bring an AS 'on-line'? 3 months.
2. After how many months of not being in use should an AS be returned? 3 months.
3.After how many months of being single-homed should an AS be returned? 9-12 months.
I agree with the time scales for unused ASes and think Hank has raised a very valid point about those in use.I would be in favour of a 6 month timescale for return of these 'unless intent can be proven to re-multi-home within 3 months'.
Producing an easily enforceable policy covering those AS in use may be a little more complicated.I think most offenders who have become single-homed are likely to ignore warnings of an approaching return date until it arrives.I suggest a 6 month period of warning followed by a formal request for return and a 3 months for them to depreciate use of the AS and return it.The net result is a 9 month period of return with plenty of warning to depreciate use of a single-homed AS.
C.
The problem I foresee will be removing an ASN. RIPE has a policy of not changing mntner objects or overriding them so if the ASN just ignores RIPEs emails and continues to use the ASN - then what? And even if RIPE manages to have a procedure for removing an ASN against the will of the organization it was allocated to, what is to stop the organization to continue to use it? Those that follow NANOG have seen a case of AS5757 which is not listed in any DB and it has been announced for the past 3 years. Hank Nussbacher
On Wed, 10 Jul 2002 00:17:20 +0300 (IDT), Hank Nussbacher <hank@att.net.il> wrote:
The problem I foresee will be removing an ASN. RIPE has a policy of not changing mntner objects or overriding them so if the ASN just ignores RIPEs emails and continues to use the ASN - then what?
I agree. However, I think the community is agreed that an AS return policy is needed. What that policy is and how it is implemented is going to be the harder question to answer. For new applicants I believe 3 months should be enough to bring their new AS on-line. It should also be soon enough after the initial registration to guarantee having accurate contact details for the applicant (either from the registration or via the LIR through which it was submitted). Contact will be a lot harder with older registrations. The LIRs through which such applications were made often no-longer have contact with the maintainers. Contacting the maintainers of long-unused ASNs will be problematic. I imagine a large percentage of registrants will simply no-longer exist and their contacts will have moved on. I believe a general RIPE policy is needed to cover all unused registrations where the registrant no-longer exists - or have I missed something? The sooner RIPE contacts the mntner of an AS after it appears to become unused the better the chances of making contact and a successful return of the ASN. This is why I back a short period of disuse before the mntner is contacted requesting return of the ASN. I think we will see a pattern of depreciating contactability for those whose ASN is in use but no-longer multi-homed. Many of these registrants are in the process of down-sizing and have no strong technical focus. This means registered mntners are less likely to be available as time goes on and there may be no skilled replacement contact available. Early communication with such registrants will be critical in negotiating the return of their unused AS. For this reason I suggest a 6 month period before contact is made, followed by a 3 month period for "migration" from the single-homed AS. I agree with Neil [apologies if it was not you] that there should be a long period before a returned AS is released. The question of what is to be done when no mntner can be contacted for an apparently disused object is a much larger problem to address and is not specific to ASNs.
And even if RIPE manages to have a procedure for removing an ASN against the will of the organization it was allocated to, what is to stop the organization to continue to use it?
Whilst this is a very valid point I hope registrants like these are in the minority. The refusal of a few members to observe protocol is not a reason not to define a policy and attempt to enforce it. I suspect that many of the single-homed AS in use still have a relationship with the LIR through which the application was made, in which case pressure could be brought to bear with the LIR to assist. Ultimately the community will decide if they feel strongly enough to bring such offenders to justice. This is likely to take the form of bogon filters. C.
At 10:08 PM 09-07-02 +0000, Christopher Sharp wrote:
Contacting the maintainers of long-unused ASNs will be problematic. I imagine a large percentage of registrants will simply no-longer exist and their contacts will have moved on. I believe a general RIPE policy is needed to cover all unused registrations where the registrant no-longer exists - or have I missed something?
The LIR that allocated the ASN should be able to handle its removal. I have started creating mntner objects for new ASNs with duplicate auth tags ( with different MD5-PW passwords). I give one to the requesting organization and one I keep for myself. In the event the company goes bankrupt and I can't find anyone to talk to in the company, then I at least have the ability to remove their entry without them being around.
And even if RIPE manages to have a procedure for removing an ASN against the will of the organization it was allocated to, what is to stop the organization to continue to use it?
Whilst this is a very valid point I hope registrants like these are in the minority. The refusal of a few members to observe protocol is not a reason not to define a policy and attempt to enforce it. I suspect that many of the single-homed AS in use still have a relationship with the LIR through which the application was made, in which case pressure could be brought to bear with the LIR to assist.
Ultimately the community will decide if they feel strongly enough to bring such offenders to justice. This is likely to take the form of bogon filters.
I don't think we have to resort to the courts for this and I doubt they would help. But the problem is not only with ASNs but also with IP blocks being advertised by organizations that don't own them. Those that get routing-wg@ripe.net see the list every week of unallocated ASNs and IP blocks being used freely on the Internet. I'd like to make a suggestion. Since these ASNs and IP blocks are the property of the RIRs, and since organizations are cybersquatting on these resources why shouldn't these RIRs advertise these IP blocks and ASNs themselves and blackhole them to their routers? You'd get the attention of these cybersquatting organizations *real* fast. -Hank
C.
On Wed, 10 Jul 2002 10:01:34 +0300, Hank Nussbacher <hank@att.net.il> wrote:
At 10:08 PM 09-07-02 +0000, Christopher Sharp wrote:
The LIR that allocated the ASN should be able to handle its removal. I have started creating mntner objects for new ASNs with duplicate auth tags ( with different MD5-PW passwords). I give one to the requesting organization and one I keep for myself. In the event the company goes bankrupt and I can't find anyone to talk to in the company, then I at least have the ability to remove their entry without them being around.
This is excellent for future registrations but doesn't help with historical allocations that were not done like this. Especially where the allocating LIR has had no contact with the registrant for an extended period of time. I suspect we need to look back, as well as forward, when implementing a solution.
I don't think we have to resort to the courts for this and I doubt they would help. But the problem is not only with ASNs but also with IP blocks being advertised by organizations that don't own them. Those that get routing-wg@ripe.net see the list every week of unallocated ASNs and IP blocks being used freely on the Internet. I'd like to make a suggestion. Since these ASNs and IP blocks are the property of the RIRs, and since organizations are cybersquatting on these resources why shouldn't these RIRs advertise these IP blocks and ASNs themselves and blackhole them to their routers?
You'd get the attention of these cybersquatting organizations *real* fast.
To succeed in grabbing the attention of all such offenders you probably need the support of all RIRs and IANA to carry out a unilateral crackdown. Otherwise the skilled offenders will just migrate to other unallocated address space. An informal approach such as the wider distribution of this list may well help. I'm sure a lot of people would start listing many of these ASNs and IP blocks in their filters. C.
On Wed, 10 Jul 2002, Christopher Sharp wrote:
An informal approach such as the wider distribution of this list may well help. I'm sure a lot of people would start listing many of these ASNs and IP blocks in their filters.
I wouldn't like to then be allocated an AS that had been on one these lists... I'd imagine that it is just for RIPE/ARIN to put pressure on the upstreams of such rogue AS holders. They could withhold the allocation of extra IP space, if necessary, to the Tranist providers in order to encourage them not to provide service to such ASs. Regards, aid -- Adrian Bool | http://noc.vianw.net/ Director, Global Core Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | noc://+49.203.3093.1111/
On Wed, 10 Jul 2002, Hank Nussbacher wrote:
I'd like to make a suggestion. Since these ASNs and IP blocks are the property of the RIRs, and since organizations are cybersquatting on these resources why shouldn't these RIRs advertise these IP blocks and ASNs themselves and blackhole them to their routers?
I'd like to back this idea! However, even if ICANN itself suddenly gets stroken by lightning of technical wisdom and starts announcing unused /8's - that won't prevent offenders from announcing more specific routes, will it? On the other hand, announcing /24's will really pollute the global routing table, which is big enough anyway. Still, having a service like Paul Vixie's AS7777 would help a lot: an ISP willing to receive blackhole routes would bring a route server on their backbone, establish a peering session with "IANA blackhole AS" and use the routes to construct filters etc. Regards, Beri
At 12:38 PM 10-07-02 +0200, Berislav Todorovic wrote:
On Wed, 10 Jul 2002, Hank Nussbacher wrote:
I'd like to make a suggestion. Since these ASNs and IP blocks are the property of the RIRs, and since organizations are cybersquatting on these resources why shouldn't these RIRs advertise these IP blocks and ASNs themselves and blackhole them to their routers?
I'd like to back this idea!
However, even if ICANN itself suddenly gets stroken by lightning of technical wisdom and starts announcing unused /8's - that won't prevent offenders from announcing more specific routes, will it? On the other hand, announcing /24's will really pollute the global routing table, which is big enough anyway.
Just announce those exact prefixes being announced by offenders. The prefix already appears in the routing tables so it won't increase the size of the table - just a slight memory increase for the extra paths. I don't think there are more than 100 such prefixes these days. -Hank
Still, having a service like Paul Vixie's AS7777 would help a lot: an ISP willing to receive blackhole routes would bring a route server on their backbone, establish a peering session with "IANA blackhole AS" and use the routes to construct filters etc.
Regards, Beri
Dear Hank, Hank Nussbacher wrote: [...]
The problem I foresee will be removing an ASN. RIPE has a policy of not changing mntner objects or overriding them so if the ASN just ignores RIPEs emails and continues to use the ASN - then what?
Yes, the RIPE NCC have such general policy indeed. But there are exceptions especially when it comes to conflicts with the RS data. If someone has a record in the Database that they have not been delegated this record will be deleted if necessary. Many of such records are from the old times when the database was much less secure. Regards, Andrei Robachevsky DB Group RIPE NCC
participants (5)
-
Adrian Bool -
Andrei Robachevsky -
Berislav Todorovic -
Christopher Sharp -
Hank Nussbacher