- lir-wg - mailman.ripe.net

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

11 Jul '02

> -----Original Message----- > From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] > Sent: Thursday, July 11, 2002 6:41 AM > To: lir-wg(a)ripe.net > Subject: RE: [lir-wg] AS Number Policy > > > > > A customer can have a peer with the default transit, which > aggregates the > > adresspace from the customer, and the customer can have > other peerings > > via some ix:es, and the customer could perform transit > to/from the ix:es > > to the default transit, in this scenario the customer MUST > have a public > > AS, which you will not see in the public space, since > removing private > > AS in the AS-path will result in somewhat unpredictable > behaviour if there > > are several private AS involved at the customer premises. > > Yes, but this still makes the AS publicly visible. > > Best regards, > > - kurtis - > As we already seen some real examples, the correct USED ASN will only be seen from their upstream (it is public no matter what) but not outside to other peers (may due to CIDR, may due to inactive route). This has nothing to do with private ASN but make it impossible to enforce the proposed policy just by looking at the RIS. I agree that RIPE NCC need to have an ASN revoke policy but just can NOT based on the RIS info only. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

A quick question.
by Stephen Burley 11 Jul '02

11 Jul '02

HI I have a question about the RIPE meetings. Due to the nature of the business we are all in at the moment (myself probably more than others ATM), would it not be possable the webcast the RIPE meetings allowing input from outside via phone, email, or other means. The reason i ask this is that the meetings are open to all IF and its a big IF you can attend the meeting in the exotic locations we have met in the past. I am not against the meetings moving about and a meeting in Amsterdam will be just as hard to get to for some one in North Africa as a meeting in North Africa for those in Amsterdam. What i am asking is could we make it more accessable to those who for what ever reason (ahem) can not make the meeting, otherwise it might not have the coverage and diversity of people having input. Just a thought. Regards, Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE

2 1

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

11 Jul '02

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. 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). Technically I don't see how RIPE NCC can possibly find all the ASes that are originated but invisible to the public route server. 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 3:26 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 02:01:26PM -0400, Lu, Ping wrote: > >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 ? > > Could you possibly provide us with more examples in which > circumstances someone > may need to use AS number from the PUBLIC range instead of > using AS number from > PRIVATE range in the case when there is no need to advertise > any prefixes > originated by such AS-number to the PUBLIC Internet (i.e. > this AS number will > never be visible outside of some private network)? > > I can remind only one case - some kind of IX, are used by > some ASes to > exchange routing information localy. Generaly speaking IX-AS > may not be > visible from PUBLIC, but in the most cases, especialy if we > are talking > about enterprise networks, same results may be achieved by > using AS-number > from private range. > > By way of proof - AS15645 is used for the public Ukrainian > Internet-Exchange. > Appearance of any prefixes originated by this AS outside of > IX members networks > violates IX rules and should be avoided. > > Lets summarise - there ARE circumstances when AS number from > PUBLIC range may > be requested and used being invisible from the majority of > the Internet. > > It would be nice to mention that in policy and provide some examples. > > -- > Regards, > Vladimir. >

5 7

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

11 Jul '02

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 >

6 8

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

11 Jul '02

[snip] > > Yes. I had recently a lengthy "discussion" with RIPE hostmasters about > a multihomed AS of a customer. Primary upstream with us, secondary > upstream with AS702. Using 702:80 community to lower localpref within > 702, making the backup link real backup. As 702 announces best path > (which is via their peering to us to the customer), RIPE was unable to > see the 702 backup announcement anywhere. Explanation of BGP basics by > myself were not understood or ignored. Or both. They also did not > contact AS702 for simple confirmation of what I've told them. > Took three > or four emails to get that finally sorted out. Whom do I bill > those 30-45 > minutes to (rhetoric question)? ;-> > This is another good example why AS number is originated but invisible to the global routing table. > End of the story was that they finally said "We have found AS21197 in > the import policy of AS702 and going to close this ticket now." :-]]] > > IF they really want to enforce ASN assignment policy, they > should REALLY > have to have a clue about BGP. Looking at some random looking glasses > or RIS data and not understanding it is NOT enough for a > policy-enforcing agency. And someone should explain them the > difference > between a looking glass and a traceroute server. > > Let's say... Halabi as compulsary lecture for hostmasters who have to > evaluate ASN assignment policy compliance. :-) > > > Regards, > Daniel > It is almost impossible for RIPE NCC to look into all upstream ISP's routing table and verify that an AS is being used properly. If RIPE NCC can't find a way to reduce the false alarm of AS verification, the enforcement will become more likely an harassment. 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 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