My Master of Science degree in Computer and Information Science (MS-CIS) with the University of Michigan-Dearborn has culminated in a published master’s thesis and academic journal article.
While these hold a wealth of information, the underlying concept is actually quite simple.
Please note that, though my thesis discusses Neighbor Discovery Sessions, I will not be covering that topic here, because it’s not as relevant (and it’s very dry).
This article, by its title, will be an informal addendum to my research where I can discuss exactly what this is all about and why it’s important in plain terms. I will avoid discussing many of the concepts in depth and instead focus on maximizing the impact of the work. In this post, I’ll explain:
- why the problem is not already solved,
- what voucher-based addressing conceptually is,
- what it could mean for local network security,
- and how I plan to make it a reality.
Background: Spoofing
The first order of business: what is a spoof? “Spoofing” is defined by Merriam-Webster broadly as an act of “hoaxing” or “deceiving”. More relevant to network security (specifically IP networks), spoofing occurs when the receiver of information on a network is unaware that the communicating party on the other side is not truly who they say they are. It is actually true for local networks — ’local’ typically just meaning ‘in one physical place’ — that computers are very trusting of others.
Suppose for a minute that you called into a caterer to pick up an order on your sister’s behalf because you need to prepare for your mom’s birthday party. For this hypothetical situation, it’s important that the order is only delivered by the company to the given address after they verify “your” identity. Otherwise, anybody could call in for the order with no or minimal information like a name.
So, pretending to be your sister, you give the customer service representative her name, her phone number, and maybe some details about what the order contains. Once you clear that step, the company asks where you want the order delivered to. You send it to your own house instead of your sister’s because you’re throwing the party there.
You just spoofed your sister’s identity, and it was really easy because (1) you knew how to “be” her and (2) you knew exactly what you were “intercepting”.
Networks are susceptible to spoofing too: the tiny ones in your home, at your corporate office, and in the large majority of places you’ll ever visit and get connected. Believe it or not, any evil computer on the network can publicly or privately tell the others it’s you, and they will take its word for it. This relies on a set of unique identifiers that neighbors exchange to tell one another how to deliver their messages back and forth. If you’re interested in learning more about the technical details of spoofing, see this article.
So why’s this a problem? Well, to start, if any device in a local network can pretend to be you, then the others who wanted to actually contact you first will now instead talk to the spoofer. This means the evil device is intercepting all of your network messages and it can decide what you see, what you don’t, and which private information it wants to spy on. This is a lot of power.
Prior Work: Solving the Problem
In IPv6 networks, a “neighbor” — as the name implies — is another host connected to the same network as you. In these neighborhoods, your neighbors can’t be trusted and they’re not your friends; any of them could be out for your identity and you would be none the wiser. The early designs of the internet accepted trade-offs of security for performance and convenience. Nowadays, we have the capability and power to have all three, where we can build a utopia neighborhood preventing neighbor spoofing in the first place.
Of course, in IPv6 networks there already exist solutions to the spoofing problem. Secure Neighbor Discovery (SEND) and Cryptographically Generated Addresses (CGA) are one such [very complicated] combination of techologies designed to fight this problem, among others. But the technical details are long and boring, they’re beyond what I need to cover, and ain’t nobody got time for that.
Just know that SEND and CGA have failed to become the de facto answers to neighbor spoofing. There are proposed alternative solutions to these, but none have stood the test of time: there is close to ZERO adoption or awareness of these standards. The reason for the lack of adoption always comes down to missing one or more of three key aspects: privacy preservation, flexibility, and simplicity. The proposed solution must put the user’s privacy first; i.e., nothing about what it offers should compromise the anonymity of end users and enable any kind of tracking. It must also be flexible and adaptable enough to be feasible within several different network configurations and to work its way into what already exists. And lastly, it must be simple because (1) large changes are difficult to enact on a scale as big as the internet and (2) complexity is the nemesis of execution.
My work with Voucher-Based Addressing (VBA) has sought to integrate these three properties into one universally-applicable approach that can work in just about any modern IPv6 networking context.
What is it?
A Voucher-Based Address looks like any other IPv6 address you or a neighbor might have. If I were to provide you a list of neighbor addresses and have you tell me which one has VBA enabled, you wouldn’t be able to. What matters about an individual VBA is how it’s created and what verifiers do with it based on their receiving settings. With VBA, neighbors can generate and verify addresses at will: generation means a new IPv6 address is created and verification means a neighbor’s given IPv6 address is confirmed for legitimacy. If an address does not verify during communication, the neighbor with the bad address will be blocked.
Previous solutions to stop spoofing relied on adding extra information to messaging between neighbors, but VBA takes advantage of the free space already available in neighbor addresses to convey the details it needs. Coupled with verification only occurring at key moments, this makes the proposal extremely adaptable across the majority of network configurations.
Neighbors on the network can freely choose to disable VBA entirely, only generate (and not verify) them, strictly generate and verify them with no mercy, or show a little mercy for non-compliant neighbors. These are the Address Awareness Disabled (AAD), Address Generation Only (AGO), Address Generation & Verification (AGV), and AGV with Levels (AGVL) operating modes, respectively. These are important to keep in mind, since neighbors can select their own to operate in at any time.
Explaining by Analogy
An analogy is much better at expressing the underlying mechanism of VBA. You don’t need to know all of the technical specifics to realize it works if you can overlay the principle onto an everyday system.
Personally Identifying Information
Consider your Social Security Number (or whatever national identifier you use if you’re outside the United States): it uniquely identifies you and only you during the course of your lifetime. When you die, it’s retired — though in the future when the USA runs out of new ones, numbers may begin to recycle. The same is mostly true of your Driver’s License ID in that it’s used to uniquely identify you. The most important aspect is that while you’re alive, the number is yours and cannot be changed.
Your home address is not only a piece of identifying information, but it’s where you receive a lot of official and important communications from the outside world. For example, if you weren’t receiving mail, you might miss direct communications like a jury duty summons or a bill. In many US states, you can use an online form to change your address according to the records of the state. You can also set up mail forwarding rules with the US Postal Service.
Crazy Neighbors
Now ask yourself: what if your neighbor went through the state or the US Postal Service and updated your information to use their own address? For the sake of the example, disregard what happens when you need to enter your license’s address into state forms or what happens when you get a new card (with the new address on it!). This change means the neighbor would now receive all of your mail before you, and you might never know they were snooping on your mail if they opened each message, read through it, repackaged it into a new envelope, and deposited it into your mailbox by the next day. This also means the neighbor can throw out certain messages they don’t want you to get. Slimy!
The Clever Post Office
This is weird, but imagine your home address — the number portion, not the street — was mathematically derived from a combination of the SSN, date of birth, or license ID of each individual that lives there, mixed with the name of the street and the post office “jurisdiction” code (basically, a unique code representing the post office that serves your home).
Resident SSNs:
127-80-9023 123-00-9879 334-09-8080
^ ^ ^
| | |
`[my SSN] `[my son's] `[my spouse's]
Street Name: "BOURBON AVE"
Post Office Code (x): WEIHFWE2342309
ALGORITHM:
{{ [SSN] + [x] + [StreetName] }} (for each input SSN)
\________|________/
\_______|_______/ <-- Some mathematical
\______|______/ function making
\_____|_____/ unique numbers out
\____|____/ of these inputs...
|
/ | \
/ | \
651239 48982 1894633
| | |
651239 X 48982 X 1894633 ==> 60436876653857834
The home number is always assigned the last 5 numbers, so...
THE ADDRESS IS: 57834 BOURBON AVE.
In the figure above, the resulting house number is only a portion (the last 5 characters) of the final calculation result. Because the beginning of the number is discarded, the resulting public house number in the address cannot be reversed to reveal your identifying information, or that of anyone else in the home. This method has successfully preserved your privacy!
For verification purposes, the post office — before giving anything to couriers for delivery — will look up the SSN of the recipient and make sure the resulting
SSN + x + StreetName
is a factor of the final number from the algorithm (which they maintain in their own database). If so, they deliver the mail. If not, something else is going on and it needs a closer look, or the message is held with a notification.
The key takeaway from this contrived scenario is that senders and receivers of messages do not need to change their messages in order to comply with this post office standard for mail authentication. The post office also has everything it needs on the envelope to verify that this is the correct and current address for the recipient. Everything is handled at the logistics layer and most recipients have no idea it’s even happening. The process for VBA is the same, unlike competing proposals which would require message modifications at the sending and receiving sides.
Irrelevant side notes: With this hypothetical, when someone is born or leaves the home, the address will change. The “math” here is really weak and is trying to make more of a what-if point than formulate a real algorithm. Also, in the real world, this would be a nightmare for couriers since none of the street addresses would follow any sort of logical pattern like they do now. To be fair, this could theoretically be offset by the advanced GPS capabilities we have in the modern world.
Bringing it Together
This exact analogy maps onto IPv6 communications between neighbors connected to the same physical network. By deriving an address from a neighbor’s current ID (SSN) and other public and shared information (the post office code), they can in no way falsify their information since their ID (SSN) is immutable and unchanging. This also means they can’t spoof your identity, because your IP address does not calculate or derive properly from their ID. On top of that, two neighbors cannot share the same ID at the same time, just like two houses cannot have the same address and expect reliable mail delivery.
This is the core of it all, that’s literally it. And any neighbor can be in an operating mode that either requires confirmations of address-to-ID correlations or doesn’t care about it.
Implications & Plans
It is truly and genuinely possible that VBA is the answer to the IPv6 neighbor spoofing problem that’s been around since IPv6’s conception around the start of the new millennium. It’s also possible that it’s not at all what the experts are interested in.
It’s a simple change, it’s flexible enough to slide into software implementations designed for the current paradigm, and it honors the end user’s right to privacy on the internet to the highest degree. It’s a novel approach with other security features built in and it’s based on solid principles for network security. But, like all other algorithm-dependent works, all it takes is one overlooked “silver bullet” weakness and the entire thing comes crashing down; thankfully, this hasn’t happened.
VBA hasn’t yet faced the blunt scrutiny of IPv6 experts within the IETF, which is absolutely what it needs. If there is enough buy-in after the completion and submission of one or more engaging Internet Drafts, then it’s possible that this work could achieve RFC candidacy, advancing it to a known and deployed standard that vendors will implement. This would of course be after much intense debate and revision of the original idea as proposed in my research at UM-Dearborn.
In my personal opinion: while it would be an absolute honor to contribute to RFCs, I’m not sure the IETF is interested in solving this decades-old problem any time soon. Anyway, the IETF is VBA’s last stop; beyond that, it’s left to researchers and field experts to use it or develop it as they see fit.
I hope this gave you some more insight into this work and that you possibly came away with a better understanding of a very niche internet security topic. As always, thank you for reading.