What are the best practices for the Internet?

A healthy Internet ecosystem is often considered to be one that is well-interconnected and exhibits a distribution of control (as opposed to singular central points of failure). But interconnection is just the beginning.  A healthy Internet also relies on factors such as responsible management of the Domain Name System (DNS), resource record management, routing hygiene, and network security and monitoring.

So what can network operators do to ensure they are contributing to a healthy Internet ecosystem? In this post, we will summarize several ‘current best practices’ for operating an Internet network.

 

Number registry

Maintaining accurate and up-to-date public records is a key responsibility of an Internet resource holder. It means that anyone can make a whois or RDAP query to understand who is responsible for a particular name, AS Number (ASN) or address prefix.

The accuracy of this information becomes particularly important in an incident response situation (such as a security breach, routing leak or DoS attack) to ensure that the incident can be reported to the correct responsible party as quickly as possible.

To this end, it is mandatory to register an Incident Response Team (IRT) contact for each record in the APNIC Whois Database. Contacts are validated every six months to ensure they are contactable and responsive. For further information on this policy, check the APNIC website.

Internet routing

Peering

Peering provides the greatest benefits when you peer widely, with as many networks as you can. Connecting to an Internet Exchange (IX) makes this easy to achieve.

Peering among networks in your economy also allows you to keep local traffic local, avoiding transit costs and delivering improved performance to your end users. This goes for IPv6 as much as IPv4, so make sure your v6 peering mirrors that of your v4 where possible.

BGP

Ensuring that you are peering with who you think you’re peering with is obviously important. The following mechanisms can help you do just that and should be enabled on all BGP sessions.

• BGP TTL Security (RFC 5082) looks at an IP datagram’s TTL field to ensure that it was generated on an adjacent node on a connected link.

• TCP Authentication Option (RFC 5925) authenticates a BGP session in a more advanced manner than BGP MD5 Authentication. If your router doesn’t support TCP-AO, enable MD5 Auth as a minimum.

An important aspect of routing hygiene is to aggregate your announcements as much as possible. The only reason you need to announce more specific routes is for specific traffic engineering needs. As an example, if you have a /18, it is reasonable to announce say, four /20s if they run over different uplinks, but there is no need to de-aggregate all the way down to 64 /24s. The global routing table (and community) will thank you!

Filtering is a vital aspect of maintaining a secure and reliable Internet.  Operators should be implementing prefix filters for both inbound and outbound announcements. These filters should have a maximum prefix limit set for routes received from peers. They should also deny bogons and your own prefixes.

AS Path filtering is also recommended. Set it to not allow private ASNs to be announced or accepted. You may still use private ASNs, but they must be stripped before announcing to upstreams and peers. Operators should also enforce the first ASN in the AS Path to be their direct peers and limit the path length for prefixes received — currently the Internet is about five to seven ASNs deep.

Inbound announcements should be filtered using Route Origin Validation (ROV); that is, routes with invalid origins or prefix length should be dropped. Make sure that you create and publish ROAs for all the prefixes you advertise and ask your downstreams and peers to do the same.

Read more: Creating RPKI ROAs in MyAPNIC

In addition to these measures, ensure your default BGP route propagation behaviour is changed from permit to deny, as proposed in RFC 8212. This functionality is not yet supported by all vendors, so if yours doesn’t support it, request it! Where your network nodes do not support this behaviour, make sure that BGP sessions with peers are shut down during configuration until you have defined and applied explicit import and export policies to your peer, before bringing up the session.

Network security

DNS

DNS servers are critical pieces of Internet infrastructure, providing name and address resolution for most applications. The DNS can be subject to DoS, cache poisoning and monkey-in-the-middle attacks, among others, so securing it is highly important.

There are several ways you can protect DNS servers. DNSSEC can ensure the integrity of messages sent between servers using digital signatures, and DNS over HTTPS (DoH) and DNS over TLS (DoT) can encrypt the last mile to prevent interception and eavesdropping.

Next Secure (NSEC) caching prevents DoS attacks against authoritative resolvers by allowing DNSSEC-validating recursive resolvers to use an NSEC record to answer all queries for a given name. NSEC records also include the next record name in the zone, so that recursives can also prove the non-existence of a name, preventing random name attacks.

Finally, Passive DNS involves the logging of responses received from DNS servers by recursive resolvers. Since passive DNS is not concerned with communication with stub resolvers, the data collected is effectively all cache misses. When this data is uploaded to a central database and deduplicated, it can become a valuable tool for detecting compromises, malicious activity and can inform the blocking of suspicious new domain names.

Back on the network side, BCP38 (RFC 2827) should be implemented at the network edge to drop packets with a spoofed source address, based on a reverse path lookup. Strict unicast reverse path forwarding (uRPF) is the norm, however, multihomed networks should implement BCP84 to avoid dropping false positives and creating asymmetric routing.

IPv6

Some IPv6-specific practices are also recommended. First, drop all IPv6 fragments that do not have upper layer headers in the first fragment, as well as dropping fragments that are destined for your network nodes.

Ensure you are not dropping ICMPv6 – this will break your IPv6 deployment. Rate limit it instead.

Finally, do everything you were doing for IPv4 for your IPv6 traffic. This includes things such as filters, ACLs, host and application hardening and cryptographic protections where necessary.

Some general security concepts to remember

• Always start with zero trust.
  • Deny all then explicitly allow, not the other way around.
• Put your firewalls close to the services they are protecting.
  • Prevent unnecessary firewall traversal — placing it in your backbone will reduce throughput.
• Anycast your services for resiliency.
  • DNS, for example.
• Know what is normal so you can tell what is abnormal.
  • Use monitoring tools such as NMSes and IDSes to establish a baseline and alert you when thresholds are exceeded or anomalous events occur.
• Profile your network using flow tools.
  • This allows you to optimize your use of infrastructure, and identify issues and potential peering partners.

Learn and share

The final best practice to remember is to share with and learn from your community.

Current best practices for Internet network operators are not set in stone — they evolve as the Internet does. The best way to keep up to date with current best practices, issues, and developments is to get involved in your community by attending events such as Network Operator Group meetings (NOGs) and APNIC and APRICOT conferences.

Staying in touch with your community will ensure that the lines of communication remain open between operators in your economy or region and that you can learn from each other’s experiences and achievements as your networks — and the greater Internet — grow.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.