What You Need to Know about the Big 3 Protocols

BGP, DNS and SMTP. The big three protocols, you might say. When someone upstream messes with these protocols, you and your users are going to have a bad day--and there is not much you can do about it other than beware. Here's what to look for.

Border Gateway Patrol

The most powerful Internet protocol is BGP, or Border Gateway Protocol. It's also the protocol you have the least control over. It’s managed by top Internet gateways. Your ISP or carrier connection has its entry on the Roadmap Of The Internet that routes all of the packets your organization produces in all of its locations, with the exception of private networks.

Why worry about BGP? Imagine a map of connecting dots covering the planet Earth. Each of these dots represents an address, and where the next address ought to be, in a huge table. BGP is the roadmap that gets a packet to its correct destination. For example, to get to X, you must go through D and L.

Routing happens through each interconnected gateway. Changes are supposed to be infrequent--indeed, the map between and among major gateways doesn’t change very often. Equipment and peering arrangements change every day, but it's not something that anyone should notice--unless something goes wrong and a mistaken entry is made. If an ISP or gateway router changes a route, everyone who is affected--which is most of the world--goes along with the change.

If not, mayhem ensues. For example, it would be possible to grab enormous chunks of the Internet’s traffic and route huge swaths of hosts through China until someone noticed. The implications of traffic being routed through China are political, of course, but, from a technology standpoint, what it would mean for organizations is that where traffic is correctly protected, delays would become huge. Whether BGP hijacks are accidental or on purpose, captured traffic can be investigated. This is one reason why it is so important to encrypt traffic to and from websites.

Domain Name System

The Domain Name System is used by every internet user many times in a session.

DNS on its face is very simple: It delivers an IP address for a name query, such as itprotoday.com The IP address, in turn, is the end destination for whatever is being exchanged. It’s possible to navigate the internet by memorizing IP addresses, but domain names are much easier. It’s also possible to build your own table using a hosts.txt file, although even the hosts.txt file table may not always be referenced by your operating system.

There have been (and are) numerous attacks based on DNS queries. Denial of service (DoS) can happen due to quirks in the way DNS queries are managed. Attacks can be amplified in several schemes into distributed denial of service (DDoS) attacks, where many systems are forced to answer questions repeatedly of the same DNS server. This DNS server will become overwhelmed with traffic and either shut down or become unavailable until the queue for the requests ceases. This results in "not found" errors for simple queries because IP addresses can’t be correctly answered.These attacks can be mitigated in several ways, and many vendors offer solutions for protecting against such attacks.

DNS tables are managed in a distributed manner. There are top-level domains (TLDs), such as .com and .org, as well as many newly established TLDs, including .date and .xyz. These are called root servers, and various servers forward queries that can’t be found in local tables to root servers. These servers are often located at ISPs, MSPs or organizational data centers that are authoritative for subordinate entries controlled by them.

When a user makes a query by typing, say, geico.com into a browser, the browser queries the DNS resolver handed to it when the computer running the browser was started. If that DNS server knows the answer (or has it in cache), it answers immediately. If it doesn’t know the answer, it asks its upstream DNS server, which may pass the query along until it reaches the root servers (the final authority).

Much mayhem can ensue in the middle. DNS servers can be poisoned, meaning they can be filled with entries that are wrong--perhaps pointing to fake destinations (although this is rare). The pointers in a DNS server also may point to incorrect upstream DNS servers. The DNS servers themselves might be interested in who’s asking for a DNS result, and store the IP address of the user making the request--a privacy risk. Several vendors offer alternate DNS servers that can be used to get around this problem, but it should be noted that these vendors would then be able to see who is asking for what.

There are other attacks that have been partially solved by using the DNS SECurity (DNSSEC) protocol, usually closest to the TLD DNS servers. Even this protocol, which uses certificates, has had its difficulties.

Dithering with DNS also can thwart phone systems based on VoIP. Slow DNS services, when hindered by attacks or other excessive use patterns, slow down call connections. Alternate DNS servers can also help here.

Simple Mail Transport Protocol

Email messages account for a huge amount of the traffic on the internet. The Simple Mail Transport Protocol, or SMTP, became an RFC early in the history of the internet, and it has been updated many times since.

Email uses an ancient protocol called telnet to perform mail exchanges. Telnet has a history of bugginess, and alternatives now abound, but it is still used for email. The good news is that the protocol allows a method for switching to SSL/TLS encryption, which subsequently encrypts mail transfer and the maintenance traffic that envelops an email exchange.

During an exchange over SMTP, one server contacts another at an encrypted destination port. With no response, it attempts an exchange at an unencrypted port. The problem is that certain hosts, often at shared hosting environments, don’t automatically switch to TLS, forcing an unencrypted packet-readable exchange of mail. Often, the sender and receiver don’t even realize that an email was completely readable by anyone in the middle of the circuit pathway, from the mail sender’s outgoing server to the server of the recipient. If sent by a browser, meaning an online mail system, the circuit between the browser and a server is usually encrypted with SSL/TLS via an HTTPS: connection. It’s the link between mail servers where the message could be revealed because the recipient server forces the sending server not to send via SSL/TLS. Such a switch from one protocol to another is pretty simple to do.

Some server systems also now require that specific DNS records be in place where the outgoing domain name is registered (on the domain’s referent DNS server), so that an answer-back DNS lookup will validate the sender--to prevent spam. This process is almost impossible to implement for many ISP/MSP/hosting companies because of their shared resources architecture.