Jamie Scaife - United Kingdom 🇬🇧 

Introduction to BGP Routing Security - Part 1: BGP Peering with Quagga

Monday 1st June 2020

Quagga is a network routing software suite providing implementations of various routing protocols, including RIP, OSPF and BGP. It is a fork of the discontinued GNU Zebra project, and utilises a configuration syntax very similar to that of Cisco IOS.

An 1804 illustration by Samuel Daniell of a South African quagga, an extinct subspecies of plains zebra after which the Quagga network routing software suite was named. Source (Public Domain)

Unlike traditional routing daemons which interact directly with the kernel, Quagga operates a central kernel routing manager (known as zebra) which exposes an API to the various Quagga routing daemons. This allows the routing daemons to be enabled, disabled and configured on a 'pick and mix' basis, including the ability to run multiple of the same routing daemon on one machine.

This article and series will be primarily focusing on Quagga BGPd, which is Quagga's BGP routing implementation. Continue reading...

BGP DN42 Guide

Using SPF Macros to Solve the Operational Challenges of SPF

Monday 11th May 2020

Sender Policy Framework (SPF) provides a way to restrict the mail servers that are permitted to send as your domain, and is particularly effective when used with DMARC.

However, maintaining an SPF policy for a large or complex infrastructure with numerous distinct mail servers can pose a significant operational challenge. Some of the most common issues include:

• SPF record is too long
• Maximum number of DNS lookups has been reached
• Keeping your SPF record up-to-date when mail is sent by third-parties
• Keeping track of which whitelisted senders are for what, who put them there, and removing them when they're no-longer needed
• Having to globally whitelist third-party systems when they only need to send-as a single or small number of addresses
• SPF record syntax becoming messy or breaking when it is maintained by multiple different people

SPF macros, a seldom used yet widely supported feature of the SPF specification, provide a potential solution to some of these challenges.

This article includes an introduction to SPF macros, as well as several examples of how they can be used to solve the various operational complications that SPF so often poses. Continue reading...

Security RFC Guide

Introduction to BGP Routing Security - Prelude: Connecting to the DN42 Overlay Network

Tuesday 31st March 2020

Decentralized Network 42, known as DN42, is a private overlay network built using thousands of distinct nodes interconnected with each other via VPN tunnels. DN42 employs routing protocols such as BGP and OSPF in order to route packets, allowing users to deploy services such as websites, IRC servers and DNS servers in a way very similar to the real internet.

The landing page for DN42, available at dn42.us.

The DN42 network is primarily used by network and security engineers in order to provide a safe and accessible environment to practise using network technologies, as well as allowing isolated networks, such as those behind strict firewalls or NAT, to communicate with each other directly.

However, the primary selling-point for DN42 is that it provides free and realistic access to a production-like BGP environment, which is something usually reserved for network operators responsible for large enterprise networks or ISPs who are also often paying expensive registry fees. Continue reading...

BGP DN42 Guide

Restricting Who Can Issue Certificates for Your Domain with CAA

Thursday 13th February 2020

Certificate Authority Authorisation (CAA) is a security control that can be used to restrict the Certificate Authorities (CAs) that are permitted to issue certificates for your domain. The purpose of this is to help ensure that only explicitly whitelisted CAs are able to issue certificates, and also to report on any attempted violations of this policy.

CAA policies are set using the CAA DNS resource record type, and it has been mandatory for issuing CAs to check for and comply with CAA policies since 8th September 2017. The CAA specification is defined in RFC8659.

The following sample CAA policy marks Let's Encrypt as the only CA authorised to issue certificates for example.com, while requesting that violations are reported to the caa-violations@example.com mailbox:

example.com IN CAA 0 issue "letsencrypt.org"
example.com IN CAA 0 iodef "mailto:caa-violations@example.com"

This policy will then be checked by CAs when a certificate request is submitted for your domain. Continue reading...

Security TLS RFC