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

[<[e-mail]>]

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.

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

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

>
>> 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.
>
>>>
>>> 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.
>
>>> - Req-C 7: how about timezone in addition to date&time information?
>>>   
>> Yes, I agree
>I also agree.
>
>>> - 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.

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

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

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

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

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