route ingress [summary 2]

Wed Dec 31 06:43:11 UTC 1997

One thing I've heard several times now is "yes, I share an unrestricted IGP
with some set of customers and so my net could be victimized by this trash,
but we filter on egress to our BGP peers so we could not be a conduit."  This
is new and useful information for me -- it may mean that only a multinational
network could get one of these prefixes into enough end systems to matter,
and MOST (hint, hint, nudge, nudge) multinationals are doing static ingress.
This problem may be solvable with small deltas in only a few bad spots.  (You
know who you are, we'll talk in Alburqurque.)

The other thing I've learned from this escapade is that when folks think they
can talk on NANOG without anyone flaming them by name afterward, some folks
talk who normally don't.  This may say something bad about the way we treat
each other -- not everybody whose participation I value has thick enough skin
to put up with my manners, much less those of some folks here I could name.

------- Forwarded Messages

I am not replying to provide any sage input.  I have none. I'm pretty
new to BGP in general.  I'm replying mainly to say thanks for directing
a discussion that, to me, is fascinating, and from which I hope to learn
a great deal.

[ well, i'm not a real routing guy but i'm glad to help illuminate a topic. 
  --vix ]

I'm one of those newbies who is having to come up to speed in a hurry.
I began contracting with XYZZY on a somewhat unrelated network upgrade
project.  Basically, for the time being, I've inherited the future of
the network.  I've done lots of IP networking, just not on this high a
level, until now.

I'm lurking.  It's a tough crowd out there on NANOG. :-)  My goal is
to make/keep XYZZY a responsible networking outfit while learning enough
to keep myself employed. :-)

I won't take anymore of your time.  I have included below a belated response 
to your earlier query.

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

I think so. We announce static routes only for those CIDR blocks allocated
to us.

>(2) degree of enforcement of (1) is probably going to be a term of most 
>peering agreements by this time next year; 

OK, I promise to bring it up when we next agree to a peering arrangement

>(3) enough folks are enough opposed to the RADB that intermediate-system 
>route control probably won't come that way; 

I'm a newbie.  I'm still working on understanding all the inner workings
of RADB.  I know what it does, but not how it works.

[ so far it has run aground on the old prescriptive/descriptive debate, and
  some significant large providers have not joined the party.  needless to
  say, it won't solve THIS problem until EVERYBODY uses it.  --vix ]

I believe the following three responses re true of our network as well

> 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 would accept it it all cases.

------- Message 2

1. Currently, we filter what is advertised to our upstream providers so it 
would not get advertised to the Internet at large, but it would be propagated
through our IBGP mesh and to our BGP peers/customers.  So, I guess this 
is a "mostly" no.

[ this is sometimes called "unintended transit" and it's a large enough
  problem that it's probably worth solving for operational reasons even
  apart from the security issues.  you should filter on egress to your BGP
  neighbors no matter what.  you should filter on ingress where possible,
  and use static ingress with any single homed customer.  --vix ]

2. We do not filter inbound announcements from BGPpeers/customers/upstreams,
so yes.  We do plan to generate filters from IRR for the smaller ones in 
the near future (once they keep their information up to date), but it seems 
infeasible to do so for upstreams such as MCI, UUNet, etc. given the 
size of the resulting filters.

[ yes, i worry about the large ones too, but way down below i'll waffle.
  using the IRR wherever possible makes sense unless you have high BGP
  wizardry on your staff in which case you'd want all the knobs to yourself.
  --vix ]

3. Yes, and I don't see a practical way to do it given current technology.

When you talk about fixing the problems by changing BGP, I am curious what
design you would propose to fix this.  As I see it, the only practical 
way to validate advertised routes automatically is using digital signatures
of address delegations, and validating the chain of delegations back to a
root (configurable in the router).  

[ yes, that's my thinking, and it's also what i've heard from the security
  folks.  --vix ]

                                    One problem with this is that the
bandwidth required to exchange routing information will increase 
dramatically, as well as the memory required to store the routing information
(since a peer will have to be able to pass on the certificate of a received
route object).  Do you see another solution to the problem?

[ here's the promised waffle.  routers have been getting bigger, and despite
  the lamentations of the "i want a routing table i can count on one hand"
  crowd, they are going to keep getting bigger.  if IOS were still scalable,
  cisco would be selling MasPar-like RP's with a gigabyte of ram (expandable).
  then we have bgp itself, which is a delta protocol based on reliable TCP
  for its statekeeping, so other than at startup or during heavy route flap,
  the bandwidth consumed by BGP is microscopic compared to, say, DNS or SMTP.
  (note, i'm not comparing it to HTTP, next to which anything is microscopic.)
  finally, security engineering is all about tradeoffs.  some balance will be
  found between the size of the keys and signatures, the complexity of the
  algorythms, and the economic realities of the market.  i see a big overlap.
  --vix ]

------- Message 3

     subquestion 1: if the spammer is your customer.

They couldn't inject the route unless they registered with us first
and that process should disallow it if it's unregistered. Using the
IP address wouldn't get caught yet, we are waiting for Cengiz to add
ingress filtering to RtConfig so we can build the filters out of the
policy info stored at RADB.

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

We only check that the route is tagged with an AS path that we are
expecting to see from the peer so if they get it past the peer then we
will believe it.

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

We lose here since we believe what we get from our provider.

------- Message 4

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

no. customers are considered dangerous when armed with BGP. they are
AS and prefix fitlered.

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

Only if they're ASpath is valid by RA registries.  We are not [yet! in
my copious spare time we will be!] prefix filtering on peers.

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

n/a, if I read the question right.

------- Message 5

> routing core allow it?  

Yup, mostly. :( 

>                        subquestion 1: if the spammer is your customer.  

"No", but then we don't have any BGP customers either.  We're in the
process of creating a BGP service for those customers that want it.  I'll
be collecting this thread from NANOG as part of the argument to make sure
we "do it right" and get the resources to make sure the answer to this
question will remain "no".

Of course, if the customer was multihomed we might still learn the route
via the method in subquestion 3 because it would be a false assumption to
apply the same filters to what we learn via their other upstreams as to
what they announce to us. (Hmm. but we could make it a true assumption by
writing the contract carefully... "tell us all routes you expect to
originate in your AS even if you don't plan to announce them to us because
we will filter you on our other borders too" ;)

[ this is pretty common.  no potential customer is going to choose a different
  provider based on this restriction -- or if they do, you're better off.
  --vix ]

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

"yes, unless RFC1918 addresses". I'm hoping to overbudget for the above so
that we can change this to a "no" as well.  That would probably rely on IRR
data, which is also open to fakery, but the filter reloads wouldn't be
realtime so it should still block 5 minute announcements.

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

"yes, unless RFC1918 addresses". I notice that some of our "big" transit
providers trust whatever some of the other "big" backbone carriers feed to
them. It's interesting to see networks belonging to peering LANs at various
IXPs show up from time to time.

I'm not sure that this can be easily fixed. Maybe the solution is similar
to the IP filtering one, in that it only works when everyone filters at all
the 'little' BGP sessions so that we can then 'trust' what our backbones
feed us.

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

Thanks for making me think. 

Do you realise that you accidentally posted something of operational 
content and interest to NANOG ? 

[ i didn't mean to.  it was the only audience i could think of for my
  question.  i don't think i'm part of a trend of any kind, though.  --vix ]

------- Message 6

> up before now.  I guess spamming was the first natural application for it.

If we required all mail relayers to have valid in-addr.arpa DNS, this
would be a non-issue.  Unfortunately, when I used sendmail rules to
enforce that, too many valid (but clueless) sites were prevented from
passing mail into FDT, and I had to back down.

[ the in-addr.arpa tree was never really populated at all the way it is now
  until uunet.uu.net, then the net's largest ftp server in the days before
  the web or even gopher, started requiring forward/reverse matches for all
  inbound anonftp connections.  i think the progress we collectively made
  then is about all we can expect for the remainder of the experiment. --vix ]

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

How impractical would it be to put all unallocated space in the RBL??

[ i did that today, but it's somewhat hopeless since i'm advertising /8's and
  the address thieves only need to offer something longer.  it's time to hack
  on gated some and get it to automatically warn me when a more-specific comes
  in and occludes a particularly-tagged static.  --vix ]

It's hard to believe spam providers have stooped to this level...but
assuming they have, I suppose the next step would be temporary theft of
address space, though that would probably generate a lot more heat for
them.  The run of the mill small ISP or business on the net might not even
notice a 5 minute interruption of routing, and would certainly lack the
ability to track down those responsible.

[ indeed.  while this has been done from time to time it was always with the
  intent of doing harm to the network's owner, not just to steal their
  identity for various purposes.  next april 1 we should see some demon-
  strations of this concept in hopefully friendly ways.  --vix ]

------- Message 7

***SEE the end re 7777:x communities for your BGP announcments***

>routing core allow it?  

In to us from the world? YES
Out from us? We ingress filter most but not quite all customer traffic, so NO

>subquestion 1: if the spammer is your customer.  

regular customer, NO (see above), BGP speaking customer (i provide transit 
for) YES - they are FEW and trusted.

I may be using terms differently... I am using "BGP peer" as a peering 
point NO TRANSIT either way connection.

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

I'd use his routes internally, but would not propagate them.

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

We would pass it all like any other traffic.

BUT, I was delighted to see you have now decided to blackhole them
but have a problem perhaps you can help with!

We are subscribed to your BGP blackhole system but are not currently
using it internally because we had objections from downstream ISPs
that hate spam but also are leary of censorship. 

I need to work out a scheme where I can selectively apply the 
blackholing routes for the rest of my customers, probably
right into my 2501 at each of their sites!

[ i think you should just use the DNS access method in that case.  --vix ]

However I would LOVE to immediately use the ones you send for 
unassigned blocks - all the /8s you listed in other email.

PLEASE decide on a community or whatever to tag them with so I and
others can selectively use this subset of the blackhole system,
and skip the others for now.

And, while you are at it, perhaps there are some other subtle 
subdivisions that also could benefit from having their own
community. I assume the most logical community conventions
would be 7777:x and x would be on a published list of special tags.

Some thought might be made to more complex situations where a route
might have multiple communities and could be tested for appropriately
if it were known that that possibility existed.

[ the gated version i'm using doesn't support communities at all.  when it
  does, i will do what you said.  --vix ]

Also on your /8 announcements, won't the tighter masks of spammer
5 minute announcements override your /8 or am I missing something?

[ yes.  but i felt that the symbolic gesture was better than nothing.
  actually i think the IANA ought to be advertising real routes for these,
  blackholed of course, just to keep somebody else from camping on "by
  accident" as happens every year or two.   --vix ]

------- End of Forwarded Messages