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 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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg