Subject: [Rucus] Scoping question about rucus BoF

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 18 Feb 2008 13:46:25 +0100

Hi all,

I have been looking for some information about the rucus bof and ran into Hannes' web page (http://www.tschofenig.priv.at/bof-rucus.html). I have no clue whether this page is authorative or not. Anyhow, here goes my question.

I have seen the discussions on SIPPING and the SPITSTOP mailing list, plus the above mentioned web page. However, after all, I still fail in getting the intended scope of the RUCUS BoF. The title suggests the topic, but the web page just says:
1) There is a potential threat resulting from SPIT;
2) SIP identity management;
3) some hand-waving about prior art. 

Me personally does like to see a WG taking care of SPIT countermeasures, but (as usual) the field of SPIT is so broad that there is the need to focus. 

The agenda is, to be honestly, strange. Why should a Bof burn time to discuss RFC 5111?
Is RUCUS not about SPIT but a test tool for RFC 5111?

  Martin

[email-masked]   <== NEW ADDRESS

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 
_______________________________________________
Rucus mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rucus

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Feb 2008 15:16:12 +0200

Hi Martin,

you raised a couple of points. I will try to give you a short answer now 
and longer answers later:

* BOF Description

It is currently on my private webpage (and in emails posted to the list) 
but it is not on an IETF page.
That's quite common at this stage.

* Agenda

I will update the agenda as I find more speakers. Currently, I got the 
confirmation from Henning to speak about architectural aspects. Jim 
Fenton is going to give a presentation about "Lessons learned from Email 
Spam work" and either Bernard or Lakshminath will speak about RFC 5111. 
I would like to have someone from the privacy and from the XMPP/Jabber 
community but I do not yet have confirmations.

As such, the agenda is still work in progress. Suggestions are welcome!
 
* RFC 5111

This document is pretty now, I agree. The idea is also pretty novel for 
the IETF itself.
Hence, the ADs thought it would be useful to have a short presentation 
by the authors of that RFC to explain the community that an Exploratory 
Group actually is.
I think that's a good idea since I believe around 90% of the folks in 
the room have never heard about this concept before.

* Scope

As indicated by Cullen in his mail the scope has be made precisely. We 
should use the mailing list for doing so. I also understand that most 
people are working on draft updates during these too weeks. Hence, I do 
not expect too much feedback before the draft submission deadlines are 
over.

One thing I got as input was that we should not investigate anything 
relating to the interpretation of RTP. The IAB thought that this is very 
much a research issue and I agree with their assessment.

Ciao
Hannes

---

From: Dan York <[email-masked]>
Date: Mon, 18 Feb 2008 09:01:27 -0500

Martin,

Just to add on to Hannes' points, to me the point of the RUCUS BOF is  
really to look at the overall *architecture* for realtime  
communications over SIP and  address questions such as:
   - can we in fact establish an overall framework for dealing with  
SPIT/spam?
   - what are the various pieces of that framework?
   - what of the existing IETF work can we simply use with no  
modification? (for instance, perhaps the various forms of SIP Identity)
   - in what areas of the framework can we define the problem and  
simply need to write some documents and formalize current thinking?
   - in what areas of the framework do we need more research?

I'm not naive enough to think we'll solve all of that in  
Philadelphia, but the point to me is to get the various people  
interested in the problem of SPIT all in one room and bash this stuff  
out and see where we need to go next.

If you look at RFC 5039 - http://tools.ietf.org/rfcmarkup?doc=rfc5039  
- there is no lack of proposed solutions out there to combat SPIT.   
There are a good number of folks working in this space. I also don't  
expect we'll ever see a "silver bullet" solution that mystically  
makes the problem go away. There's a zillion different network  
configurations out there in deployed networks and each one is  
different enough from others that in the end I'm sure we'll end up  
with a range of solutions that are applicable to different kind of  
networks.

Where I believe we in the IETF can add value is to help put together  
the pieces (and create new ones if necessary) that provide an overall  
framework to guide network administrators in protecting their  
networks.   Jonathan and Cullen propose a starting point in RFC 5039  
for a framework:

1. Strong Identity
2. White Lists
3. Solve the Introduction Problem
4. Don't Wait Until It's Too Late

In my mind the work of RUCUS is to look at how to take that (and  
other work) and turn it into an actual framework/architecture. We've  
had a lot of I-Ds that propose individual point solutions (and have  
had BOF proposals in the past that intended to focus on those  
solutions).  This is to look at how we put it all together.  At  
least, that is *my* perspective and why I support this BOF.

My 2 cents,
Dan

On Feb 18, 2008, at 8:16 AM, Hannes Tschofenig wrote:

>> I have been looking for some information about the rucus bof and  
>> ran into Hannes' web page (http://www.tschofenig.priv.at/bof- 
>> rucus.html). I have no clue whether this page is authorative or  
>> not. Anyhow, here goes my question.
>>
>> I have seen the discussions on SIPPING and the SPITSTOP mailing  
>> list, plus the above mentioned web page. However, after all, I  
>> still fail in getting the intended scope of the RUCUS BoF. The  
>> title suggests the topic, but the web page just says:
>> Me personally does like to see a WG taking care of SPIT  
>> countermeasures, but (as usual) the field of SPIT is so broad that  
>> there is the need to focus.
>>
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria  
>> Road, London W3 6BL | Registered in England 2832014

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

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

---

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 18 Feb 2008 15:23:31 +0100

Hi,

> much a research issue and I agree with their assessment.

Can you be a bit more precise about "the interpretation of RTP"?
I did not get what you mean by that.

Cheers,
Saverio

============================================================
Dr. Saverio Niccolini
Senior Researcher
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
_______________________________________________
Rucus mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rucus

---

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 18 Feb 2008 15:59:12 +0100

Hi Hannes, all,

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Monday, February 18, 2008 2:16 PM
> To: Martin Stiemerling
> Cc: rucus BoF
> Subject: Re: [Rucus] Scoping question about rucus BoF
> 
> Hi Martin,
> 
> you raised a couple of points. I will try to give you a short 
> answer now and longer answers later:
> 
> * BOF Description
> 
> It is currently on my private webpage (and in emails posted 
> to the list) but it is not on an IETF page.

I do know this ;)

I was just wondering about not finding anything on the several email lists related to rucus.

> 
> * Agenda
> 
> I will update the agenda as I find more speakers. Currently, 
> I got the confirmation from Henning to speak about 
> architectural aspects. Jim Fenton is going to give a 
> presentation about "Lessons learned from Email Spam work" and 
> either Bernard or Lakshminath will speak about RFC 5111. 

Could be a good idea.

> I would like to have someone from the privacy and from the 
> XMPP/Jabber community but I do not yet have confirmations.

I don't see the reason for this.

> As such, the agenda is still work in progress. Suggestions 

Here is a change proposal for the agenda (moving "legal" things first) and giving more space for the chair to explain what's up in the BoF:

 Title                                                   Duration
  ---------------------------                          -----------
  Introduction                                          (chairs, 15)
  Intro of RFC 5111                            (chairs/ADs, 5)

  RFC 5039 Overview                                       (TBD, 10)

  Architectural Considerations                     (Tschofenig, 30)
    (based on 
     draft-tschofenig-sipping-framework-spit-reduction-02.txt
     draft-niccolini-sipping-spitstop-00.txt ) 

  Discussion                                       (all, remaining)
  Warp-up                                               last 10 mins
                                                       ------------

>  
> * RFC 5111
> 
> This document is pretty now, I agree. The idea is also pretty 
> novel for the IETF itself.
> Hence, the ADs thought it would be useful to have a short 
> presentation by the authors of that RFC to explain the 
> community that an Exploratory Group actually is.
> I think that's a good idea since I believe around 90% of the 
> folks in the room have never heard about this concept before.

I would shift it to the beginning, as this will definitely impact the discussions. Also, it is more useful to put the planable things upfront, i.e., getting free time at the end for the necessary discussions.

> 
> * Scope
> 
> As indicated by Cullen in his mail the scope has be made 
> precisely. We should use the mailing list for doing so. I 
> also understand that most people are working on draft updates 
> during these too weeks. Hence, I do not expect too much 
> feedback before the draft submission deadlines are over.

Yes, I agree that most people are busy with writing drafts. And my intention was to give the whole scoping discussions a kick-start ( or slow-start).

My brief scoping proposal for rucus (open for discussions!):
- SPIT as threat for SIP is foreseeable, but not fully understood to all extend.
- RFC 5039 is used as problem statement for SPIT
- rucus should define an architecture/framework for SIP to mitigate SPIT
- rucus should produce a set of requirements how to mitigate SPIT
- rucus output used as input to sipping

> 
> One thing I got as input was that we should not investigate 
> anything relating to the interpretation of RTP. The IAB 
> thought that this is very much a research issue and I agree 
> with their assessment.

I assume this refers to investigation of RTP playload, i.e. voice/video?

  Martin

---

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 18 Feb 2008 16:26:50 +0100

Dan,

I see us both on the same line.

Thanks,

  Martin

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Dan York
> Sent: Monday, February 18, 2008 3:01 PM
> To: [email-masked]
> Cc: rucus BoF; Martin Stiemerling
> Just to add on to Hannes' points, to me the point of the 
> RUCUS BOF is really to look at the overall *architecture* for 
> realtime communications over SIP and  address questions such as:
>   - can we in fact establish an overall framework for dealing 
> with SPIT/spam?
>   - in what areas of the framework can we define the problem 
> and simply need to write some documents and formalize current 
> thinking?
> Philadelphia, but the point to me is to get the various 
> people interested in the problem of SPIT all in one room and 
> bash this stuff out and see where we need to go next.
> 
> If you look at RFC 5039 - 
> http://tools.ietf.org/rfcmarkup?doc=rfc5039 - there is no 
> lack of proposed solutions out there to combat SPIT.  There 
> are a good number of folks working in this space. I also 
> don't expect we'll ever see a "silver bullet" solution that 
> mystically makes the problem go away. There's a zillion 
> different network configurations out there in deployed 
> networks and each one is different enough from others that in 
> the end I'm sure we'll end up with a range of solutions that 
> are applicable to different kind of networks.
> 
> Where I believe we in the IETF can add value is to help put 
> together the pieces (and create new ones if necessary) that 
> provide an overall framework to guide network administrators 
> in protecting their networks.   Jonathan and Cullen propose a 
> starting point in RFC 5039 for a framework:
> 
> 1. Strong Identity
> 2. White Lists
> In my mind the work of RUCUS is to look at how to take that 
> (and other work) and turn it into an actual 
> framework/architecture. We've had a lot of I-Ds that propose 
> individual point solutions (and have had BOF proposals in the 
> past that intended to focus on those solutions).  This is to 
> look at how we put it all together.  At least, that is *my* 
> perspective and why I support this BOF.
> 
> My 2 cents,
> Dan
> 
> 		I have been looking for some information about 
> the rucus bof and ran into Hannes' web page 
> (http://www.tschofenig.priv.at/bof-rucus.html). I have no clue 
> whether this page is authorative or not. Anyhow, here goes my 
> question.
> 
> 		I have seen the discussions on SIPPING and the 
> SPITSTOP mailing list, plus the above mentioned web page. 
> However, after all, I still fail in getting the intended 
> scope of the RUCUS BoF. The title suggests the topic, but the 
> web page just says:
> 		Me personally does like to see a WG taking care 
> of SPIT countermeasures, but (as usual) the field of SPIT is 
> so broad that there is the need to focus. 
> 
> 		The agenda is, to be honestly, strange. Why 
> should a Bof burn time to discuss RFC 5111?
> 		NEC Europe Limited | Registered Office: NEC 
> House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Feb 2008 17:33:46 +0200

Hi Martin

> I was just wondering about not finding anything on the several email lists related to rucus.
When you register for the mailing list then you can find the link to the 
text.

> I don't see the reason for this.
Interesting.

There are a couple of privacy related questions that come up with regard 
to this topic in the past. Learning something about this would be helpful.
The XMPP/Jabber work is as important as hearing about the Email 
Anti-Spam work given that XMPP/Jabber is about real-time communication 
and many of the work we are doing here right now has been done by these 
folks years ago already. Would be interesting to hear what their big 
picture was (since this is not described in any of their documents).

> Here is a change proposal for the agenda (moving "legal" things first) and giving more space for the chair to explain what's up in the BoF:
The reason why I put the RFC 5111 presentation to the end was it relates 
to the charter discussion.

> I would shift it to the beginning, as this will definitely impact the discussions. Also, it is more useful to put the planable things upfront, i.e., getting free time at the end for the necessary d…

See above but I am easy to convince.

> - rucus should define an architecture/framework for SIP to mitigate SPIT
I intentionally used the term "reducing unwanted communication" in the 
BoF proposal since I believe we are not only talking about SPIT.

> - rucus should produce a set of requirements how to mitigate SPIT
In my past IETF work I got the impression that a lot of the work on 
requirements was wasted time (btw, discussion about terminology was 
useful since it often ended up in the same document). I think once we 
roughly agree on the big picture then the work on the solutions is "easy".

> - rucus output used as input to sipping
Whether any subsequent work should be done in SIPPING is something I do 
not worry about at this point in time (also since it is up to the ADs to 
decide).

> I assume this refers to investigation of RTP playload, i.e. voice/video?
I will respond to this issue in a separate mail.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Feb 2008 17:39:40 +0200

For example, one could imagine to develop a mechanism that analyzes the 
speech characteristic of the caller in order to draw some conclusions 
about the likelihood of unwanted communication attempt.

It is believed that this is not really something we want to work on in 
RUCUS (and I agree).

Ciao
Hannes

---

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 18 Feb 2008 16:45:39 +0100

Ok,

I agree.

I still think that challenging a caller with a CAPTCHA like:
"Please dial 3 4 6 to get connected to the callee"
(and how to realize this scenario with standard SIP) could
be something for RUCUS.

Cheers,
Saverio

> Sent: Monday, February 18, 2008 4:40 PM
> To: Saverio Niccolini
> Cc: Martin Stiemerling; rucus BoF
> For example, one could imagine to develop a mechanism that 
> analyzes the speech characteristic of the caller in order to 
> draw some conclusions about the likelihood of unwanted 
> communication attempt.
> 
> It is believed that this is not really something we want to 
> work on in RUCUS (and I agree).
> 
> Ciao
> Hannes
> 
> 
> 
> Saverio Niccolini wrote:
> > Hi,
> >
> >   
> >> relating to the interpretation of RTP. The IAB thought 
> that this is 
> >> very much a research issue and I agree with their assessment.
> >>     
> >
> > NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> > London W3 6BL Registered in England 2832014
> >   
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Feb 2008 17:49:59 +0200

> (and how to realize this scenario with standard SIP) could
That's something different.

Ciao
Hannes

>>>> One thing I got as input was that we should not 
>>>>         
>> investigate anything 
>>

---

From: Dan York <[email-masked]>
Date: Mon, 18 Feb 2008 10:56:13 -0500

Saverio,

I don't think Hannes was indicating that something like a CAPTCHA  
couldn't be a possible piece of the solution (and indeed it is  
mentioned in RFC 5039).   I don't really see that as "interpreting  
RTP"... I think of that more in the lines of what Hannes mentioned  
about "voice stress analysis", etc.

Again, though, this is diving down into the weeds of point  
solutions.  We need to take a step back up and look at "the big  
picture", into which things like a voice CAPTCHA may ultimately fit.

Regards,
Dan

---

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 18 Feb 2008 17:05:30 +0100

Dan,

I agree, RUCUS is about architecture and CAPTCHA is a punctual solution
but I wanted to know the answer since it may impact the architecture.

And if we say CAPTCHA can be one solution the architecture shold be thought
accordingly.

Saverio

> From: Dan York [mailto:[email-masked]] 
> Sent: Monday, February 18, 2008 4:56 PM
> To: Saverio Niccolini
> Cc: [email-masked]; rucus BoF; Martin Stiemerling
> I don't think Hannes was indicating that something like a 
> CAPTCHA couldn't be a possible piece of the solution (and 
> indeed it is mentioned in RFC 5039).   I don't really see 
> that as "interpreting RTP"... I think of that more in the 
> lines of what Hannes mentioned about "voice stress analysis", etc.
> 
> solutions.  We need to take a step back up and look at "the 
> big picture", into which things like a voice CAPTCHA may 
> ultimately fit.
> 
> Regards,
> Dan
> 
>