Essentially, the originating host would sign the packet with its own private key, then encrypt it with the destination host’s public key. (I think that’s how it goes in crypto: sign, then encrypt -- or is it the other way around?) Just before sending the packet, the originating host would obtain the destination host’s public key and cache it for future use. Like any asymmetric crypto solution, the packet would remain securely encrypted to prevent prying eyes along the way, and if the originator was spoofed, the packet would not verify correctly.
IPv6 gets us part of the way there, but we need more: Default authentication and default encryption, no exceptions. More robust key exchange protocols. Ubiquitous application. Absolute standards adherence. Network access control (a.k.a. network access protection) can play a role, too. You can’t join the network unless you agree to the IP stack operations.
We have similar pseudo-models all over the place for this type of thing, including PKI, S/MIME, DNSSEC, and some of the newer anti-spoofing protocols. We’re already overly familiar with the challenges. But every challenge I’ve ever read about was basically due to a lack of empathy and participation. DNSSEC and all the other newer crypto standards would work better if we all cared more, implemented them in a standard way, and required them.
I believe any decrease in performance due to the new network crypto mechanics would be more than made up by the decrease in spam and malware that is so pervasive today.
The next column on this topic will talk about application authentication in a secure ecosystem.