"Chris Lewis" <clewis(_at_)nortelnetworks(_dot_)com> wrote:
One glaring difference in behaviour is volume. But the net isn't
currently set up to even be *aware* of volume.
That leads to an interesting question: can we extend the lower layers of
the Internet protocols (eg: at TCP/IP) to allow someone to specify and
enforce rate limiting in such a way as to seriously affect spam?
Current QoS methods may address this issue. Do you really consent
to accepting more SMTP traffic than your MTA's can handle?
Unfortunately, I think not. Consider striker - that's a broad-source
attack. Any one of the IPs spamming striker has less volume than some
of our legitimate senders. Anyone disagree?
No, but that's not quite on-point. I didn't consent to having 100
TCP SYN's per second sent to my MTA. Even those syn's wouldn't be
much of a problem if I could inform my upstream provider that I do not
consent to that traffic. But I can't.
Look at it as a problem of the network not being aware of consent.
If there was a mechanism available for consent to flow back in the
network, that would result in back-pressure on the originator. Near
the recipient, consent is easy to administer, because most people
consent to most traffic. As we get closer in the network to the
sender, consent becomes more difficult to administer, because the
entire net is informing the sender of their non-consent.
There's no problem with "who created the consent", either. Someone
3 hops away from me doesn't know, or care, that I didn't consent to
some traffic. But I have a consent relationship with my upstream hop,
to not send me traffic. He can accept it from his upstream provider
and then not send it to me, or he can tell his upstream provider that
he doesn't consent to that traffic. Either way, I don't care. I
don't get the traffic.
But notice the consent model: When my upstream provider tells his
provider he doesn't consent to the traffic, it's NOT my consent any
more. It's his. So there's no problem with tracking consent across
multiple hops. Each hop already has a mutual business, technical,
and trust relationship which can be leveraged to administer consent.
The end result is that if someone sends you traffic you indicated
non-consent for, it's incentive to stop talking to them at all.
If a site hosts someone who gets non-consent from the everyone on
net, then they may decide that administering that consent is more
expensive than the money they get from that client. If they *don't*
administer that consent, then everyone else cuts them off.
The Usenet Death Penalty has been proven to work. But it requires
administrator input, and isn't automated.
For people who say that administering consent (most likely
implemented in the form of massive ACL's) is difficult, remember that
this is a *research* group. Even with that, solutions exist today
which can do packet filtering at multi gigabit rates, with 10's of
1000's of ACL's. It's not trivial, but it shouldn't prevent us from
examining consent enforcement in the network.
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg