True enough, but are there any providers currently that filter /24's from the old Class C space that /24's were assigned directly from? I realize that if proposal 2002-3 does get passed but everyone filters those prefixes then it will be a completely worthless proposal, and even worse than using PA space. It seems to me that proposal 2002-3 could enable providers to filter more efficiently however. They could accept the long prefixes out of the micro-assignment block, while filtering out all the garbage /24's in the other space caused by people needlessly announcing every /24 out of their large aggregate. Forrest On Wed, 15 Oct 2003, Andrew Dul wrote:
Forrest,
Even if ARIN passes this policy that will not make any provider change their filtering policy. It is true that many providers do use the ARIN allocation sizes to create their filtering rules but the two are not inherently linked. Any ASN can choose the filter on what ever rule set they choose.
Andrew
Hello; On Wednesday, October 15, 2003, at 11:57 PM, Forrest wrote:
True enough, but are there any providers currently that filter /24's from the old Class C space that /24's were assigned directly from?
As someone who is multihomed but uses others /24's, I am sensitive to this. I do not _think_ that any major provider filters on /24's now - but it's fairly common to filter on /25 and longer.
I realize that if proposal 2002-3 does get passed but everyone filters those prefixes then it will be a completely worthless proposal, and even worse than using PA space.
I had good luck contacting the ISP's that were filtering and asking them nicely not to. I think that providers will mostly follow ARIN's lead.
It seems to me that proposal 2002-3 could enable providers to filter more efficiently however. They could accept the long prefixes out of the micro-assignment block, while filtering out all the garbage /24's in the other space caused by people needlessly announcing every /24 out of their large aggregate.
I would agree.
Forrest
Regards Marshall Eubanks
On Wed, 15 Oct 2003, Andrew Dul wrote:
Forrest,
Even if ARIN passes this policy that will not make any provider change their filtering policy. It is true that many providers do use the ARIN allocation sizes to create their filtering rules but the two are not inherently linked. Any ASN can choose the filter on what ever rule set they choose.
Andrew
Regards Marshall Eubanks T.M. Eubanks e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Our New Video Service is in Beta testing http://www.americafree.tv
On the topic of announcing PA /24's, what procedures do you take to make sure that a new customer who want's to announce a few PA (P being one or more P's other than yourself) IP space is legit and should be announcing that IP space? I'm not sure what they do internally, but I know Sprint, C&W, UUNet, Genuity, Level3, MFN and Broadwing will all comply with a customer's request to route space with nothing in writing other than an email request / webform filled out / route objects properly setup. A client multihomed to a few of those providers (and who has a /24 from each provider) just signed up with a 4th provider. P4 wants an LOA on company letterhead from each other P authorizing the client to announce those other P's /24's. This is the first time I've ever heard of such precautions. The client was really not ammused, but I explained that it's possible P4 (who has a rep for doing business with spammers) has gotten burned by customers announcing hijacked (or otherwise unauthorized) blocks and just wants to be extra careful now. Personally, I just check whois, and if it looks legit, I'll listen to those routes and even create their route objects as necessary, since some of our upstreams require that. ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
jlewis wrote:
On the topic of announcing PA /24's, what procedures do you take to make sure that a new customer who want's to announce a few PA (P being one or more P's other than yourself) IP space is legit and should be announcing that IP space?
I'm also interested in hearing current practices on this for PA space, PI space, or whatever. With UUNet and Qwest all I've had to do is make a phone call. I don't know whether or not whois was checked before the changes were made. I think this is important because what seems to be the current, fairly-lax policies on this negates some of the benefit of edge anti-spoof filtering. If, for example, it's quick & easy to contact an ISP posing as a customer (or maybe the customer is doing the evil deeds themselves, so no posing is necessary) and get IP block X allowed through the ISP's BGP/anti-spoof filters for that customer, what good have the filters done? If we want ISPs to put forth the effort to deploy filters on all their edge links, it seems silly for it to be so easy for one to socially engineer their spoofed packets right through them.
Personally, I just check whois, and if it looks legit, I'll listen to those routes and even create their route objects as necessary, since some of our upstreams require that.
If everyone checked whois it would at least put an end to the unencouraging amount of unallocated prefixes one can find in the BGP tables at any given time. But it's also not difficult for someone with bad intentions to find space that is allocated per whois but not advertised by anyone. So it seems like additional verification steps may be needed if we're serious about wanting to put an end to spoofed packets. -Terry
A proposal was made some years ago, which I thought was by Tony Li, but, IIRC, he says it wasn't original with him. It does require cooperation from competitors, but can reduce the number of announcements. Under some circumstances, it may cause blackholing, but so can /24 filtering. The idea is to establish bilateral blocks of provider space. Let us say Provider A and Provider B recognize that they have a significant number of common multihomed customers. Arbitrarily, one of the providers (assume A) starts off with a block -- let's say a /19 or /20 to which both providers will assign their multihomed customers. A and B peer and send more-specifics to each other. To the outside world, however, A advertises its largest aggregate plus the multihomed block. B advertises this block of Provider A space as well as its own aggregates. If A and B do not peer, the likelihood of blackholes become much higher since they may not see the more-specifics in the multihomed block. Has anyone reexamined this proposal lately?
participants (5)
-
Forrest -
Howard C. Berkowitz -
jlewis＠lewis.org -
Marshall Eubanks -
Terry Baranski