Hi Mark,
This is a problem that depends on how the web-/freemailers setup their
systems. As long as the traffic stays within the mail servers of that
company I think they could use some in-house tool to filter probably
abusive
users. As soon as they send it to others their reputation is on the line
and
they should act to defend it accordingly (by trying to prevent abusive
users
to sign up/block email/filter outbound/etc.).
True, but you're essentially saying ESPs will have to cleanup spam(mers)
later, expensively, that they could have prevented earlier if they had
had working IP filters/reputation. True, IP filters do little/nothing
that one couldnt do without them. But the issue here is being efficient
(or: being overrun if you are not). Also, outgoing spam-filtering is just
more error prone (worse filter training, user-feedback, lack of viable
consequences if unsure of classification).
If you ask me we should do it for multiple ranges. Let me explain it
below:
- 2 spam messages per [time] per /128 could be "acceptable", with more
block
that /128. For a good reputation a /128 should send at least XX messages
per
[time] without X being marked as spam.
- 10 spam messages per [time] per /64 could be "acceptable", with more
block
that /64. For a good reputation a /64 should send at least XX messages
per
[time] without X being marked as spam.
- 50 spam messages per [time] per /32 could be "acceptable", with more
block
that /32. For a good reputation a /32 should send at least XXX messages
per
[time] without XX being marked as spam.
2 problems:
* You dont want to punish whole groups for a few bad apples. If "group"
means another ESP (/32) this could hurt your bottom line outright.
* You dont want to give spammers freebies either. AFAIK, some ISPs even
give /48s to "end-customers". If your count onto /64 thats, according to
your example 10*2^16 freebies.
on 1): criteria for reasonable reputation entities
* the number of entities must be limited to something much smaller then
2^64
<- for computational cost
<- for meaning; in the end, "reputation" means judging the history
of
behavoir
of a real-world communication/inter-action partner
* corollary: creating entities must incur some type of cost
<- e.g. simply rotating your hosts /64 suffix is for free
<- e.g. money for registering a domain
<- e.g. effort for an attacker to take over a host
That is why I'd look for some reputation based on multiple ranges to look
for the best action to take. If you've an ISP that has paying clients
that
are hurting others with their bad reputation they are more likely to say
good bye to the clients that are hurting business. Or do you've a better
idea for this?
What I was trying to say (in a rather overly generic way) is, that
it doesnt make sense to count & give *bad* reputation to entities
that are (almost) infinitely available (/128s and even /64s).
Even if you could, computationally. Because attackers would simply
keep creating new entities.
on 1): a more concrete question
Can we manage to deduce (for traffic seen)
* the internal partitioning of ISP's (e.g) /32s into subnets
Difficult if the ISP isn't cooperating/updating data sources.
* classify each subnet into static vs. dynamic IP address assignment
Depends on the ISP and that makes it difficult to use I think.
* for static SNs, the end-customer prefix (length)
?
Difficult if the ISP isn't cooperating/updating data sources.
.."Difficult".. Exactely. ** But somewhat/somehow doable ? **
If we cant aggregate /128s /64s etc. onto prefixes that are
tied to meaningful, costly entites (hosts, customers, companies..),
then, I think, (bad) IP blacklisting is dead, independently of all
clever solutions to 2) and 3).
Regards,
--jan
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg