Reducing Unwanted Communications in SIP (RUCUS) BOF Hannes Tschofenig Francois Audet

Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: -the IETF plenary session, -any IETF working group or portion thereof, -the IESG or any member thereof on behalf of the IESG, -the IAB or any member thereof on behalf of the IAB, -any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, -the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3978 (updated by RFC 4748) and RFC 3979(updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3978 (and RFC 4748) for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

Agenda Introduction and Agenda Bashing (Chairs) RFC 5111 Overview: "Experiment in Exploratory Group Formation within the IETF“ (Bernard Aboba) Unwanted Communication (David Schwartz) RFC 5039 Overview: "The Session Initiation Protocol (SIP) and Spam“ (Jonathan Rosenberg) An Architectural Journey (Henning Schulzrinne) Lessons learned from the IETF Spam Work (Jim Fenton) Privacy and Regulatory Aspects (John Morris) Discussion

The Session Initiation Protocol (SIP) defines a system for user-to-user multimedia communications. Therefore, it is susceptible to unwanted communication attempts. RFC 5039 analyzes the problem of spam in SIP and examines various possible solutions that have been discussed for and considers their applicability to SIP. RFC 5039 gives good, high-level recommendations regarding future work, namely * Strong Identity * White Lists * Solve the Introduction Problem * Don't Wait Until It's Too Late Strong identities and white lists will be essential but do do not address all problems. Among the challenges are compromised hosts controlled by a botnet, even with access to credentials, are the major source of spam today and expected to remain the main source of SIP spam in the future. Among the many individual solution building blocks that are discussed in RFC 5039 (including content filtering, black lists, white lists, consent-based communication, reputation systems, address obfuscation, limited use addresses, turing tests, computational puzzles, payments at risk, circles of trust, and many others) there is no framework outlined how various mechanisms work together to produce a complete solution nor does the document attempt to offer a ranking to determine which solutions could form an initial set of candidate for subsequent standardization.

This exploratory group chartered for one year aims to create a venue where discussions on unwanted communication in SIP can take place. The main goal of the group is to produce an architecture document that sheds light on the interworking between a minimal set of building blocks. The architectural investigations should cover different threat models, including those of compromised end hosts. The group will consider prior work on SIP identity and related techniques and will consult with privacy experts to deal with the regulatory aspects of blocking communication attempts. Outside the scope of the group are investigations in the area of voice analysis and algorithms for statistical analysis. Milestones Mar IETF#71 Jul Formation of an exploratory working group Jan First WG draft on the architecture document Jun Submit architecture document to the IESG for consideration as informational RFC Jul Close group and decide on future work