How does the community feel about using /24 originations in BGP as a
tactical advantage against potential bgp hijackers?
All of our allocations are larger and those prefixes we announce for
clients as well usually are. But we had a request recently to
originate everything as distinct /24 prefixes, to reduce the effect of
a potential bgp hijack. It seemed a little bit like a tragedy of the
commons situation.
Is this seen as route table pollution, or a necessary evil in today's world?
How many routers out there today would be affected if everyone did this?
Are there any big networks that drop or penalize announcements like this?
It's route table pollution if you ask me.. in today's world we have many
IXPs and several tier-1 operators that support RPKI ROV, so when you
have issued ROAs for the supernet of the IP space in question it'll
already significantly reduce the effects of a BGP hijack.
Best regards,
Martijn
How does the community feel about using /24 originations in BGP as a
tactical advantage against potential bgp hijackers?
How many routers out there today would be affected if everyone did this?
Hi Billy,
I did some math on this years ago and it worked out to about 8.5
million IPv4 routes. That's 10 times the current table size, more than
any big-iron router can handle today. If everybody did it, it'd crash
the Internet.
Is this seen as route table pollution, or a necessary evil in today's world?
Pollution. And it won't save you from a hijack either, since your
adversary's /24 routes will compete and win for at least part of the
Internet.
Are there any big networks that drop or penalize announcements like this?
Not in an automated way. Which is bad news for you if you do this
because it means getting folks to -undo- the restrictions they
manually enforce on your specific address space is nearly impossible.
Regards,
Bill Herrin
Not just a route table.
- RIB scale
- FIB scale
- Configuration scale
We just recently learned of a IOS-XR prefix-set limit of 300001 when a
particular customer AS-SET expanded to a higher number of prefixes.
The problem with this scaling is that it doesn't reflect an increase
of revenue but it reflects an increase of cost. CAPEX to upgrade
devices without winning new business and OPEX to manage those
upgrades.
So it is a somewhat selfish solution to a problem.
Yes, it is bad practice. Yes, it’s polluting the route table.
If the # of /24s involved is not ridiculously large (say, <64?) them I would go ahead, as long as IRR and/or RPKI are also updated.
Obviously if everyone did it (i.e. advertising /24s exclusively) then our FIBs would collectively balloon to a grotesquely un-manageable size, at least on platforms that can’t auto-aggregate that back down. Thankfully, everyone isn’t doing it.
I, too, would vastly prefer no-one did this, but I have two customers that demand it from time to time… and we’ve even done it for our own allocation sometimes, and there’s no robust, never mind bullet-proof, technical argument why I can’t do that for them (or for ourselves). OTOH robust arguments exist for why it’s a good thing to do - sometimes, and temporarily.
¯_(ツ)_/¯
-Adam
William Herrin wrote:
I did some math on this years ago and it worked out to about 8.5
million IPv4 routes.
It should be 14M.
Worse, it will be reached unless we stop doing multihoming by
routing, which is selfish.
Masataka Ohta
Doubtful. Like I said, I did the math. The question I asked at the time was:
If:
IPv6 fails to overtake IPv4 and
IPv4 continues to be divided and redistributed to progressively
higher-value uses and
the /24 public Internet announcement boundary holds then
What will the terminal size of the IPv4 Internet BGP table be?
There are 2^24 = 16.8M /24s in the IPv4 address space.
Many of these are reserved for non-unicast uses, e.g. 224/3, 0/8
Many of the unicast addresses are reserved for non-public uses, e.g. 10/8, 127/8
Some portion of the assigned address space is used off-Internet in
valuable enough ways that its owners are unlikely to release it for
use on the Internet.
Some portion of the address space won't be disaggregated to /24
because their owners won't find it convenient
Some portion of the address space will have overlapping announcements
(/24s and the overlapping the /20, that sort of thing)
I no longer have the exact formula but I made some reasonable
assumptions for each of these factors and it worked out to 8.5 million
as the probable terminal size of the IPv4 table. There were error
bands too, I forget what they were, but nothing came even close to
14M.
Regards,
Bill Herrin
Hi,
It should be 14M.
Just for fun, I did the math. A total of 16,777,216 /24s fit in 32 bits. Take away all the reserved space as per IANA (this is 1,266,696 /24s, see below), and we end up with 16,777,216 - 1,266,696 = 15,510,520 potential /24 advertisements.
The largest FIB table I have seen (hi Jim!) was 3,563,546 routes in hardware. This was in a lab environment, of course.
Thanks,
Sabri
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
Subnet Number of /24s
0.0.0.0/8 65536
10.0.0.0/8 65536
100.64.0.0/10 16384
127.0.0.0/8 65536
169.254.0.0/16 256
172.16.0.0/12 4096
192.0.0.0/24 1
192.0.2.0/24 1
192.31.196.0/24 1
192.52.193.0/24 1
192.88.99.0/24 1
192.168.0.0/16 256
192.175.48.0/24 1
198.18.0.0/15 512
198.51.100.0/24 1
203.0.113.0/24 1
240.0.0.0/4 1048576
Total reserved 1,266,696
In addition to what everyone else said, announcing /24s will not help you one bit since ASNs announce /25s, /26s, /27s, etc. Attached is a 7800+ line text file sorted by ASN with prefixes being announced that are more specific than /24 (only /25+/26+/27 listed).
This is based on http://www.ris.ripe.net/dumps/riswhoisdump.IPv4.gz from about a month ago.
That dump lists all the IPv4 prefixes seen in the collective of latest RIS table dumps, together with origin AS and number of peers that passed the routes to RIS.
So good luck with announcing /24s.
Regards,
Hank
(Attachment more-specifics-sorted-by-asn.7z is missing)
Folks can announce longer than 24 masks all day. They’re unlikely to propagate very far though, since most won’t accept longer than 24 from the world at large.
To the OP, there are some valid reasons to strategically deaggregate here and there, but a blanket “yolo my entire allocation into /24s” seems to be a pretty ill considered request.
I prefer the approach of disaggregating only when needed, not as a preventative measure. There are tools that can help with automating this disaggregation (ARTEMIS can do this, for example).
Dear team,
I have resorted to more specific announcements during hijacks, though
with only one purpose in mind: To buy us a bit of time while the
upstreams and peers put blocks in place to thwart the hijack as close to
the source as possible. The more specifics are an imperfect solution,
since they don't always propagate as widely or as quickly as the
hijacks, but it buys us a bit of time.
The more important part of that solution is to network with fellow
network operators. This is my go-to solution for everything from
hijacking to DDoS to "what the heck is that?!" 
Be well,
Rabbi Rob.
Howdy,
It's not that simple. For example, 224/4 is not a 'reserved' space but
it can't appear in the unicast BGP table either. That alone is a
million routes unaccounted for in your math.
Regards,
Bill Herrin
Bill said,
Is this seen as route table pollution, or a necessary evil in today’s world?
Pollution. And it won’t save you from a hijack either, since your
adversary’s /24 routes will compete and win for at least part of the
Internet.
I agree, of course, that moving to announce every /24 would pollute the net. Note that if you use ROAs, you’ll also have to make corresponding /24 ROAs, and I don’t know if this won’t have problematic impact also on the RPKI infrastructure. Not good.
But:
- assuming the /24 will have proper ROA, and ROV is reasonably deployed, this would protect most of the traffic sent to the /24 from a hijacker announcing /24 (and even more if hijack is of shorter prefix, of course).
- As long as ROV isn’t very widely deployed, it would often fail to protect against the hijack without such measure (competing /24), so this will remain necessary (if you wish to prevent hijack).
We’ve done some relevant simulations, as well as proposed a simple extension to ROV, called ROV++, which protects against such sub-prefix hijacks without requiring competing /24 announcement, and effective already with modest adoption (of ROV++) by BGP routers. (Should also be assisted by mixed ROV / ROV++ adoption but we didn’t do these simulations yet.)
See at: https://www.ndss-symposium.org/ndss-paper/rov-improved-deployable-defense-against-bgp-hijacking/
tl; dr : ROV++ routers would blackhole subprefix traffic rather than send it on a route which would be hijacked (i.e., if the route is to a neighbor AS that announced legit prefix and hijacked subprefix). Simple.
[and no, I’m not happy with the resulting disconnections. but it’s better than hijack imho]
best, Amir
RPKI is more effective than a competing /24. Unless they hijack you ASn as well.
man. 9. aug. 2021 22.13 skrev Grzegorz Janoszka <grzegorz@janoszka.pl>:
How does the community feel about using /24 originations in BGP as a
tactical advantage against potential bgp hijackers?
RPKI is more effective than a competing /24. Unless they hijack you ASn
as well.
You will usually get an as path length advantage even if they do hijack your asn.
Regards
Baldur
Unless your RPKI is set to allow /24 but you normally advertise /21 or something shorter.. then RPKI works to the hijacker's advantage.
You could argue this is no different than before RPKI which is true.. except that now that RPKI exists people are tempted to use it to automate configuration and take humans out of the loop.
I imagine there are quite a few RPKI enabled prefixes (those configured to allow too long advertisements) that are easier to hijack now than they were before RPKI existed.
-Rob
This will break the internet at scale. No.
Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
6x7 Networks & 6x7 Telecom, LLC
CEO
lb@6by7.net
"The only fully end-to-end encrypted global telecommunications company in the world.”
FCC License KJ6FJJ
Are there any big networks that drop or penalize announcements like this?
It's possible you could get your peering request denied for this. I
have put *reasonable* prefix aggregation into peering requirements for
some years now. If you are a small eyeball network with 8192 IP
addresses and originate 32 /24's, that is *not* reasonable.
Sabri Berisha wrote:
Just for fun, I did the math. A total of 16,777,216 /24s fit in 32
bits. Take away all the reserved space as per IANA (this is 1,266,696
/24s, see below),
> 240.0.0.0/4 1048576
I think we should also take away multicast addresses of
> 224.0.0.0/4 1048576
because multicast route can not be aggregated and must
be treated as /32.
Anyway,
The largest FIB table I have seen (hi Jim!) was 3,563,546 routes in
hardware. This was in a lab environment, of course.
for /24, these days, having 16M entry SRAM (simple one, not
TCAM) is trivially easy.
Masataka Ohta