Lately, I've been getting a ton of unwanted calls on my cell phone. I'm fooled into answering these calls because the caller-ID looks like someone in my local area. I very quickly realize I have been tricked – and the caller has faked the caller id. I did some research and it appears the FCC and several state governments are trying to regulate or legislate a stop to this. When you can't trust the originator of a communication, there is no trust.
Recently, a major denial of service attack was initiated by exploiting the 17,000 memcached servers that are on the public internet that support UDP messages. These servers permit an initial cache request to store data, then an ability to recall the same data later. These are designed to make applications run much faster. An attacker can cache data for a commercial website by using one of the websites public addresses. Then the attacker can pretend to be the website, and request the data be sent. The attacker can amplify a denial of service request 51,000 times using this technique overwhelming any service. Attackers are now seeking a ransom from sites wishing not to be attacked this way.
In both cases, the technology exists to insert authentication tokens that can be verified or checked PRIOR to processing a call or web-session. Application developers have been using single sign-on tokens, or session cookies to accomplish much the same thing, a capability we can only dream about at the mobile phone or at the IP network layer.
With software-based networking functions becoming all the rage, it's easy to assume that our network layers may soon be able to provide innovative enhancements that are borrowed from the application layers. One of these enhancements should be the authentication of a source of a communication request. Accomplishing this on a packet-by-packet basis may not be practical, but clearly for TCP and UDP, authenticating each session once would be a great improvement. For the authentication to be trusted, it must be performed by a different entity than the actual sender. This means the carriers or enterprises should vouch for the authenticity of a call or data flow. This authentication would provide an audit trail as well, indicating who used what address when.
In an ideal world, everybody would use their real network address. Unfortunately, there are many address translations at networking boundaries. This suggests that authentication may actually need to be tied to not just an originating address, but to one or more translated addresses. This would suggest that routers at the edges of networks, or routers performing NAT translations should re-authenticate the original source and the translated source on a hop-by-hop basis.
The computer science question to ask is could this work? Can modern software-based IP routers perform line rate processing and insert/replace authentication tokens at the start of each session? Off the shelf CPU's with crypto assist can perform hundreds of thousands of authentication signatures a second, and GPU's can achieve orders of magnitude more. It is quite reasonable to assume then that authenticated first packet routing is technically feasible. There are several challenges though to overcome.
(a) Router Key Management. Each router would need to have a cryptographic key exchange with neighboring or peering routers. This means that a secure mechanism for distributing cryptographic keys would need to be developed, and added to existing routing protocols. Many SD-WAN vendors are distributing keys today in proprietary fashion, so it is reasonable to assume with a standardization, that this is possible.
(b) Detection of a first packet. Each router would need to be more than flow aware with a last-in/first out limited flow table. Each router would need server-like memory to hold a much larger table of sessions. Each router would also need to be able to determine through deep packet inspection when TCP or UDP sessions were starting so that authentication tokens could be added, verified, and replaced as needed. Modern firewalls do this at line rate, so one must assume it is possible.
(c) Routers would need to know that the next-hop router supported authentication. This would also need to be added to routing protocols through a standardization effort. Overlay networks operate on this assumption, so this must also be practical.
These required capabilities are easily achieved at required performance levels with software.
Hardware-centric networking is not easily modifiable and can't be easily replaced. Software-based networking can usher in a massive wave of innovation by augmenting hardware with new capabilities where needed. One of these new capabilities might be session-based authentication for some or all of your applications.
Imagine a world where specific services have network asserted authentication for a source and destination address. We would eliminate and contain most if not all of the volumetric attacks that cloak themselves in false source addresses. This capability would enhance our security in so many ways, providing an audit trail of a session through NAT boundaries, IPv4 and IPv6 boundaries. The network would not understand user identity, but it would understand that the network addresses in use are correct and auditable.
