Subject: [Rucus] how to move forward towards an EG

From: "Jan Seedorf" <[email-masked]>
Date: Thu, 8 May 2008 10:32:36 +0200

Dear all,

I would like to make a proposal on how to move forward with RUCUS (after all, it should be the discussion on this mailing list that drives RUCUS towards an EG). During the BoF in Philadelphia, Henning Schulzrinne presented some slides (see https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm) which in my opinion include some key ideas for potential RUCUS work and goals on which I have not seen much discussion on this list (at least not directly):

-- We should keep in mind that attacks and mechanisms (as countermeasures against unsolicited communications) are likely to evolve. Thus, RUCUS work should focus on a flexible "communication glue" for mechanisms to communicate in a (distributed) setting, or as Henning put it "separate mechanisms from communication protocols". In that sense, RUCUS as an EG could/should work out what communication protocol properties are necessary to achieve this flexible communication glue. Such communication glue should be independent of concrete mechanisms and allow for evolving mechanisms.

-- There is a need for distributed communication among entities (e.g., configuring and communicating authorization policies, querying oracles, conveying downstream metrics, see the slides). This includes the need for a common policy language to enable the communication of authorization policies. This would allow for automated decisions, so that for instance based on a) some call characteristics perceived and b) a policy set by a user (where a) and b) are at different locations) actions on a SIP message can be taken (e.g., "forward to mailbox"). Therefore, such communication glue would need to allow for distributed communication and to allow mechanisms from different vendors to work together (something where the e-mail world has failed). 

At the BoF in Philly it was agreed to follow the proposal from Jonathan Rosenberg to select 3 mechanisms from the ones in RFC 5039 and explore these in detail. Following the points above (to make distinct that very concrete mechanisms should not be standardised because these would only be of limited value due to evolving attacks), I think RUCUS should consider 3 prototypical "classes" of mechanisms as key ones (e.g., identity-based mechanisms, statistics-based mechanisms, ... -> to be agreed on) and then work on how these could fit in an overall architecture and what "communication glue" between entities would be necessary for these "classes of mechanisms" to work interoperable in a distributed setting (I believe this lies in the spirit of the proposal by Jonathan when he talked about 3 mechanisms: to have RUCUS explore what general communication properties are necessary, but limiting the work to 3 classes of mechanisms in order to make the charter achievable in resonable time).

I am interested to hear what others think about the slides Henning presented and the potential goals for RUCUS discussed above. Please provide comments so that we can find consensus and confine these ideas towards an updated charter for the RUCUS EG, convincing the ADs to grant it.

Kind regards,
Jan

P.S.: Admitedly, some text parts above are taken directly from the slides Henning presented

============================================================
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:  [email-masked] 
============================================================
NEC Europe Limited Registered Office: NEC House,
1 Victoria Road, London W3 6BL Registered in England 2832014 
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

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

Hi Jan,

at slide 12 of 
https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm 
Henning lists what the outcome of the work would be, namely:
* mechanisms to convey metrics downstream
* mechanisms to query oracles
* policy languages to allow automated decisions

Working on the specific solutions is not the job of an EG; this is the 
work that would be done afterwards in a working group.

Hence, what we would want todo in an EG is to decide on the mechanisms 
one would pick (in Henning's case the above three). Other folks may have 
different mechanisms in mind.

Jonathan proposed to again describe the mechanisms as an excercise to 
pick a certain number of mechanisms.
For example, one would describe what white lists do, what features they 
provide, where they provide advantages and where they fail.

I considered this as a useless excercise for 2 reasons:
a) we already know the mechanisms. Their properties are already known 
and described. See for example RFC 5039
b) many mechanisms need to be used in concert with some other mechanisms 
(example: strong identities are nice but you need to make an 
authorization decision afterwards; white lists are useless if there is 
no strong identity mechanisms, etc. )

Hence, I suggested to write a framework that lists a few mechanism that 
make sense when used together. This means selecting useful building blocks.

I believe we are able to write such a document in the timeframe of an 
EG. Then, we move on to the work on the detailed solutions.

Ciao
Hannes

---

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

Hannes and all,

> * policy languages to allow automated decisions

This is exactly what we are proposing since AGES...
-1- Can we finally agree on this framework view to be part of the EG planned output?

> Working on the specific solutions is not the job of an EG; 
> this is the work that would be done afterwards in a working group.

This is THE unclear point that came out in the BOF, I am personally:
-- against specifying 3 specific mechanisms in the EG
-- not against specifying 3 class of mechanism (I would be fine with saying
we agree with slide 7 of https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm)
--> but this could also be a separate doc
 
Thus the ONLY unclear point is:
-2 do we want to have, in addition to the framework, also a list
of 3 class of mechanisms for the follow-up work? If yes, as a single
doc with the framework or as a separate one?

> Hence, I suggested to write a framework that lists a few 
> mechanism that make sense when used together. This means 
> selecting useful building blocks.

the useful building blocks are:
* mechanisms to convey metrics downstream
* mechanisms to query oracles
* policy languages to allow automated decisions

> I believe we are able to write such a document in the 
> timeframe of an EG. Then, we move on to the work on the 
> detailed solutions.

We will be for sure able to do it.

Let me summarize (I am trying to help get this EG started here)
Can we set a deadline for people to answer to -1- and -2- ?
What about 2 weeks from now (23rd of May)?
After this deadline we will draw conclusions and propose the
agreed charter for RUCUS EG and have ADs grant it :-)

If there are objections to this please speak

Saverio

> 
> Ciao
> Hannes
> 
> 
> Jan Seedorf wrote:
> > Dear all,
> >
> > I would like to make a proposal on how to move forward with 
> RUCUS (after all, it should be the discussion on this mailing 
> list that drives RUCUS towards an EG). During the BoF in 
> Philadelphia, Henning Schulzrinne presented some slides (see 
> https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1
> .ppt.htm) which in my opinion include some key ideas for 
> potential RUCUS work and goals on which I have not seen much 
> discussion on this list (at least not directly):
> >
> > -- We should keep in mind that attacks and mechanisms (as 
> countermeasures against unsolicited communications) are 
> likely to evolve. Thus, RUCUS work should focus on a flexible 
> "communication glue" for mechanisms to communicate in a 
> (distributed) setting, or as Henning put it "separate 
> mechanisms from communication protocols". In that sense, 
> RUCUS as an EG could/should work out what communication 
> protocol properties are necessary to achieve this flexible 
> communication glue. Such communication glue should be 
> independent of concrete mechanisms and allow for evolving mechanisms.
> >
> > -- There is a need for distributed communication among 
> entities (e.g., configuring and communicating authorization 
> policies, querying oracles, conveying downstream metrics, see 
> the slides). This includes the need for a common policy 
> language to enable the communication of authorization 
> policies. This would allow for automated decisions, so that 
> for instance based on a) some call characteristics perceived 
> and b) a policy set by a user (where a) and b) are at 
> different locations) actions on a SIP message can be taken 
> (e.g., "forward to mailbox"). Therefore, such communication 
> glue would need to allow for distributed communication and to 
> allow mechanisms from different vendors to work together 
> (something where the e-mail world has failed). 
> >
> > At the BoF in Philly it was agreed to follow the proposal from 
> > Jonathan Rosenberg to select 3 mechanisms from the ones in RFC 5039 
> > and explore these in detail. Following the points above (to make 
> > distinct that very concrete mechanisms should not be standardised 
> > because these would only be of limited value due to 
> evolving attacks), 
> > I think RUCUS should consider 3 prototypical "classes" of 
> mechanisms 
> > as key ones (e.g., identity-based mechanisms, statistics-based 
> > mechanisms, ... -> to be agreed on) and then work on how 
> these could 
> > fit in an overall architecture and what "communication 
> glue" between 
> > entities would be necessary for these "classes of 
> mechanisms" to work 
> > interoperable in a distributed setting (I believe this lies in the 
> > spirit of the proposal by Jonathan when he talked about 3 
> mechanisms: 
> > to have RUCUS explore what general communication properties are 
> > necessary, but limiting the work to 3 classes of mechanisms 
> in order 
> > to make the charter achievable in resonable t
>  im
> >  e).
> >
> > I am interested to hear what others think about the slides 
> Henning presented and the potential goals for RUCUS discussed 
> above. Please provide comments so that we can find consensus 
> and confine these ideas towards an updated charter for the 
> RUCUS EG, convincing the ADs to grant it.
> >
> > Kind regards,
> > Jan
> >

============================================================
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: Hannes Tschofenig <[email-masked]>
Date: Fri, 09 May 2008 12:48:33 +0300

Hi Saverio,

> -- against specifying 3 specific mechanisms in the EG
OK
> we agree with slide 7 of https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm)
OK
> --> but this could also be a separate doc
OK

> doc with the framework or as a separate one?
I hope that the solution classes are specific enough so that we could 
then start the details of the work.
I personally would like to keep it separate: scenarios&framework could 
already be quite long.
> * policy languages to allow automated decisions
I understand your preference.

> If there are objections to this please speak
Could you briefly compile a drafty draft containing a description of the 
solution classes? Just to give folks an idea on how it would look like?

Ciao
Hannes

---

From: "Saverio Niccolini" <[email-masked]>
Date: Sat, 10 May 2008 09:11:58 +0200

> >> Hence, I suggested to write a framework that lists a few mechanism 
> >> that make sense when used together. This means selecting useful 
> >> building blocks.
> >>     
> >

That is my preference AND what is described in slide 11 and 12
of Henning's presentation:
https://www3.ietf.org/proceedings/08mar/slides/rucus-1/rucus-1.ppt.htm

Citing Henning (slide 12):
"What's to do?
- Need for glue to allow distirbuted mechanisms:
  -a- mechanisms to convey metrics downstream
  -b- mechanisms to query oracle
  -c- policy language to allow automated decisions"

if you look at -a- and -b- this is what we tried to describe in SPITSTOP
draft (and others like spam score)
-c- is your policy draft, plus maybe some feedbacks from users (that would
allow to trigger policies automatically)

and, in my opinion, these are the only things that makes really
sense right now for the EG (as you originally wrote in the BOF proposal)
--> and of course the idea of Jonathan that popped up in the BOF can be
added as well thus we are all happy and can really start working on the EG :-)

Ciao,
Saverio

---

From: "Jan Seedorf" <[email-masked]>
Date: Sat, 10 May 2008 23:54:14 +0200

Dear Hannes,

> this is the work that would be done afterwards in a working group.
You are right, in the scope of a 6 months EG solutions cannot be developed, I am aware of that and was not trying to suggest that.

My idea (based on Henning's slides) is that the EG should explore what kind of "communication glue" (as described in my last e-mail) is necessary to make the (to be decided on) three classes of mechanisms work together, specifically under the two in my opinion important considerations a) mechanisms and attacks will evolve and b) distributed communication between entities is necessary. I was not trying to suggest that RUCUS should develop solutions for this, but rather that RUCUS should confine requirements/necessary properties of such a "communication glue" (for a potential follow-up WG to have in a document) with respect to three classes of mechanisms (in order to focus and have achievable goals as proposed by Jonathan).

> selecting useful building blocks.
I believe this is not far from what I suggested in my e-mail. The difference may be that I think RUCUS should explore what communication is necessary between these building blocks as well.

> timeframe of an EG. Then, we move on to the work on the 
I share that view.

 - Jan

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Friday, May 09, 2008 10:32 AM
> To: Jan Seedorf
> Cc: [email-masked]
> Subject: Re: [Rucus] how to move forward towards an EG
> 
> Hi Jan,
> 
> at slide 12 of
> Hence, what we would want todo in an EG is to decide on the 
> mechanisms one would pick (in Henning's case the above 
> three). Other folks may have different mechanisms in mind.
> 
> Jonathan proposed to again describe the mechanisms as an 
> excercise to pick a certain number of mechanisms.
> For example, one would describe what white lists do, what 
> features they provide, where they provide advantages and 
> where they fail.
> 
> a) we already know the mechanisms. Their properties are 
> already known and described. See for example RFC 5039
> authorization decision afterwards; white lists are useless if 
> there is no strong identity mechanisms, etc. )
> 
> > Jonathan Rosenberg to select 3 mechanisms from the ones in 
> RFC 5039 and explore these in detail. Following the points 
> above (to make distinct that very concrete mechanisms should 
> not be standardised because these would only be of limited 
> value due to evolving attacks), I think RUCUS should consider 
> 3 prototypical "classes" of mechanisms as key ones (e.g., 
> identity-based mechanisms, statistics-based mechanisms, ... 
> -> to be agreed on) and then work on how these could fit in 
> an overall architecture and what "communication glue" between 
> entities would be necessary for these "classes of mechanisms" 
> to work interoperable in a distributed setting (I believe 
> this lies in the spirit of the proposal by Jonathan when he 
> talked about 3 mechanisms: to have RUCUS explore what general 
> communication properties are necessary, but limiting the work 
> to 3 classes of mechanisms in order to make the charter 
> achievable in resonable tim  e).
> >

---

From: Thomas Froment <[email-masked]>
Date: Mon, 12 May 2008 10:27:18 +0200

I mostly agree with Saverio's views:

> -1- Can we finally agree on this framework view to be part of the EG planned output?
Yes, of course.
> -- against specifying 3 specific mechanisms in the EG
same for me.
> --> but this could also be a separate doc
Yes
> doc with the framework or as a separate one?
I am in favor of "3 class of mechanisms" document(s), probably as 
separate documents because I feel it is better to clearly categorize
the solution space...
 
>> timeframe of an EG. Then, we move on to the work on the 
Perfect, when do we start? :

Thomas

---

From: <[email-masked]>
Date: Mon, 12 May 2008 12:25:29 +0300

>> -2 do we want to have, in addition to the framework, also a 
>list of 3 
>> class of mechanisms for the follow-up work? If yes, as a single doc 
>> with the framework or as a separate one?
>>   
>I am in favor of "3 class of mechanisms" document(s), probably 
>as separate documents because I feel it is better to clearly 
>categorize the solution space...
> 

Thomas, please note that the 3 classes of mechanisms being described in
the Exploratory Group itself are at a high-level rather than actually
describing the detailed solutions. 
Hence, we are talking about 2 pages per class at a maximum. 

Ciao
Hannes

---

From: <[email-masked]>
Date: Mon, 12 May 2008 12:41:36 +0300

Right. 

The reason why I say that is that the EG is not the place todo the
detailed solution work but rather the place todo the preparation for the
work that happens in some working group later. 

Ciao
Hannes
 
>From: ext Thomas Froment [mailto:[email-masked]] 
>Sent: 12 May, 2008 12:35
>To: Tschofenig Hannes (NSN - FI/Espoo)
>Cc: [email-masked]; [email-masked]; 
>[email-masked]
>[email-masked] wrote:
>>
>> Thomas, please note that the 3 classes of mechanisms being described 
>> in the Exploratory Group itself are at a high-level rather than 
>> actually describing the detailed solutions.
>Well, if it's only 2 pages, that's true it is not mandatorily 
>worth a separate document, but could have been a way to split 
>the work more easily...
>This is not an important issue anyway...
>
>Ciao :)
>Thomas
>
>
>

---

From: Thomas Froment <[email-masked]>
Date: Mon, 12 May 2008 11:34:30 +0200

> Hence, we are talking about 2 pages per class at a maximum. 
Well, if it's only 2 pages, that's true it is not mandatorily worth a 
separate document, but could have been a way to split the work more 
easily...
This is not an important issue anyway...

Ciao :)
Thomas

---

From: "Jan Seedorf" <[email-masked]>
Date: Mon, 12 May 2008 15:55:13 +0200

Dear Thomas,

> I am in favor of "3 class of mechanisms" document(s), 
> probably as separate documents because I feel it is better to 
> clearly categorize the solution space...
I agree that two separate documents (most probably referring to each other) make sense. However, at this stage I think it is not so important if it will be one or two documents in the end. I am rather interested if others agree on the path described in my mail a couple of days ago and then further discussed by Hannes and Saverio on this list ...

Kind regards,
Jan

> From: Thomas Froment [mailto:[email-masked]] 
> Sent: Monday, May 12, 2008 10:27 AM
> To: Saverio Niccolini
> Cc: Hannes Tschofenig; Jan Seedorf; [email-masked]
> >> Working on the specific solutions is not the job of an EG; this is 
> >> the work that would be done afterwards in a working group.
> >>     
> >
> > -- not against specifying 3 class of mechanism (I would be 
> fine with 
> > saying we agree with slide 7 of 
> > 
> > )
> I am in favor of "3 class of mechanisms" document(s), 
> probably as separate documents because I feel it is better to 
> clearly categorize the solution space...
>  
> timeframe of an

---

From: "Jan Seedorf" <[email-masked]>
Date: Mon, 12 May 2008 15:43:42 +0200

Dear Hannes,

> The reason why I say that is that the EG is not the place 
> todo the detailed solution work but rather the place todo the 
> preparation for the work that happens in some working group later. 
I think this is clear by now and was explicitly pointed out at the BoF in Philly. But it probably cannot hurt to remind everyone once in a while that RUCUS (if granted) will be an EG, not a WG.

 - Jan

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, May 12, 2008 11:42 AM
> To: [email-masked]
> Cc: Saverio Niccolini; [email-masked]; Jan Seedorf
> Subject: RE: [Rucus] how to move forward towards an EG
> 
> Right. 
> 
> The reason why I say that is that the EG is not the place 
> todo the detailed solution work but rather the place todo the 
> preparation for the work that happens in some working group later. 
> 
> Ciao
> Hannes
>