We all know about Border Gateway Protocol (BGP). We also know that it’s permissive by nature and that serious problems can happen when routes are leaked or, worse still, hijacked. In previous years, even prominent organisations such as Google, Apple, Facebook, YouTube, and Microsoft have been victims of hijacking, which is a good reminder that we need to actively prevent it.

So, the question remains, how do we protect ourselves and reduce our networks’ vulnerability to leaking and hijacking? Think BGP security!

Although it’s a topic that has been widely discussed for many years, there are a few things you can do to instantly improve BGP security on your network by adopting some of our tips for good BGP hygiene.

Tip One: Block bogons

Plain and simple, by definition, bogon prefixes should not exist on the Internet. Bogon routes are bogus. They are those routes that comprise IP address ranges mistakenly, or purposely, advertised that are unassigned, or even reserved for something else altogether. We should not be receiving or sending packets from them, and if collectively blocked, we can protect our networks.

What do people achieve by using this space? SPAM! You can use a prefix that no one owns and spam to your heart’s content. TEAM CYMRU provides a BGP feed that you can use to drop these at your edges automatically.

Tip Two: Filter, filter, filter!

Filtering should be applied at every stage, starting with a ‘drop all’ and being specific about what to allow.

Transit Providers – Ingress:

• Drop Bogons (including RFC1918 space) – DON’T RELY ON A DROP ALL RULE TO CATCH THESE
• If you are expecting only a default route, DROP EVERYTHING ELSE
• If you are expecting a full transit feed without default, DROP DEFAULT

 Transit Providers – Egress

• Send your routes
• Send your customer routes – send your customer tagged routes based on your internal community
• Do not use prefix lists alone – you MUST use prefix lists and communities together

 Customers – Ingress

• Drop Bogons (including RFC1918 space)
• Validate prefixes with RIRs and get LOAs – if the customer does not own the prefix, do not accept it
• Match BOTH prefix AND AS-Path
• Drop RPKI invalids
• Set max-prefixes – if a customer should only be sending you ten prefixes, set a limit of 15 on the session. That way, if they have a route leak, their session will be disabled and will stop you from propagating the leak (see tip three for more information on leaky routes)
• Use communities – tag valid routes here with an internal community, and propagate to your providers based on the communities

 Peering Providers (that’s us) – Ingress:

• Drop Bogons (including RFC1918 space)
• Do not trust routes from route servers – we validate, but you MUST validate them too
• Set max prefix limits on sessions and shut down route servers if it exceeds the max prefix limit (generally 10-20% of total routes)
• Drop RPKI invalids
• Set max-prefixes – our numbers are on PeeringDB

 Peering Providers – Egress:

• See Transit Provider Egress
• Send your internal routes
• Send your customer routes – send your customer tagged routes based on your internal community
• Do not use prefix lists alone – you MUST use prefix lists and communities together.

Tip Three: Adopt good routing practices

You should always have a consistent route advertisement policy. Don’t send /24s to peering and /22s to transit providers. Unfortunately, this adds junk into the ever-expanding global routing table and is not beneficial in any shape or form.

Our Tech Team Leader predicts that if we *remove* all the redundant specific routes – that is /24s when the same path exists with a /22 or something larger – we can reduce the size of the routing table from 870,317 routes all the way down to 390,074 routes (please note that this an internal finding and should be taken with a grain of salt).

The best local preference orders are:

• Preference customer routes – they pay you, so if you have a route from a customer, you should use that first.
• Preference peering routes – peering is cheap, so offload as much as you can here to reduce your transit bill
• Preference transits – the *last* resort path, as it’s generally expensive

With everyone following the model above, using /24s on peering and /22s on transits makes no sense, as peering will already be preferred – YOU CAN HELP TO SAVE THE ROUTE TABLES!

Tip Four: Use Resource Public Key Infrastructure (RPKI)

If you haven’t already, deploy RPKI. This form of authentication helps by using Route Origin Authorisation (ROA), a form of authentication of the origin AS number to verify routes. Simply, it acts as a digital thumbprint.

Validate RPKI at every step. Validate routes from transit, peering, and customers.

• If RPKI state is INVALID, then drop the route. Do not use it to route any packet – no matter what
• If RPKI state is VALID, prefer this path over an unknown
• If RPKI state is UNKNOWN, use this path at a lower preference

The Internet continues to be a place of opportunity, both good and bad, and we need to do our best to reduce our networks susceptibility to leaking and hijacking. To instantly reduce some of the vulnerabilities of your network, try following our tips for good BGP hygiene or get in contact to speak with one of our network experts at the Internet Association of Australia Ltd, who are always happy to help.

Disclaimer: Before choosing to action any of the tips in this post, please be sure to consult with your organisation’s network and security experts.

We are pleased to announce the purchase of 35 Nodegrid Gate Services Routers and two Net Service Routers that will improve our network management and infrastructure. These new pieces of hardware will be used for both in-band and out-of-band services, with one device located in each point-of-presence (PoP) on our network.  

These routers provide peace of mind in the unlikely event that equipment breaks down by ensuring engineers can gain access to broken devices. The new ZPE Systems hardware will also contain both Telstra and Optus SIM cards to ensure redundancy and continuous coverage.  

In future, we will also be able to create data centre latency maps available on Grafana and, later, the members portal.