I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided) Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time... --Phil
seems a hack. what if they announce a /24 from your space and they mostly have shorter path lengths? you still lose... Steve On Mon, 5 Aug 2002, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
--Phil
On Mon Aug 05, 2002 at 11:45:05PM +0100, Stephen J. Wilcox wrote:
seems a hack. what if they announce a /24 from your space and they mostly have shorter path lengths? you still lose...
Advertise the /24 yourself, and 2 * /25, and hope. I had to do this recently, due to a certain ISP in .au advertising a /24 from our space, and it actually worked remarkably well. To their credit, the ISP were also pretty responsive about fixing the problem. Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart@bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/
Well.... I can announce /27s or even /32s... but who will listen?
seems a hack. what if they announce a /24 from your space and they mostly have shorter path lengths? you still lose...
Steve
On Mon, 5 Aug 2002, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
--Phil
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
Seems like a remarkable waste of time and IRR resources. That is why NOCs exist, so you can contact them quickly and make those announcements stop. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
I had a problem in the past with Telia announcing sub aggregates from my space, and even after getting in touch with their American NOC, I was told "you need to contact our NOC in Europe" When doing that, I had difficulty finding someone who spoke English -- needless to say, it took a few hours to get that fixed. Because I hadn't put more specifics in the IRR, I had no choice but to just sit and deal with NOC employees who couldn't care less. You thing trusting another NOC with *YOUR* uptime is a better idea than taking control? --Phil -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Richard A Steenbergen Sent: Monday, August 05, 2002 6:53 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
Seems like a remarkable waste of time and IRR resources. That is why NOCs exist, so you can contact them quickly and make those announcements stop. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd way of handling it. On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
--Phil
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult to contact as well? --Phil -----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd way of handling it. On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
--Phil
I usually don't play the "what if" game, as there will always be exception, but. ... If the upstream provider is obscure, remote, or incompetent odds are their A S path is equally obscure, remote, or incompetent. A subsection of the globe may by holed until reasonable parties can be contacted. Advertising deaggragated ro utes my be a viable temporary solution for misconfigurations--and other than a f ew angelic engineers, no one would fault you--but malevolent configurations woul d most certainly be /24. I believe a discussion once occurred here advocating BG P authentication using some distributed source for AS verification, and while I believe such a process is feasible, I advocate an open community in a heirarchic al model to enforce good policy. HMM, I swear I had a point when I started... -- sig=$header Phil Rosenthal(pr@isprime.com)@2002.08.05 21:00:55 +0000:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult to contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd way of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
--Phil
Yes, obscure places will feel the "pain" of their error more than others. Personally, I haven't seen this be a real problem. Eg, not a once a month major melt down type of an issue. john brown chagres technologies, inc On Mon, Aug 05, 2002 at 09:23:47PM -0500, jnull wrote:
I usually don't play the "what if" game, as there will always be exception, but. ... If the upstream provider is obscure, remote, or incompetent odds are their A S path is equally obscure, remote, or incompetent. A subsection of the globe may by holed until reasonable parties can be contacted. Advertising deaggragated ro utes my be a viable temporary solution for misconfigurations--and other than a f ew angelic engineers, no one would fault you--but malevolent configurations woul d most certainly be /24. I believe a discussion once occurred here advocating BG P authentication using some distributed source for AS verification, and while I believe such a process is feasible, I advocate an open community in a heirarchic al model to enforce good policy.
HMM, I swear I had a point when I started...
-- sig=$header
Phil Rosenthal(pr@isprime.com)@2002.08.05 21:00:55 +0000:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult to contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd way of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
--Phil
get on the bandwaggon that filtering is a good thing ?? :) at some point some transit is going to listen and drop the announcement. Lets take an example. Deep Dark middle of asia, someone starts announcing a /24 of yours. Their upstream takes the packet, and so forth. At some point they will touch a NSP or ISP (international service provider) and you can get things dropped their. Your pushing out a /24 will help slurp some of the traffic towards you, but not all. Personally I have deagged some prefixes to cause a DOS/DDOS towards a particular address to route down a slow connection I had. Sacrifice one link, to keep customers running on the others. But thats different. Its about networking, the people kind, at this point. cheers john brown chagres technologies, inc On Mon, Aug 05, 2002 at 09:00:55PM -0400, Phil Rosenthal wrote:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult to contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd way of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
--Phil
What about announcing and registering with your IRR, more-specific routes for the period that the problem ONLY exists, instead of being lazy? If all else fails, break out Outlook and your favorite translator, because last time I checked, speaking English was not a requirement to run a network. Even if most of you do, this is not a "Majority Rules" situation. On Mon, Aug 05, 2002 at 10:47:33PM -0700, john@chagresventures.com wrote:
get on the bandwaggon that filtering is a good thing ?? :)
at some point some transit is going to listen and drop the announcement.
Lets take an example. Deep Dark middle of asia, someone starts announcing a /24 of yours. Their upstream takes the packet, and so forth. At some point they will touch a NSP or ISP (international service provider) and you can get things dropped their.
Yes. End of story. Go directly to the finish diamond at the end of your flowchart. If the next step in your flowchart is "pollute IRRs with 3592375238957235893275839572 /32s", please return your maintainer object.
Your pushing out a /24 will help slurp some of the traffic towards you, but not all.
Personally I have deagged some prefixes to cause a DOS/DDOS towards a particular address to route down a slow connection I had. Sacrifice one link, to keep customers running on the others. But thats different.
Yes, but you removed it later on, correct?
Its about networking, the people kind, at this point.
cheers
john brown chagres technologies, inc
On Mon, Aug 05, 2002 at 09:00:55PM -0400, Phil Rosenthal wrote:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult to contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd way of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
--Phil
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
Based on my experience with the BGP misconfiguration study http://www.cs.washington.edu/homes/ratul/bgp/index.html I can say that this is not an idle worry. We saw about 15 hijack incidents (mostly of more-specifics, but full prefixes too) per day. We used route-views data, so even if hijacks come from middle of asia (some did, not all), they did make it to the tables of some major providers. On Tue, 6 Aug 2002, Omachonu Ogali wrote:
If all else fails, break out Outlook and your favorite translator, because last time I checked, speaking English was not a requirement to run a network. Even if most of you do, this is not a "Majority Rules" situation.
This too is a concern when depending on foreign nocs to take action. I ran into many non-english speaking nocs; mainly in south america. -- Ratul On Tue, 6 Aug 2002, Omachonu Ogali wrote:
What about announcing and registering with your IRR, more-specific routes for the period that the problem ONLY exists, instead of being lazy?
If all else fails, break out Outlook and your favorite translator, because last time I checked, speaking English was not a requirement to run a network. Even if most of you do, this is not a "Majority Rules" situation.
On Mon, Aug 05, 2002 at 10:47:33PM -0700, john@chagresventures.com wrote:
get on the bandwaggon that filtering is a good thing ?? :)
at some point some transit is going to listen and drop the announcement.
Lets take an example. Deep Dark middle of asia, someone starts announcing a /24 of yours. Their upstream takes the packet, and so forth. At some point they will touch a NSP or ISP (international service provider) and you can get things dropped their.
Yes. End of story. Go directly to the finish diamond at the end of your flowchart. If the next step in your flowchart is "pollute IRRs with 3592375238957235893275839572 /32s", please return your maintainer object.
Your pushing out a /24 will help slurp some of the traffic towards you, but not all.
Personally I have deagged some prefixes to cause a DOS/DDOS towards a particular address to route down a slow connection I had. Sacrifice one link, to keep customers running on the others. But thats different.
Yes, but you removed it later on, correct?
Its about networking, the people kind, at this point.
cheers
john brown chagres technologies, inc
On Mon, Aug 05, 2002 at 09:00:55PM -0400, Phil Rosenthal wrote:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult to contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd way of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
--Phil
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
On Tue, Aug 06, 2002 at 03:59:50AM -0400, Omachonu Ogali wrote:
What about announcing and registering with your IRR, more-specific routes for the period that the problem ONLY exists, instead of being lazy?
Secondly, show me a ISP that updates their filters with IRR data every 60 seconds. So even if you do pollute the IRRs, it won't hit filters until the next morning, and during that period you could have fired off 2390573295827598 e-mails to 3472398473298 of their upstreams (assuming this is a large misconfigured network).
If all else fails, break out Outlook and your favorite translator, because last time I checked, speaking English was not a requirement to run a network. Even if most of you do, this is not a "Majority Rules" situation.
On Mon, Aug 05, 2002 at 10:47:33PM -0700, john@chagresventures.com wrote:
get on the bandwaggon that filtering is a good thing ?? :)
at some point some transit is going to listen and drop the announcement.
Lets take an example. Deep Dark middle of asia, someone starts announcing a /24 of yours. Their upstream takes the packet, and so forth. At some point they will touch a NSP or ISP (international service provider) and you can get things dropped their.
Yes. End of story. Go directly to the finish diamond at the end of your flowchart. If the next step in your flowchart is "pollute IRRs with 3592375238957235893275839572 /32s", please return your maintainer object.
Your pushing out a /24 will help slurp some of the traffic towards you, but not all.
Personally I have deagged some prefixes to cause a DOS/DDOS towards a particular address to route down a slow connection I had. Sacrifice one link, to keep customers running on the others. But thats different.
Yes, but you removed it later on, correct?
Its about networking, the people kind, at this point.
cheers
john brown chagres technologies, inc
On Mon, Aug 05, 2002 at 09:00:55PM -0400, Phil Rosenthal wrote:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult to contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd way of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or maliciously, announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting their NOC is likely going to take a long time...
--Phil
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
Most ISPs that build off of the IRR's do it nightly. I am talking about 10 /24's out of /19, and I'm not announcing any of the /24's -- and wont unless there is an emergency, and only then would it be temporary. --Phil -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Omachonu Ogali Sent: Tuesday, August 06, 2002 4:00 AM To: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes What about announcing and registering with your IRR, more-specific routes for the period that the problem ONLY exists, instead of being lazy? If all else fails, break out Outlook and your favorite translator, because last time I checked, speaking English was not a requirement to run a network. Even if most of you do, this is not a "Majority Rules" situation. On Mon, Aug 05, 2002 at 10:47:33PM -0700, john@chagresventures.com wrote:
get on the bandwaggon that filtering is a good thing ?? :)
at some point some transit is going to listen and drop the announcement.
Lets take an example. Deep Dark middle of asia, someone starts announcing a /24 of yours. Their upstream takes the packet, and so forth. At some point they will touch a NSP or ISP (international service provider) and you can get things dropped their.
Yes. End of story. Go directly to the finish diamond at the end of your flowchart. If the next step in your flowchart is "pollute IRRs with 3592375238957235893275839572 /32s", please return your maintainer object.
Your pushing out a /24 will help slurp some of the traffic towards you, but not all.
Personally I have deagged some prefixes to cause a DOS/DDOS towards a particular address to route down a slow connection I had. Sacrifice one link, to keep customers running on the others. But thats different.
Its about networking, the people kind, at this point.
cheers
john brown chagres technologies, inc
On Mon, Aug 05, 2002 at 09:00:55PM -0400, Phil Rosenthal wrote:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult to contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd
way
of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or
maliciously,
announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting
Yes, but you removed it later on, correct? their
NOC is likely going to take a long time...
--Phil
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
You should check that your upstream router vendor can handle the increased config size. You are lucky to have as much as 512k config mem on a router let alone 2M+ as is necessary for some people that do IRR based filtering. This is something everyone should keep in mind doing vendor selection these days... - Jared On Tue, Aug 06, 2002 at 01:29:58PM -0400, Phil Rosenthal wrote:
Most ISPs that build off of the IRR's do it nightly. I am talking about 10 /24's out of /19, and I'm not announcing any of the /24's -- and wont unless there is an emergency, and only then would it be temporary.
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Speaking of that, anyone know of the config mem size on a Cisco 6509, a Foundry Bigiron, a Juniper M40 for example? --Phil -----Original Message----- From: Jared Mauch [mailto:jared@puck.nether.net] Sent: Tuesday, August 06, 2002 1:38 PM To: Phil Rosenthal Cc: 'Omachonu Ogali'; nanog@merit.edu Subject: Re: Deaggregating for emergency purposes You should check that your upstream router vendor can handle the increased config size. You are lucky to have as much as 512k config mem on a router let alone 2M+ as is necessary for some people that do IRR based filtering. This is something everyone should keep in mind doing vendor selection these days... - Jared On Tue, Aug 06, 2002 at 01:29:58PM -0400, Phil Rosenthal wrote:
Most ISPs that build off of the IRR's do it nightly. I am talking about 10 /24's out of /19, and I'm not announcing any of the /24's -- and wont unless there is an emergency, and only then would it be temporary.
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Tue, 6 Aug 2002, Phil Rosenthal wrote:
Speaking of that, anyone know of the config mem size on a Cisco 6509
512k NVRAM -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli ------------------------------------------------------------------------------- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
On Tue, Aug 06, 2002 at 01:29:58PM -0400, Phil Rosenthal wrote:
Most ISPs that build off of the IRR's do it nightly. I am talking about 10 /24's out of /19, and I'm not announcing any of the /24's -- and wont unless there is an emergency, and only then would it be temporary.
Yes, and during that time, you could have: a) Gone to CompUSA and bought some translation software. b) Installed Windows and Office XP. c) E-mailed some friends in fluid Spanish/German/Italian. d) Bought a $10 international calling card. e) Gone back to CompUSA and bought some text to speech software. f) Put it all together in an e-mail to the ISP's upstreams, and blasted the NOC's phone with a translated message of "Stop announcing 192.168.0.0/16, it is my space". And once again, if the ISPs in question receiving the routes actually filtered based on IRR data, the route would not have made it in the first place, correct? So how is IRR pollution going to help this if there's no IRR filtering policy to begin with?
--Phil
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Omachonu Ogali Sent: Tuesday, August 06, 2002 4:00 AM To: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
What about announcing and registering with your IRR, more-specific routes for the period that the problem ONLY exists, instead of being lazy?
If all else fails, break out Outlook and your favorite translator, because last time I checked, speaking English was not a requirement to run a network. Even if most of you do, this is not a "Majority Rules" situation.
On Mon, Aug 05, 2002 at 10:47:33PM -0700, john@chagresventures.com wrote:
get on the bandwaggon that filtering is a good thing ?? :)
at some point some transit is going to listen and drop the announcement.
Lets take an example. Deep Dark middle of asia, someone starts announcing a /24 of yours. Their upstream takes the packet, and so forth. At some point they will touch a NSP or ISP (international service provider) and you can get things dropped their.
Yes. End of story. Go directly to the finish diamond at the end of your flowchart. If the next step in your flowchart is "pollute IRRs with 3592375238957235893275839572 /32s", please return your maintainer object.
Your pushing out a /24 will help slurp some of the traffic towards you, but not all.
Personally I have deagged some prefixes to cause a DOS/DDOS towards a particular address to route down a slow connection I had. Sacrifice one link, to keep customers running on the others. But thats different.
Yes, but you removed it later on, correct?
Its about networking, the people kind, at this point.
cheers
john brown chagres technologies, inc
On Mon, Aug 05, 2002 at 09:00:55PM -0400, Phil Rosenthal wrote:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult to contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd
of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or
maliciously,
announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting
way their
NOC is likely going to take a long time...
--Phil
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
IRR pollution helps because all of *MY* uplinks filter, even if theirs don't. --Phil -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of nanog@missnglnk.com Sent: Tuesday, August 06, 2002 1:57 PM To: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes On Tue, Aug 06, 2002 at 01:29:58PM -0400, Phil Rosenthal wrote:
Most ISPs that build off of the IRR's do it nightly. I am talking about 10 /24's out of /19, and I'm not announcing any of the /24's -- and wont unless there is an emergency, and only then would it be temporary.
Yes, and during that time, you could have: a) Gone to CompUSA and bought some translation software. b) Installed Windows and Office XP. c) E-mailed some friends in fluid Spanish/German/Italian. d) Bought a $10 international calling card. e) Gone back to CompUSA and bought some text to speech software. f) Put it all together in an e-mail to the ISP's upstreams, and blasted the NOC's phone with a translated message of "Stop announcing 192.168.0.0/16, it is my space". And once again, if the ISPs in question receiving the routes actually filtered based on IRR data, the route would not have made it in the first place, correct? So how is IRR pollution going to help this if there's no IRR filtering policy to begin with?
--Phil
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Omachonu Ogali Sent: Tuesday, August 06, 2002 4:00 AM To: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
What about announcing and registering with your IRR, more-specific routes for the period that the problem ONLY exists, instead of being lazy?
If all else fails, break out Outlook and your favorite translator, because last time I checked, speaking English was not a requirement to
run a network. Even if most of you do, this is not a "Majority Rules" situation.
On Mon, Aug 05, 2002 at 10:47:33PM -0700, john@chagresventures.com wrote:
get on the bandwaggon that filtering is a good thing ?? :)
at some point some transit is going to listen and drop the announcement.
Lets take an example. Deep Dark middle of asia, someone starts announcing a /24 of yours. Their upstream takes the packet, and so forth. At some point they will touch a NSP or ISP (international service provider) and you can get things dropped their.
Yes. End of story. Go directly to the finish diamond at the end of your flowchart. If the next step in your flowchart is "pollute IRRs with 3592375238957235893275839572 /32s", please return your maintainer
object.
Your pushing out a /24 will help slurp some of the traffic towards you, but not all.
Personally I have deagged some prefixes to cause a DOS/DDOS towards a particular address to route down a slow connection I had. Sacrifice one link, to keep customers running on the others. But thats different.
Yes, but you removed it later on, correct?
Its about networking, the people kind, at this point.
cheers
john brown chagres technologies, inc
On Mon, Aug 05, 2002 at 09:00:55PM -0400, Phil Rosenthal wrote:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult
contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd way of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or
maliciously,
announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting
to their
NOC is likely going to take a long time...
--Phil
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
On Tue, Aug 06, 2002 at 02:07:13PM -0400, Phil Rosenthal wrote:
IRR pollution helps because all of *MY* uplinks filter, even if theirs don't. --Phil
*sigh* Here is one example of why IRR polution will not work: --snip-- route: 198.41.0.0/24 descr: PNAP-WDC netsol-2 origin: AS19836 mnt-by: INAP-MAINT-RADB changed: shawnb@internap.com 20010313 source: RADB route: 198.41.0.0/24 descr: Inic-route origin: AS6245 mnt-by: INIC-MAINT-MCI changed: mkaras@internic.net 19990406 source: CW route: 198.41.0.0/24 descr: HarvardNet Transit Client route object origin: AS6082 mnt-by: HARVARDNET changed: hluu@harvardnet.com 20010129 source: CW route: 198.41.0.0/24 descr: PNAP-WDC descr: netsol-2 origin: AS19836 mnt-by: INAP-MAINT-MCI changed: shawnb@internap.com 20010313 source: CW route: 198.41.0.0/24 descr: Proxy-registered route object for Sprint :-) origin: AS11840 remarks: auto-generated route object remarks: this next line gives the robot something to recognize remarks: The quick brown fox jumped over the lazy dog. remarks: remarks: This route object is for a Sprint customer route remarks: which is being exported under this origin AS. remarks: remarks: This route object was created because no existing remarks: route object with the same origin was found, and remarks: we really just wanted to help out those poor Sprint remarks: folks who have an aversion to registering routes. remarks: remarks: We hope they have a sense of humor. remarks: remarks: Please contact WeLoveThoseCrazySprintFolks@Level3.net remarks: if you have any questions regarding this object. mnt-by: SPRINT-MNT changed: WeLoveThoseCrazySprintFolks@Level3.net 20020319 source: LEVEL3 --snip-- Two, you're betting on everyone setting a high value for their local-preference with Verio and Peer1, you don't know who prefers who. But hey, I give up, this conversation is most likely going to continue in the form of a circle.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of nanog@missnglnk.com Sent: Tuesday, August 06, 2002 1:57 PM To: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
On Tue, Aug 06, 2002 at 01:29:58PM -0400, Phil Rosenthal wrote:
Most ISPs that build off of the IRR's do it nightly. I am talking about 10 /24's out of /19, and I'm not announcing any of the /24's -- and wont unless there is an emergency, and only then would it be temporary.
Yes, and during that time, you could have: a) Gone to CompUSA and bought some translation software. b) Installed Windows and Office XP. c) E-mailed some friends in fluid Spanish/German/Italian. d) Bought a $10 international calling card. e) Gone back to CompUSA and bought some text to speech software. f) Put it all together in an e-mail to the ISP's upstreams, and blasted the NOC's phone with a translated message of "Stop announcing 192.168.0.0/16, it is my space".
And once again, if the ISPs in question receiving the routes actually filtered based on IRR data, the route would not have made it in the first place, correct? So how is IRR pollution going to help this if there's no IRR filtering policy to begin with?
--Phil
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Omachonu Ogali Sent: Tuesday, August 06, 2002 4:00 AM To: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
What about announcing and registering with your IRR, more-specific routes for the period that the problem ONLY exists, instead of being lazy?
If all else fails, break out Outlook and your favorite translator, because last time I checked, speaking English was not a requirement to
run a network. Even if most of you do, this is not a "Majority Rules" situation.
On Mon, Aug 05, 2002 at 10:47:33PM -0700, john@chagresventures.com wrote:
get on the bandwaggon that filtering is a good thing ?? :)
at some point some transit is going to listen and drop the announcement.
Lets take an example. Deep Dark middle of asia, someone starts announcing a /24 of yours. Their upstream takes the packet, and so forth. At some point they will touch a NSP or ISP (international service provider) and you can get things dropped their.
Yes. End of story. Go directly to the finish diamond at the end of your flowchart. If the next step in your flowchart is "pollute IRRs with 3592375238957235893275839572 /32s", please return your maintainer
object.
Your pushing out a /24 will help slurp some of the traffic towards you, but not all.
Personally I have deagged some prefixes to cause a DOS/DDOS towards a particular address to route down a slow connection I had. Sacrifice one link, to keep customers running on the others. But thats different.
Yes, but you removed it later on, correct?
Its about networking, the people kind, at this point.
cheers
john brown chagres technologies, inc
On Mon, Aug 05, 2002 at 09:00:55PM -0400, Phil Rosenthal wrote:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult
contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd way of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or
maliciously,
announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting
to their
NOC is likely going to take a long time...
--Phil
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
At 1:57 PM -0400 2002/08/06, nanog@missnglnk.com wrote:
Yes, and during that time, you could have: a) Gone to CompUSA and bought some translation software. b) Installed Windows and Office XP. c) E-mailed some friends in fluid Spanish/German/Italian.
I've used translation software. I live in a country that has three official languages, one of which is not supported by any translation software that I have found. Of the languages that are supported, the translation is -- at best -- a joke. It might give you kinda-semi-sorta an idea of what the other person was trying to say. However, if you try to use it to translate something that you have written, it doesn't come anywhere remotely close to producing something that you would ever want anyone to see. Trust me. I only ever used it once or twice, and then I got laughed out of the building. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
PR> Date: Tue, 6 Aug 2002 13:29:58 -0400 PR> From: Phil Rosenthal PR> Most ISPs that build off of the IRR's do it nightly. I am PR> talking about 10 /24's out of /19, and I'm not announcing any PR> of the /24's -- and wont unless there is an emergency, and PR> only then would it be temporary. How did you arrive at 10x /24's? What about when someone else has a shorter as-path, or it gets to "oldest route wins"? Polluting the IRRs for little/no benefit is a bad thing. 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 <blacklist@brics.com> To: blacklist@brics.com 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 <blacklist@brics.com>, or you are likely to be blocked.
I only have 10 /24's that are absolutely mission critical to keep up. We have scaled back our IP usage, and we are a lot more efficient than we were before about the IP space. We are pretty well connected, so I would bet we would have a shorter AS path than many other networks (particularly ones that would make a mistake like that). --Phil -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of E.B. Dreger Sent: Tuesday, August 06, 2002 1:59 PM To: nanog@merit.edu Subject: RE: Deaggregating for emergency purposes PR> Date: Tue, 6 Aug 2002 13:29:58 -0400 PR> From: Phil Rosenthal PR> Most ISPs that build off of the IRR's do it nightly. I am talking PR> about 10 /24's out of /19, and I'm not announcing any of the /24's PR> -- and wont unless there is an emergency, and only then would it be PR> temporary. How did you arrive at 10x /24's? What about when someone else has a shorter as-path, or it gets to "oldest route wins"? Polluting the IRRs for little/no benefit is a bad thing. 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 <blacklist@brics.com> To: blacklist@brics.com 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 <blacklist@brics.com>, or you are likely to be blocked.
PR> Date: Tue, 6 Aug 2002 14:12:41 -0400 PR> From: Phil Rosenthal PR> I only have 10 /24's that are absolutely mission critical to PR> keep up. We have scaled back our IP usage, and we are a lot PR> more efficient than we were before about the IP space. So explain how this is superior to DNS entr(y|ies) stating who your peers and upstreams are. And there's nothing to say that one could not specify allowed filters in DNS, too. If someone wants me to advertise 192.168.7/24, and DNS indicates the proper netblock is 192.168.0/19 and their ASN is not origin or adjacent hop, I'll be suspicious. What I do from there becomes a policy question; I probably would contact the IP block owner to verify the request. PR> We are pretty well connected, so I would bet we would have a PR> shorter AS path than many other networks (particularly ones PR> that would make a mistake like that). I see. Clueless and malicious people never buy from the big ASNs. If said large ASNs don't filter, you still have a problem. If they do, your problem is closer to the edge... the as-path to reach the "real" you will be longer than the imposter at those points. 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 <blacklist@brics.com> To: blacklist@brics.com 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 <blacklist@brics.com>, or you are likely to be blocked.
--- So explain how this is superior to DNS entr(y|ies) stating who your peers and upstreams are. And there's nothing to say that one could not specify allowed filters in DNS, too. If someone wants me to advertise 192.168.7/24, and DNS indicates the proper netblock is 192.168.0/19 and their ASN is not origin or adjacent hop, I'll be suspicious. What I do from there becomes a policy question; I probably would contact the IP block owner to verify the request. --- My way isn't superior at all to a secure BGP solution, but until that exists, I need a choice. I am definitely on the bandwagon for the need for a secure BGP. --Phil
Phil, You would think, after hearing about 30 people with clue+++ talk, you may realize that this is a patently *bad* thing and should not be done. If your route's are being hijacked you can generally solve your problems in 2-5 phone calls...That's all it's *ever* taken me. 1. Call their NOC. 2. If not helpful call their upstream. 3. Call a couple of Tier 1's who are transit for their upstream, and have them filter it. Done deal, in the time that you've managed to call your ISP and (maybe) gotten about half the internet to reach you, you've solved the problem for the whole net and have ZERO reachability concerns. This is my first and last post to this ridiculous thread. Derek -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Phil Rosenthal Sent: Tuesday, August 06, 2002 2:44 PM To: 'E.B. Dreger'; nanog@merit.edu Subject: RE: Deaggregating for emergency purposes --- So explain how this is superior to DNS entr(y|ies) stating who your peers and upstreams are. And there's nothing to say that one could not specify allowed filters in DNS, too. If someone wants me to advertise 192.168.7/24, and DNS indicates the proper netblock is 192.168.0/19 and their ASN is not origin or adjacent hop, I'll be suspicious. What I do from there becomes a policy question; I probably would contact the IP block owner to verify the request. --- My way isn't superior at all to a secure BGP solution, but until that exists, I need a choice. I am definitely on the bandwagon for the need for a secure BGP. --Phil
Yes, it is lovely when things work out like that. My one experience with this problem was with Telia announcing my more specifics, and their US NOC referred me to their Europe NOC, and there no one spoke English. They are a tier1, so they don't have any upstream to call. It took 20 phone calls and more than an hour to get to someone who cared enough to do anything about it. --Phil -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Derek Samford Sent: Tuesday, August 06, 2002 2:51 PM To: pr@isprime.com; 'E.B. Dreger'; nanog@merit.edu Subject: RE: Deaggregating for emergency purposes Phil, You would think, after hearing about 30 people with clue+++ talk, you may realize that this is a patently *bad* thing and should not be done. If your route's are being hijacked you can generally solve your problems in 2-5 phone calls...That's all it's *ever* taken me. 1. Call their NOC. 2. If not helpful call their upstream. 3. Call a couple of Tier 1's who are transit for their upstream, and have them filter it. Done deal, in the time that you've managed to call your ISP and (maybe) gotten about half the internet to reach you, you've solved the problem for the whole net and have ZERO reachability concerns. This is my first and last post to this ridiculous thread. Derek -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Phil Rosenthal Sent: Tuesday, August 06, 2002 2:44 PM To: 'E.B. Dreger'; nanog@merit.edu Subject: RE: Deaggregating for emergency purposes --- So explain how this is superior to DNS entr(y|ies) stating who your peers and upstreams are. And there's nothing to say that one could not specify allowed filters in DNS, too. If someone wants me to advertise 192.168.7/24, and DNS indicates the proper netblock is 192.168.0/19 and their ASN is not origin or adjacent hop, I'll be suspicious. What I do from there becomes a policy question; I probably would contact the IP block owner to verify the request. --- My way isn't superior at all to a secure BGP solution, but until that exists, I need a choice. I am definitely on the bandwagon for the need for a secure BGP. --Phil
PR> Date: Tue, 6 Aug 2002 14:59:15 -0400 PR> From: Phil Rosenthal PR> My one experience with this problem was with Telia announcing PR> my more specifics, and their US NOC referred me to their PR> Europe NOC, and there no one spoke English. They are a PR> tier1, so they don't have any upstream to call. It took 20 PR> phone calls and more than an hour to get to someone who cared PR> enough to do anything about it. What if I local-pref Telia up or have a shorter as-path via them? them? And, ignoring local-pref and as-path, the older routes would have beaten your newly-added more specifics. Note also the delay time for IRR-based filters to update. What you suggested rarely will help anything. It always will cause a mess. Messes are harder to maintain, and cause problems of their own. The Internet needs to be built on well-designed systems, not kludges. I think everyone here wants a workable answer. I also think that Bill (I don't know him, but I think it's safe to say he's very clueful, and personally respect his credentials) is much closer to the right answer. Several people have pointed out flaws with IRR cruft. Please look at Bill's paper, and try pointing out flaws in it. Don't make <Internet - you> bear the weight for something that can be solved with <you> carrying the load. This theme sounds familiar... Alas, this is becoming circular and repetitious, as Omachonu noted. My last post unless I have something new to add. 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 <blacklist@brics.com> To: blacklist@brics.com 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 <blacklist@brics.com>, or you are likely to be blocked.
Whats a tier 1?? ps: follow the AS path, call AS's in the path from the bad announcment. Get the peers to stop receiving it. it might be wack-a-mole, but thats part of the job.. On Tue, Aug 06, 2002 at 02:59:15PM -0400, Phil Rosenthal wrote:
Yes, it is lovely when things work out like that. My one experience with this problem was with Telia announcing my more specifics, and their US NOC referred me to their Europe NOC, and there no one spoke English. They are a tier1, so they don't have any upstream to call. It took 20 phone calls and more than an hour to get to someone who cared enough to do anything about it.
--Phil
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Derek Samford Sent: Tuesday, August 06, 2002 2:51 PM To: pr@isprime.com; 'E.B. Dreger'; nanog@merit.edu Subject: RE: Deaggregating for emergency purposes
Phil, You would think, after hearing about 30 people with clue+++ talk, you may realize that this is a patently *bad* thing and should not be done. If your route's are being hijacked you can generally solve your problems in 2-5 phone calls...That's all it's *ever* taken me. 1. Call their NOC. 2. If not helpful call their upstream. 3. Call a couple of Tier 1's who are transit for their upstream, and have them filter it. Done deal, in the time that you've managed to call your ISP and (maybe) gotten about half the internet to reach you, you've solved the problem for the whole net and have ZERO reachability concerns. This is my first and last post to this ridiculous thread.
Derek
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Phil Rosenthal Sent: Tuesday, August 06, 2002 2:44 PM To: 'E.B. Dreger'; nanog@merit.edu Subject: RE: Deaggregating for emergency purposes
--- So explain how this is superior to DNS entr(y|ies) stating who your peers and upstreams are. And there's nothing to say that one could not specify allowed filters in DNS, too.
If someone wants me to advertise 192.168.7/24, and DNS indicates the proper netblock is 192.168.0/19 and their ASN is not origin or adjacent hop, I'll be suspicious. What I do from there becomes a policy question; I probably would contact the IP block owner to verify the request. ---
My way isn't superior at all to a secure BGP solution, but until that exists, I need a choice.
I am definitely on the bandwagon for the need for a secure BGP.
--Phil
On Tue, 6 Aug 2002, John M. Brown wrote:
Whats a tier 1??
As previously reported, 'Tier 1' generally has something to do with poor financial health. Perhaps, a 'Tier 1 bankruptcy' is less latency and more throughput than a 'tier 2 bankruptcy'. -- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
At 02:50 PM 8/6/02, you wrote:
Phil, You would think, after hearing about 30 people with clue+++ talk, you may realize that this is a patently *bad* thing and should not be done.
Actually, what the many people have said sounded a lot more like "it won't help very much."
If your route's are being hijacked you can generally solve your problems in 2-5 phone calls...That's all it's *ever* taken me. 1. Call their NOC.
typical response: you're not our customer, go away.
2. If not helpful call their upstream.
typical response: you're not our customer, go away.
3. Call a couple of Tier 1's who are transit for their upstream, and have them filter it.
response: who the hell are you? Until you get back to the people you buy transit from, or peer with, and try to get them to take on your cause. When you can't get your own upstreams to understand what you're talking about, you post to NANOG, and the problem gets solved in short order. This tends to be the sad reality. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com
On Tue, Aug 06, 2002 at 03:56:32PM -0400, Daniel Senie wrote:
At 02:50 PM 8/6/02, you wrote:
Phil, You would think, after hearing about 30 people with clue+++ talk, you may realize that this is a patently *bad* thing and should not be done.
Actually, what the many people have said sounded a lot more like "it won't help very much."
If your route's are being hijacked you can generally solve your problems in 2-5 phone calls...That's all it's *ever* taken me. 1. Call their NOC.
typical response: you're not our customer, go away.
Typical response: You're not our customer, who are you? I'm Omachonu Ogali with XYZ Networks, and I'd like to speak to a network engineer regarding a routing problem. -- Ah ok, please hold.
2. If not helpful call their upstream.
typical response: you're not our customer, go away.
See above.
3. Call a couple of Tier 1's who are transit for their upstream, and have them filter it.
response: who the hell are you?
Cut the crap, when US/CKS was leaking Digex to UUnet, I called UUnet, and within 30 minutes the problem was resolved. Plus when I called, I wasn't representing any company or calling any magic numbers.
Until you get back to the people you buy transit from, or peer with, and try to get them to take on your cause. When you can't get your own upstreams to understand what you're talking about, you post to NANOG, and the problem gets solved in short order.
No, most of you post to NANOG about irrelevant drivel that brings the S/N ratio lower each year, or you post 3-4 hops out of a 12 hop traceroute, or you resort to NANOG instead of calling your upstream first, or you talk about implementing the most wacked out routing policy to exist on the planet.
This tends to be the sad reality.
Yes, the above tends to be the sad reality.
----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
This was by far the most clued post in the entire thread. 1. For the most part, engineers are happy to talk to engineers. 2. See one. 3. A Tier-1 lives and dies by its reputation. If they let hijacks go unnoticed, then that's a black tarnish, and all of NANOG will know. Besides they are generally extremely helpful. I speak from experience, as I've had to deal with this on a few occasions. Generally speaking, 30 minutes is the longest you'll have to wait for something as easy to stop as this. Derek -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Omachonu Ogali Sent: Tuesday, August 06, 2002 4:15 PM To: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes On Tue, Aug 06, 2002 at 03:56:32PM -0400, Daniel Senie wrote:
At 02:50 PM 8/6/02, you wrote:
Phil, You would think, after hearing about 30 people with clue+++ talk, you may realize that this is a patently *bad* thing and should
not
be done.
Actually, what the many people have said sounded a lot more like "it won't help very much."
If your route's are being hijacked you can generally solve your problems in 2-5 phone calls...That's all it's *ever* taken me. 1. Call their NOC.
typical response: you're not our customer, go away.
Typical response: You're not our customer, who are you? I'm Omachonu Ogali with XYZ Networks, and I'd like to speak to a network engineer regarding a routing problem. -- Ah ok, please hold.
2. If not helpful call their upstream.
typical response: you're not our customer, go away.
See above.
3. Call a couple of Tier 1's who are transit for their upstream, and have them filter it.
response: who the hell are you?
Cut the crap, when US/CKS was leaking Digex to UUnet, I called UUnet, and within 30 minutes the problem was resolved. Plus when I called, I wasn't representing any company or calling any magic numbers.
Until you get back to the people you buy transit from, or peer with, and try to get them to take on your cause. When you can't get your own upstreams to understand what you're talking about, you post to NANOG, and the problem gets solved in short order.
No, most of you post to NANOG about irrelevant drivel that brings the S/N ratio lower each year, or you post 3-4 hops out of a 12 hop traceroute, or you resort to NANOG instead of calling your upstream first, or you talk about implementing the most wacked out routing policy to exist on the planet.
This tends to be the sad reality.
Yes, the above tends to be the sad reality.
----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
On Tue Aug 06, 2002 at 04:21:13PM -0400, Derek Samford wrote:
1. For the most part, engineers are happy to talk to engineers. 2. See one. 3. A Tier-1 lives and dies by its reputation. If they let hijacks go unnoticed, then that's a black tarnish, and all of NANOG will know. Besides they are generally extremely helpful. I speak from experience, as I've had to deal with this on a few occasions. Generally speaking, 30 minutes is the longest you'll have to wait for something as easy to stop as this.
Having gone through this last week, I can attest to the fact that this actually happens this way. Telstra were advertising a /24 from our netblock. I looked on www.telstra.net, found the "contact us" page, and called their "Faults" number. I told the guy who answered the phone what was happening, and he fully understood the problem, and promised to escalate to their NOC guys. I followed up with an email for good measure. Meanwhile, with the help of some "local" friends, I determined that Reach were the transit provider for Telstra, and called their NOC in Hong Kong. Despite the language barrier, I managed to get the point across, and he asked that I confirm my request for them to stop listening to the annoucement from Telstra. (Fair point, given the language difficulties, and the nature of my request, I too would have requested an email). Within 15-20 minutes, I got a call from the Telstra NOC saying they'd found the problem and recitified it. About 10 minutes later, I got an email from the Reach NOC saying they couldn't see the problem any more. All in all, I was happy with the way it was handled. (Although, it would have been better if Telstra hadn't made the announcement in the first place) Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart@bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/
1. Call their NOC.
typical response: you're not our customer, go away.
Typical response: You're not our customer, who are you? I'm Omachonu Ogali with XYZ Networks, and I'd like to speak to a network engineer regarding a routing problem. -- Ah ok, please hold.
Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
Hum. I take ~4 calls each day for things that are some other ISPs problem. Folks are -politely- told that the issues are either with their ISP or someone upstream of their ISP. When they get pushy, I offer them a service contract. 99.999% (hey Sean, there are your five 9's!) of them then choose to work with thier ISPs. I suspect that you have more than enough clue to never have to give me a call, but if you do, be prepared to be re-directed... :) --bill
On Tue, 6 Aug 2002 bmanning@karoshi.com wrote:
Typical response: You're not our customer, who are you? I'm Omachonu Ogali with XYZ Networks, and I'd like to speak to a network engineer regarding a routing problem. Hum. I take ~4 calls each day for things that are some other ISPs problem. Folks are -politely- told that the issues are either with their ISP or someone upstream of their ISP. When they get pushy, I offer them a service contract. 99.999% (hey Sean, there are your five 9's!) of them then choose to work with thier ISPs. I suspect that you have more than enough clue to never have to give me a call, but if you do, be prepared to be re-directed... :)
I hope you pay better attention on the phone then you do on lists. :) The point was calling up the upstream of the AS who is generating bogus routes. The upstream of the caller is not at all involved.
At 6:38 PM +0000 2002/08/06, E.B. Dreger wrote:
So explain how this is superior to DNS entr(y|ies) stating who your peers and upstreams are. And there's nothing to say that one could not specify allowed filters in DNS, too.
You don't want to do this with DNS. Trust me. There are far too many seriously screwed up nameservers out there -- including many TLD nameservers, and even some mildly mis-configured root nameservers. Until such time as these issues get addressed (either DNS software gets more idiot-resistant, or we have DNSSEC and things like cache pollution are basically impossible), you want to find other ways to handle these sorts of things. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On 8/6/02 3:05 PM, "Brad Knowles" <brad.knowles@skynet.be> wrote:
You don't want to do this with DNS. Trust me. There are far too many seriously screwed up nameservers out there -- including many TLD nameservers, and even some mildly mis-configured root nameservers.
"Mildly mis-configured root nameservers"? Care to explain? Rgds, -drc
At 4:28 PM -0700 2002/08/06, David Conrad wrote:
"Mildly mis-configured root nameservers"?
Care to explain?
Sure. We know that some root nameservers are in violation of RFC 2870 sections 2.3 and 2.4. They just can't handle anywhere remotely close to: ... three times the measured peak of such requests on the most loaded server in then current normal conditions ... We also know that some of the root nameservers are in violation of section 2.6 -- for example, I believe that the networks hosting the nameservers operated by the US government and the US military routinely block all packets from certain netblocks which they believe to be "subversive". I ran into this problem frequently at Skynet, where they would block all packets coming from 195.238.0.0/20, apparently because this netblock was in Europe and therefore "dangerous". It didn't seem to matter to them that we were also the primary network provider for many NATO groups in Europe, and by their blocking us, they were also blocking NATO. Note that these same idiots had explicit holes cut in their firewalls for 194.78.0.0/16, which was an older netblock also owned by Skynet. This affected the nameservers hosted by the US government & military, as well as at least some of the machines that are registered authoritative nameservers for the .mil and .gov zones. Section 2.5 is outright blatantly violated, since there are definitely some root nameservers that are listed as being authoritative for zones other than "." and "root-servers.net". IMO, section 2.7 is a bigger issue. I think you can reasonably argue that the root zone itself should (or could) be exposed to zone transfers, in part because it is relatively easy to create (the gTLDs are known, and you can easily programmatically find the ccTLDs). Moreover, I don't think there's much danger in exposing the root zone. However, if it's going to be available for AXFR, then it should be available at all root nameservers, and not just a selected few. You can also argue that .arpa falls into this same category. Contrariwise, I believe that the Domain Managers for .gov, .mil and .edu would probably violently disagree with this point, and their zones should not be exposed for zone transfers. If we made appropriate changes so that all root nameservers were in compliance with section 2.5, then this would become a moot point. IMO, sections 3.2.1, 3.2.3, and 3.2.4 are highly questionable with regard to certain machines. My testing is not yet complete, so I won't say much more with regards to these sections. So far as I know, this document is supposed to describe the way these machines should be operated. Without any information to the contrary, I have to assume that the root server operators were in general agreement that they would follow these principles. Clearly, this is not happening. Therefore, at least some of the root nameservers are at least mildly mis-configured. This really is a lot further than I wanted to go into detail, at least publicly. If you want any further discussion of this matter, you should contact me via private e-mail, or you can come to my invited talk "Domain Name Server Comparison: BIND 8 vs. BIND 9 vs. djbdns vs. ???" that I will be giving at LISA 2002, and where I will be discussing these issues and a whole lot more. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
"Mildly mis-configured root nameservers"?
Care to explain?
We know that some root nameservers are in violation of RFC 2870 ...
RFC 2870 had a lot of cooks, and the end result is somewhat descriptive of TLD servers but is anywhere from mildly to wildly wrong with respect to the root servers.
... We also know that some of the root nameservers are in violation of section 2.6 -- for example, I believe that the networks hosting the nameservers operated by the US government and the US military routinely block all packets from certain netblocks which they believe to be "subversive".
There's no way to change this, really, and one of the ways to not change it would be to write an RFC. USGov has its own way of doing things. I don't expect anybody to tell them they have to give up their root servers as a result. (Except maybe Karl or Jim, I guess.)
... Section 2.5 is outright blatantly violated, since there are definitely some root nameservers that are listed as being authoritative for zones other than "." and "root-servers.net".
We cooperate with the spirit of that provision (which it shares with RFC 2010, by the way) by not adding any new zones to any server which is also authoritative for ".". The current list, as far as I know, is: A: . arpa in-addr.arpa gov edu mil root-servers.net B: . arpa in-addr.arpa gov edu mil [root-servers.net] C: . arpa in-addr.arpa gov edu [root-servers.net] D: . arpa in-addr.arpa gov edu [root-servers.net] E: . arpa in-addr.arpa gov edu mil [root-servers.net] F: . arpa in-addr.arpa gov edu root-servers.net G: . arpa in-addr.arpa gov edu mil [root-servers.net] H: . arpa in-addr.arpa gov edu mil [root-servers.net] I: . arpa in-addr.arpa gov edu [root-servers.net] J: . root-servers.net K: . root-servers.net L: . [root-servers.net] M: . [root-servers.net] Speaking only for F, I'll say that ISC will never ask ARPA, IN-ADDR.ARPA, GOV, or EDU to seek elsewhere for their name service. I'd like to say that they're "grandfathered" but what I really mean is they're "Postel'd". (The []'s indicate stealth slave status.)
... IMO, section 2.7 is a bigger issue. I think you can reasonably argue that the root zone itself should (or could) be exposed to zone transfers, in part because it is relatively easy to create (the gTLDs are known, and you can easily programmatically find the ccTLDs). Moreover, I don't think there's much danger in exposing the root zone.
Not only that. F allows transfer of every zone it handles, and always has, other than a brief period when COM, NET, and ORG were restricted due to a request from VeriSign. (VeriSign now serves COM, NET, and ORG for itself.) If the operators of the zones F serves asked that they be restricted from zone transfer, we would of course comply. But RFC 2870 is flat wrong in its attempts to legislate F's ACL -- only the zone operators can do that.
... However, if it's going to be available for AXFR, then it should be available at all root nameservers, and not just a selected few. You can also argue that .arpa falls into this same category.
You ought to take that up with the zone operator, who at this moment appears for all intents and purposes to be US-DoC, or failing that, talk to IANA.
Contrariwise, I believe that the Domain Managers for .gov, .mil and .edu would probably violently disagree with this point, and their zones should not be exposed for zone transfers.
If so then they sure havn't told F, even after many years of full openness.
... IMO, sections 3.2.1, 3.2.3, and 3.2.4 are highly questionable with regard to certain machines. My testing is not yet complete, so I won't say much more with regards to these sections.
Some of the hosts from whom I have recently dropped more than 50 packets due to their exceeding a 100Kbit/sec ingress quota are shown below. Presumably yours is among them if you're still flooding me with queries to find out how fast I'll answer them. 124 ip 210.220.163.80/0 0.0.0.0/0 209 12466 0 0 126 313 ip 216.127.34.163/0 0.0.0.0/0 321 18939 0 0 120 64 ip 210.220.163.78/0 0.0.0.0/0 157 9385 0 0 88 499 ip 209.67.50.88/0 0.0.0.0/0 141 8987 0 0 84 1011 ip 144.137.113.189/0 0.0.0.0/0 119 6854 0 0 84 203 ip 216.175.216.50/0 0.0.0.0/0 139 8865 2 129 81 916 ip 209.150.65.1/0 0.0.0.0/0 160 9344 2 120 80 408 ip 218.44.147.218/0 0.0.0.0/0 130 7800 0 0 67 188 ip 65.192.24.190/0 0.0.0.0/0 121 8712 0 0 64 Evi gave a *wonderful* talk at NANOG a year or so back in which she explored the many bad flows seen on F. Anyone who runs benchmarks against root servers would be a "bad flow". So it's no wonder that your testing isn't complete :-).
So far as I know, this document is supposed to describe the way these machines should be operated.
That's one way to look at it. I think it's got more to do with TLD servers, and is advisory. With 250+ ccTLD's, there are a lot of new operators, and this document seems to have sought to advise that group.
Without any information to the contrary, I have to assume that the root server operators were in general agreement that they would follow these principles.
Allow me to present information to the contrary. I co-authored RFC 2010, but I had no part in RFC 2870 and in fact had not even read it until well after it was published. I consider it inadequate and inaccurate for root service, while nonetheless acknowledging its applicability toward some ccTLD servers.
Clearly, this is not happening. Therefore, at least some of the root nameservers are at least mildly mis-configured.
Clearly, you're way ahead of yourself. -- Paul Vixie
At 4:19 AM +0000 2002/08/07, Paul Vixie wrote:
RFC 2870 had a lot of cooks, and the end result is somewhat descriptive of TLD servers but is anywhere from mildly to wildly wrong with respect to the root servers.
I have since learned that there is an update to 2010 in the works, which should be more acceptable to the root server operators. As such, I will stop comparing the current state of the servers against 2870.
There's no way to change this, really, and one of the ways to not change it would be to write an RFC. USGov has its own way of doing things. I don't expect anybody to tell them they have to give up their root servers as a result. (Except maybe Karl or Jim, I guess.)
They're welcome to run their own servers however they like. However, if they want to arbitrarily cut off their networks from "subversive" networks around the world, then I feel that they should voluntarily give up their root nameservers because they are unable to adhere to the spirit of the standards by which they are supposed to be operating (whatever RFC or document you use as that standard).
124 ip 210.220.163.80/0 0.0.0.0/0 209 12466 0 0 126 313 ip 216.127.34.163/0 0.0.0.0/0 321 18939 0 0 120 64 ip 210.220.163.78/0 0.0.0.0/0 157 9385 0 0 88 499 ip 209.67.50.88/0 0.0.0.0/0 141 8987 0 0 84 1011 ip 144.137.113.189/0 0.0.0.0/0 119 6854 0 0 84 203 ip 216.175.216.50/0 0.0.0.0/0 139 8865 2 129 81 916 ip 209.150.65.1/0 0.0.0.0/0 160 9344 2 120 80 408 ip 218.44.147.218/0 0.0.0.0/0 130 7800 0 0 67 188 ip 65.192.24.190/0 0.0.0.0/0 121 8712 0 0 64
Nope, none of those are mine. I was primarily talking about the other machines on the same network, and the other services that I strongly suspect that some of the machines are running. Nmap scans would have a good chance of turning up some results.
Evi gave a *wonderful* talk at NANOG a year or so back in which she explored the many bad flows seen on F. Anyone who runs benchmarks against root servers would be a "bad flow". So it's no wonder that your testing isn't complete :-).
Yeah, I think I read that paper. I understand, and now I fully agree. The problem is that there are a dearth of good tools (like queryperf) to help measure the jitter of the RTTs of low-rate DNS queries.
Allow me to present information to the contrary. I co-authored RFC 2010, but I had no part in RFC 2870 and in fact had not even read it until well after it was published. I consider it inadequate and inaccurate for root service, while nonetheless acknowledging its applicability toward some ccTLD servers.
I disagree. Certainly, Daniel Karrenberg has publicly disagreed with this use of RFC 2870. Check the archives of the RIPE DNS Working Group.
Clearly, you're way ahead of yourself.
I was comparing the current state of affairs against the wrong document. I await the publication of the right document. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On 2002-08-06-14:12:41, Phil Rosenthal <pr@isprime.com> wrote:
I only have 10 /24's that are absolutely mission critical to keep up.
...and this necessitates cluttering the IRR with 10 /24 entries, how? A number of upstreams who prefix-filter based on IRR are cool with the 'le' and 'ge' directives, e.g. so you could register just one object for your aggregate, and announce anything /24 or less specific. -a -- "I'm not known to be the best googler." --Jane Pawlukiewicz <pawlukiewicz_jane@bah.com>
Truth be told, if someone was advertising your space illegitimately, any networks that use the IRR's to filter would not be accepting the rogue announcement in the first place, at least in theory. Thus, the emergency registration of more-specific route object should not be necessary, right? -C On Tue, Aug 06, 2002 at 01:29:58PM -0400, Phil Rosenthal wrote:
Most ISPs that build off of the IRR's do it nightly. I am talking about 10 /24's out of /19, and I'm not announcing any of the /24's -- and wont unless there is an emergency, and only then would it be temporary.
--Phil
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Omachonu Ogali Sent: Tuesday, August 06, 2002 4:00 AM To: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
What about announcing and registering with your IRR, more-specific routes for the period that the problem ONLY exists, instead of being lazy?
If all else fails, break out Outlook and your favorite translator, because last time I checked, speaking English was not a requirement to run a network. Even if most of you do, this is not a "Majority Rules" situation.
On Mon, Aug 05, 2002 at 10:47:33PM -0700, john@chagresventures.com wrote:
get on the bandwaggon that filtering is a good thing ?? :)
at some point some transit is going to listen and drop the announcement.
Lets take an example. Deep Dark middle of asia, someone starts announcing a /24 of yours. Their upstream takes the packet, and so forth. At some point they will touch a NSP or ISP (international service provider) and you can get things dropped their.
Yes. End of story. Go directly to the finish diamond at the end of your flowchart. If the next step in your flowchart is "pollute IRRs with 3592375238957235893275839572 /32s", please return your maintainer object.
Your pushing out a /24 will help slurp some of the traffic towards you, but not all.
Personally I have deagged some prefixes to cause a DOS/DDOS towards a particular address to route down a slow connection I had. Sacrifice one link, to keep customers running on the others. But thats different.
Yes, but you removed it later on, correct?
Its about networking, the people kind, at this point.
cheers
john brown chagres technologies, inc
On Mon, Aug 05, 2002 at 09:00:55PM -0400, Phil Rosenthal wrote:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult to contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd
of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or
maliciously,
announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting
way their
NOC is likely going to take a long time...
--Phil
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
Please...Let this thread just die. Derek -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Chris Woodfield Sent: Wednesday, August 07, 2002 10:25 AM To: Phil Rosenthal Cc: 'Omachonu Ogali'; nanog@merit.edu Subject: Re: Deaggregating for emergency purposes Truth be told, if someone was advertising your space illegitimately, any networks that use the IRR's to filter would not be accepting the rogue announcement in the first place, at least in theory. Thus, the emergency registration of more-specific route object should not be necessary, right? -C On Tue, Aug 06, 2002 at 01:29:58PM -0400, Phil Rosenthal wrote:
Most ISPs that build off of the IRR's do it nightly. I am talking
about
10 /24's out of /19, and I'm not announcing any of the /24's -- and wont unless there is an emergency, and only then would it be temporary.
--Phil
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Omachonu Ogali Sent: Tuesday, August 06, 2002 4:00 AM To: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
What about announcing and registering with your IRR, more-specific routes for the period that the problem ONLY exists, instead of being lazy?
If all else fails, break out Outlook and your favorite translator, because last time I checked, speaking English was not a requirement to run a network. Even if most of you do, this is not a "Majority Rules" situation.
On Mon, Aug 05, 2002 at 10:47:33PM -0700, john@chagresventures.com wrote:
get on the bandwaggon that filtering is a good thing ?? :)
at some point some transit is going to listen and drop the announcement.
Lets take an example. Deep Dark middle of asia, someone starts announcing a /24 of yours. Their upstream takes the packet, and so forth. At some point they will touch a NSP or ISP (international service provider) and you can get things dropped their.
Yes. End of story. Go directly to the finish diamond at the end of your flowchart. If the next step in your flowchart is "pollute IRRs with 3592375238957235893275839572 /32s", please return your maintainer object.
Your pushing out a /24 will help slurp some of the traffic towards you, but not all.
Personally I have deagged some prefixes to cause a DOS/DDOS towards a particular address to route down a slow connection I had. Sacrifice one link, to keep customers running on the others. But thats different.
Yes, but you removed it later on, correct?
Its about networking, the people kind, at this point.
cheers
john brown chagres technologies, inc
On Mon, Aug 05, 2002 at 09:00:55PM -0400, Phil Rosenthal wrote:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult
contact as well?
--Phil
-----Original Message----- From: John M. Brown [mailto:jmbrown@ihighway.net] Sent: Monday, August 05, 2002 8:12 PM To: Phil Rosenthal Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes
Hmm, this would be a "Bad Idea" (TM) (C) 2002, DMCA Protected
Having had this happen to me several different times, I'd have to recommend, calling the NOC of the advertising party. as the pref'd way of handling it.
On Mon, Aug 05, 2002 at 06:41:22PM -0400, Phil Rosenthal wrote:
I am currently announcing only my aggregate routes, but I have lately thought about the possibility of someone mistakenly, or
maliciously,
announcing more specifics from my space. The best solution for an emergency response to that (that I can think of), is registering all of the /24's that make up my network, so if someone should announce a more-specific, I can always announce the most specific that would be accepted (assuming they don't announce the /24's too, it should be a problem avoided)
Does anyone else have any other ideas on ways to quickly deal with someone else announcing your more specifics, since contacting
to their
NOC is likely going to take a long time...
--Phil
-- Omachonu Ogali missnglnk@informationwave.net http://www.informationwave.net
I agree that the thread needs to die. Anything useful that could be said has been said. The end result is, the proper thing to do is make sure your upstream allows you to announce any more specifics than what you have in the IRR. Use your best judgment in deaggregating, and it is always better if you can get it fixed by having the offending party stop announcing, or their uplinks filter. --Phil -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Valdis.Kletnieks@vt.edu Sent: Wednesday, August 07, 2002 11:17 AM To: Derek Samford Cc: nanog@merit.edu Subject: Re: Deaggregating for emergency purposes On Wed, 07 Aug 2002 10:48:00 EDT, Derek Samford said:
Please...Let this thread just die.
Well.. if the Routing Nazis were doing their jobs, this thread wouldn't be necessary. ;) Godwin. :)
On Mon, Aug 05, 2002 at 09:00:55PM -0400, Phil Rosenthal wrote:
But the question is, what do you do if it's coming from somewhere with a difficult to contact NOC, and their upstream is difficult to contact as well?
If you really MUST plan to announce more specifics, I'd suggest you lookup RPSL and the ^ operator (ex: 1.2.3.0/19^+). If done correctly, it should result in no real overhead in IRR or on your providers' routers. Those ge and le operators are there for a reason, use 'em. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
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 <blacklist@brics.com> To: blacklist@brics.com 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 <blacklist@brics.com>, or you are likely to be blocked.
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.)
See http://www.isi.edu/~bmanning/inet98.html for ways to do just this... --bill
participants (25)
-
Adam Rothschild -
Alex Rubenstein -
bmanning＠karoshi.com -
Brad Knowles -
Chris Woodfield -
Daniel Senie -
David Conrad -
Derek Samford -
Dominic J. Eidson -
E.B. Dreger -
Greg Maxwell -
Jared Mauch -
jnull -
John M. Brown -
John M. Brown -
john＠chagresventures.com
-
nanog＠missnglnk.com -
Omachonu Ogali
-
Paul Vixie -
Phil Rosenthal -
Ratul Mahajan -
Richard A Steenbergen -
Simon Lockhart -
Stephen J. Wilcox -
Valdis.Kletnieks＠vt.edu