Re: Best way to deal with bad advertisements?

[Matthew Petach <mpetach () netflight com>]

>   Hi Matt,
>
> > > In this case, the very first thing you should probably do is to
> > > start announcing the more specific /24s to match their advertisements!
> > > Depending on AS-PATH length (how various nets hear your announcements
> > > vs. theirs) this may solve the immediate problem, allowing you to hunt
> > > them down and kill them at your leisure.
> >
> > The downside to this is that we go from advertising /16's
> > out, to advertising a fleet of /24's out, most of which 
> > would be filtered by Sprint's ever-lovin' CIDR-forcing
> > wall.  
>
>   If your more specific networks are filtered, then wouldn't the
>   evil ISP's be filtered as well?
>
>   This would be a large problem only if you gain transit from Sprint....

Bingo.  We buy transit from Sprint.
 
> > I agree with Sprint, and Sean, but in this case
> > it pretty much makes it hard for us to force the issue
> > by dropping to the same or smaller sized announcement.
>
>   Well, I'm not sure that the two entities can be put in the 
>   same sentence any more, but you can always leave the less specific
>   /16 in there while you attempt to advertise the more speciic.

Good point; I'd forgotten you can have both advertised, and
those that hear the /16, and no /24's will honor it, those
that hear the /24's get to worry about the weights independantly
of the /16's advertisement.
 
> > Good thought, though!   Even if it does result in going
> > from 2 /16 announcements to 512 /24 announcements in
> > the process, growing the routing tables, and generally
> > making everyone else unhappy as well.
>
>   I'd rather have happy workable customers and an unhappy
>   community in the short run, than unhappy unworkable customers and
>   a happy community.

Agreed; if this were something I felt would be resolved within
24 hours, it wouldn't even really be worth mentioning.  When
it starts moving on 48 hours, I start worrying about whether
or not we're going to start showing up in the Top 50 lists.  :-)
 
>   I think your letter will raise the awareness of this kind of
>   problem.  Of course we all know it's possible, but it's not a
>   problem that we've had to deal with on a malicious level.
>
> ? I do assume that there's no doubt the evil-isp is doing this
>   maliciously?

This is the third time they've done this.  The first two times
we chalked up to ignorance and stupidity.

This time, though, we're not as willing to give them
the benefit of the doubt.
 
> > *sigh*  There really MUST be some nice way of handling
> > lame ISP's like this.
>
>   One thing you could do is coordinate with largerish ISPs to filter
>   the incorect network from the affected peering sessions.  While
>   this is a stopgap fix, and not one to be repeated, I don't think
>   you'd have problems getting it done w/ MCI, UUnet, AGIS, etc...
>
> > > 1) Announce *your own* routes more specifically.
> > >    This may lose you ANS connectivity, though.
> >
> > And Sprint, and anyone else that filters small specifics.
>
>   Again, not if you leave the /23 or /16s in place...   Then you
>   just revert to the pre-action situation.  It is again important to
>   note that if your announcement would be blocked by mask length
>   policies, then the evil-isp would be as well.

Not since we connect through sprint, and they don't.  :-(
 
> > > 2) Announce *their* routes more specifically.
>
>   Ouch, that's playing as dirty as them.  Can't recommend it unless
>   it's life or death...

I know.  Tempting though it is...
 
> > I took that step last night, and was advised to remove it by
> > those more in tune with legal issues.   I guess it's not
> > considered "nice" to sink to the same level as your
> > attacker, and play dirty.  :-}
>
>   Aiyeee.

In thinking about it, I realized I didn't want to be the
one listed as having escalated the cold war prefix race
resulting in a flood of GIFS illustrating the death of
the net.  :-)
 
> > > 3) You can post to NANOG and other lists in an attempt to embarrass/
> > >    get someone who knows the jokers to poke them.
>
>   I recommend this, show traceroutes, RR entries, InterNIC assignments,
>   routing table dumps, and state the problem clearly.  You can bet 
>   the appropriate folks will poke them.

We did this last time, in complaining to MCI, their upstream
provider, and MCI responded in record time, putting in a
temporary filter for those blocks in less than 36 hours.

That helped for about 30 seconds, before we found that they
then announced the same blocks through a second connection
which hadn't shown up as a path previously when we did
a 'show ip bgp 205.158.193.0 255.255.255.0 l'

With the advent of more and more multihomed networks, there's
more and more paths that need to be filtered to stop an
invalid announcement like this; perhaps the concept of a
routing database that can only be updated by authoratative
contacts isn't that unreasonable anymore.  Gone are the
days when you can just trust that everyone else will 
"do the right thing" in maintaining the well-being of the
net.  Just as the Guardian project came to the InterNIC,
perhaps a similar check-and-verify proceedure needs to
be put in place before new routing announcements are
added or believed.

I miss the older, more democratic days of the net, but it
seems the overall level of knowledge and skill is dropping,
forcing more and more levels of checks and balances to
prevent abuse either through stupidity and ignorance, or
malicious intent.
 
>   In summary, whatever they do to hit you, do for yourself in
>   self-defense.  Don't advertise their networks, just advertise your
>   networks as specifically as needed.  Continue to raise the ante by
>   involving more appropriate folks, and provide specific
>   documentation to those involved of what happened when.  It sounds
>   like a war to me.  Try to find middle ground with them, there must
>   be SOME reason they are after your cidr space.  Perhaps you can
>   negotiate a fix?
>
>   I doubt it will be to long before a standard as-path list looks
>   like this:
>
>   ....
>   ip as-path 10 deny EVIL-ISP1-AS
>   ip as-path 10 deny EVIL-ISP2-AS
>   ip as-path 10 deny EVIL-ISP3-AS
>   ....
>
>   In this age of global routing, with no central body, politicking
>   and negotiation are your best tools for solution.  There's no
>   overseeing body to go to.  You can gain allies, but it's up to
>   you.  Good luck, and count most folks here as allies.
>
>   $.02
>
>   -alan


Thanks!  It's a new ballgame for geeks and engineers more
at home in a telco closet hunched over a laptop cabled into
a console port; I'm not as familiar with politics and the
subtle tactics of diplomacy, negotiation, and power brokering.

I can see it's time I started learning some new tricks, and
prepared for the new way of doing business on the net.

Thanks again for the support.  I'm sorry to see that the
days of simple trust may be coming to a close, but we've
all invested money into this creation, and we can't really
afford to let others bring it down, whether by SYN attacks,
domain name theivery, or IP theivery.

Matt
- - - - - - - - - - - - - - - - -