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

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 16 Jun 2007 16:03:34 +0200

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 17 Jun 2007 14:29:44 +0200

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

-- 
Juergen Quittek        [email-masked]       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

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 19 Jun 2007 13:25:26 +0200

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
-- messages explaining to the sender domain why the message was blocked

I clearly see these two points having priority over the authorization
polices when it comes to pushing info towards the sender domain.

Cheers,
Saverio

============================================================
Dr. Saverio Niccolini
Senior Research Staff Member
Network Laboratories, NEC Europe Ltd.
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
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

> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> 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
> It is good that you replaced 
> draft-froment-sipping-spit-authz-policies with 
> > when reading through the documents I came across the following 
> > statement in <draft-niccolini-sipping-spitstop-00.txt>:
> >
> > "
> > <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
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> 
> 
> 
> -- 
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL, 
> UK Registered in England 2832014
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 23 Jun 2007 18:53:55 +0200

Hi Saverio,

> -- info related to SPIT estimations

Have you looked at the following document 
http://www.tschofenig.priv.at/drafts/draft-schwartz-sipping-spit-saml-00.txt
Is this close to the mechanisms you have in mind?
(ignore the encoding in a SAML assertion for a moment)
> -- 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?
> 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

Ciao
Hannes

>>>    Please note that the described reference scenario does 
>>>       
>> not addresses
>>     
>>> <draft-froment-sipping-spit-authz-policies-02.txt> got 
>>>       
>> misunderstood.
>>     
>>> http://fon.gs/spit-requirements)  that focuses purely on 
>>>       
>> requirements 
>>

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 26 Jun 2007 13:45:52 +0200

Hannes,

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

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

> individual calls or on an aggregate

I agree on this.

Cheers,
Saverio

> >>> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 26 Jun 2007 14:26:28 +0200

Hi Saverio, 

> anyway I think more can be added, maybe we can find time at next IETF

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

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

Ciao
Hannes

---

From: "Jeremy Barkan \(DigitalShtick\)" <[email-masked]>
Date: Wed, 27 Jun 2007 13:22:55 +0300

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

-----Original Message-----
From: Tschofenig, Hannes [mailto:[email-masked]] 
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, 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 28 Jun 2007 13:30:14 +0200

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

Ciao
Hannes

>>>> as you are saying, the authorization policies are just a 
>>>>         
>>> special case
>>>       
>>>> -- messages explaining to the sender domain why the message 
>>>>         
>>> was blocked
>>>       
>>>>   
>>>>         
>>> Is this your intention or to share blacklists between the 
>>>       
>> two domains?
>>
>>>> I clearly see these two points having priority over the 
>>>>         
>>> authorization
>>>       
>>> In some sense this is quite similar to "authorization" 
>>>       
>> policies. The 
>>     
>>>>> Subject: Re: [Sipping] Pushing Policies towards the 
>>>>>           
>> Sender's Domain
>>     
>>>>> Hi Hannes,
>>>>>
>>>>>>    management interfaces to entities involved in SPIT 
>>>>>>             
>>> prevention.  A
>>>       
>>>>>> <draft-froment-sipping-spit-authz-policies-02.txt> that 
>>>>>>             
>>> envisioned 
>>>       
>>>>>> in particular towards the sender's domain. There is 
>>>>>>             
>> obviously the 
>>     
>>>>>> priority list for work that has to be done in the SPIT 
>>>>>>             
>> prevention 
>>     
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> [email-masked] for questions on 
>>>>>>             
>> current sip Use 
>>     
> spitstop mailing list
> [email-masked]
> https://listserv.netlab.nec.de/mailman/listinfo/spitstop
>