July 2002 - lir-wg - mailman.ripe.net

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

See the inline comment. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Vladimir A. Jakovenko [mailto:vovik@lucky.net] > Sent: Tuesday, July 09, 2002 4:16 PM > To: Lu, Ping > Cc: 'wtremmel(a)vianetworks.com'; 'Matthew Robinson'; Wilfried > Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > Subject: Re: [lir-wg] AS Number Policy > > > On Tue, Jul 09, 2002 at 03:57:49PM -0400, Lu, Ping wrote: > >Several examples: > > > >1. Confederate AS : only the top level AS number is > announced by design, all > >member ASes should not be visible outside the confederate. > > What is the reason (or advantage) in using AS numbers from > PUBLIC pool for > confederate ASes, if they are not visible outside of confederation? > Why do you think confederate AS should belong to the same company ? And you can force one of them to use private AS ? > >2. CIDR aggregate : If customer's address got aggregated by > upstream ISP, > >usually you won't see their AS numbers from the upstream ISP's CIDR > >(especially for those people like to filter on allocation boundary). > > Again - what is the reason in using AS numbers from PUBLIC pool for > customer's ASes if this ASes will never appear outside of upstream ISP > network? > Huh ? RIPE NCC always recommends that the end user should use PA address from the upstream ISP so only the less specific CIDR (with ISP's AS number) will appear in the GLOBAL routing table and the more specific prefixes (with end user's AS number) WON'T POLLUTE the GLOBAL routing table.Now in order to show their assigned AS numbers, end user will have to POLLUTE the GLOBAL routing table with their more specific prefixes. > I may imagine only one case - customer's AS peering with public IX. > Yes, IX is another example that AS is originated but not visible in the GLOBAL routing table. > >Technically I don't see how RIPE NCC can possibly find all > the ASes that are > >originated but invisible to the public route server. > > Agree. But there are also administrative possibilites. > > -- > Regards, > Vladimir. >

2 1

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

> -----Original Message----- > From: Christopher Sharp [mailto:ripe-lir-wg@chriss.net] > Sent: Wednesday, July 10, 2002 11:32 AM > To: lir-wg(a)ripe.net > Cc: Lu, Ping > Subject: Re: [lir-wg] AS Number Policy > > > On Wed, 10 Jul 2002 11:22:29 -0400, "Lu, Ping" <PLu(a)cw.net> wrote: > > >I don't think to blackholing traffic is a good idea, especially > >when bandwidth means money in today's internet. > > I agree. Neither do I think the community should be paying > to provide the > bandwidth for such a service. > > Encouraging people to filter out these netblocks/ASNs does > make it very hard to > re-allocate them in the short term. However, most people who > maintain good > bogon filters also update them frequently, so hopefully would > remove any such > filters in plenty of time for ASNs to be re-allocated after > 12/24/36 months. > The major ISPs usually update these filters daily and if the tier-1 ISPs all have these filters then smaller ISPs don't have to filter them again. > >RIRs should publish a list to include all the offending prefixes and > >the major ISPs will be more than happy to apply the prefix filter to > >block transit to those prefixes. There is already an IANA > bogon filter > >floating around. > > This was my suggestion in a nutshell. I believe the most > commonly observed > bogon list is maintained by Rob Thomas > (http://www.cymru.com/Documents/bogon-list.html). > draft-iana-special-ipv4-03 is > IANA's most comprehensive list of special use netblocks > (http://www.ietf.org/internet-drafts/draft-iana-special-ipv4-03.txt). > Maybe we can have an official filter-set object so people don't have to update these info manually. > >RIPE NCC could add a filter-set object, let's say > FLTR-RIPE-RESERVED-IPV4 > >and > >ARIN should have a FLTR-ARIN-RESERVED-IPV4 object, > >APNIC also should have a FLTR-APNIC-RESERVED-IPV4 object. > >Then all major ISPs could apply these filter to block > transit traffic for > >these > >prefixes. > > This sounds excellent but doesn't cover prefixes IANA have > not yet allocated to > an RIR. This is why I would encourage frequent sharing of > this data with the > networking community and especially the maintainers of public > bogon lists on > which many people filter. > In the IANA assigned RIR range, we still need RIRs to tell us what range under their authority are not allocated yet thus should be filtered. > >Blocking is a better idea than blackholing.... > > C. > Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

3 2

RE: [lir-wg] AS Number Policy
by Hank Nussbacher 10 Jul '02

10 Jul '02

At 11:22 AM 10-07-02 -0400, Lu, Ping wrote: > > -----Original Message----- > > From: Berislav Todorovic [mailto:beri@kpnqwest.net] > > Sent: Wednesday, July 10, 2002 6:38 AM > > To: Hank Nussbacher > > Cc: Christopher Sharp; lir-wg(a)ripe.net > > Subject: Re: [lir-wg] AS Number Policy > > > > > > 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. > >I don't think to blackholing traffic is a good idea, especially >when bandwidth means money in today's internet. > >RIRs should publish a list to include all the offending prefixes and >the major ISPs will be more than happy to apply the prefix filter to >block transit to those prefixes. There is already an IANA bogon filter >floating around. As mentioned earlier by someone, I'd hate to get an ASN or IP block that happened to be in the past inside such a published list. You can bet that somewhere, someplace, sometime, such a filter list will not be updated and will end up blocking someone inadvertantly. -Hank >RIPE NCC could add a filter-set object, let's say FLTR-RIPE-RESERVED-IPV4 >and >ARIN should have a FLTR-ARIN-RESERVED-IPV4 object, >APNIC also should have a FLTR-APNIC-RESERVED-IPV4 object. >Then all major ISPs could apply these filter to block transit traffic for >these >prefixes. > > > > > > 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 > > > >Blocking is a better idea than blackholing.... > >Ping Lu >Cable & Wireless USA >Network Tools and Analysis Group >W: +1-703-292-2359 >E: plu(a)cw.net

1 0

Re: [lir-wg] AS Number Policy
by Wilfried Woeber, UniVie/ACOnet 10 Jul '02

10 Jul '02

>Lets see the following example: > > +-----------+ +-------+ > | AS-UPLINK | | AS-IX | > +---------o-+ +o------+ > | | > +o-----------o+ > | AS-CUSTOMER | > +-------------+ > >[ ... ] > >Should AS-CUSTOMER be considered as multihomed? Definitely, as they'd probably have more then one eBPG session, and probably a different routing policy. I don't see any reason to treat "customer" status (i.e. packets shipped for money) different from "peering" status (i.e. packets shipped for "free"). >-- >Regards, >Vladimir. Wilfried.

3 3

Re: [lir-wg] AS Number Policy
by Wilfried Woeber, UniVie/ACOnet 10 Jul '02

10 Jul '02

>1. How long does the community believe it is reasonable to take to > bring an AS 'on-line'? What is the definiton of "on-line" here? Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

6 6

Re: [lir-wg] AS Number Policy
by Hank Nussbacher 10 Jul '02

10 Jul '02

On Tue, 9 Jul 2002, Christopher Sharp wrote: > On Tue, 09 Jul 2002 12:57:46 +0300, Hank Nussbacher <hank(a)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

5 7

Re: [lir-wg] AS Number Policy
by Wilfried Woeber, UniVie/ACOnet 10 Jul '02

10 Jul '02

>Again - what is the reason in using AS numbers from PUBLIC pool for >customer's ASes if this ASes will never appear outside of upstream ISP >network? How do you define "never" in today's or tomorrow's Internet ?! ;-) -w

2 1

RE: [lir-wg] AS Number Policy
by Lu, Ping 09 Jul '02

09 Jul '02

This has nothing to do with the private AS-number. If an AS number existed in our backbone (public to CW) but not to RIPE NCC's route server. Will that be considered NOT USED ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Wolfgang Tremmel, WT5-RIPE [mailto:wtremmel@vianetworks.com] > Sent: Tuesday, July 09, 2002 1:27 PM > To: Lu, Ping; 'Matthew Robinson'; Vladimir A. Jakovenko > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > Subject: RE: [lir-wg] AS Number Policy > > > If it is nowhere advertised you could use a privat AS-number... > > Wolfgang > > > > -----Original Message----- > > From: owner-lir-wg(a)ripe.net > [mailto:owner-lir-wg@ripe.net]On Behalf Of > > Lu, Ping > > Sent: Tuesday, July 09, 2002 6:55 PM > > To: 'Matthew Robinson'; Vladimir A. Jakovenko > > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > > Subject: RE: [lir-wg] AS Number Policy > > > > > > Definitely there is AS number being used within our backbone but not > > advertised to public > > network. So the AS number should be allowed to be registered but not > > advertised the same way > > as IP address is treated. > > > > Ping Lu > > Cable & Wireless USA > > Network Tools and Analysis Group > > W: +1-703-292-2359 > > E: plu(a)cw.net > > > > > > > > > -----Original Message----- > > > From: Matthew Robinson [mailto:matthew@crescent.org.uk] > > > Sent: Tuesday, July 09, 2002 9:57 AM > > > To: Vladimir A. Jakovenko > > > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > > > Subject: Re: [lir-wg] AS Number Policy > > > > > > > > > In the documentation for address space provision is made for > > > assigning addresses to organisations that will NEVER be > > > connected to the Internet but require uniqueness from private > > > address space. > > > > > > Whilst I can't think of a specific example to apply to AS > > > numbers, should this uniqueness be extended to AS numbers > > > that do not show up in the routing table but are very > much on-line? > > > > > > I also recon 3 months to get online although given the length > > > of time it can take a big comapany to integrate a small one > > > lets say 12 months for returning. > > > > > > Kind regards > > > > > > Matthew > > > >

2 1

Re: [lir-wg] AS Number Policy
by Wilfried Woeber, UniVie/ACOnet 09 Jul '02

09 Jul '02

Beri, I agree with most of your statements, in particular your assessment of the "credibility" of RIS data *) to base such important decisions on - as well as the suggestion to accept a "statement of use" as sufficient. However, doing so leaves me with a cost vs. benefit ratio for the whole exercise! I guess there is a considerably big number of AS#s the RIR/LIR tree does not have authority over (or rather: distribution predating existence of those structures). And, unless we have a _clear consensus_ that going through this exercise can avoid the introduction of AS#s with more than 16 bits _altogether_ (or at least extends the lifetime of the 16bit version *considerably*), the whole issue might be mute... Wilfried. *) this is not questioning the usefulness or utility of RIS data, but it seems to be the wrong tool for obtaining a reliable reading for this context. And I guess it's pretty easy to fake... ______________________________________________________________________ Date: Tue, 9 Jul 2002 15:33:53 +0200 (CEST) From: Berislav Todorovic <beri(a)kpnqwest.net> To: leo vegoda <leo(a)ripe.net> CC: lir-wg(a)ripe.net Subject: Re: [lir-wg] AS Number Policy On Tue, 9 Jul 2002, leo vegoda wrote: >> We would be grateful if the community would clarify the policy so >> that it is clear when an unused AS number should be returned to >> the pool. Let's try to summarize things a bit: this issue is not only about numbers and timescale. A complete AS number revokation policy must comprise of 4 components: * Audit policy on AS number usage. * Clear definition of policy violation. * Revoking AS numbers from customers violating AS number usage policies. * Reusing revoked AS numbers. RIPE NCC reserves the right to perform periodic audits on AS number usage and take appropriate actions if necessary, to enforce compliance with ripe-245 and RFC 1930. RIPE NCC will use RIS to check if an AS number is used with compliance with those documents. RIPE NCC must never consider RIS as the ultimate source and must always raise an audit ticket towards the LIR and/or an end customer of an AS before taking any further action. A possible violation of the policy happens if an AS number: (1) Does not appear in the routing table at all: (a) Assigned, but never appeared (startup case) within S months. (b) Missing completely for more than D months. (2) Appears in the routing table via a single AS path for more than M months. While we can discuss on the values of S, D and M special care must be taken on revokation and reusal policy. For (1a) - there seems to be a consensus that S would be 3 months. For (1b) - just to be on the safe side D should be at least 6 months. For (2) - also to be on the safe side M should be at least 12 months. If a violation if found, RIPE NCC reserves the right to notify the LIR that requested the AS number about violation and ask them to provide additional evidence that the AS number is still in valid use. A clear statement from the LIR that the AS number is still used in compliance with the policy MUST be enough to close the audit ticket. No further action should be taken in that case. If there is no response from the LIR, RIPE NCC should contact the admin-c and tech-c specified in the aut-num object. In a lot of cases an AS number is issued by a LIR that doesn't have anything to do with the customer any more. If no response counting from notification date is received from the end customer: * In the case (1a) - within 3 months, * In the case (1b) - within 6 months, * In the case (2) - within 12 months the AS number may be revoked by RIPE NCC. AS number reusage policy - a revoked AS number may be reused after certain period of time, defined as: * In the case (1a) - 3 months after it is revoked from the end customer. * In the case (1b) - same time period that elapsed between revokation date and initial assignment date of the AS number. That should give enough time to all people to cleanup their configurations, policies etc. * In the case (2) - same as (1b). Regards, Beri --------------------------------------------------------------------------------

1 0

AS Number Policy
by leo vegoda 09 Jul '02

09 Jul '02

Dear Colleagues, Within the RIPE community the AS policy (ripe-245) is based upon RFC 1930. The RIPE policy states that "a network [is required] to be multihomed for an AS number to be assigned". However, there is no clear policy on returning unused AS numbers to the pool. We would be grateful if the community would clarify the policy so that it is clear when an unused AS number should be returned to the pool. Specific questions we would like to ask are: 1. How long does the community believe it is reasonable to take to bring an AS 'on-line'? 2. After how many months of not being in use should an AS be returned? Due to a lack of time in the LIR Working Group session at RIPE 42 (May 2002) we were not able to discuss the community's policy for AS numbers. We would like to raise the issue now so that there is ample time for a discussion before RIPE 43, on Rhodes, in September. We welcome the community's input on this policy matter. Kind regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager

7 7