Subject: Re: [Rucus] Charter proposal

From: "Jan Seedorf" <[email-masked]>
Date: Tue, 1 Jul 2008 19:37:50 +0200

Dear Cullen,

Thanks for taking the time to reply, I know you are busy so I appreciate it.

> My recollection of the BOF (without going and checking the 
> notes so it may be wrong) is that there was reasonable 
> consensus on a specific set of work items in an EG that 
> involved the following:
> 
>      Taking some small set (~3) of techniques from existing drafts,
>      remove the implementation details and focus on the basic 
> approach,
>      turn them into a few pages and discuss the pros and cons and
>      applicability assumptions. From this form a plausible picture of
>      one way that might help mitigate unwanted communications.

You recollection above is inline with mine. You are right that in the BoF in Philly it was agreed on what you summarize above and not more. 

It is just that after some discussions after the BoF we were thinking that RUCUSEG work should also address some of the issues presented in Henning's slides at the BoF. The reason is that we believe these issues to be key engineering tasks that need further exploration before a future WG could work on them (so perfect for an EG). I tried to summarize these ideas in order to see if people interested in the topic and willing to work on that share that view. My idea was not to question the agreement from Philly, but rather to raise the question on this mailing list if not in fact exploring the necessary communication between 3 techniques should additionally be part of RUCUSEG work and can be combined with the consensus from Philly. After all, consensus at the BoF does not exclude additions/variations if people on the mailing list agree on those.

> This charter seems to be for a rather more specific set of 
> work items, namely mechanisms for exchange of spit-related 
> information between various parts of the SIP infrastructure. 
> It's quite possible that that's an important part of the 
> solution space, but I didn't hear any consensus in the room 
> that people wanted to focus solely on that.
1) You are right that there was no consensus in the room on that. This is exactly why I raised the question on this mailing list (through an email and later through a charter proposal), trying to find consensus for that on this list. Unfortunately there was not much feedback.
2) If the charter reads to be specific it needs to be rewritten because it was not intended in that way at all. In contrary, we believe the information exchange necessary between different entities to be a general engineering challenge which is a common necessity for different techniques. The idea is not to work solely on that but to combine this with the agreement from the room to work on 3 techniques. RUCUSEG could explore 3 techniques and the corresponding communication requirements for these techniques, this is our proposal in short.

> I'd love to see an EG formed around SPAM, but I do think that 
> that group needs to be chartered more along the lines of the 
> consensus reached in Philadelphia. I'd encourage you to go 
> back and revise the draft charter so it's more consistent with that.
We are not questioning the consensus from Philly, just trying to add some additional key points to explore and asking for feedback on this. There was not much support for this proposal on this list so far. So I can understand that you as AD must stick with the consensus from the BoF as long as there is no consensus on further confinements on this list. 

I hope we can discuss face-to-face also with other people interested in the topic in Dublin to see what the community thinks. If everybody agrees that the consensus from the BoF to work on three techniques only is the final scope for RUCUSEG we are certainly not against it and happy to start EG work on that.

Kind regards,
Jan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Cullen Jennings
> Sent: Tuesday, June 24, 2008 9:41 PM
> To: [email-masked]
> Cc: Jan Seedorf
> Subject: Re: [Rucus] Charter proposal
> 
> My recollection of the BOF (without going and checking the 
> notes so it may be wrong) is that there was reasonable 
> consensus on a specific set of work items in an EG that 
> involved the following:
> 
>      Taking some small set (~3) of techniques from existing drafts,
>      remove the implementation details and focus on the basic 
> approach,
>      turn them into a few pages and discuss the pros and cons and
>      applicability assumptions. From this form a plausible picture of
>      one way that might help mitigate unwanted communications.
> 
> This charter seems to be for a rather more specific set of 
> work items, namely mechanisms for exchange of spit-related 
> information between various parts of the SIP infrastructure. 
> It's quite possible that that's an important part of the 
> solution space, but I didn't hear any consensus in the room 
> that people wanted to focus solely on that.
> 
> I'd love to see an EG formed around SPAM, but I do think that 
> that group needs to be chartered more along the lines of the 
> consensus reached in Philadelphia. I'd encourage you to go 
> back and revise the draft charter so it's more consistent with that.
> 
> Cullen <with my AD hat on>
> 
> 
> On Jun 10, 2008, at 5:54 AM, Jan Seedorf wrote:
> 
> > Dear all,
> >
> > A short while ago I sent an e-mail on this list, proposing 
> a direction 
> > and scope for RUCUS to work on as an EG. I received some 
> feedback on 
> > this list and some off-list. Since I did not receive any negative 
> > comments (convincing me that this is the wrong direction), 
> I tried to 
> > write these ideas up in a charter proposal for RUCUS.
> > Below you can find a suggestion for a charter, describing 
> what I think 
> > should be the scope of RUCUSEG, the work to be done, and the 
> > corresponding achievable goals within the scope of an EG.
> >
> > Obviously, this is open for discussion. Any input/comment 
> on this is 
> > appreciated.
> >
> > Btw: We plan to organise a one-day workshop in Heidelberg 
> (right after 
> > IPTComm 2008) in order to discuss potential IETF work in 
> the area of 
> > Unsolicited Communications and to make progress on a charter for 
> > RUCUSEG agreed on by the community. I believe Saverio is 
> going to post 
> > details regarding this workshop on this list soon.
> >
> > Kind regards,
> > Jan
> >
> > Charter Proposal for RUCUS:
> > ---------------------------------------
> > With massive deployment of SIP infrastructures it is 
> foreseeable that 
> > an increased amount of unsolicited communication will impose a 
> > potentially severe threat for real-time applications. 
> Efforts on how 
> > to reduce such a threat have received a lot of attention in 
> the IETF 
> > and have been recognized as an important item to be investigated by 
> > SIPPING. Preliminary investigations resulted already in the 
> > publication of RFC 5039.
> >
> > Unfortunately, so far, further discussions on the issue did 
> not find a 
> > big consensus on the approach to be followed. On the other 
> hand first 
> > products and solutions are now being developed and there is a big 
> > interest from different institutions to allow interoperability.
> > This interest is reflected by many individual draft submissions, 
> > indicating an active community working in the area.
> >
> > For effectively mitigating unsolicited communications, an 
> exchange of 
> > information between different entities of a SIP infrastructure 
> > ("communication glue") is required. Which information is relevant, 
> > where in the network it is generated, and with which 
> entities it needs 
> > to be exchanged depends on the organization of the network and of 
> > communication between users (e.g., closed, semi-open, or 
> open groups). 
> > Examples of such "communication glue" are: configuring and 
> > communicating authorization policies, querying oracles (trust 
> > brokers), or conveying downstream metrics to use trust among peers.
> > Such communication would allow for automated decisions with 
> respect to 
> > unsolicited communication, so that proper actions on a SIP 
> message can 
> > be taken (e.g., "forward to mailbox"). As a result, such 
> > "communication glue" would enable distributed communication 
> and allow 
> > mechanisms from different vendors to work together while mechanisms 
> > for mitigation can evolve and follow the threat evolutio n.
> >
> > It is not clear yet what precise properties are necessary to enable 
> > the exchange of information collected at different locations in a 
> > network (by different entities). A key challenge which has been 
> > identified for standardizing such communication is that attacks and 
> > mitigation mechanisms are likely to evolve. This implies 
> that a rather 
> > generic and flexible standard for information exchange is required, 
> > because a fixed standards tied to known potential attacks only may 
> > soon be outdated.
> >
> > Thus, in the spirit of an Exploratory Group, RUCUSEG will 
> explore the 
> > problem space and confine requirements for such flexible 
> exchange of 
> > information among different entities of a SIP 
> infrastructure. To lay 
> > out the path for a potential WG, RUCUSEG will derive the properties 
> > for mechanisms to communicate in a distributed setting, separating 
> > concrete mechanisms from communication protocols. As a main result, 
> > RUCUSEG will identify what communication protocol properties are 
> > necessary to achieve flexible exchange of information in a 
> way that it 
> > is independent of concrete mechanisms and allows for evolving 
> > mechanisms.
> >
> > In order to keep the work achievable within the context of an EG, 
> > RUCUSEG will select a few (e.g., 3) prototypical classes of 
> mechanisms 
> > as key ones and then work on confining how these could fit in an 
> > overall architecture and what kind of communication between 
> entities 
> > would be necessary for these classes of mechanisms in a distributed 
> > setting. The main goal of RUCUSEG is to summarize these 
> considerations 
> > in a document and to derive achievable goals for a 
> potential WG which 
> > can then start work in order to standardize communication 
> for reducing 
> > unsolicited communications.
> >
> > -- Goals/Milestones (6-12 months after work starts)
> >  -- WG charter for a follow-up WG (with consensus on the 
> mailing list)
> >  -- document on recommendations and achievable goals for a WG
> >
> > ============================================================
> > 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
> 
> _______________________________________________
> Rucus mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rucus
> 
_______________________________________________
Rucus mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rucus

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 Jul 2008 22:28:08 -0700

On Jun 25, 2008, at 9:21 AM, Saverio Niccolini wrote:

> Dear Cullen,
>
> if you look carefully in the charter text (without always thinking
> that we want to push only spam score) you will see that this charter
> proposal is nothing more than:

I was simply trying to help this charter move forward - I basically  
regret having sent any email on it now.

>
> -- a mix of Henning's presentation on architectural issues
> merged with the 3 mechanisms proposal of Jonathan
>
> I do not see any hidden thing nor pushing of something that has
> no consensus.

I did not mean to imply it was.

>
>
> We all agree that work currently established in SIPPING should have
> precedence and policy framework is (one of) the best candidates
> --> maybe this needs to be added as Mary pointed out
>
> I personally see no problems with the charter, if you still see
> them can you please detail them more?
>
> If we do not know what is your exact objection, we will have hard
> time to meet requirements for forming the EG...
>
> Looking forward to your answer,
> Saverio
>
> Dr. Saverio Niccolini
> Manager, Real-Time Communications Group
> NEC Laboratories Europe, Network Research Division	
> Tel.     +49 (0)6221 4342-118
> e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
> NEC Europe Limited Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL Registered in England 2832014
>
>
>
>> On Behalf Of Juergen Quittek
>> Sent: Wednesday, June 25, 2008 9:10 AM
>> To: Cullen Jennings; [email-masked]
>> Cc: Jan Seedorf
>> Hi Cullen,
>> Thanks for the feedback!
>> On 24.06.08 21:40  "Cullen Jennings" <[email-masked]> wrote:
>>
>> notes so it
>>> may be wrong) is that there was reasonable consensus on a
>> specific set
>>> of work items in an EG that involved the following:
>>>
>> Maybe we have to be more clear about what a "technique" is.
>> I think the charter proposal covers techniques from several existing
>> drafts including
>>  a) configuring and communicating authorization policies
>>  b) querying oracles (trust brokers)
>>  c) conveying downstream metrics to use trust among peers
>> By chance or intention these explicitly mentioned items are
>> exactly three.
>>
>>>     remove the implementation details and focus on the
>> basic approach,
>> work items,
>>> namely mechanisms for exchange of spit-related information between
>>> various parts of the SIP infrastructure.
>>
>> I do not see in what respect the charter proposal is specific.
>> I would understand if you told us it would be too general, because
>> it includes all work that has been contributed in drafts so far.
>>
>> An essential property of all three items a)-c) is that they require
>> communication between entities of the SIP infrastructure,
>> be it for exchanging very general authorization policies or for
>> exchanging very specific information on a single call.
>> I consider it quite natural, that the charter proposal reflects this.
>>
>>
>>>                                          It's quite possible that
>>> that's an important part of the solution space, but I
>> didn't hear any
>>> consensus in the room that people wanted to focus solely on that.
>>
>> Again, I do not see any part of the solution space that is excluded.
>> Can you give an example of a part of the solution space that is
>> actually excluded. This would be extremely helpful.
>>
>> Thank you,
>>
>>    Juergen
>>
>>
>>> I'd love to see an EG formed around SPAM, but I do think that that
>>> group needs to be chartered more along the lines of the consensus
>>> reached in Philadelphia. I'd encourage you to go back and revise the
>>> draft charter so it's more consistent with that.
>>>
>>>> A short while ago I sent an e-mail on this list, proposing a
>>>> direction and scope for RUCUS to work on as an EG. I received some
>>>> feedback on this list and some off-list. Since I did not
>> receive any
>>>> negative comments (convincing me that this is the wrong direction),
>>>> I tried to write these ideas up in a charter proposal for RUCUS.
>>>> Below you can find a suggestion for a charter, describing what I
>>>> think should be the scope of RUCUSEG, the work to be done, and the
>>>> Btw: We plan to organise a one-day workshop in Heidelberg (right
>>>> after IPTComm 2008) in order to discuss potential IETF work in the
>>>> area of Unsolicited Communications and to make progress on
>> a charter
>>>> for RUCUSEG agreed on by the community. I believe Saverio is going
>>>> to post details regarding this workshop on this list soon.
>>>>
>>>> Kind regards,
>>>> Jan
>>>>
>>>> With massive deployment of SIP infrastructures it is foreseeable
>>>> that an increased amount of unsolicited communication will impose a
>>>> to reduce such a threat have received a lot of attention
>> in the IETF
>>>> SIPPING. Preliminary
>>>> investigations resulted already in the publication of RFC 5039.
>>>>
>>>> Unfortunately, so far, further discussions on the issue
>> did not find
>>>> a big consensus on the approach to be followed. On the other hand
>>>> first products and solutions are now being developed and there is a
>>>> big interest from different institutions to allow interoperability.
>>>> For effectively mitigating unsolicited communications, an exchange
>>>> of information between different entities of a SIP infrastructure
>>>> where in the network it is generated, and with which entities it
>>>> needs to be exchanged depends on the organization of the
>> network and
>>>> of communication between users (e.g., closed, semi-open, or open
>>>> groups). Examples of such "communication glue" are: configuring and
>>>> Such communication would allow for automated decisions with respect
>>>> to unsolicited communication, so that proper actions on a SIP
>>>> message can be taken (e.g., "forward to mailbox"). As a
>> result, such
>>>> "communication glue" would enable distributed communication and
>>>> allow mechanisms from different vendors to work together while
>>>> mechanisms for mitigation can evolve and follow the threat evolutio
>>>> n.
>>>>
>>>> mitigation mechanisms are likely to evolve. This implies that a
>>>> rather generic and flexible standard for information exchange is
>>>> required, because a fixed standards tied to known potential attacks
>>>> only may soon be outdated.
>>>>
>>>> Thus, in the spirit of an Exploratory Group, RUCUSEG will explore
>>>> the problem space and confine requirements for such flexible
>>>> exchange of information among different entities of a SIP
>>>> infrastructure. To lay out the path for a potential WG,
>>>> RUCUSEG will derive the properties for mechanisms to communicate in
>>>> a distributed setting, separating concrete mechanisms from
>>>> communication protocols. As a main result, RUCUSEG will identify
>>>> what communication protocol properties are necessary to achieve
>>>> flexible exchange of information in a way that it is independent of
>>>> concrete mechanisms and allows for evolving
>>>> mechanisms.
>>>>
>>>> mechanisms as key ones and then work on confining how these could
>>>> fit in an overall architecture and what kind
>>>> of communication between entities would be necessary for these
>>>> classes of mechanisms in a distributed setting. The main
>>>> goal of RUCUSEG is to summarize these considerations in a document
>>>> and to derive achievable goals for a potential WG which can then
>>>> start work in order to standardize communication for reducing