Subject: Re: [perpass] What problems does perpass need to solve?

From: "Dickson, Brian" <[email-masked]>
Date: Thu, 12 Sep 2013 22:10:26 +0000

Dave wrote:

 "privacy properties of IETF protocols and concrete ways in which
    those could be improved."

So my simple question is:

   What are the problems that need to be solved here?

I think one thing we should look at, is what place(s) in the protocol stack exist, and can be considered for incremental privacy modifications via protocol enhancements. Clearly, there are already some protocols that support security after some fashion, which also often provides privacy. Privacy is trivial in those cases, but only if they are used (and usable).

I think it would be good to look at active and passive independently. There will be methods which may be useful against one, which are not useful against the other.

I'll start with things specific to the "passive" case.

(BTW - Enumerating them seems like it would be useful to do, I.e. identify privacy weaknesses, privacy protection methods, and requirements/deficiencies of each.)

As an example, if we distinguish privacy from security, we can observe:

  *   If we can accomplish "privacy == anonymity" (by protecting the identities), the cost of doing so may be significantly lower.
  *   Observe, that in order to surveil a subject on a network, it is necessary (but maybe not sufficient) to identify source & destination address & port, plus enough protocol-specific information (e.g . sequence numbers for TCP) to decipher and de-multiplex the protocol stream from the aggregate traffic collected.
  *   Hide (e.g. encrypt, or otherwise render "hidden") those, and the traffic becomes a soup of clear-text without sufficient context to decipher.
  *   This is analogous to using a shredder shared with lots of co-tennants. The characters are visible, but the arrangement of them trashed, and finding bits that belong together is difficult at best. The larger the volume, the harder it becomes.
  *   This becomes scaling problem for the attacker. The easier it is to collect volumes of data, the harder it is to process.
  *   If the decode is deterministic, and if encode/decode operate at line rate, the economics shift drastically for the passive observer, at no incremental cost to the networks.

This leads to an immediate suggestion:
If we make possible hop-by-hop packet obfuscation, in such a way that adjacent routers (sender & receiver) mangle/unmangle the first N bytes of each L3 packet, so that a passive listener could not trivially discover the "keys" used, then privacy (where privacy == anonymity) against passive listeners can be achieved. If, for example the first 8 bytes are clear, but the next 56 bytes are mangled, IPv4 and IPv6 both gain privacy, against both IP and "next protocol" header data. The "IP Version" field could be overloaded for signaling use of clear/mangled, and possibly for additional purposes (two extra bits for signaling crypto behavior on-the-fly, for example). Some feasibility of doing this mangling/un-mangling at line rate on current hardware needs to be done, but my gut says that XOR on a subset of the first 64 bytes of each packet, with a periodically-updated small set of fixed values, should be possible to do (and be interoperable) on pretty much every major platform already deployed, without that much work. Operating at L3 means all upper layer protocols gain the same benefit, at no cost. L2 addresses should be sufficient for disambiguation (for de-mangling).

This only protects non-end-points, though, unless the end points have this capability added (e.g. via protocols the key exchange piggy-backs on, such as BGP, OSPF, or ISIS). However, this means any aggregation point beyond the first hop, represents a place where opportunistic privacy can be incrementally be deployed.

Obviously, this requires some kind of opt-in or negotiation, and key sharing/distribution/exchange, ideally with PFS using ephemeral keys. As Randy Bush pointed out, for EBGP neighbors, adding key exchange is pretty easy to do. For IGPs, this should also be easy to do. Across the Internet, each hop should be either over an IGP link or over an EBGP link, generally. (Outer packet only for tunneled links.) So, other than getting vendors to implement this and operators to configure it, it should be feasible to deploy ubiquitously, defeating all passive observers. QED.

Brian