Subject: [Rucus] Charter proposal

From: "Jan Seedorf" <[email-masked]>
Date: Tue, 10 Jun 2008 14:54:20 +0200

Dear all,

A short while ago I sent an e-mail on this list, proposing a direction and scope for RUCUS to work on as an EG. I received some feedback on this list and some off-list. Since I did not receive any negative comments (convincing me that this is the wrong direction), I tried to write these ideas up in a charter proposal for RUCUS. Below you can find a suggestion for a charter, describing what I think should be the scope of RUCUSEG, the work to be done, and the corresponding achievable goals within the scope of an EG.

Obviously, this is open for discussion. Any input/comment on this is appreciated.

Btw: We plan to organise a one-day workshop in Heidelberg (right after IPTComm 2008) in order to discuss potential IETF work in the area of Unsolicited Communications and to make progress on a charter for RUCUSEG agreed on by the community. I believe Saverio is going to post details regarding this workshop on this list soon.

Kind regards,
Jan

Charter Proposal for RUCUS:
---------------------------------------
With massive deployment of SIP infrastructures it is foreseeable that an increased amount of unsolicited communication will impose a potentially severe threat for real-time applications. Efforts on how to reduce such a threat have received a lot of attention in the IETF and have been recognized as an important item to be investigated by SIPPING. Preliminary
investigations resulted already in the publication of RFC 5039.

Unfortunately, so far, further discussions on the issue did not find a big consensus on the approach to be followed. On the other hand first products and solutions are now being developed and there is a big interest from different institutions to allow interoperability. This interest is reflected by many individual draft submissions, indicating an active community working in the area.

For effectively mitigating unsolicited communications, an exchange of information between different entities of a SIP infrastructure ("communication glue") is required. Which information is relevant, where in the network it is generated, and with which entities it needs to be exchanged depends on the organization of the network and of communication between users (e.g., closed, semi-open, or open groups). Examples of such "communication glue" are: configuring and communicating authorization policies, querying oracles (trust brokers), or conveying downstream metrics to use trust among peers. Such communication would allow for automated decisions with respect to unsolicited communication, so that proper actions on a SIP message can be taken (e.g., "forward to mailbox"). As a result, such "communication glue" would enable distributed communication and allow mechanisms from different vendors to work together while mechanisms for mitigation can evolve and follow the threat evolution.

It is not clear yet what precise properties are necessary to enable the exchange of information collected at different locations in a network (by different entities). A key challenge which has been identified for standardizing such communication is that attacks and mitigation mechanisms are likely to evolve. This implies that a rather generic and flexible standard for information exchange is required, because a fixed standards tied to known potential attacks only may soon be outdated.

Thus, in the spirit of an Exploratory Group, RUCUSEG will explore the problem space and confine requirements for such flexible exchange of information among different entities of a SIP infrastructure. To lay out the path for a potential WG,
RUCUSEG will derive the properties for mechanisms to communicate in a distributed setting, separating concrete mechanisms from communication protocols. As a main result, RUCUSEG will identify what communication protocol properties are necessary to achieve flexible exchange of information in a way that it is independent of concrete mechanisms and allows for evolving
mechanisms.

In order to keep the work achievable within the context of an EG, RUCUSEG will select a few (e.g., 3) prototypical classes of mechanisms as key ones and then work on confining how these could fit in an overall architecture and what kind
of communication between entities would be necessary for these classes of mechanisms in a distributed setting. The main
goal of RUCUSEG is to summarize these considerations in a document and to derive achievable goals for a potential WG which can then start work in order to standardize communication for reducing unsolicited communications.

-- Goals/Milestones (6-12 months after work starts)
  -- WG charter for a follow-up WG (with consensus on the mailing list)
  -- document on recommendations and achievable goals for a WG

============================================================
Jan Seedorf
Research Scientist
NEC Europe Ltd., NEC Laboratories Europe, Network Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-221
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] 
============================================================
NEC Europe Limited Registered Office: NEC House,
1 Victoria Road, London W3 6BL Registered in England 2832014 
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Jun 2008 12:40:51 -0700

My recollection of the BOF (without going and checking the notes so it  
may be wrong) is that there was reasonable consensus on a specific set  
of work items in an EG that involved the following:

     Taking some small set (~3) of techniques from existing drafts,
     remove the implementation details and focus on the basic approach,
     turn them into a few pages and discuss the pros and cons and
     applicability assumptions. From this form a plausible picture of
     one way that might help mitigate unwanted communications.

This charter seems to be for a rather more specific set of work items,  
namely mechanisms for exchange of spit-related information between  
various parts of the SIP infrastructure. It's quite possible that  
that's an important part of the solution space, but I didn't hear any  
consensus in the room that people wanted to focus solely on that.

I'd love to see an EG formed around SPAM, but I do think that that  
group needs to be chartered more along the lines of the consensus  
reached in Philadelphia. I'd encourage you to go back and revise the  
draft charter so it's more consistent with that.

Cullen <with my AD hat on>

On Jun 10, 2008, at 5:54 AM, Jan Seedorf wrote:

> Dear all,
>
> A short while ago I sent an e-mail on this list, proposing a  
> direction and scope for RUCUS to work on as an EG. I received some  
> feedback on this list and some off-list. Since I did not receive any  
> negative comments (convincing me that this is the wrong direction),  
> I tried to write these ideas up in a charter proposal for RUCUS.  
> Below you can find a suggestion for a charter, describing what I  
> think should be the scope of RUCUSEG, the work to be done, and the  
> corresponding achievable goals within the scope of an EG.
>
> Btw: We plan to organise a one-day workshop in Heidelberg (right  
> after IPTComm 2008) in order to discuss potential IETF work in the  
> area of Unsolicited Communications and to make progress on a charter  
> for RUCUSEG agreed on by the community. I believe Saverio is going  
> to post details regarding this workshop on this list soon.
>
> Kind regards,
> Jan
>
> With massive deployment of SIP infrastructures it is foreseeable  
> that an increased amount of unsolicited communication will impose a  
> potentially severe threat for real-time applications. Efforts on how  
> to reduce such a threat have received a lot of attention in the IETF  
> and have been recognized as an important item to be investigated by  
> SIPPING. Preliminary
> Unfortunately, so far, further discussions on the issue did not find  
> a big consensus on the approach to be followed. On the other hand  
> first products and solutions are now being developed and there is a  
> big interest from different institutions to allow interoperability.  
> This interest is reflected by many individual draft submissions,  
> indicating an active community working in the area.
>
> For effectively mitigating unsolicited communications, an exchange  
> of information between different entities of a SIP infrastructure  
> ("communication glue") is required. Which information is relevant,  
> where in the network it is generated, and with which entities it  
> needs to be exchanged depends on the organization of the network and  
> of communication between users (e.g., closed, semi-open, or open  
> groups). Examples of such "communication glue" are: configuring and  
> communicating authorization policies, querying oracles (trust  
> brokers), or conveying downstream metrics to use trust among peers.  
> Such communication would allow for automated decisions with respect  
> to unsolicited communication, so that proper actions on a SIP  
> message can be taken (e.g., "forward to mailbox"). As a result, such  
> "communication glue" would enable distributed communication and  
> allow mechanisms from different vendors to work together while  
> mechanisms for mitigation can evolve and follow the threat evolutio
> n.
>
> It is not clear yet what precise properties are necessary to enable  
> the exchange of information collected at different locations in a  
> network (by different entities). A key challenge which has been  
> identified for standardizing such communication is that attacks and  
> mitigation mechanisms are likely to evolve. This implies that a  
> rather generic and flexible standard for information exchange is  
> required, because a fixed standards tied to known potential attacks  
> only may soon be outdated.
>
> Thus, in the spirit of an Exploratory Group, RUCUSEG will explore  
> the problem space and confine requirements for such flexible  
> exchange of information among different entities of a SIP  
> infrastructure. To lay out the path for a potential WG,
> RUCUSEG will derive the properties for mechanisms to communicate in  
> a distributed setting, separating concrete mechanisms from  
> communication protocols. As a main result, RUCUSEG will identify  
> what communication protocol properties are necessary to achieve  
> flexible exchange of information in a way that it is independent of  
> concrete mechanisms and allows for evolving
> mechanisms.
>
> In order to keep the work achievable within the context of an EG,  
> RUCUSEG will select a few (e.g., 3) prototypical classes of  
> mechanisms as key ones and then work on confining how these could  
> fit in an overall architecture and what kind
> of communication between entities would be necessary for these  
> classes of mechanisms in a distributed setting. The main
> goal of RUCUSEG is to summarize these considerations in a document  
> and to derive achievable goals for a potential WG which can then  
> start work in order to standardize communication for reducing  
> unsolicited communications.
>

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 25 Jun 2008 09:10:24 +0200

Hi Cullen,

Thanks for the feedback!

>      Taking some small set (~3) of techniques from existing drafts,

Maybe we have to be more clear about what a "technique" is.
I think the charter proposal covers techniques from several existing
drafts including
  a) configuring and communicating authorization policies
  b) querying oracles (trust brokers)
  c) conveying downstream metrics to use trust among peers
By chance or intention these explicitly mentioned items are exactly three.

> various parts of the SIP infrastructure.

I do not see in what respect the charter proposal is specific.
I would understand if you told us it would be too general, because
it includes all work that has been contributed in drafts so far.

An essential property of all three items a)-c) is that they require
communication between entities of the SIP infrastructure,
be it for exchanging very general authorization policies or for
exchanging very specific information on a single call.
I consider it quite natural, that the charter proposal reflects this.

>                                           It's quite possible that

Again, I do not see any part of the solution space that is excluded.
Can you give an example of a part of the solution space that is
actually excluded. This would be extremely helpful.

Thank you,

    Juergen

---

From: "Saverio Niccolini" <[email-masked]>
Date: Wed, 25 Jun 2008 18:21:15 +0200

Dear Cullen,

if you look carefully in the charter text (without always thinking
that we want to push only spam score) you will see that this charter
proposal is nothing more than:
-- a mix of Henning's presentation on architectural issues
merged with the 3 mechanisms proposal of Jonathan

I do not see any hidden thing nor pushing of something that has
no consensus.

We all agree that work currently established in SIPPING should have
precedence and policy framework is (one of) the best candidates 
--> maybe this needs to be added as Mary pointed out

I personally see no problems with the charter, if you still see
them can you please detail them more?
If we do not know what is your exact objection, we will have hard
time to meet requirements for forming the EG...

Looking forward to your answer,
Saverio

============================================================
Dr. Saverio Niccolini
Manager, Real-Time Communications Group
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Juergen Quittek
> Sent: Wednesday, June 25, 2008 9:10 AM
> To: Cullen Jennings; [email-masked]
> Cc: Jan Seedorf
> Subject: Re: [Rucus] Charter proposal
> 
> Hi Cullen,
> 
> Thanks for the feedback!
> 
> >> Obviously, this is open for discussion. Any input/comment 
> on this is
> >> appreciated.
> >>