IP addresses are currently used as a source of “reputation” in conjunction with other signals to protect against malicious traffic. Servers use these reputations in determining whether or not a given packet, connection, or flow corresponds to malicious traffic. Tor exit nodes often have bad reputation because there exists some client sending bad traffic through the node. Absent any sort of signal beyond the IP address, all connections through the exit node are assigned the same reputation. Fundamentally, the current ecosystem operates by making the paths of a connection accountable for bad traffic, rather than the sources of the traffic itself. This is problematic because paths are shared by multiple clients and are impermanent. Ideally, clients could present proof of reputation that is separate from the IP address, and uniquely bound to a given connection.
- Reputation: A random variable with some distribution. A reputation can either be "bad" or "good" with some probability according to the distribution.
- Reputation signal: A representative of a reputation.
- Reputation proof: A non-interactive zero knowledge proof of a reputation signal.
- Reputation context: The context in which a given reputation applies.
- Identity: Any identifying information about an end-user or service, be it a client or server, including IP addresses.
- Clients MUST be able to request and present new reputation proofs on demand.
- A reputation signal MUST NOT be linkable to any identifying information for which the signal corresponds.
- Clients MUST be able to demonstrate good faith and improve reputation if needed.
- Clients MUST be able to dispute their reputation.
- Clients MUST be able to determine and verify the context in which a given reputation applies.
- Reputation signals MUST NOT remain valid indefinitely. (Clients must obtain new reputation signals periodically.)
- Reputation signals MUST be bound to a context, and MUST NOT be transferrable across contexts.
- Clients MUST NOT be able to transfer reputations.
Original material from Matthew Finkel on the PEARG mailing list.