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
Hello;
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
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.
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?