Subject: [Rucus] Charter Proposal

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 30 Jul 2008 15:58:59 +0300

RUCUS-EG:
---------

The Session Initiation Protocol (SIP) is an application-layer control 
(signaling) protocol for creating, modifying, and terminating sessions 
with one or more participants. These sessions include Internet telephone 
calls, multimedia distribution, and multimedia conferences. Like other 
communication protocols, SIP 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 email and 
considers their applicability to SIP.

RFC 5039 gives good, high-level recommendations regarding future work, 
namely to provide
* Strong Identity
* White Lists
* Solve the Introduction Problem
* Don't Wait Until It's Too Late

Among the many individual 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. It also does not indicate a ranking of 
specific solution approaches in order to determine which onces form an 
initial candiate set for subsequent standardization.

This exploratory group is chartered for one year with the aim to create 
a venue where discussions on preventing unwanted communication in SIP 
can take place. The group will produce a framework document that sheds 
light on the interworking between various solution components. 
Architectural considerations are, for example, related to where 
information for decision making comes from, what information is required 
for the decision making process, where policy decision points / policy 
enforcement points are located, what privacy aspects need to be 
considered and how the underlying trust model looks like?
A second document will then list a minimal set of initial solution 
approaches (such as 3 solution classes) that should be selected for 
later standardization, whereby the work will be done later in a new or 
an existing working group. This document will describe what the 
characteristics this solution set provides. This document is entitled as 
"Applicability of Selected SPIT Mechanisms".

The group will consider prior work on SIP identity and related 
techniques and will consult with privacy experts to deal with the legal 
aspects of filtering communication attempts.

Goals and Milestones:

Aug 2008  Formation of an exploratory working group
Aug 2008  First WG draft on the framework document
Oct 2008  First WG draft on "Applicability of Selected SPIT Mechanisms" 
document
Dec 2008  Submit framework document to the IESG for consideration as 
informational RFC
Jan 2009  Submit "Applicability of Selected SPIT Mechanisms" document to 
the IESG for consideration as informational RFC
Jul 2009  Close group

_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: "Michael Liljenstam" <[email-masked]>
Date: Wed, 30 Jul 2008 18:58:00 +0200

Hi Hannes,

It would be nice to see this moving forward. To that end, my
recollections from the BOF comments include a desire to see (motivating)
"scenarios" described, which I think is implicit in your text. Might it
perhaps make sense to weave in something to also make this more
explicit? 
Taking a stab at very slightly modifying one of your paragraphs:

...
A second document will then list a minimal set of initial 
solution approaches (such as 3 solution classes) along with 
motivating scenarios that clarify what characteristics this 
solution set provides and what the expected limitations are. 
This set should be selected for later standardization, 
whereby the work will be done later in a new or an existing 
working group. This document is entitled "Applicability of 
Selected SPIT Mechanisms".
...

Makes sense?
Admittedly, this is only a minor nit. Just trying to preempt
objections...

Regards,
Michael Liljenstam

---
Michael Liljenstam
Senior Research Engineer, Communications Security, Ericsson Research
Phone: +46-8-404 4602, Email: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Hannes Tschofenig
> Sent: den 30 juli 2008 14:59
> To: rucus BoF
> Subject: [Rucus] Charter Proposal
> 
> RUCUS-EG:
> ---------
> 
> (signaling) protocol for creating, modifying, and terminating 
> sessions with one or more participants. These sessions 
> include Internet telephone calls, multimedia distribution, 
> and multimedia conferences. Like other communication 
> protocols, SIP 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 email and considers their applicability to SIP.
> 
> RFC 5039 gives good, high-level recommendations regarding 
> future work, namely to provide
> * Strong Identity
> * White Lists
> Among the many individual 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. It also does not indicate a ranking 
> of specific solution approaches in order to determine which 
> onces form an initial candiate set for subsequent standardization.
> 
> This exploratory group is chartered for one year with the aim 
> to create a venue where discussions on preventing unwanted 
> communication in SIP can take place. The group will produce a 
> framework document that sheds light on the interworking 
> between various solution components. 
> Architectural considerations are, for example, related to 
> where information for decision making comes from, what 
> information is required for the decision making process, 
> where policy decision points / policy enforcement points are 
> located, what privacy aspects need to be considered and how 
> the underlying trust model looks like?
> A second document will then list a minimal set of initial 
> solution approaches (such as 3 solution classes) that should 
> be selected for later standardization, whereby the work will 
> be done later in a new or an existing working group. This 
> document will describe what the characteristics this solution 
> set provides. This document is entitled as "Applicability of 
> Selected SPIT Mechanisms".
> 
> The group will consider prior work on SIP identity and 
> related techniques and will consult with privacy experts to 
> deal with the legal aspects of filtering communication attempts.
> 
> 
> Goals and Milestones:
> 
> Aug 2008  Formation of an exploratory working group Aug 2008  
> First WG draft on the framework document Oct 2008  First WG 
> draft on "Applicability of Selected SPIT Mechanisms" 
> document
> Dec 2008  Submit framework document to the IESG for 
> consideration as informational RFC Jan 2009  Submit 
> "Applicability of Selected SPIT Mechanisms" document to the 
> IESG for consideration as informational RFC Jul 2009  Close group
> 
> 
>

---

From: David Schwartz <[email-masked]>
Date: Wed, 30 Jul 2008 23:07:06 +0100

Hi Hannes.

The things I would add are:

* limit EG to 6 months (not a year) - should be enough for specified  
goals
* clear criteria for success so that upon success we roll right into WG
* Perhaps schedule and interim meeting to really move this along

D.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 Jul 2008 01:11:26 +0300

David,

Limiting the EG to 6 months puts more pressure on us to make decisions 
quickly. No need to delay things.
I believe that's a good idea.

I also like the two other suggestions.

Thanks for the feedback

Ciao
Hannes

---

From: "Charzinski, Joachim (NSN - DE/Muenich)" <[email-masked]>
Date: Thu, 31 Jul 2008 08:37:06 +0200

Hi Hannes and Michael,

shouldn't it read  
...
working group. This document is entitled "Applicability of 
Selected _Anti_-SPIT Mechanisms".
...
?

Best regards

	Joachim.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Michael Liljenstam
Sent: Wednesday, July 30, 2008 6:58 PM
To: Hannes Tschofenig
Cc: rucus BoF
Subject: Re: [Rucus] Charter Proposal

Hi Hannes,

...

Makes sense?

Regards,
Michael Liljenstam

---
Michael Liljenstam

----------------------------------------------------------
Joachim Charzinski
Principal Innovator

Nokia Siemens Networks
Research, Technology and Platforms / Innovations
 
St.-Martin-Str. 53
Post box: D-80240 Muenchen
D-81541 Muenchen
Germany
Tel: +49 89 636 79902

[email-masked] 
http://www.nokiasiemensnetworks.com/global/

Think before you print

Nokia Siemens Networks GmbH & Co. KG
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRA 88537
WEEE-Reg.-Nr.: DE 52984304

Persönlich haftende Gesellschafterin / General Partner: Nokia Siemens Networks Management GmbH
Geschäftsleitung / Board of Directors: Lydia Sommer, Olaf Horsthemke
Vorsitzender des Aufsichtsrats / Chairman of supervisory board: Lauri Kivinen
Sitz der Gesellschaft: München / Registered office: Munich
Registergericht: München / Commercial registry: Munich, HRB 163416
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 31 Jul 2008 09:22:54 +0200

Hi Joachim,

I don't think the charter needs to fix a title.
It should be sufficient to agree on the content.

And yes, of course the document should be about the
applicability of selected mechanisms for mitigating SPIT.

Thanks,

    Juergen