Re: [Sipping] SPITSTOP: Requirements for Authorization Policies to tackle Spam for Internet Telephony and Unwanted Traffic

[Hannes Tschofenig <[e-mail]>]

Hi Thomas,
Hi Eva,

I have updated the draft based on this discussion. Here is the updated 
version:
http://www.tschofenig.priv.at/svn/draft-froment-sipping-spit-authz-policies/draft-froment-sipping-spit-requirements-01.txt

Please find a few minor comments below:

[e-mail] wrote:
> Hi Hannes and Thomas,
>
> Thanks for you answers. Please see inline (marked with Eva:).
>
> BR, Eva
>
>   
>> -----Original Message-----
>> From: ext Hannes Tschofenig [mailto:[e-mail]] 
>> Sent: 28 June, 2007 15:12
>> To: Thomas Froment
>> Cc: Leppanen Eva (NSN - FI/Tampere); [e-mail]
>> Subject: Re: [Sipping] SPITSTOP: Requirements for 
>> Authorization Policies to tackle Spam for Internet Telephony 
>> and Unwanted Traffic
>>
>> Hi Thomas,
>> Hi Eva,
>>
>> Thomas Froment wrote:
>>     
>>> Hi eva,
>>> here are some thoughts on your suggestions...
>>> [e-mail] wrote:
>>>       
>>>> Hi all,
>>>>
>>>> Section 3.1: new requirements to be considered (for discussion):
>>>> - Req-C x: Policies SHOULD allow usage of external user lists, e.g.
>>>> usage of address book or resource lists.
>>>>   
>>>>         
>>> I don't succeed in understanding the use case here, could 
>>>       
>> you give an 
>>     
>>> example?
>>>       
>> Eva, I guess you need to explain this aspect.
>>     
>
> Eva: if the user has existing user or contact lists available, they
> could be directly referred to from the policy. E.g. already existing
> resource lists created for presence list subscriptions. If the lists are
> added by references, the user just do not need to keep several versions
> of the lists up-to-date.
>   

I have not yet added anything regarding this proposal. I need more time 
to figure out how it could work.

>   
>>>> - Req-C x: Policies SHOULD allow an anonymous identity as a 
>>>>         
>> condition.
>>     
>>>>   
>>>>         
>>> This one makes sense to me...
>>>       
>> We had this discussion in the context of Common Policy in the past. We 
>> initially had an element that referred to "anonymous identities".
>> The problem was just what it actually means.
>>
>> It can mean two things:
>>
>> a) The identity of a particular user was obfuscated by the privacy 
>> mechanisms when used together with SIP Identity. Then, you still have 
>> the domain you can look at even though the individual user is not 
>> identifiable anymore. The existing policies already provide 
>> support for 
>> this.
>>
>> b) If neither  the username nor the domain name was authenticated then 
>> the "anonymous user" is equal to the unauthenticated. This is also 
>> provided by the current specification.
>>
>> So, which of the two cases do you have in mind and what additional 
>> functionality is needed ?
>>
>>     
>
> Eva: I quess that I ment the option a); the requests that are indicated
> as anonymous would match. 
> But, if you see that this is already covered well enough, ok for me.
>
>   
I have added this requirement since my response was referring to a 
solution rather than the requirement itself.
Hence, I believe that the requirement is valid.

>>     
>>>> - Req-C x: Policies SHOULD allow the Subject header field value or a
>>>> part of the value to be used as a condition. - 
>>>>         
>> Additionally, it could 
>>     
>>>> be required that the user is able to define a
>>>> default rule (= action) which matches when no else rule is 
>>>>         
>> applied. (I
>>     
>>>> know that there are issues with this in the common-policy.) 
>>>>         
>>> I clearly see the use case here but previous version of requirements 
>>> draft was "opening the door" to any header value as 
>>>       
>> condition: I think 
>>     
>>> this is not the direction right now. Waiting for comments from 
>>> Framework authors to decide if this one fit or NOT in the 
>>>       
>> requirement 
>>     
>>> draft...
>>>
>>>       
>> It is true that we might need to provide some form of 
>> treatment based on 
>> the occurrence of specific fields. We had quite a bit of 
>> discussion and 
>> disagreement within the group of authors. For me the challenging part 
>> was to identify which fields are relevant. Thomas was more in favor of 
>> providing an extensively mechanism that allowed you to have something 
>> like "function-name" ( "fieldname", "value" ) [if I recall our 
>> discussion correctly].
>>
>>     
>
> Eva: After thinking further, maybe the subject field is not that
> important if we think about SPIT.
>   

Nothing added .

>   
>>> Same remark for the default rule which was part of initial draft and 
>>> was removed...
>>>       
>> We can put the default rule back into the document.
>>
>>     
>>>> - "Sphere" was mentioned in the corresponding framework 
>>>>         
>> I-D, but I did
>>     
>>>> not find any requirements for it. I personally don't see it that
>>>> important, but could be anyway mentioned when included in 
>>>>         
>> the framework.
>>     
>>>> The requirements could be something like: "Req-C: Policies 
>>>>         
>> MAY allow to
>>     
>>>> make decisions based on the current state of the user. E.g. 
>>>>         
>> based on a
>>     
>>>> user selected active profile, or sphere or other presence 
>>>>         
>> information."
>> Right. We forgot that.
>>
>> Sphere is nice since it allows you to switch the entire ruleset quite 
>> quickly depending on the environment you are in.
>>     

Added this requirement

>>     
>>>> Comments to the existing requirements:
>>>> - Req-C 6: In addition to SIP method, also the content type and/or
>>>> offered (or used) media of the request SHOULD be allowed as 
>>>>         
>> condition.   
>>     
>>> Same remark as for "Subject header"...
>>>       
>> That sounds good to me.
>>     

Added.

>>     
>>>> - Req-C 7: how about timezone in addition to date&time information?
>>>>   
>>>>         
>>> Yes, I agree
>>>       
>> I also agree.
>>
>>     
Added.

>>>> - Req-C 9: Also authentication method could be a condition.
>>>>  
>>>>         
>> We had this discussion in the GEOPRIV working group a couple of years 
>> back. Initially this was even part of Common Policy.
>> The problem was just the type of conclusions you could draw from that 
>> info. I can see it being useful in certain environment where the end 
>> host is not really a user but rather a server that performs different 
>> actions based on the type of authentication you performed but for a 
>> human I am not so sure whether it makes a big difference whether the 
>> other end was authenticated using digest or TLS. It would be more 
>> important to know how difficult it was to create the account; this was 
>> one of the mechanisms listed in 
>> draft-schwartz-sipping-spit-saml-00.txt.
>>     
>
> Eva: Ok for me to leave it out.
>   
Omitted it for the moment.

>   
>>> Section 3.2:
>>>       
>>>> Req-A 6:  In addition to e-mail, SMS and MMS, also "other 
>>>>         
>> notifications"
>>     
>>>> could be supported.
>>>>
>>>> In general, it'd be good to mention how the actions relate to each
>>>> other. E.g. if the redirection and notification can be both applied.
>>>> And, e.g., which actions exclude each other.
>>>>         
>> We really need to investigate this as part of the conflict resolution 
>> procedure.
>> I, however, believe that this does not need to be described in a 
>> requirements draft since this is more or less dependent on the 
>> specific 
>> solution.
>>     
>
> Eva: on the other hand, this is a matter which is seen by the "end
> user". Namely, which kind of functions are needed from the solution,
> e.g. is there a need to send an additional notification when a request
> gets blocked or forwarded. Of course, technical issues are solved in
> other documents. Anyway, I'll leave the decision to you.
>
>   
Added a small note.

>>>> For example, "blocked", "politely blocked", "pending (=SPIT
>>>> text/consent)", "redirect" and "allowed" could be thought to exclude
>>>> each other. And "notification" and "mark" could be applied 
>>>>         
>> parallel to
>>     
>>>> those. On the other hand, redirect could also be seen as a parallel
>>>> operation.
>>>>   
>>>>         
>>> Nice feature, but isn't it too complex?
>>> On the question of "other notifications"  I have some 
>>>       
>> difficulties to 
>>     
>>> accept designing a system with a non-extensible set of actions...
>>>       
>
> Eva: I was mostly thinking about e.g. SIP MESSAGE or other possible SIP
> specific notifications.
>   
I don't think that these issues belong into the requirements draft. They 
are solution specific and we need to deal with them as part of the 
conflict resolution mechanism.

>   
>>>> Section 3.3: new requirement to be considered:
>>>> - Req-T 2: Policies MAY allow SIP message modifications, 
>>>>         
>> e.g. filtering
>>     
>>>> binary objects or contents of bodies of SIP messages.
>>>>   
>>>>         
>>> again, was in initial document and voluntarily removed...
>>>       
>> SIP does not allow SIP proxies to remove content from the SIP body.
>>     
>
> Eva: ok.
>   
Nothing added.

>   
>>>> Section 3.4:
>>>> Comments to the following requirements:
>>>> - Req-G 1: This could be explained more. E.g. what would be the real
>>>> "end user" requirement? Or, what additional value the hierarchy 
>>>> brings?   
>>>>         
>>> Actually, hierarchies of policies seems a very complex requirement
>>>       
>> I could imagine that it is quite likely that you will have a hierarchy 
>> of policies.
>> Consider a company environment. There are policies from the 
>> sysadmin and 
>> your own policies.
>>
>>     
Added a note.

>>>> - Req-G 4: does this cover discovering supported capabilities (e.g.
>>>> which extensions are supported and understood by a network element)?
>>>>
>>>>         
>> Req-G 4: The policies MUST provide a mandatory-to-implement conflict 
>> resolution mechanism.
>>
>> This does not relate to the supported capability.
>>
>> There needs to be a way to discover the supported capability.
>>
>>     
>>>> Proposal for a new requirement: "Req-G X: The policies MUST allow
>>>> several Rule Makers for a policy
>>>>         
>>> What is your definition of Rules Makers, do you mean several actors?
>>>       
>> RFC 3693 defines these terms.
>>
>> Why do you need multiple rule makers to update the policy?
>>     
>
> Eva: e.g. operator, end user, several devices of the end user. 
>
>   
Is there a specific impact for the policies itself?
To me this rather seems quite loosely coupled to the authorization 
policies itself and might be an issue for XCAP.

Ciao
Hannes
>> Ciao
>> Hannes
>>
>>     
>>> Thomas
>>>       
>>     



_______________________________________________
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