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

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

Hi all,

we have just submitted a new draft on "Requirements for Authorization 
Policies to tackle Spam for Internet Telephony and Unwanted Traffic". 
Please find the document here: http://fon.gs/spit-requirements

This document replaces <draft-froment-sipping-spit-authz-policies-02.txt>.

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: <[email-masked]>
Date: Mon, 25 Jun 2007 11:42:51 +0300

Hi all,

A couple of comments and proposals for new requirements for discussion
as follows. 
(Note that I've provided some additional editorials directly to Hannes.)

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.
- Req-C x: Policies SHOULD allow an anonymous identity as a condition.
- 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.) 
- "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."

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. 
- Req-C 7: how about timezone in addition to date&time information?
- Req-C 9: Also authentication method could be a condition.

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.

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.

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.

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? 

- Req-G 4: does this cover discovering supported capabilities (e.g.
which extensions are supported and understood by a network element)?

Proposal for a new requirement: "Req-G X: The policies MUST allow
several Rule Makers for a policy."

BR, Eva Leppanen

>-----Original Message-----
>From: ext Hannes Tschofenig [mailto:[email-masked]] 
>Sent: 14 June, 2007 14:29
>To: SIPPING LIST
>Subject: [Sipping] Requirements for Authorization Policies to 
>tackle Spam for Internet Telephony and Unwanted Traffic
>
>Hi all,
>
>This document replaces 
><draft-froment-sipping-spit-authz-policies-02.txt>.
>
>Ciao
>Hannes

---

From: Thomas Froment <[email-masked]>
Date: Wed, 27 Jun 2007 15:08:02 +0200

Hi eva,
here are some thoughts on your suggestions...
> usage of address book or resource lists.
I don't succeed in understanding the use case here, could you give an 
example?
> - Req-C x: Policies SHOULD allow an anonymous identity as a condition.
This one makes sense to me...
> 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...

Same remark for the default rule which was part of initial draft and was 
removed...
> offered (or used) media of the request SHOULD be allowed as condition. 
Same remark as for "Subject header"...
> - Req-C 7: how about timezone in addition to date&time information?
Yes, I agree
> those. On the other hand, redirect could also be seen as a parallel
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...
> binary objects or contents of bodies of SIP messages.
again, was in initial document and voluntarily removed...
> "end user" requirement? Or, what additional value the hierarchy brings? 
Actually, hierarchies of policies seems a very complex requirement
> several Rule Makers for a policy
What is your definition of Rules Makers, do you mean several actors?

Thomas

---

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

Hi Thomas,
Hi Eva,

> I don't succeed in understanding the use case here, could you give an 
Eva, I guess you need to explain this aspect.

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

>> part of the value to be used as a condition. - Additionally, it could 
>> be required that the user is able to define a
> 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.

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

> Same remark as for "Subject header"...
That sounds good to me.

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

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

> again, was in initial document and voluntarily removed...

SIP does not allow SIP proxies to remove content from the SIP body.

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

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

> 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