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
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
