Re: [spitstop] [Sipping] Pushing Policies towards the Sender's Domain

[Hannes Tschofenig <[e-mail]>]

Hi Jeremy,

one idea that was mentioned by a couple of folks was to provide a very 
simple spam score added to a header. The most likely use case is that 
your trusted proxy adds a score to a message based on some statistical 
technique. If you have already have your proxy instructed to act 
according to a specific value range of this spam score then it would 
just perform the action. Alternatively, you could also forward the info 
to the end host. For one hop you will quite likely not need any digital 
signature but instead you would rely on the mechanisms you have in place 
already to secure the rest of the signaling message exchanges between 
the proxy and the SIP UA.

The case where two domains exchange some information about the 
likelihood of spam is a bit different. In 
draft-niccolini-sipping-feedback-spit-02 the mechanism to convey this 
info is suggested to be carried in an additional header.
In draft-schwartz-sipping-spit-saml-00.txt a more extensive set of info 
is encoded in XML.

The main questions are:

* What is the most likely usage model?
   - Who does the marking?
   - Who makes the decisions based on this marking?
* Can we trust intermediaries that they do not play around with the 
marking?
* Can we trust the entity that makes the marking?

Ciao
Hannes



Jeremy Barkan (DigitalShtick) wrote:
> Hi Hannes - 
>
> Regarding domain crossing and policy - there would need to be some trust
> mechanism in order for the receiving domain [ either the terminating domain
> or some proxy/transit/provider domain in the downstream flow ] to apply the
> authorizations.
>
> If the authorization is end-to-end - the trust model is simplified [ such as
> SIP Identity ] and this is what I understood from the draft.
>
> If the authorization is distributed across the hops - it's more complicated,
> with all the fragility and complexity you mentioned of a chain of trust.
> In this case - we would need a framework [ SAML ] to express the
> relationships. 
>
> Your thoughts ?
>
> Regards
>
> Jeremy
>
>   
Ciao
Hannes

> -----Original Message-----
> From: Tschofenig, Hannes [mailto:[e-mail]] 
> Sent: Tuesday, June 26, 2007 3:26 PM
> To: ext Saverio Niccolini; SIPPING LIST
> Cc: Signaling TO Prevent SPIT
> Subject: AW: [Sipping] Pushing Policies towards the Sender's Domain
>
> Hi Saverio, 
>
>   
>> Hannes,
>>
>>     
>>> Hi Saverio,
>>>
>>> Saverio Niccolini wrote:
>>>       
>>>> Hi Hannes,
>>>>
>>>> to add on what Juergen said, what we adressed in our SPITSTOP
>>>> draft was not meant to cover only the authorization policies
>>>> as you are saying, the authorization policies are just a 
>>>>         
>>> special case
>>>       
>>>> of the possible communications between domains, others are;
>>>> -- info related to SPIT estimations
>>>>   
>>>>         
>>> Have you looked at the following document 
>>> http://www.tschofenig.priv.at/drafts/draft-schwartz-sipping-spit-s
>>> aml-00.txt
>>> Is this close to the mechanisms you have in mind?
>>> (ignore the encoding in a SAML assertion for a moment)
>>>       
>> (Ignoring the SAML assertion for a moment)
>> I had a look at it some time ago (this draft expired in 2006),
>> I think the SPITSuspect security attribute is the most important
>> example of info to be exchanged, but also others are good examples,
>> anyway I think more can be added, maybe we can find time at next IETF
>> to discuss this.
>>     
>
> Sure, we can discuss this issue also at the IETF meeting. 
>
> Re-writing the SAML SPIT draft I would probably separate the encoding
> >from the security mechanisms. In any case, I believe you needs to be
> some sort of security, such as SAML, when you cross domain boundaries
> (unless you believe that the walled garden model with transitive trust
> is the right way to go).
>
> In the case where you are not crossing domain boundaries you might not
> need to integrity protect and authenticate the info. 
>
>   
>> >From an encoding point of view there are essentially two ways: 
>>     
>
> (a) You put the attributes into the SAML assertion
>
> That's even possible not to sign it if the info is just made available
> (for example, between your proxy and yourself). In this case you would
> just make the information available via an XML document. Since a proxy
> would add this info it would only attach a reference; if I, as an end
> host, do not care about the info then I just ignore it. 
>
> (b) Alternatively, you could encode the info into a header (without
> using all the XML stuff).
>
>   
>>>> -- messages explaining to the sender domain why the message 
>>>>         
>>> was blocked
>>>       
>>>>   
>>>>         
>>> If you are talking about ordinary SIP mechanisms then that is 
>>> fine for 
>>> me. This might help the sender
>>> Is this your intention or to share blacklists between the 
>>>       
>> two domains?
>>
>> This could be an example but also pushing back the SPITSuspect scores
>> or the reason why the callee's rejected a call could be othjer
>> examples (with the proper considerations to be applied)
>>
>>     
>
> I have seen proposals for individual calls and for bulk transfer of
> information. The use cases a somewhat different but the underlying
> mechanisms might be the same (i.e., the bulk transfer is just a
> concatenation of individual "spit" reports). 
>
> The other question is also what you would like to report. 
>
>   
>>>> I clearly see these two points having priority over the 
>>>>         
>>> authorization
>>>       
>>>> polices when it comes to pushing info towards the sender domain.
>>>>   
>>>>         
>>> In some sense this is quite similar to "authorization" 
>>>       
>> policies. The 
>>     
>>> difference is, however, whether you do the interaction based on 
>>> individual calls or on an aggregate
>>>       
>> I agree on this.
>>     
>
> Ciao
> Hannes
>
>   
>> Cheers,
>> Saverio
>>
>>     
>>> Ciao
>>> Hannes
>>>
>>>       
>>>> Cheers,
>>>> Saverio
>>>>
>>>> ============================================================
>>>> Dr. Saverio Niccolini
>>>> Senior Research Staff Member
>>>> Network Laboratories, NEC Europe Ltd.
>>>> Kurfuerstenanlage 36, D-69115 Heidelberg
>>>> Tel.     [phone]
>>>> Fax:     [phone]
>>>> e-mail:  [e-mail]
>>>> ============================================================
>>>> NEC Europe Limited Registered Office: NEC House, 1 Victoria
>>>> Road, London W3 6BL Registered in England 2832014
>>>>  
>>>>   
>>>>
>>>>   
>>>>         
>>>>> -----Original Message-----
>>>>> From: Juergen Quittek [mailto:[e-mail]] 
>>>>> Sent: Sunday, June 17, 2007 2:30 PM
>>>>> To: Hannes Tschofenig; SIPPING LIST
>>>>> Subject: Re: [Sipping] Pushing Policies towards the 
>>>>>           
>> Sender's Domain
>>     
>>>>> Hi Hannes,
>>>>>
>>>>> I fully agree, that pushing policies between domains should 
>>>>> get low priority at this point in time in the context of 
>>>>> standards required for SPIT prevention.  This is why we did 
>>>>> not cover it in draft-niccolini-sipping-spitstop and just 
>>>>> made the note that you cited below pointing to 
>>>>> draft-froment-sipping-spit-authz-policies
>>>>> where it seemed that this was included.
>>>>>
>>>>> It is good that you replaced 
>>>>> draft-froment-sipping-spit-authz-policies with 
>>>>> draft-froment-sipping-spit-requirements that only focuses on 
>>>>> requirements.
>>>>>
>>>>> Thanks,
>>>>>
>>>>>     Juergen
>>>>>
>>>>>
>>>>> --On 16.06.07 16:03 +0200 Hannes Tschofenig wrote:
>>>>>
>>>>>     
>>>>>           
>>>>>> Hi all,
>>>>>>
>>>>>> when reading through the documents I came across the following 
>>>>>> statement in <draft-niccolini-sipping-spitstop-00.txt>:
>>>>>>
>>>>>> "
>>>>>>    Please note that the described reference scenario does 
>>>>>>       
>>>>>>             
>>>>> not addresses
>>>>>     
>>>>>           
>>>>>>    management interfaces to entities involved in SPIT 
>>>>>>             
>>> prevention.  A
>>>       
>>>>>>    first approach to this issue has been made is described in
>>>>>>    [I-D.froment-sipping-spit-authz-policies].
>>>>>> "
>>>>>>
>>>>>> it seems that some parts of
>>>>>> <draft-froment-sipping-spit-authz-policies-02.txt> got 
>>>>>>       
>>>>>>             
>>>>> misunderstood.
>>>>>     
>>>>>           
>>>>>> There are some text paragraphs in
>>>>>> <draft-froment-sipping-spit-authz-policies-02.txt> that 
>>>>>>             
>>> envisioned 
>>>       
>>>>>> that the authorization policies are distributed to other 
>>>>>>       
>>>>>>             
>>>>> domains, and 
>>>>>     
>>>>>           
>>>>>> in particular towards the sender's domain. There is 
>>>>>>             
>> obviously the 
>>     
>>>>>> question what you would but in these policy documents, when to 
>>>>>> distribute them and whether there are potential privacy 
>>>>>>       
>>>>>>             
>>>>> problems with that approach.
>>>>>     
>>>>>           
>>>>>> This is an interesting technical issue BUT I would put it on my 
>>>>>> priority list for work that has to be done in the SPIT 
>>>>>>             
>> prevention 
>>     
>>>>>> space to the end of the queue. This lead us actually to 
>>>>>>       
>>>>>>             
>>>>> create a new 
>>>>>     
>>>>>           
>>>>>> document (see
>>>>>> http://fon.gs/spit-requirements)  that focuses purely on 
>>>>>>       
>>>>>>             
>>>>> requirements 
>>>>>     
>>>>>           
>>>>>> for authorization policies that are not distributed 
>>>>>>             
>>> between domains.
>>>       
>>>>>> I wonder what other people think about pushing policies 
>>>>>>             
>>> towards the 
>>>       
>>>>>> sender's domain.
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Sipping mailing list  
>>>>>>             
>>> https://www1.ietf.org/mailman/listinfo/sipping
>>>       
>>>>>> This list is for NEW development of the application of SIP Use 
>>>>>> [e-mail] for questions on 
>>>>>>             
>> current sip Use 
>>     
>>>>>> [e-mail] for new developments of core SIP
>>>>>>       
>>>>>>             
>>>>> -- 
>>>>> Juergen Quittek        [e-mail]       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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Sipping mailing list  
>>>>>           
>>> https://www1.ietf.org/mailman/listinfo/sipping
>>>       
>>>>> This list is for NEW development of the application of SIP 
>>>>> Use [e-mail] for questions on current 
>>>>> sip Use [e-mail] for new developments of core SIP
>>>>>
>>>>>     
>>>>>           
>>>       
>> ============================================================
>> Dr. Saverio Niccolini
>> Senior Research Staff Member
>> Network Laboratories, NEC Europe Ltd.
>> Kurfuerstenanlage 36, D-69115 Heidelberg
>> Tel.     [phone]
>> Fax:     [phone]
>> e-mail:  [e-mail]
>> ============================================================
>> NEC Europe Limited Registered Office: NEC House, 1 Victoria
>> Road, London W3 6BL Registered in England 2832014
>>
>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use [e-mail] for questions on current sip
>> Use [e-mail] for new developments of core SIP
>>
>>     
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>
>
> _______________________________________________
> spitstop mailing list
> [e-mail]
> https://listserv.netlab.nec.de/mailman/listinfo/spitstop
>   



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