From rucus-bounces@ietf.org Tue Jun 10 05:57:10 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E683A69E9; Tue, 10 Jun 2008 05:57:10 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10343A6A88 for ; Tue, 10 Jun 2008 05:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0z1Z+2AayBG for ; Tue, 10 Jun 2008 05:57:08 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 51A8E3A6B2C for ; Tue, 10 Jun 2008 05:57:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 277472C00035C for ; Tue, 10 Jun 2008 14:57:27 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmEtHo-DjrOw for ; Tue, 10 Jun 2008 14:57:27 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 0148E2C000359 for ; Tue, 10 Jun 2008 14:57:21 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 14:54:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Charter proposal Thread-Index: AcjK+RmdEypWDZdcR3W65zeaV7SHgw== From: "Jan Seedorf" To: Subject: [Rucus] Charter proposal X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org 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: jan.seedorf@nw.neclab.eu ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Jun 11 06:05:22 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8132D3A6950; Wed, 11 Jun 2008 06:05:22 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F63F3A6936 for ; Wed, 11 Jun 2008 06:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gksQ4+iBuxhd for ; Wed, 11 Jun 2008 06:05:20 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1135D3A68FD for ; Wed, 11 Jun 2008 06:05:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 109612C00035C for ; Wed, 11 Jun 2008 15:05:42 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ067S-WBWjt for ; Wed, 11 Jun 2008 15:05:41 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id E41BB2C00035B for ; Wed, 11 Jun 2008 15:05:36 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 11 Jun 2008 15:04:55 +0200 Message-ID: <547F018265F92642B577B986577D671C0DB64F@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RUCUS workshop in Heidelberg on July 3rd Thread-Index: AcjLpDTCZJgwQTEMQcC4g7G4rFrRdw== From: "Saverio Niccolini" To: Subject: [Rucus] RUCUS workshop in Heidelberg on July 3rd X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear all, in order to better discuss the RUCUSEG charter and move forward in a convincing way to get RUCUS approved as EG, we wanted to offer our location (http://www.nw.neclab.eu/HotelTransportationInfo.pdf) for a RUCUS workshop in Heidelberg on July 3rd. The day is chosen because on July 1st and 2nd there will be a conference (http://www.iptcomm.org/) that I am organizing together with Henning and other researchers and this is a good occasion to get together while some of us are there anyway. For those of you not being able to come to Heidelberg we can also arrange an additional phone bridge. If you are interested please send me an email: subject: RUCUS workshop Body: Heidelberg or phone (depending how you prefer to attend) thus I can handle registrations and organize a decent phone bridge. Let me know your comments, 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: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Jun 12 00:58:05 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C09F3A69A2; Thu, 12 Jun 2008 00:58:05 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA633A6843 for ; Thu, 12 Jun 2008 00:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpFZTEfybau4 for ; Thu, 12 Jun 2008 00:58:03 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 9BF803A69A2 for ; Thu, 12 Jun 2008 00:58:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 27A542C00035D for ; Thu, 12 Jun 2008 09:58:31 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iExmo9p-1Hci for ; Thu, 12 Jun 2008 09:58:31 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id EE9A42C00035B for ; Thu, 12 Jun 2008 09:58:25 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jun 2008 09:58:22 +0200 Message-ID: <547F018265F92642B577B986577D671C0DB738@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] RUCUS workshop in Heidelberg on July 3rd Thread-Index: AcjLpDTCZJgwQTEMQcC4g7G4rFrRdwAvaaFA References: <547F018265F92642B577B986577D671C0DB64F@VENUS.office> From: "Saverio Niccolini" To: Subject: Re: [Rucus] RUCUS workshop in Heidelberg on July 3rd X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear all, I got the tip that in order to stimulate U.S. participation we might consider holding this meeting BEFORE IPTCOMM (i.e., on the 30th of June), as July 4th is a major U.S. holiday and a wrong timing of this meeting forces U.S. participants for the most part to have to travel on a holiday. Please let me know if this would help U.S. participation. Thanks, 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: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Saverio Niccolini > Sent: Wednesday, June 11, 2008 3:05 PM > To: rucus@ietf.org > Subject: [Rucus] RUCUS workshop in Heidelberg on July 3rd > > Dear all, > > in order to better discuss the RUCUSEG charter and move > forward in a convincing way to get RUCUS approved as EG, we > wanted to offer our location > (http://www.nw.neclab.eu/HotelTransportationInfo.pdf) > for a RUCUS workshop in Heidelberg on July 3rd. > > The day is chosen because on July 1st and 2nd there will be a > conference (http://www.iptcomm.org/) that I am organizing > together with Henning and other researchers and this is a > good occasion to get together while some of us are there anyway. > > For those of you not being able to come to Heidelberg we can > also arrange an additional phone bridge. > > If you are interested please send me an email: > > subject: RUCUS workshop > Body: Heidelberg or phone (depending how you prefer to attend) > > thus I can handle registrations and organize a decent phone bridge. > > Let me know your comments, > 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: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Jun 19 06:42:09 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC1A3A6A3D; Thu, 19 Jun 2008 06:42:09 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314883A6A8D for ; Thu, 19 Jun 2008 06:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrCsXq3XIQAr for ; Thu, 19 Jun 2008 06:42:05 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C83AF3A6AAA for ; Thu, 19 Jun 2008 06:41:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 39AE32C000350; Thu, 19 Jun 2008 15:42:18 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTWBQSxIKBSi; Thu, 19 Jun 2008 15:42:18 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 1B7C72C000305; Thu, 19 Jun 2008 15:42:08 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 15:42:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback on charter proposal Thread-Index: AcjSEkP93gcMAwPTQXWGjIRYNZaXNQ== From: "Jan Seedorf" To: Subject: [Rucus] Feedback on charter proposal X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dear all, I posted an updated charter proposal for RUCUS on this list, taking into account many discussions on this list and on the topic of unsolicited communications in the IETF from the past. The idea was to find consensus on how to move forward and to discuss this on this list. After all, the BoF in Philadelphia showed considerable interest in an EG. So far, I have not seen any feedback on this list, which lets me think there are two possibilities: A) People have nothing to complain about the charter proposal and think it goes in the right direction B) Folks are thinking the proposal is so bad that it is not worth answering to or they do not care about RUCUS anymore Of course, there is also option C) that people are realy busy with other things, which is understandable. My experience on IETF mailing lists is that if people do not like something they reply immediately saying so :) This makes me think that people tend to option A). If so, it would still be helpful if they could state so on this list so that this is visible and that the people responsible in the IETF for granting an EG could see that there is (still) interest in the community on forming an EG on the topic and agreement on achievable goals. Let me know what you think, Kind regards, Jan ============================================================ 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: jan.seedorf@nw.neclab.eu ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Jun 23 03:55:39 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D5D3A6912; Mon, 23 Jun 2008 03:55:39 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781FF3A6912 for ; Mon, 23 Jun 2008 03:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZgRTMy3gcuU for ; Mon, 23 Jun 2008 03:55:37 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D7E783A68F4 for ; Mon, 23 Jun 2008 03:55:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4CC382C000352 for ; Mon, 23 Jun 2008 12:55:33 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3kdv73B3+U7 for ; Mon, 23 Jun 2008 12:55:33 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 21ADE2C000303 for ; Mon, 23 Jun 2008 12:55:28 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 12:54:21 +0200 Message-ID: <547F018265F92642B577B986577D671C121060@VENUS.office> In-Reply-To: <547F018265F92642B577B986577D671C0DB738@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] RUCUS workshop in Heidelberg on July 3rd thread-index: AcjLpDTCZJgwQTEMQcC4g7G4rFrRdwAvaaFAAi9dn6A= References: <547F018265F92642B577B986577D671C0DB64F@VENUS.office> <547F018265F92642B577B986577D671C0DB738@VENUS.office> From: "Saverio Niccolini" To: Subject: Re: [Rucus] RUCUS workshop in Heidelberg on July 3rd X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi, it looks like that this workshop will not happen because there was a lack of feedback if this is interesting or not. Best regards, Saverio Niccolini ============================================================ 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: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Saverio Niccolini > Sent: Thursday, June 12, 2008 9:58 AM > To: rucus@ietf.org > Subject: Re: [Rucus] RUCUS workshop in Heidelberg on July 3rd > > Dear all, > > I got the tip that in order to stimulate U.S. participation > we might consider holding this meeting BEFORE IPTCOMM (i.e., > on the 30th of June), as July 4th is a major U.S. holiday and > a wrong timing of this meeting forces U.S. participants for > the most part to have to travel on a holiday. > > Please let me know if this would help U.S. participation. > > Thanks, > 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: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > > > > -----Original Message----- > > From: rucus-bounces@ietf.org > [mailto:rucus-bounces@ietf.org] On Behalf > > Of Saverio Niccolini > > Sent: Wednesday, June 11, 2008 3:05 PM > > To: rucus@ietf.org > > Subject: [Rucus] RUCUS workshop in Heidelberg on July 3rd > > > > Dear all, > > > > in order to better discuss the RUCUSEG charter and move > forward in a > > convincing way to get RUCUS approved as EG, we wanted to offer our > > location > > (http://www.nw.neclab.eu/HotelTransportationInfo.pdf) > > for a RUCUS workshop in Heidelberg on July 3rd. > > > > The day is chosen because on July 1st and 2nd there will be a > > conference (http://www.iptcomm.org/) that I am organizing together > > with Henning and other researchers and this is a good > occasion to get > > together while some of us are there anyway. > > > > For those of you not being able to come to Heidelberg we can also > > arrange an additional phone bridge. > > > > If you are interested please send me an email: > > > > subject: RUCUS workshop > > Body: Heidelberg or phone (depending how you prefer to attend) > > > > thus I can handle registrations and organize a decent phone bridge. > > > > Let me know your comments, > > 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: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > > ============================================================ > > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, > > London W3 6BL Registered in England 2832014 > > > > > > _______________________________________________ > > Rucus mailing list > > Rucus@ietf.org > > https://www.ietf.org/mailman/listinfo/rucus > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Jun 24 12:40:05 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71B93A6844; Tue, 24 Jun 2008 12:40:05 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F183A681F for ; Tue, 24 Jun 2008 12:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghQ8DfWDEAhf for ; Tue, 24 Jun 2008 12:40:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0CE743A68FB for ; Tue, 24 Jun 2008 12:40:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,698,1204531200"; d="scan'208";a="117828572" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Jun 2008 12:40:03 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5OJe3gF026259; Tue, 24 Jun 2008 12:40:03 -0700 Received: from [128.107.103.28] ([128.107.103.28]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5OJe3j5009177; Tue, 24 Jun 2008 19:40:03 GMT Message-Id: From: Cullen Jennings To: rucus@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 12:40:51 -0700 References: X-Mailer: Apple Mail (2.924) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6980; t=1214336403; x=1215200403; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Rucus]=20Charter=20proposal |Sender:=20; bh=DFfO8LTrJExGjUK/6x5Vw5qWBR0UXiiYBlpAznE4s1M=; b=kybBy7HxTxw1/LCDyvLOMW6XlmprTwAZYJDsgMv8shdJYyPDsVfdOQ88eQ Xi5NG2me/HgQEjD8Xqs2s1RCI3l6QenEoaLWHYaBZ9pX59of1gWubqdnb8aW fydvhWEfGl; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Jan Seedorf Subject: Re: [Rucus] Charter proposal X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org 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 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. > > 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 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. > > -- 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: jan.seedorf@nw.neclab.eu > ============================================================ > NEC Europe Limited Registered Office: NEC House, > 1 Victoria Road, London W3 6BL Registered in England 2832014 > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Jun 25 00:10:39 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4E783A67F9; Wed, 25 Jun 2008 00:10:39 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590EE3A67F9 for ; Wed, 25 Jun 2008 00:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJZevpTB4PIS for ; Wed, 25 Jun 2008 00:10:37 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 1870A3A67AB for ; Wed, 25 Jun 2008 00:10:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1131B2C0004E3; Wed, 25 Jun 2008 09:10:35 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEFUwlrmHxEO; Wed, 25 Jun 2008 09:10:34 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id D4F102C00035C; Wed, 25 Jun 2008 09:10:24 +0200 (CEST) Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Jun 2008 07:10:24 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 25 Jun 2008 09:10:24 +0200 From: Juergen Quittek To: Cullen Jennings , Message-ID: Thread-Topic: [Rucus] Charter proposal Thread-Index: AcjWkol4fRTNO4OEbUCvBTPozOwN1Q== In-Reply-To: Mime-version: 1.0 Cc: Jan Seedorf Subject: Re: [Rucus] Charter proposal X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Cullen, Thanks for the feedback! On 24.06.08 21:40 "Cullen Jennings" wrote: > 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, 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. > 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. 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 > 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. 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 > 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 > > > 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. >> >> 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 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. >> >> -- 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: jan.seedorf@nw.neclab.eu >> ============================================================ >> NEC Europe Limited Registered Office: NEC House, >> 1 Victoria Road, London W3 6BL Registered in England 2832014 >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Jun 25 09:21:18 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12ABF3A69E6; Wed, 25 Jun 2008 09:21:18 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B33C3A69E6 for ; Wed, 25 Jun 2008 09:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT3vGMO9AQDE for ; Wed, 25 Jun 2008 09:21:15 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 14A103A6882 for ; Wed, 25 Jun 2008 09:21:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EC2ED2C000359 for ; Wed, 25 Jun 2008 18:21:16 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+ZbakHf5bwv for ; Wed, 25 Jun 2008 18:21:16 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id C0ADB2C000351 for ; Wed, 25 Jun 2008 18:21:11 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 18:21:15 +0200 Message-ID: <547F018265F92642B577B986577D671C12137A@VENUS.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Charter proposal thread-index: AcjWkol4fRTNO4OEbUCvBTPozOwN1QAS3SwQ References: From: "Saverio Niccolini" To: Subject: Re: [Rucus] Charter proposal X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org 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: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Juergen Quittek > Sent: Wednesday, June 25, 2008 9:10 AM > To: Cullen Jennings; rucus@ietf.org > Cc: Jan Seedorf > Subject: Re: [Rucus] Charter proposal > > Hi Cullen, > > Thanks for the feedback! > > On 24.06.08 21:40 "Cullen Jennings" wrote: > > > 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, > > 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. > > > 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. > > 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 > > 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. > > 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 > > > > 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 > > > > > > 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. > >> > >> 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 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. > >> > >> -- 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: jan.seedorf@nw.neclab.eu > >> ============================================================ > >> NEC Europe Limited Registered Office: NEC House, > >> 1 Victoria Road, London W3 6BL Registered in England 2832014 > >> _______________________________________________ > >> Rucus mailing list > >> Rucus@ietf.org > >> https://www.ietf.org/mailman/listinfo/rucus > > > > _______________________________________________ > > Rucus mailing list > > Rucus@ietf.org > > https://www.ietf.org/mailman/listinfo/rucus > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus