Subject: [Sipping] WGLC review of draft-ietf-sipping-spam-03

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 03 Jan 2007 15:18:17 -0600

Draft: draft-ietf-sipping-spam-03
Reviewer:  Vijay K. Gurbani <[email-masked]>
Review Date: Jan 3, 2007
Review Deadline:  Dec 31, 2006
Status: WGLC

Review Summary:
This draft is on the right track but has open issues, described in
the review.

Draft Summary: This is an excellent survey on spam in general, and
SIP-related spam in particular.  It ties in nicely the various
extensions to SIP (consent, identity, presence, etc.) to solve a
particular problem, namely preventing SIP spam.  In my opinion, the
sooner it gets to RFC status, the better it would be for the SIP
user community.

Issues needing discussion listed below, followed by some nits.

Issues needing discussion:

* S2.1, paragraph "This number (9 deliveries ... will be more
   effective."  I am not sure how you are characterizing the first
   sentence in that paragraph.  Certainly, a SMTP server (probably the
   closest equivalent to a SIP proxy) would be able to, and probably
   already does deliver 9 or more messages a second.  For some existing
   analysis on SMTP server performance, see [1,2], which describes
   systems that can handle anywhere from 52 to 5000 messages/second.

   If however, the 9 deliveries per second refers to the MUA (closest to
   a SIP UA), then I would agree that it is hard to pin down how many
   messages per second an individual receives.  For instance, sending a
   message to an enterprise reflector usually always elicits "On
   vacation" responses, and many times such responses are in numbers
   greater than 9 messages arriving per second.

* S2.2, s/which only allow spam to be/which only allow IM to be
   I think you meant that the *IM* will be delivered only if the sender
   is on a white list, not that the *spam* will be delivered only if the
   sender is on a white list.

* In S3.1, the third paragraph is redundant; it restates what the
   first sentence of the second paragraph alread said.  I would suggest
   taking it out completely, and modifying the first sentence of the
   second paragraph as follows:

   OLD:
   Unfortunately, this type of spam filtering is almost completely
   useless for call spam.

   NEW:
   Unfortunately, this type of spam filtering, while successful for email
   spam, is completely useless for call spam.

* In S3.1, to be complete, you should also add a blurb on whether or not
   content filtering helps for presence spam (since you mention that it
   does not help for call spam and may help for IM spam.)
   I would suggest the addition of the following paragraph at the end
   of the section:

     Content filtering will not help for presence spam because by
     definition, a request subscribing for the presence of a user will
     be devoid of any content.

* In S3.2, you may want to change [email-masked] and spammer.com.
   domain.com is registered to someone in Vancouver, WA, and
   spammer.com is a registered to someone in Houston, TX.
   Suggest using [email-masked] for [email-masked]
   and spam.example.com for spammer.com.

   spammers.com also appears in S5.

* In S3.3, it is worth discussing that in addition to Turing tests,
   the "introduction problem" can also be solved by tagged addresses,
   of which the Tagged Message Delivery Agent (TDMA,
   http://tmda.net/index.html) is a good example.  Using tagged
   addresses, you can limit an email address by temporal interval
   (i.e., valid only for 5 days) or sender-specific addresses.  I
   do think they are worth discussing (for email, they work well;
   they have limited utility in call spam, but could be used for
   IM spam and presence spam.)  I will leave it upto you to determine
   whether a new sub-section should be added in Section 3 to discuss
   tagged addresses, or you can discuss them as part of S3.7 "Limited
   Use Addresses".

* In S3.4, first complete paragraph on page 11: it is stated in the
   last sentence that "Fortunately, traditional content-based filtering
   can be applied to this type of information."  I presume the phrase
   "this type of information" refers to the SIP address
   "sip:[email-masked]".  If
   so, then this is not content, but a header; more specifically,
   a From header.  Would white- or black-lists not be a better match
   then content-based filtering in this case?

* In S3.5, I don't think I agree with your assertion that "Reputation
   systems have not enjoyed much success outside of the instant messaging
   space." (third paragraph in that section.)  Certainly, in the business
   space occupied by eBay and Amazon, reputation is very intrinsic and
   an important contributor to the smooth functioning of the enterprise.
   Since eBay and Amazon have authority over their namespace, they can
   warn other users of identity mining (eBay, for instance, displays a
   special icon if you have recently changed your identity.)  Likewise,
   anyone who has bought a used book or CD through Amazon first scans
   the reputation of the seller before pressing the "1-click" button.

   My suggestion would be to begin the third paragraph using text
   suggested below:

   OLD:
   Reputation systems have not enjoyed much success outside of the
   instant messaging space.  This is in part because few other
   communications systems admit of the same degree of centralization and
   monolithic control.

   NEW:
   Reputation systems have been successful in communication systems
   where centralization of resources (user identities, authentication,
   etc.) and monolithic control dominate.

* S3.8, page 15, it is stated at the top of the page that "Automata
   cannot easily perform the image recognition needed to extract the
   word or number sequence, but a human user usually can."  Note that
   there exist programs (called CAPTCHAs) that can acheive with 93%
   correct recognition rate of visual puzzles (see
   http://www.captcha.net, and [3]).

* S3.8, of the two problems with the voice Turing tests mentioned
   towards the end of the section, the first one appears to *not* be
   a problem.  Yes, voice Turing test would need to be language
   specific, but as you note, SIP already has provisions to help here.
   Even if it did not, the experience is no different than what happens
   now when A calls B, and is instead redirected to B's voicemail
   which prompts him to enter "1" for A, "2" for A's wife and so on.
   If A is in the US, and B is in Lisbon, the instructions are rendered
   in Portugese.  A swears a bit, and hangs up, vowing to call B
   at a later time.

   The second problem -- cheap labor -- is indeed a problem.

* In S3.9, there is no mention of Cullen's hashcash draft?  Is that
   effort dead?

* In S3.9, one disadvantage of Payments At Risk scheme is the
   discrepancy of currency value between the sender and recipient.
   If the sender is in a third world country (albeit being financed by a
   spamming corporation in a first world country) and the receiver is
   in a first world country, then the sender really does not care about
   not getting his money refunded.  The benefactor funding the
   sender is able to use the currency valuation of his host country
   to conduct spam.  The sender deposits the payment in his local
   currency, the exchange value of which is much lower when compared to
   that of his benefactor's country.

* Isn't S3.13 similar to VoIP peering?  If domains establish a
   peering relationship, then they could optionally add spamming fines
   to the service level agreement.  In fact, the Circle of Trust
   idea of S3.12 is a simpler case of what is described in S3.13.
   Suggestion: remove S3.12, or subsume it in S3.13.

* The last statement of S3.13 is a strongly worded opinion of the
   authors.  While in and of itself, this is perfectly okay, I feel
   that standards documents ought to be a bit more impartial (okay,
   beat me here if you want.)  Instead, I would suggest that the last
   two sentences of S3.13 be reworded as follows to convey the authors
   distate in an objective manner:

   OLD:
   However, it puts back into SIP much of the complexity and monopolistic
   structures that SIP promised to eliminate.  As such, it is a solution
   that the authors find distasteful and contrary to the SIP design
   and architecture.

   NEW:
   However, centralized architectures as these are deliberately eschewed
   because they put back into SIP much of the complexity and mono-
   polistic structures that the protocol promises to eliminate.

* In S6, I would suggest that the three core recommendations be given
   labels; something like:

     1.  Enforce SIP Identity
     ...

     2.  Leverage White Lists
     ...

     3.  Provide a Solution for the Introduction Problem
     ...

   Implicitly, the last paragraph contains the fourth recommendation:

     4.  Do Not Ignore Spam
     ...

* There is no IANA Consideration section (I realize that this is an
   Informational track RFC, so an IANA Consideration section may not
   be required.  I do not remember if the IESG requires such a
   section in all drafts, even Informationals.)

References
[1] Wyman Miles, "A High-Availability High-Performance E-Mail Cluster,"
  Proceedings of the 30th annual ACM SIGUCCS conference on User services,
  pp. 84-88, November 20-23, 2002.
[2] Yasushi Saito, Brian N. Bershad, and Henry M. Levy, "Manageability,
  availability, and performance in porcupine: a highly scalable, cluster-
  based mail service," ACM Transactions on Computer Systems (TOCS), pp.
  298-332, 18(3), August 2000.
[3] Luis von Ahn, Manuel Blum, and John Langford, "Telling Humans and
  Computers Apart Automatically," Communications of the ACM, pp. 57-60,
  47(2), February 2004.

Nits
* S2.1, page 6,
   s/addresses, in that, in concert/addresses, such that in concert/

* S3.4, page 11,
   s/but to make the permission is extremely limited/but to ensure
   that the permission is extremely limited

* S3.5, first paragraph, second sentence:
   s/and they attempt/and A attempts to/

* S3.5, first paragraph, third sentence:
   s/from A, a reputation score/from A, and along with the consent, a
   reputation score/

* S3.5, regarding "reputation mafias" in the fourth paragraph, I am
   curious: is there any published reference?  It seems that such a
   mafia would neccessarily be a large, distributed, self-organizing
   system that shares a common goal, although the victims change over
   time.

* S3.8, last paragraph:
   s/turing tests/Turing tests

* In S3.9, I am not sure what the last sentence of the section
   is supposed to convey.  Any research is subject to patent and IP
   constraints, I suppose; SIP spam is no exception.  Best to simply take
   that sentence out.

* S3.10, first paragraph:
   s/A sends to user B/A sends email to user B/

* S3.10, third paragraph:
   s/for small transactions, for transaction as small as one cent./
   for small transactions, as small as one cent.

* S3.11, second sentence of second parargraph: I am not sure I
   can parse what it says.  Maybe you would consider, instead,
   to simply say:

       Whether they are, or are not effective remains to be seen.

* S 3.11, last sentence of the section: suggest rewrite as follows:

   OLD:
   For example, Habeas <http://www.habeas.com> inserts material in the
   header that, if a spammer inserted it without an appropriate license,
   allegedly causes the spammer to be violating US copyright and
   trademark laws, possibly reciprocal laws, and similar laws in many
   countries.

   NEW:
   For example, Habeas <http://www.habeas.com> inserts material in the
   header that, if it was inserted by a spammer without an appropriate
   license, would allegedly causes the spammer to violate US copyright
   and trademark laws, possibly reciprocal laws, and similar laws in
   many countries.

* S4.1, expand MTA and MUA on their first use.

* Reference 24, the terminating comma should appear before Third
   Annual Workshop...

Thank you.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dale Worley <[email-masked]>
Date: Tue, 9 Jan 2007 11:37:31 -0500

I was reading this draft and noticed the following nit:

Section 3.8, page 15:

   In the case of voice, there are problems with the Turing test
   described above.  First, it is language specific.  The application
   could be made to run in different languages, if the caller indicates
   their supported languages.  This is possible in SIP, using the
   Accept-Language header field, but this is not widely used at the
   moment.

As far as I can tell, the Accept-Language header applies only to
"reason phrases" and the like in the SIP message, and not to the audio
content of the session.  See RFC 3261, section 20.3:

   20.3 Accept-Language

   The Accept-Language header field is used in requests to indicate the
   preferred languages for reason phrases, session descriptions, or
   status responses carried as message bodies in the response.  If no
   Accept-Language header field is present, the server SHOULD assume all
   languages are acceptable to the client.

Dale

---

From: Dale Worley <[email-masked]>
Date: Tue, 9 Jan 2007 11:51:43 -0500

From: "Vijay K. Gurbani" <[email-masked]>

This isn't exactly true -- if the recipient demands USD 1.00 as a
payment at risk, the currency at the location of the sender is not
important.  But the economic disparities between countries are
important, since (nominal) income levels vary between countries by a
factor of 100, and a sender in a poor country may not be willing to
risk the payment for a recipient in a rich country, even if the
message is legitimate.

This is mitigated by the fact that introductions are relatively
uncommon, and people at greatly different income levels tend to be in
different social circles.  For business purposes, a payment of even
USD 1.00 is not such a problem, as even businesses in poor countries
have ways of mobilizing money.

But perhaps I am exaggerating the problem -- cell phone use seems to
cost around USD 0.05 per minute around the world, and even in the
poorest countries, people can pay that much for calls they consider
important.  And a payment of 50,000 microcents per spam is 250 times
the facilities cost of 215 microcents per spam.

Dale

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 09 Jan 2007 17:00:10 -0600

Dale Worley wrote:
> important.  

In the Payments at Risk scheme, the recipient does not get to
demand the payment he or she will accept.  That attribute is
left to the sender of the request.  Thus, if the sender of the
request is in a low-cost country, then the value would be
chosen accordingly.

> different social circles.  

That will depend; a software engineer practicing in a low-cost
country and one practicing in a high-cost country could be
considered to be in the same social circle, albeit different
income level.

Interestingly enough, in the Payments at Risk scheme, the
refunding portion is optional; so you may have an unscrupulous
receiver that accepts non-spam emails and never refunds the
money ;-)  Of course, for email spam, it would have to be made
mandatory.

Ciao.

- vijay

---

From: [email-masked]
Date: Wed, 10 Jan 2007 14:03:20 -0500

Although isn't the use of Payments at Risk ultimately enforced by the
recipient's UA verifying that the payment is high enough (or that the
sender is whitelisted)?  So the recipient has final say whether the
payment is adequate.

Good point.  (Though the reports I hear are that the nominal pay rates
of software engineers in different countries are converging more than
one would expect due to vigorous outsourcing.)

   money ;-)

Though I suppose that the sender could then blacklist the recipient.
But it's a risk that has to be considered.

Could this be used to generate "inverse spam", where someone posts an
attractive public solicitation.  Thousands of people send introductory
e-mail, enclosing their Payment at Risk of (say) USD 0.05.  Then the
recipient just keeps the money.

Dale

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 10 Jan 2007 13:58:16 -0600

> sender is whitelisted)?  So the recipient has final say whether the

There is a difference: yes, the recipient has a final say whether
the payment is adequate, but he (or she) does not have a final
say in *determining* the amount of that payment (at least, that is
how I interpret this scheme when I read the paper.)

> recipient just keeps the money.

Oh, neat.  I like this inverse spam idea.

Thanks,

- vijay

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 11 Jan 2007 15:07:31 -0800

> Oh, neat.  I like this inverse spam idea.

Such an 'attractive solicitation' could appear to be an important 
message from your employer, your bank, your employer's healthcare 
billing company, etc., but it would actually belong to someone 
in a far-away country.  Like today's spam, rotating through 
identities (to thwart reputation systems and black lists)
and a "small" 0.01% take rate can be sufficient to make a 
profit.

It seems the escrowing company would need to detect such 
activity and police it or prevent it -- it's in their business
interest to do so, or else nobody will trust them.  

Similarly, the users have an interest in not falling for such
phishing emails -- they'll get charged money (costs them money)
or have to contest the charge (costs them time).

-d