The Session Initiation Protocol (SIP) and Spam
draft-ietf-sipping-spam-05

[Ballot discuss]
This is a "please consider fixing" DISCUSS.  See my comments for things I
think are worth fixing or considering improving.  However, I'm willing to
clear this discuss if asked as publication of even this version of the
document would be better than excessive delay.

[Ballot comment]
This is an important document and I believe it would benefit the
community to have this published soon.

However, this document repeatly makes the mistake of being too
authoritative in an area which is more of a research problem space.  As
a result, it includes several statements that are factually incorrect or
execessively authoritative.  This weakens the document significantly. I
recommend one editing pass to try to at least fix the factual errors.


The first problem I noticed was this:

"  a plague on the Internet email system, rendering it nearly useless."

The phrase "rendering it nearly useless" is a factual error.  Spam has
done a great deal of damage to the Internet mail system -- made it
_much_ more expensive to run, it has made it annoying, it has swaped
solicited/desired traffic with unsolicited/undesired traffic, and it has
basically destroyed the robustness principle.  But it has not made email
"nearly useless".  Starting this document with a false statement greatly
weakens an otherwise interesting analysis.

Other factual errors:

  "These kinds of consent-based systems are used widely in presence and
  IM but not in email."

Factually incorrect -- most email mailing lists use consent-based systems, including IETF mailing lists.

  "This is likely due to the need for a secure
  authenticated identity mechanism, which is a pre-requisite for this
  kind of solution."

Email mailing lists provide a consent-based mechanism without a secure authenticated identity mechanism.  They leverage the fact that it is quite difficult to intercept mail destined for a specific address.

  "Email does not have this kind of secure
  domain identification, although new techniques are being investigated
  to add it using reverse DNS checks (see below)."

What about RFC 4871?

  "In email, there are no standards established for
  securely identifying the identity of the sending domain of a message."

RFC 4871 is such a standard.  Also SMTP STARTTLS could be used for inter-domain transfers (although deployment of the key infrastructure is likely impractical for this purpose at the moment).



I also think it's very easy to fall into pitfalls when talking about
spam absent an attack tree analysis of spamming.  An attack tree looks
at what kinds of spammers are out there and what their motivations are.
I would put 3 nodes under the root of the spam attack tree:
"pranksters", "commercial" and "organized international crime".  Under
"commercial", we have in-house and out-sourced UBE sub-nodes.  An
important sub-node of the organized international crime node is phising
(very profitable and thus largely immune to costs).  The anlaysis in
this document applies well to the in-house sub-node of the commercial
node.  The analysis starts to fall apart on some of the other nodes in
the attack tree.

Examples of text which is too authoritative:

"As a result, the problem of forged senders can be eliminated, making the
  white list solution feasible."

The problem may be largely addressed, but it's not eliminated as there are always attacks that work (as a last resort, social engineering or coersion of
the identity the attacker is forging).

  "Fortunately, it is possible to apply traditional content
  filtering systems to the header fields in the SIP messages, thus
  blocking these kinds of consent requests."

Content filtering only partially blocks such requests. 

  "Thus, if consent is required first, and nearly all users do not give consent
  to spammers, the value in sending spam is reduced"

This varies based on the node in the attack tree, while true for commercial
spam this is much less true for phishers.

  "One way to prevent spam is to make your address difficult or impossible to
  gather."

This is a way to _reduce_ spam, not prevent it.

  "This technique has the potential to truly make it prohibitively
  expensive to send spam of any sort."

It depends on how profitable the spam product happens to be.  In the case of phishing, I doubt this statement is true.

  "Since spam is a consequence of untrusted domains and users that get
  connected to the network,"

Spam can be a consequence of a _trusted_ user who manages their Windows machine poorly. ;-)

[Ballot comment]
Section 3.2 on Black Lists and section 3.3 on White lists should mention zombie spam.  Both blacklists and whitelists are problematic because spam can come from infected machines in domains, or from addresses, that we'd otherwise like to receive messages from.  Zombies are mentioned elsewhere in the document but they're particularly harmful to blacklist and whitelist solutions.  For that matter, reputation systems are quite undermined by zombies.  It might be useful to point out that existing botnets can be quickly adapted to SIP -- a set of existing compromised machines can easily be given new code to send SIP spam.

(Indeed, in section 3.9, the text reads as if whitelists are a solution to zombie networks which they're not, and botnets are also ignored in section 4.2.)

3.4: "Since most of today's IM systems are closed" -- I don't know what is meant by "closed"

[Ballot comment]
I've registered a no objection position.  However there are a lot of
statements in this draft that seem to ignore dkim.  As far as I can
tell dkim and sip identity are very similar solutions.

I'm not sure that the advice here will work, but it does seem like the
best advice I've read on the subject.  There is a lot of good stuff
here.

[Ballot comment]
Section 2.3 Presence Spam

Unlike sections 2.1 (Call Spam) and 2.2 (IM Spam), there are no cost
estimates.  Since cost is used to estimate the likelihood of spam in
the parallel subsections, it seems that cost should be addressed here
as well.

Section 3.8 Turing Tests

7th paragraph:  I believe the cost should be .50 cents per test and per
message, rather than 50 cents per test and message.

3.10 Payments at Risk

Third paragraph: If the sender is allowed, the provider takes .64 cents
rather than 64 cents.  The total cost to the sender for a legitimate
transaction should be 1.39 cents (.75 plus .64 cents).  For ten new
recipients per day, the cost would be $4.17 per month (assuming 30
days in the month).

The remaining comments are from the SecDir Review by Donald Eastlake:

This draft is a reasonably thorough review of potential "spam" problems
with SIP and a survey of possible solutions including anti-spam
recommendations.

The Security Considerations section says merely

  This memo is entirely devoted to issues relating to secure usage of
  SIP services on the Internet.

I'm fine with a very short Security Considerations section for this
document, given its survey nature, but I don't think "secure usage" is
really accurate. Maybe

  This memo is entirely devoted to issues related to the amelioration
  of spam in SIP and references a variety of security mechanisms in
  support of that goal.

Also, at the end of section 3.4, in the paragraph split between pages 11
and 12, the possibility of automatically granting permission for a
limited length IM for the purpose of examining the content of that IM
and discarding it without bothering the user if it is judged to be spam,
and maybe then blocking that sender for a while, appears not to be
considered.

++++++++++++++++++

Editorial/trivia:

"UAC" is used exactly once in this document. Suggest spelling it out.

Several places "10s" -> "10 seconds".

Last line of page 12, suggest "grant" -> "give" as "grant" has a
connotation to me of giving something that is positive or favorable.

Section 3.8, page 15, "processing an artificial" -> "processing and
artificial".

First line of the third paragraph in Section 3.8, delete the comma.

Spell out IVR, at least the first time it is used.

Section 3.8, third paragraph on page 16, "50 cents" -> "0.5 cents"
twice.

There are numerous occurrences of "TLS". I assume these are references
to Transport Layer Security but this is never spelled out nor is there
any RFC reference given for this.

Spell out PSTN, at least the first time it is used.

Section 5, first paragraph, second line, suggest deleting "identity of
a".

Section 6, "White Lists" paragraph, 3rd line, suggest deleting "of the".

Thanks,
Donald

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Gonzalo Camarillo is the shepherd for this document. He believes this
document is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, this document has been adequately reviewed and the shepherd does
not have any concern at this point.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The shepherd does not have any concern.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

The shepherd does not have any concern.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The whole WG considers SPAM to be a very important problem. The draft
was formally reviewed by a few individuals within the WG.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No, nobody threatened an appeal or indicated discontent.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document only contains informative references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations Section looks OK.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The document does not use formal language.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

Spam, defined as the transmission of bulk unsolicited messages, has
plagued Internet email. Unfortunately, spam is not limited to email.
It can affect any system that enables user to user communications.
The Session Initiation Protocol (SIP) defines a system for user to
user multimedia communications. Therefore, it is susceptible to
spam, just as email is. In this document, we analyze the problem of
spam in SIP. We first identify the ways in which the problem is the
same and the ways in which it is different from email. We then
examine the various possible solutions that have been discussed for
email and consider their applicability to SIP.


Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

There was strong consensus behind this document.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

Vijay Gurbani performed a dedicated review on this draft.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director?


The document shepherd is Gonzalo Camarillo and the responsible area
director is Jon Peterson.