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

From: "C. Wegrzyn" <[email-masked]>
Date: Wed, 09 Jul 2003 08:26:23 -0400

Let me inject my point of view on the notion of trusted/secure networks. 
I would think we wouldn't want to depend on them at all. We should view 
the "core" with some scepticism at all times. If we take the other tack 
- assume a network that is secure/trusted all we are doing is opening 
our solution to vulnerabilities. Regardless of how hard we try we will 
never build a system without "warts". So plan for them and design around 
them.

Regards,
Chuck Wegrzyn

Yakov Shafranovich wrote:

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

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg