Subject: [Rucus] Any further comments on draft-york-sipping-spit-similarity-scenarios-00.txt ?

From: Dan York <[email-masked]>
Date: Fri, 2 May 2008 16:33:19 -0400

SIPPING & RUCUS,

Because I've had some various pieces of feedback on the document, I'm  
going to rev draft-york-sipping-spit-similarity-scenarios in the next  
week or so to incorporate that feedback.  Since I'm doing so, I  
thought I'd just ask.... anyone else have comments on:

   http://tools.ietf.org/id/draft-york-sipping-spit-similarity-scenarios-00.txt

Additional scenarios you think I should include.... points of  
clarification... whatever?

Thanks,
Dan
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 03 May 2008 19:39:22 +0300

Hi Dan,

I like your document, as mentioned previously already. I shows some of 
the limitations with systems that use learning of past behavior as their 
basis for future actions. Some of the statistical techniques belong to 
this category.

However, the most important question is: What should happen with the 
document at the end?
Furthermore, the document points to potential problems to a specific 
category of solutions. For systems that do not rely on learning 
techniques these scenarios are not a problem as such.

Ciao
Hannes

---

From: Dan York <[email-masked]>
Date: Sat, 3 May 2008 16:12:36 -0400

Hannes,

> I like your document, as mentioned previously already. I shows some  
> of the limitations with systems that use learning of past behavior  
> as their basis for future actions. Some of the statistical  
> techniques belong to this category.

DY> Yes, you have mentioned this before.  Thank you.

> However, the most important question is: What should happen with the  

DY> Good question. My goal with the document was really to inform the  
ongoing debate and ensure that these points were being considered.   
There's probably a couple of tracks the document could take:

1. Do nothing further with it beyond the next revision.  The point has  
been made. It can continue to exist as a current (and then expired)  
Internet-Draft.
2. Fold it into some larger problem statement document along with  
similar views for other categories of solutions.

Or do something else entirely... I don't actually know.
> techniques these scenarios are not a problem as such.

DY> Yes.  In fact, the majority of SPIT/SPAM solutions *suggested by  
the IETF* so far are NOT this category of solutions.  Now, I can  
completely see the various network security vendors looking to try to  
address voice SPAM/SPIT using these techniques... but I have not  
really seen any of these solutions being brought into the IETF yet.

Regards,
Dan

---

From: <[email-masked]>
Date: Sun, 4 May 2008 16:00:03 +0300

Hi Dan, 

>> the limitations with systems that use learning of past behavior as 
>> their basis for future actions. Some of the statistical techniques 
>> belong to this category.
>
>1. Do nothing further with it beyond the next revision.  The 
>point has been made. It can continue to exist as a current 
>(and then expired) Internet-Draft.
>2. Fold it into some larger problem statement document along 
>with similar views for other categories of solutions.

I prefer (2) together with David's document. 

>the IETF* so far are NOT this category of solutions.  Now, I 
>can completely see the various network security vendors 
>looking to try to address voice SPAM/SPIT using these 
>techniques... but I have not really seen any of these 
>solutions being brought into the IETF yet.

You are right. In some sense one could use your document as a
requirements document in the style of: "Ah. You are developing a SPIT
solution then please tell us how you address these scenarios." 

Ciao
Hannes

---

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 5 May 2008 20:38:59 +0200

Dear Hannes,

> I like your document, as mentioned previously already. I 
> shows some of the limitations with systems that use learning 
> of past behavior as their basis for future actions. Some of 
> the statistical techniques belong to this category.

we all agree statistical techniques do have limitations, but
they are also powerful and this does not mean they should not
be considered in the RUCUS work

I remember all the list of methods indicated by Henning during
the BOF as most promising (check his ppt slides):
-- identity-based
-- statistics
-- price-based

For some of the scenarios Dan describes in his draft the statistical
techniques will never come into play:
-- "emergency notifications": if you have strong identities in place
and you are sure nobody can steal them, you just need to insert the
URIs that are allowed to send "emergency notification" into the
white list --> no need to apply statistics, just work on policy and
identity-based mechanisms (statistics are useful here to check misbehaviours)

-- Urgent Notification Systems: a bit more complicated but there is always
a previous relationship between caller and callee, thus also here
one could get around them without statistics but with policies and identity-based
mechanisms

-- for the other systems I would always repeat what I just wrote:
apply policies and identity-based mechanisms

The statistics are good when ther eis no previous relationship between
the caller and the callee and this is why they are useful

Thus if you want to choose the three class of mechanisms that RUCUS should
suggest just choose these three..

Cheers,
Saverio

> However, the most important question is: What should happen 
> with the document at the end?
> Furthermore, the document points to potential problems to a 
> specific category of solutions. For systems that do not rely 
> on learning techniques these scenarios are not a problem as such.
> 
> Ciao
> Hannes
> 
> 
> 
> Dan York wrote:
> > SIPPING & RUCUS,
> >

============================================================
Dr. Saverio Niccolini
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

---

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 5 May 2008 20:43:01 +0200

Dear all,

> point has 

I support this option.

> requirements document in the style of: "Ah. You are 
> developing a SPIT solution then please tell us how you 
> address these scenarios." 

right, if we develop any framework for preventing UC we should be
surethat we do not block such communications
--> that is why I think the policy draft of Hannes is an important piece
of work (but only a part of it, not the whole picture)

Saverio

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 09 May 2008 11:17:57 +0300

I agree with you, Saverio. Nevertheless it is a good idea to keep the 
scenarios Dan has described in his document in mind and to consider them 
in the overall solution.

Saverio Niccolini wrote:
>>> Because I've had some various pieces of feedback on the 
>>>       
>> document, I'm 
>>     
>>> going to rev draft-york-sipping-spit-similarity-scenarios 
>>>       
>> in the next 
>>     
>> http://tools.ietf.org/id/draft-york-sipping-spit-similarity-scenarios-
>>     
>>> 00.txt
>>>

---

From: "Saverio Niccolini" <[email-masked]>
Date: Fri, 9 May 2008 11:06:28 +0200

Hannes,

I am fine with keeping scenarios as Dan described to give people
an idea of what they risk (kind of pitfalls) if they not look carefully
into configuration of certain polcies.

Actually this is part of what we think would be the direction of RUCUS:
-- "reference scenario": 
let's take a reference scenario, e.g. a simple standard SIP one like
slide 11 of Henning's presentation
(https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) 
and let's add what the pitfalls are (Dan's doc), add the considerations
of David about the problem statement and the ones of Otmar which
people seems to agree on

-- "framework" or "communication glue" --> see Jan's email
for this we see slide 11 of Henning's presentation (https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm)
as the best example --> it includes polcies and signalling extensions to
query oracles and allow distirbuted decisions --> it would not hint to 
specific solution mechanisms if well defined

-- "class of mechanisms" -- see also Jan's email
this is what Jonathan proposed at the BOF and people agreed on,
actually we speak about classes since single mechanisms do not make
entire sense at this point in time

I do not seen any problem with this approach and I hope to see large
consensus, I think this is clean and simple and we can achieve this in
the 6 months of an EG.

Can we agree on this, write the charter proposal around that, have
ADs convinced and start real work?

Comments?

Saverio

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Friday, May 09, 2008 10:18 AM
> To: Saverio Niccolini
> Cc: Dan York; rucus BoF
> Subject: Re: [Rucus] Any further comments on 
> draft-york-sipping-spit-similarity-scenarios-00.txt ?
> 
> I agree with you, Saverio. Nevertheless it is a good idea to 
> keep the scenarios Dan has described in his document in mind 
> and to consider them in the overall solution.
> 
> 
> Saverio Niccolini wrote:
> > Dear Hannes,
> >
> >   
> shows some 
> >> of the limitations with systems that use learning of past 
> behavior as 
> > we all agree statistical techniques do have limitations, 
> but they are 
> > also powerful and this does not mean they should not be 
> considered in 
> > the RUCUS work
> >
> > I remember all the list of methods indicated by Henning 
> during the BOF 
> > as most promising (check his ppt slides):
> > -- identity-based
> > -- statistics
> > -- price-based
> >
> > URIs that are allowed to send "emergency notification" into 
> the white 
> > list --> no need to apply statistics, just work on policy and 
> > -- Urgent Notification Systems: a bit more complicated but there is 
> > always a previous relationship between caller and callee, thus also 
> > here one could get around them without statistics but with policies 
> > and identity-based mechanisms
> >
> > Thus if you want to choose the three class of mechanisms that RUCUS 
> > should suggest just choose these three..
> >
> > Cheers,
> > Saverio
> >
> >   
> > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> > London W3 6BL Registered in England 2832014
> >  
> >   
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 09 May 2008 12:18:00 +0300

Hi Saverio,

to have 2 documents as output of the WG sounds good for me. One that 
focuses on the framework & scenarios and another one that points to the 
class of mechanisms (considering the other document).

Good proposal!

Ciao
Hannes

Saverio Niccolini wrote:
>>> For some of the scenarios Dan describes in his draft the 
>>>       
>> statistical 
>>     
>>> -- "emergency notifications": if you have strong identities 
>>>       
>> in place 
>>     
>>> The statistics are good when ther eis no previous 
>>>       
>> relationship between 
>>     
>>>> However, the most important question is: What should 
>>>>         
>> happen with the 
>>     
>>>> document at the end?
>>>> Furthermore, the document points to potential problems to 
>>>>         
>> a specific 
>>     
>> http://tools.ietf.org/id/draft-york-sipping-spit-similarity-scenarios
>>     
>>>> -
>>>>     
>>>>         
>>>>> 00.txt
>>>>>