|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Deaggregating for emergency purposes
PR> Date: Mon, 5 Aug 2002 18:41:22 -0400 PR> From: Phil Rosenthal Bear with me... punchline at the end. PR> I am currently announcing only my aggregate routes, but I PR> have lately thought about the possibility of someone PR> mistakenly, or maliciously, announcing more specifics from my PR> space. PR> The best solution for an emergency response to that (that I PR> can think of), is registering all of the /24's that make up PR> my network, so if someone should announce a more-specific, I PR> can always announce the most specific that would be accepted PR> (assuming they don't announce the /24's too, it should be a PR> problem avoided) I don't think this is a valid assumption, particularly in the case of malicious route hijacking. Polluting IRRs with numerous deaggregated /24s for something with little/no benefit sounds like a bad idea to me. You advocate "s/he who dies with the shortest as-path, and oldest routes in case of a tie, wins". PR> Does anyone else have any other ideas on ways to quickly deal PR> with someone else announcing your more specifics, since PR> contacting their NOC is likely going to take a long time... Well, let's see... I wonder if this ever was a problem with domain jacking, and what a registrar would do in a similar scenario. Perhaps the answer is not to hear/announce routes blindly? First, make sure IRRs contain proper data. Maybe maintainer objects should be authorized by an ASN's POC, and both (maint-obj and ASN POC) require proper authorization (crypt/md5/aes or PGP). Use the IRRs. Granted, this will be a problem at the edge; small providers seem to take the attitude of "why should I pay to put my routes in the RADB when things 'work just fine' without?" Somewhere along the line, hopefully there will be an upstream or peer that uses the route registries. Let clueful providers cache a copy of the IRR databases. Run a BGP listener to cross-reference routes with IRR entries. In the event of a suspicious route, a real-time individual query might be useful. Flag routes that fail that test. I'll shut up now, lest I "invent" something that smellls too much like DNS. (Gee, maybe including some sort of "ASN authorized to advertise this IP space" in an-addr.arpa would be too easy.) Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <[email protected]> To: [email protected] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[email protected]>, or you are likely to be blocked.
|