Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Deaggregating for emergency purposes

  • From: Omachonu Ogali
  • Date: Tue Aug 06 14:43:11 2002

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
> 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
> 

-- 
Omachonu Ogali
missnglnk@informationwave.net
http://www.informationwave.net




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.