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

[Hannes Tschofenig <[e-mail]>]

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.

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



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


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

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

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

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

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