Subject: 1. Inventory of Problems (was RE: [Asrg] 2. - Spam Characterization - Possible Measurements)

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 09 Jul 2003 01:32:45 -0400

At 03:31 PM 7/8/2003 -0400, Barry Shein wrote:

>On July 8, 2003 at 06:00 [email-masked] (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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg