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

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Jun 2007 13:29:14 +0200

Content-TransferFrom [email-masked] Thu Jun 14 07:29:20 2007
Date: Thu, 14 Jun 2007 13:29:06 +0200
From: Hannes Tschofenig <[email-masked]>
To: SIPPING LIST <[email-masked]>
Subject: [Sipping] Requirements for Authorization Policies to tackle Spam
 for Internet Telephony and Unwanted Traffic

Hi all,

we have just submitted a new draft on "Requirements for Authorization 
Policies to tackle Spam for Internet Telephony and Unwanted Traffic". 
Please find the document here: http://fon.gs/spit-requirements

This document replaces <draft-froment-sipping-spit-authz-policies-02.txt>.

Ciao
Hannes

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Saverio Niccolini" <[email-masked]>
Date: Fri, 15 Jun 2007 11:24:01 +0200

Dear Hannes,

This is a nice work that clearly matches also what we have in mind for the SPIT prevention system we are currently running.

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.

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

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.

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.

Cheers,
Saverio

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> 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
> 
> 
>

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 15 Jun 2007 11:41:13 +0200

Hi Hannes,

Thank you for this contribution.  It helps a lot structuring the work
on SPIT.  Unfortunately it comes too late for supporting the SPIT BoF
proposal which was rejected by the IESG.

Let's discuss at a bar BoF in Chicago when is the right time and what
is the right approach for the IETF to include more work on SPIT into
WG charters.

Thanks,

    Juergen

-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 4342-115
NEC Europe Limited,    Network Laboratories        Fax: +49 6221 4342-155
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
Registered in England 2832014

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 15 Jun 2007 21:51:47 +0200

Hi Juergen, 

> proposal which was rejected by the IESG.
As I replied to Saverio that was unfortunate timing. 

> is the right approach for the IETF to include more work on SPIT into
It would be good to start discussions already earlier since we believe
that there isn't such a huge amount of work that has to be done
initially. There might be more in the future, if people see a need for
it. Via the extensiblity mechanisms you can enhance functionality later,
as needed. 

Ciao
Hannes

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 15 Jun 2007 21:51:45 +0200

Hi Saverio, 

> -----Ursprüngliche Nachricht-----
> Von: Saverio Niccolini [mailto:[email-masked]] 
> Gesendet: Freitag, 15. Juni 2007 11:24
> An: Hannes Tschofenig; SIPPING LIST
> Betreff: RE: [Sipping] A Framework for Reducing Spam for 
> Internet Telephony
> 
> Dear Hannes,
> 
> This is a nice work that clearly matches also what we have in 
> mind for the SPIT prevention system we are currently running.
> 
> 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:

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?

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. 

> 
> 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 mark the messages with a certain spam-level and forward 
> this to the caller, this supports Req-A 2
> -- 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)?

> 
> 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 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

> From [email-masked] Sat Jun 16 10:07:53 2007
Content-class: urn:content-classes:message
Subject: AW: [Sipping] A Framework for Reducing Spam for Internet Telephony
Date: Fri, 15 Jun 2007 21:51:47 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Juergen Quittek" <[email-masked]>,
	"Hannes Tschofenig" <[email-masked]>,
	"SIPPING LIST" <[email-masked]>
Cc: 

Hi Juergen, 

Ciao
Hannes

> > Sipping mailing list  https://www1.ietf.org/mailman/lisSipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping

tinfo/sipping

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 15 Jun 2007 21:51:45 +0200

Hi Saverio, 

I hope so too. 

Ciao
Hannes

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 17 Jun 2007 14:38:00 +0200

Hi Hannes,

> it. Via the extensiblity mechanisms you can enhance functionality later,

Agreed.  You already started selecting requirements in
draft-tschofenig-sipping-framework-spit-reduction. Let's all have a look
at them and at scenario issues and architecture issues for progressing
the discussion.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 17 Jun 2007 14:47:57 +0200

hi Hannes,

> So, it seems that you think that many of the requirements are in fact reasonable.

Indeed.

> 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.

Thank you very much! (considering that you co-author 55 I-Ds ;-)

However, (a) there is already quite a number of tiny documents on SPIT
and (b) I remember that about half a year ago it was you suggesting a BoF on SPIT ;-)

>> discuss the way to move the all work on SPIT forward in the IETF.

Looking forward to it,

    Juergen

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 19 Jun 2007 13:48:30 +0200

Dear Hannes,

> interactions or 
> > authorization policies you describe in Figure
> 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 

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.

> 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 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
> 
> 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.

> 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.
> 
> 
> 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

> discuss the 
> > way to move the all work on SPIT forward in the IETF.
> I hope so too. 
> 
> 
> Ciao
> Hannes
> 
> > Cheers,
> > Saverio
> > 
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments of core SIP
> > 
> > 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] 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:  [email-masked]
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

---

From: <[email-masked]>
Date: Mon, 25 Jun 2007 11:47:11 +0300

Hi all,

I reviewed the I-D and just a couple of comments as follows. (Note that
I've provided editorial comments and additional details directly to
Hannes.)

- 1st bullet in Section 5.2: it might be good to support also other
asserted identity mechanisms than SIP Identity. I'd propose to rephrase
e.g. as "SIP Identity [RFC4474] or a corresponding mechanism is
mandatory..."

- Section 5.3: there are currently several new AUIDs defined. Wouldn't
it be rather so that the SPIT had only one AUID (e.g. spit-policy) which
"contains" extensions e.g. hashcash.

- section 7: it'd be good to provide a proper XML example in addition
HTTP PUT headers; and rephrase the first sentense after the PUT request
to explain that all the rules are checked, but only the first one
matches and is thus applied. Or, is the text assuming a kind of
hierarchy of rules? 

BR, Eva Leppanen

>From: ext Hannes Tschofenig [mailto:[email-masked]] 
>Sent: 14 June, 2007 14:29
>To: SIPPING LIST