Define categories of anti-abuse patterns

[bslassey]

At a very broad level, I believe there are two forms of abuse against a single system that an IP privacy solution must consider. The first is a small set of attackers pretending to be many to prevent their abuse from being detected and blocked, which is generally the case when it comes to Denial of Service attacks (which is why distributed Denial of Service is a useful attack pattern).

The second category is when an attacker is attempting to impersonate a victim. This is the case with credential theft in general and can be protected against with technologies such as WebAuthn and techniques such as 2FA.

Being specific about the types of abuse will help us determine the types of preventative measures that may be appropriate.

I will note that these two categories are intentionally scoped to a single system. There is a third broad category where independant systems can use IP addresses as identifiers to warn others of threats. rfc5782 is one example of a standardized system to share such threat intelligence. This would also include tying an IP address to a real world identity.

And of course if there are other broad categories I'm missing, we should identify and define them.

[chris-wood]

@bslassey is it also worth highlighting that the target of abuse may be different across scenarios? In the DoS case, the target is the service, whereas in the impersonation scenario, the target is (likely) an individual.

[bslassey]

Impersonation could also be attacking a service if for example the goal of the attacker is to steal the credentials of an admin. Are you thinking of a specific way that defining the goal of the attacker could be useful?

[chris-wood]

Impersonation could also be attacking a service if for example the goal of the attacker is to steal the credentials of an admin.

True -- this one does cut both ways.

Are you thinking of a specific way that defining the goal of the attacker could be useful?

Nothing specific beyond trying to highlight that alternate solutions to these problems might be distinct, even though they currently rely on the same mechanism (IP address). For example, one might just say "2FA everywhere!" (or whatever) as "the solution" to the impersonation case, whereas a solution to the DoS case might be totally different. 🤷‍♂️

[bslassey]

I certainly agree that the solutions for DoS will most likely be different from the solutions for account take over, which is effectively what I'm driving at here.

[sysrqb]

In #11 we enumerated some common abuse patterns where IP addresses are used to find some signal in the noise. That only partially addressed the goal of this issue (as I understand it). #16 addressing the remainder, insofar as it applies specific "replacement signals" in an effort to discover abuse patterns when client IP addresses are not available.

One risk of this approach, where we evaluate each category of abuse in isolation, is that we potentially miss the forest through the trees. As an example (based on the current PR), if a server wants to detect and mitigate against both influence campaigns and financial fraud, then they may require a set of signals like: IS_HUMAN, REPUTATION, REIDENTIFICATION, SOURCE_ASN, and IDENTITY_TRANSPARENCY. Depending on some factors, this set of information could be at least as identifying as ADDRESS_ESCROW except without the escrow, but it may not as obvious from the client's perspective. We need to be careful about the effect of combining signals.

For this issue, I believe we can close it when #16 is merged, but let me know if you think we're not addressing some aspect of this.

[bslassey]

For this issue, I believe we can close it when #16 is merged, but let me know if you think we're not addressing some aspect of this. agreed