At 03:31 PM 7/8/2003 -0400, Barry Shein wrote:
On July 8, 2003 at 06:00 paul(_dot_)judge(_at_)ciphertrust(_dot_)com (Paul
Judge) wrote:
....
> believe that the unauthorized use of resources (for sending messages
as well
> as those of the recipients) are grounds for that statement. Additionally,
> the potential disruption in availability is another reason for such a
view.
>
> While one path is to focus on the 'security' of the hijacked computers, I
> think that we have learned over the years that they will continue to find
> new means of injecting their messages into the system (relays, dialups,
> hijacked machines, proxies, webforms, free mail services, etc.).
I think if MS insists on continuing to produce such trivially hijacked
OS's and no general means is installed to counter-act that problem
(e.g., monitoring for virus-like behavior with automatic slowdown or
shutoff, or fixing the OS) then yes the problem is hopeless.
But thus far I can't even get much recognition (particularly outside
of a few people on this list) that this sort of thing, the hijacking
and amplification, is the real problem, and it's not analogous to
sticking up a "No Solictors, Please" sign but rather more like the
creep with the loudspeaker or someone breaking into cable or satellite
signals.
........
This problem is listed in the inventory document as follows:
Exploitation of weak systems
- exploit open smtp relay
- exploit insecure web services (cgi formmail)
- exploit open proxies (HTTP CONNECT, HTTP)
The underlying problems with spam both with SMTP, and with hijacked
computers, stem from the fact that the network trusts its users. This
"trust" assumption is inherent throughout the Net and its protocols. That
allows hijacked computers to spew spam and worms with impunity until a
human administrator is notified and shuts down or blocks the machine. This
"trust" issue is not going to go away, and its not something that can be
taken out of the Net overnight. The way we look at the solutions is what
matters. The charter looks at possible solutions from the point of
"consent" - addressing the issue from the "edges" of the network by giving
the "edges" some control over incoming email. Barry and Eric Brunner are
addressing the issue at the "core" of the network. Once again the
"Technical Considerations" document
(http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt)
is relevant here:
"A key construct to examination of adoption and benefit is
"core-vs-edge". Generally, adoption at the edge of a system is easier and
quicker than adoption in the core. If a mechanism affects the core
(infrastructure) then it usually must be adopted by most or all of
the infrastructure before it provides meaningful utility. In something
the scale of the Internet, it can take decades to reach that level
of adoption, if it ever does."
If the problem is in fact looked at as a matter of security cause by
inherent trust of the network users by the network itself, then this issue
should be addressed together with general security issues such as worms and
viruses. A hijacked computer spewing spam is not different from one causing
DDOS attacks, or one spreading worms. This is something that must be
addressed on the infrastructure level of the Internet itself. The most that
"edge" users can do is to use various tracking systems as a SOURCE TRACKING
COMPONENT of the consent model feeding data into a consent system.
The overall security problem is something that is a general Internet issue,
not specific to spam. Therefore, we need to find out if any of the existing
IETF WGs and IRTF RGs are looking into this issue and provide coordination
with them on this topic. However, we cannot address solutions for this
network-wide security issue since our work area is limited to spam. However
what we can do is:
1. Mention the security problem in documentation.
2. Coordinate with other WGs and RGs on the topic.
3. Pass along any security proposals to other WGs and RGs where they can be
evaluated as well.
This is something the IRTF chair can advise on. However, I do not see our
group can address the security problems of spam without looking at the
wider issue Internet security.
Additionally, I think that perhaps properly stating what the spam problem
is and what it is caused by, would greatly help. For starters perhaps this
issue should reformulated as a general security issue not specific to spam.
Also, we need the inventory document to be updated with the newest
contributions from the group and perhaps a volunteer to edit it.
Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg