On Mon, 9 Jun 2003, John Brown wrote:
Fear leads to Hate, which leads to Evil, the way of the darkside ;)
RIR's are not and should not be in the business of dictating what goes into the routing table, or what label is used on what goes into the routing table.
Certainly not, but if the information we (isp's/Network operators) need to verify that our 'customer' has the right to route a block isn't correct or is easily subverted they have some responsibility there I'd think, right?
I think part of the issue here is that to many providers don't filter what they receive from their BGP speaking peer.
Hrm, I've heard this alot, and seen some other providers that clearly don't filter... but even more insidious are the ones that DO filter and rely on the information provided by an RIR to validate the 'ownership' of the blocks they build their filters for.
Its not that hard to build tools to drop known IANA reserved space packets, or even AS ranges.
that's not the issue here (or it wasn't the thrust of the original question atleast)
If we get into RIR's processing witch hunts, we run the strong and real risk of dropping real live users right off the net. Then that causes the risk for greater legal cost and exposure to happen.
Sure, this is true... so, how much is enough? and should the 'rules' still be applied equally, despite the fact that the nuns at Mother Jessica's Monestary who use Asn 8143 for upstream will get booted off the network because 8143 was hijacked?
At the end of the day, RIR's make sure the bit strings are unique, and that reasonable costs for do that job are covered in registration fees.
Its up to each provider to verify their BGP config and the data received from those peers.
Sure, you are announcing 196.1.1.0/24 and only that, fine, but are you allowed to announce that prefix? Are you "Centre for Monitoring Indian Economy" ?? Or is this your direct customer and you are just the sat-link provider for him?
If this was easy everyone would or could do it.
On Mon, Jun 09, 2003 at 05:12:26AM +0000, Christopher L. Morrow wrote:
So, with all this lifting the curtains on hijacked ASN's and ipblocks recently I have a few general question...
1) Should the rules be uniformly applied? 2) Should these rules be applied even when something 'bad' might happen? 3) How much involvment should ARIN have in enforcing these rules?
Now, by 'rules' I mean:
If you steal something you have to give it back, regardless of who you are.
So, for an example, if I steal ASN 8143 (already stolen so its mute) and I'm 'a good guy', all I want to do is run a network no spam/abuse eminates from it, should I be subject to the 'witch hunt' that my fellow ASN stealer who does abuse/spam deals with? The same is asked for hijacked ip space. If I steal/hijack a large netblock, not from an active org so there is no 'damage' done, and I don't spam/abuse from it should I be compelled to return it also? Compelled in the same way that my brother stealer who spams/abuses is?
I am not advocating one or the other, and to me the rules should apply to both groups (all theives treated equally)... I'm just curious as to the general thought on this subject.
Additionally, how should ARIN go about verifying proper 'ownership' (that I am still me after all these years of 'inactivity'), how much is enough research on these issues? I know that at the ISP there is a measure of trust placed on the customer, and upstream/downstream, when it comes to ASN's and ip announcements. ARIN is in the same position as near as I can tell. They have to trust that the community both is trustworthy (to an extent) and conscientious. If there are bad actors out there that go to enough trouble they can make ASN's or ip blocks appear to be registered to themselves. There may be breadcrumbs of evidence if you look hard enough, perhaps there won't be. How hard should ARIN be looking at these issues and at specific instances? Should they apply their rules without prejudice?
Sorry for the latenight not-completely-operational question :) but it seems as though there is some abmiguity in the current process/procedure/rules and I'd like to atleast start some discussion on the topic.
Thanks.
--Chris (chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################