Home page logo
/

nanog logo nanog mailing list archives

Re: route ingress [summary 3]
From: Paul A Vixie <paul () vix com>
Date: Mon, 05 Jan 1998 14:35:09 -0800

I think this discussion is pretty well played out.

------- Forwarded Messages

so the question that's got me perturbed at the moment is, if a spammer wanted
to spam from unallocated address space using five minute windows, would YOUR
routing core allow it?  subquestion 1: if the spammer is your customer.  

Almost always no. Almost all BGP speaking customers are filtered by network
and AS-Path. There are a couple who aren't who are filtered by network
(i.e. are filtered by path only) who should know better. We are putting
PRDB filtering on when we get the code ready.

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

Currently yes. Again we have PRDB filtering in the pipeline to fix this.

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

Currently yes. I do not currently plan to apply PRDB filtering to transit
providers - the connectivity loss would be too great. We will also leave it
off for large peers (UUnet for instance).

*HOWEVER* we've got some experimental stuff which generates ACLs
(i.e. filterlists) based on unallocated space, as well as BGP network
filtering (the IP access group business mostly for our amusement - the real
idea is to use these to automatically build customer facing anti-spoofing
filters from RIPE/RA etc.). Blackholing stuff destined for unallocated
blocks is neater by far.

My fear is that people will instead pick an unused prefix as opposed to an
unregistered one. IE if I advertize a /16 like 195.224.0.0 and the top /19
is not used, some joker will probably have a fair amount of success
stealing the top /19 for a few minutes to spam with. Worse still, they
probably would have a fair amount of success stealing an *inuse* more
specific of a block - and that really does have nasty consequences.

[ i think we can take for granted that spammers, at least, will only steal
  resources in ways they think won't be noticed.  on the other hand, sequence
  number guessing such that you don't care if the recipient can EVER get a
  packet back to you, is probably even better by that measure.  --vix ]

------- Message 2

i've been tracking some spammers through unallocated address space of late.
i'm about to have to turn on extreme-level debugging in my bgp speaker, since
what's been happening is that a route is injected "somewhere" to unallocated
space, a whole boatload of relayspam is unloaded in a matter of minutes, and
the unallocated-space route is withdrawn.

The Merit/RA/RSNG/etc folks keep logs containing every BGP announcement and
withdrawal seen by the route servers.

however, when you set up BGP peerage with somebody, you're at the mercy of
whatever level of selectivity they use in their injections.  that is, most
folks do not use RPSL or the PRDB or whatever to control what they'll listen
to from a BGP peer.  the assumption of trust and competence still runs high
among people who speak BGP to each other.

Believing any transitive source leads to the same vulnerability, whether
it is BGP or a database like PRDB or IRR.  The problem isn't one of too much
trust or competence, but rather distrust and corporate priorities.

so the question that's got me perturbed at the moment is, if a spammer wanted
to spam from unallocated address space using five minute windows, would YOUR
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.

First you have to decide what is "unallocated address space."  Unallocated
by whom:  IANA, a regional registry, a provider, or even an end-user?  And
I suspect it isn't just a question of unallocated address space, but also
what used to be known as "connected status."  There are several allocated
address blocks which are never announced to the Internet.  Longest match
rules of CIDR makes any network subnet that isn't actively being used
vulnerable to unnoticed hijacking.

The reason its important to decide what type of unallocated address space
is involved is because there are a variety of ingress filters used by
different providers and they stop different things.  The common methods
are 1) filtering by expected address, 2) filtering by AS number or path,
3) filtering by exception, e.g. blocking martian networks.  Or filtering
using a combination of those methods. A provider might block announcements
from net 1.1.1.1, but not block 213.1.1.1.

[ i am primarily interested in space which has not been allocated by IANA,
  or which has been allocated by IANA but not by the regional registry yet.
  unused portions of allocated, connected, advertised blocks are so much
  harder for me to track that i know i never shall track them.  --vix ]

Answers to your questions

1: We have a lot of backdoor connections to sites that are also connected
to the former NSF regional networks.  In general, we have to filter our
customer connections to prevent all sorts of routing leaks, not just
unallocated address announcements.  BGP speaking customers provide a list
of network numbers and ASNs they plan to announce.  Currently they are
manually verified against WHOIS and then entered into the IRR databases.
BGP core routers have egress filters to prevent both unintended transit,
and unknown network announcements.  This also acts as a belt-and-suspenders
approach to preventing unintended network announcements beyond our network.

2: All BGP peers are passed through an "Oops filter" blocking patently
offensive network announcements (martians, extremely long prefixes,
broadcast, loopback and default).  Unallocated addresses aren't blocked
(currently) by my Oops filter.  A few BGP peers have explicit network
address ingress filters, which would block an unallocated address.

3: Currently I don't have any source ASN/IP address cross-checking.  A
distant BGP-connected AS could announce any network I accept from the BGP
peer in tha path directly connected to me.  The same Oops filter or applies
in any case.

And finally, a couple of untested filters

For those that prefer "if it isn't explicitly denied, allow it":

! Based on ftp://ftp.isi.edu/in-notes/iana/assignments/ipv4-address-space
! as of Dec 30, 1997, check for new allocations if used
! IANA - Reserved
access-list 100 deny   ip 0.0.0.0 0.255.255.255 any
access-list 100 deny   ip 1.0.0.0 0.255.255.255 any
access-list 100 deny   ip 2.0.0.0 0.255.255.255 any
access-list 100 deny   ip 5.0.0.0 0.255.255.255 any
access-list 100 deny   ip 7.0.0.0 0.255.255.255 any
! IANA - Private Use
access-list 100 deny   ip 10.0.0.0 0.255.255.255 any
! IANA
access-list 100 deny   ip 23.0.0.0 0.255.255.255 any
access-list 100 deny   ip 27.0.0.0 0.255.255.255 any
access-list 100 deny   ip 37.0.0.0 0.255.255.255 any
access-list 100 deny   ip 39.0.0.0 0.255.255.255 any
access-list 100 deny   ip 41.0.0.0 0.255.255.255 any
access-list 100 deny   ip 42.0.0.0 0.255.255.255 any
access-list 100 deny   ip 58.0.0.0 0.255.255.255 any
access-list 100 deny   ip 59.0.0.0 0.255.255.255 any
access-list 100 deny   ip 60.0.0.0 0.255.255.255 any
! IANA - Reserved 64/8 - 127/8 (Note: 127/8 is LOOPBACK, not RESERVED)
access-list 100 deny   ip 64.0.0.0 63.255.255.255 any
! IANA - Private Use
access-list 100 deny   ip 172.16.0.0 0.15.255.255 any
! IANA - Private Use
access-list 100 deny   ip 192.168.0.0 0.0.255.255 any
! IANA - Reserved 213/8 - 223/8
access-list 100 deny   ip 213.0.0.0 0.255.255.255 any
access-list 100 deny   ip 214.0.0.0 1.255.255.255 any
access-list 100 deny   ip 216.0.0.0 7.255.255.255 any
! IANA - Multicast 224/8 - 239/8
access-list 100 deny   ip 224.0.0.0 15.255.255.255 any
! IANA - Reserved 240/8 - 255/8
access-list 100 deny   ip 240.0.0.0 15.255.255.255 any
! If not denied above, assume address is an allocated IPv4 unicast address
access-list 100 permit ip any any

For those that prefer "unless explicitly allowed, deny it":

! Based on ftp://ftp.isi.edu/in-notes/iana/assignments/ipv4-address-space
! as of Dec 30, 1997, check for new allocations if used
access-list 100 permit ip 3.0.0.0 0.255.255.255 any
access-list 100 permit ip 4.0.0.0 0.255.255.255 any
access-list 100 permit ip 6.0.0.0 0.255.255.255 any
access-list 100 permit ip 8.0.0.0 0.255.255.255 any
access-list 100 permit ip 9.0.0.0 0.255.255.255 any
access-list 100 permit ip 11.0.0.0 0.255.255.255 any
access-list 100 permit ip 12.0.0.0 0.255.255.255 any
access-list 100 permit ip 13.0.0.0 0.255.255.255 any
access-list 100 permit ip 14.0.0.0 0.255.255.255 any
access-list 100 permit ip 15.0.0.0 0.255.255.255 any
access-list 100 permit ip 16.0.0.0 0.255.255.255 any
access-list 100 permit ip 17.0.0.0 0.255.255.255 any
access-list 100 permit ip 18.0.0.0 0.255.255.255 any
access-list 100 permit ip 19.0.0.0 0.255.255.255 any
access-list 100 permit ip 20.0.0.0 0.255.255.255 any
access-list 100 permit ip 21.0.0.0 0.255.255.255 any
access-list 100 permit ip 22.0.0.0 0.255.255.255 any
access-list 100 permit ip 24.0.0.0 0.255.255.255 any
access-list 100 permit ip 25.0.0.0 0.255.255.255 any
access-list 100 permit ip 26.0.0.0 0.255.255.255 any
access-list 100 permit ip 28.0.0.0 0.255.255.255 any
access-list 100 permit ip 29.0.0.0 0.255.255.255 any
access-list 100 permit ip 30.0.0.0 0.255.255.255 any
access-list 100 permit ip 31.0.0.0 0.255.255.255 any
access-list 100 permit ip 32.0.0.0 0.255.255.255 any
access-list 100 permit ip 33.0.0.0 0.255.255.255 any
access-list 100 permit ip 34.0.0.0 0.255.255.255 any
access-list 100 permit ip 35.0.0.0 0.255.255.255 any
access-list 100 permit ip 36.0.0.0 0.255.255.255 any
access-list 100 permit ip 38.0.0.0 0.255.255.255 any
access-list 100 permit ip 40.0.0.0 0.255.255.255 any
access-list 100 permit ip 43.0.0.0 0.255.255.255 any
access-list 100 permit ip 44.0.0.0 0.255.255.255 any
access-list 100 permit ip 45.0.0.0 0.255.255.255 any
access-list 100 permit ip 46.0.0.0 0.255.255.255 any
access-list 100 permit ip 47.0.0.0 0.255.255.255 any
access-list 100 permit ip 48.0.0.0 0.255.255.255 any
access-list 100 permit ip 49.0.0.0 0.255.255.255 any
access-list 100 permit ip 50.0.0.0 0.255.255.255 any
access-list 100 permit ip 51.0.0.0 0.255.255.255 any
access-list 100 permit ip 52.0.0.0 0.255.255.255 any
access-list 100 permit ip 53.0.0.0 0.255.255.255 any
access-list 100 permit ip 54.0.0.0 0.255.255.255 any
access-list 100 permit ip 55.0.0.0 0.255.255.255 any
access-list 100 permit ip 56.0.0.0 0.255.255.255 any
access-list 100 permit ip 57.0.0.0 0.255.255.255 any
access-list 100 permit ip 61.0.0.0 0.255.255.255 any
access-list 100 permit ip 62.0.0.0 0.255.255.255 any
access-list 100 permit ip 63.0.0.0 0.255.255.255 any
! IANA - Private Use
access-list 100 deny   ip 172.16.0.0 0.15.255.255 any
! 128-191/8
access-list 100 permit ip 128.0.0.0 63.255.255.255 any
! IANA - Private Use
access-list 100 deny   ip 192.168.0.0 0.0.255.255 any
! 192-212/8
access-list 100 permit ip 192.0.0.0 15.255.255.255 any
access-list 100 permit ip 208.0.0.0 3.255.255.255 any
access-list 100 permit ip 212.0.0.0 0.255.255.255 any
! If not permitted above, assume address is not an allocated IPv4 address
access-list 100 deny   ip any any

[ i have to caution against installing such filters in most networks, since
  it will make it really really hard for us as a community to ever use that
  unallocated space.  this is one instance where it is safer to use the RBL
  (which has synchronized withdrawal) than to filter things locally.  though
  i would feel pretty great if IANA would advertise routes to its unallocated
  space, just to "claim" it.  --vix ]

------- Message 3

Because you indicated some concern over the silent replies the first time
around, I will add our "me too". We filter our outbound announcements, and
specify them using network statements anyway.  Injecting routes is not a
good way for us to do things.

Regarding route announcements we listen to, we accept them without filters,
and carry full tables, so we are susceptible to remote AS's which add
unallocated routes, then withdraw them.

We are multihomed to only two providers, Sprint and XXX.  XXX gets most of
their routes from MCI, whom I believe peers with the RADB, while the Sprint
peerage is likely to be more suspect.

We do not allow relay mail, so we are more likely to be stung by this than
inflict it on someone else.

------- Message 4

so the question that's got me perturbed at the moment is, if a spammer wanted
to spam from unallocated address space using five minute windows, would YOUR
routing core allow it?

subquestion 1: if the spammer is your customer.  

No, we have filters on our outgoing that allow out only the networks we are
currently advertising.

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

We don't have any customers doing BGP to us, but I would throw filters down
on their connection as well, so only the networks they were advertising or
ones they planned to advertise could get out.

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

Connected to my AS?  I think the response to 2 would apply to 3.  If not to
my AS, there's not much I can do about it.

------- Message 5

so the question that's got me perturbed at the moment is, if a spammer wanted
to spam from unallocated address space using five minute windows, would YOUR
routing core allow it?

  subquestion 1: if the spammer is your customer.  

  no. 

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

  currently yes, changed to no in a week.

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

  currently yes, changed to no in a week.

------- Message 6

From: smd () clock org

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.

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?

There is no right answer; it is endemic to the IP (v4/v6) addressing
structure.

The right thing to do is to can development on IPv6 since it (mo's proposal
notwithstanding) irretrievably suffers the same problems with respect to
the trust versus dynamism trade-off for external routing.  Next, work on
developing some of the good ideas which were abandoned after (and during)
ROAD/BIGTEN in favour of the current IPv6 proposal, letting the best get
picked through natural (rather than committee) selection.

IOW, work out a scheme whereby translating gateways can be used to make it
possible to build a multiprotocol catenet which supports current and future
applications decently.  Then let people choose what they want to run where.

Note that this is essentially (and ironically) what Bound's NNAT amounts
to, although his is more a clever hack rather than something
architecturally sound.

My gut feeling is that admitting that IPv4 will be around in some form or
another for a long time will allow us to focus on fixing some of its
near-term deficiencies, none of which have been touched on in IPv6
development.

That in turn buys us more time to develop and learn from the partial
deployment of alternative protocols.

Current answer for the routing system: prayer?  

        Sean.

------- End of Forwarded Messages


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]