route ingress [summary]

Tue Dec 30 21:56:54 UTC 1997

If you reply to this, be sure your MUA respects the "Reply-To:" field above.

I forgot to mention in my offer to summarize that no quotes will be identified
since this is a potential security hole to some people with some neighbors.  I
am actually quite surprised that abuse of unallocated address space hasn't come
up before now.  I guess spamming was the first natural application for it.

If I get more traffic on this topic I will summarize it also.  My conclusions
so are are: (1) most people know the importance of and the procedure for strict
controls over end-system routes they inject, even if not everybody does it;
(2) degree of enforcement of (1) is probably going to be a term of most peering
agreements by this time next year; (3) enough folks are enough opposed to the
RADB that intermediate-system route control probably won't come that way; (4)
this is similar enough to other things known to be wrong with the BGP security
model that we're probably in for a long march before we see work complete on
it; (5) to the extent that abusers of unallocated space are spammers, the MAPS
RBL is the only short term hope i have of controlling this.

Thanks to all who replied.

------- Forwarded Messages

> routing core allow it?  subquestion 1: if the spammer is your customer.  

While the route would propogate to my ibgp network in some cases, it would
not be announced to the internet.  I would be spammed, but my peers would
not hear the announcements.

[my net] filters its announcements to peers at the AS and IP address level.
Only known-valid addresses of our customers are propogated to our peers.

> subquestion 2: if the spammer is a customer of one of your BGP peers.

I would accept it in all cases.

> subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.
> 
> i've sent reply-to to myself.  i will summarize responses back to the list.

I would accept it it all cases.

------- Message 2

> routing core allow it?  subquestion 1: if the spammer is your customer.  

no, we filter on the prefixes we announce. 

> subquestion 2: if the spammer is a customer of one of your BGP peers.

yes, we don't screen routes with an existing database  

> subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

yes, we don't screen routes with an existing database

> i've sent reply-to to myself.  i will summarize responses back to the list.

Just FYI, 2 of my 3 upstreams (namely Sprint and AGIS) would allow me or
other customers to spam willynilly from unallocated ip's - namely they do
not me filter on announced prefix. One of my upstreams, UUNET would not
allow this - they make me call up with each new prefix I want to announce.

Wow, thanks for the info, next thing these guys will be doing is
spamming from cracked machines, like syn bombers.

[ they do this now, at various levels of crackage.  --vix ]

------- Message 3

[ this was randy's note, which he later recanted in mail to jhawk. --vix ]

------- Message 4

>routing core allow it?  subquestion 1: if the spammer is your customer.  
>subquestion 2: if the spammer is a customer of one of your BGP peers.
>subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

1. No
2. Yes
3. Yes

(The solutions to 2 and 3 are on the "list of things to do" but you know
how that goes sometimes)

------- Message 5

Since this is a worthwhile question, it deserves to be answered, presuming
that the names will be changed to protect the innocent, guilty and the lazy.

[ yes.  --vix ]

>routing core allow it?  subquestion 1: if the spammer is your customer.  
>subquestion 2: if the spammer is a customer of one of your BGP peers.
>subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

Our answers are:
No, our routing core would not allow spam from unallocated space
1.  still no, except for a few "trusted" (bad word) BGP customers.
2.  um, yes to some <sound of hand being slapped> (no to some and this list
is growing).
3.  yes, as we do not filter from our upstream (UUNET, AS701)  Of course,
for this to be no, the access-list is a bit extreme.

------- Message 6

> routing core allow it?  subquestion 1: if the spammer is your customer.

Nope.

> subquestion 2: if the spammer is a customer of one of your BGP peers.

Almost certainly.

> subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

I'm not sure what this means. if they're behind a customer then no.
if they're behind a peer, then yes. If they're behind something else
I'm not sure what the other somethings are.

[ i should have been more explicit.  i meant behind peers-of-peers-of-peers.
  i'm imputing a "yes" answer from you in that case.  --vix ]

------- Message 7

We filter all BGP announcements from our customers and limit the =
announcements to address space belonging to them or their customers. We =
make them tell us what they are going to announce and we verify their =
ownership of the address space. Yes, it is time consuming.

I hope our policy sounds anal as we try to be as anal as possible with =
IP sourcing and BGP announcements.

[ you're being liberal in what you believe and conservative in what you
  generate, which is the classical internet approach, and which has led
  to spam-as-we-know-it and is about to cause wide scale problems in the
  routing system as well.  --vix ]

------- Message 8

> routing core allow it?  subquestion 1: if the spammer is your customer.  

Not unless the spammer was also a BGP feed from us (extremely rare; we 
don't BGP feed or accept from people who aren't actually multihomed, we
static-route instead).  If we had ANY reason to suspect that something like
this was going on the BGP connection would be terminated with extreme
prejudice.  This kind of game requires active cooperation by the injector
of the bogus route, and that means they're responsible.

[ agreed.  --vix ]

> subquestion 2: if the spammer is a customer of one of your BGP peers.

Possibly, yes.  We can't verify that a BGP peer is announcing only "good"
things to us since we don't peer with the RADB (or similar).

> subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

Yes.  This one is rather impossible to prevent with the current technology
unless you know of a way to do this that I'm not aware of.  Indirect
announcements (those with more than one external element in the as-path) 
are virtually impossible to verify or craft filters to handle, unfortunately.

[ not really.  give me three hours with the RADB and pathalias/pathparse and
  i'm sure i could hack something bloody and sticky together.  whether there
  is a NOVRAM anywhere in the world large enough to contain the result is a
  separate question with a different and fatal answer.  --vix ]

------- Message 9

> routing core allow it?  subquestion 1: if the spammer is your customer.
> subquestion 2: if the spammer is a customer of one of your BGP peers.
> subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

Yes to all, Sorry!

But some of our transit providors do filter on address space, Digex, NAC
and genuity being those three. I will have RPSL/RADB filtering sorted
soon as I get the time.

------- Message 10

We filter input routes from our customers that we BGP peer with.  We only
redistribute static routes for customers that we do not peer with.  We
accept full routing announcements from our NSPs, Sprint and MCI.  I know
MCI filters what they hear from their customers, but I know Sprint is not
very good about it.  So we would be susceptible to bogus routes from Sprint
and MCI.

------- Message 11

>routing core allow it?  subquestion 1: if the spammer is your customer.  

No, all of our customers are filtered both on AS-path and network prefixes.

>subquestion 2: if the spammer is a customer of one of your BGP peers.

We do not in general filter our bi-lateral peers.  Those going through
the RADB (about 25%) of course would not work unless they created
and deleted routing objects.

>subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

Probably it would work to us.

------- Message 12

[ someone answered obliquely... ]
> one day the routing will collapse; you would think people might have been
> frightened by recent redistribution or deaggregation disasters, but people
> go blithely on not filtering.

[ and i followed up... ]
there are a lot of fence sitters such as myself who know that filtering
is good but who don't want to maintain 10,000 element filter lists for
big peers like uunet and who don't want to just trust sprint to do the
right thing and who don't want to run RPSLmumble.  what's the right answer?

------- End of Forwarded Messages