RE: [Sipping] A Framework for Reducing Spam for Internet Telephony

"Saverio Niccolini" <Saverio.Niccolini@netlab.nec.de> Tue, 19 June 2007 11:48 UTC

Return-path: <sipping-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cBt-0005TV-2R; Tue, 19 Jun 2007 07:48:09 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1I0cBq-0005Jk-V4 for sipping-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 07:48:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cBq-0005I7-J0 for sipping@ietf.org; Tue, 19 Jun 2007 07:48:06 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0cBo-0008V3-Rt for sipping@ietf.org; Tue, 19 Jun 2007 07:48:06 -0400
Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 62659200017E; Tue, 19 Jun 2007 13:48:04 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ymq5+1tzXZb; Tue, 19 Jun 2007 13:48:04 +0200 (CEST)
Received: by smtp0.netlab.nec.de (Postfix, from userid 1001) id 42AF1200CAB5; Tue, 19 Jun 2007 13:48:04 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on atlas1.office
X-Spam-Level:
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7
Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2380B200017E; Tue, 19 Jun 2007 13:47:43 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sipping] A Framework for Reducing Spam for Internet Telephony
Date: Tue, 19 Jun 2007 13:48:30 +0200
Message-ID: <113091BD57179D4491C19DA7E10CD6960150E446@mx1.office>
In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A4075802149548@MCHP7IDA.ww002.siemens.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sipping] A Framework for Reducing Spam for Internet Telephony
Thread-Index: Aceud17o1pXFXurwTdud9T1omk2qbAAtVpbwAAldYpAAxJonAA==
References: <113091BD57179D4491C19DA7E10CD6960150DFF5@mx1.office> <0D22E3C1A7D7A843B12BF8C6F0A4075802149548@MCHP7IDA.ww002.siemens.net>
From: Saverio Niccolini <Saverio.Niccolini@netlab.nec.de>
To: "Tschofenig, Hannes" <hannes.tschofenig@nsn.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, SIPPING LIST <sipping@ietf.org>, Martin Stiemerling <Stiemerling@netlab.nec.de>
X-Sanitizer: This message has been sanitized!
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc
Cc: spitstop@listserv.netlab.nec.de
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org

Dear Hannes,

> > Actually I wanted to let you know that for some of the 
> interactions or 
> > authorization policies you describe in Figure
> > 1 there are already available drafts that propose solutions:
> > 
> http://tools.ietf.org/id/draft-niccolini-sipping-feedback-spit-03.txt
> > or describe scenarios for the interactions:
> > http://tools.ietf.org/id/draft-niccolini-sipping-spitstop-00.txt
> > 
> > It would be nice to have them referenced as well in the draft.
> 
> There are quite a number of solutions proposals floating around. 
> We tried to avoid too many references but some more would not 
> hurt. What do you think is particularly interesting to 
> mention in the context of the framework?

I just wanted to point out that the authorization policy (explicit)
you depicted in "Figure 1: Overview" of your framework draft is just	
an example of the interface communication ("c" or "f") we have been
already describing in the SPITSTOP draft "Figure 1: SPIT prevention
reference scenario" in January.

Other SIP message interaction in the figure are also just an example
of what was already described in the general scenario (interfaces
"a", "b" and "c" again).

In our draft we clearly described the general scenario, your famework
is an example how this scenario could be mapped to an architecture.
It would have been good to say that there is already work ongoing on
some parts of what you describe, this would support even more the idea
that we need standards for that and would indeed support the BOF itself,
it shows that we think the same way instead of just pushing single
ideas.

Moreover our other draft that discusses the feedback mechanism can be also
regarded to be a form of authorization policy (even if this is more 
suited to deny access to certain users), and this is also not reported in
your draft.

> One of the main ideas for writing the framework document was 
> to identify the minimum functionality you need to standardize 
> now. Other things can be done in the future -- potentially never.

I agree and I think what you did is quite good, I just want to be sure
that the prior drafts addressing topics you describe in your draft
are not ignored.

> > 
> > Moreover, our SPIT prevention framework (you can find 
> references of it 
> > in proceedings of Globecom 2006) uses already some of the 
> > authorization policies you are describing also in the other draft 
> > (http://fon.gs/spit-requirements), namely:
> > -- we have built white/black list based on identities (or 
> part of it), 
> > this matches Req-C 1 and Req-C 2
> > -- we block certain messages based on the spam-level marking, this 
> > supports Req-C 7
> > -- we mark the messages with a certain spam-level and 
> forward this to 
> > the caller, this supports Req-A 2
> > -- we use some kind of Turing Tests built in answering 
> machines, this 
> > supports Req-A 4
> > -- we also run anomaly detection methods able to mark the calls and 
> > make this available for other entities, this supports Req-T 1
> 
> So, it seems that you think that many of the requirements are 
> in fact reasonable. 
> 
> Have you spotted missing functionality or functionality you 
> wouldn't provide immediately (or not at all)?

The requirements are well done, a more complete review I am planning
to do will spot if there are some missing functionalities we need and
I will report them to you.

> > I think all in all these two drafts you recently wrote 
> complement well 
> > the SPITSTOP work we are currently discussing in the 
> SPITSTOP mailing 
> > list, it is just a pity that they are coming too late to 
> support the 
> > BOF request that was just rejected.
> 
> 
> We have been trying hard to get the documents finished but 
> that was the best we were able todo. 
> In fact, we wanted to write the document already a year ago 
> when I went out for dinner with Henning Schulzrinne, Jonathan 
> Rosenberg, Dan York and David Schwartz.
> 
> Btw, I was actually hoping that we don't really need a BOF to 
> get this work started. We don't schedule BOFs for every tiny 
> document we write. 

I do not share this view since a BOF would be needed to actually identify
what is the better way to move forward and I just think SIPPING does
not want to be bothered with this kind of discussions, we should first get
a common agreement through a BOF.

Anyway we all agreed that we need to get together in Chicago and 
have a chat about this. See you there.

Cheers,
Saverio

> 
> 
> > 
> > I hope we can sit together in Chicago at the BAR BOF and 
> discuss the 
> > way to move the all work on SPIT forward in the IETF.
> I hope so too. 
> 
> 
> Ciao
> Hannes
> 
> > Cheers,
> > Saverio
> > 
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Thursday, June 14, 2007 1:29 PM
> > > To: SIPPING LIST
> > > Subject: [Sipping] A Framework for Reducing Spam for
> > Internet Telephony
> > > 
> > > Hi all,
> > > 
> > > we have just submitted a new draft on "A Framework for
> > Reducing Spam for
> > > Internet Telephony".
> > > Please find the document here: http://fon.gs/spit-framework
> > > 
> > > This document attempts to scope the work on reducing Spam
> > for Internet
> > > Telephony.
> > > 
> > > Ciao
> > > Hannes
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use 
> > > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > > sip@ietf.org for new developments of core SIP
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > sip@ietf.org for new developments of core SIP
> > 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP 
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sip@ietf.org for new developments of core SIP
> 

============================================================
Dr. Saverio Niccolini
Senior Research Staff Member
Network Laboratories, NEC Europe Ltd.
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  saverio.niccolini@netlab.nec.de
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP