Define categories of anti-abuse patterns about draft-ip-address-privacy HOT 6 CLOSED

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.

from draft-ip-address-privacy.

@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.

from draft-ip-address-privacy.

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?

from draft-ip-address-privacy.

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. 🤷‍♂️

from draft-ip-address-privacy.

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.

from draft-ip-address-privacy.

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

from draft-ip-address-privacy.