Subject: RE: [Sipping] Consent: Do we need <operations>?

From: [email-masked]
Date: Tue, 8 Nov 2005 21:16:05 +0200

Hi,

I agree with Jonathan's comment. The main purpose of doing consent at the source (i.e., a relay in a different domain than where the recipient is) rather than at recipients home domain is to protect against amplification attacks. In that case it does not matter that much what actual content (INVITE, MESSAGE, ...) is carried, and that level of filtering can be left to recipients home domain or UAS.

Markus

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Jonathan Rosenberg
> Sent: 08 November, 2005 20:58
> To: Paul Kyzivat
> Cc: [email-masked]; Adam Roach
> Subject: Re: [Sipping] Consent: Do we need <operations>?
> 
> 
> 
> 
> Paul Kyzivat wrote:
> > I think it is reasonable to want to grant permission for IM but not 
> > voice. If MSRP is used, then restricting by method isn't a 
> viable way to 
> > do this.
> 
> I think we need to separate the use cases here.
> 
> The main one that is the focus of this work are relays 
> outside of your 
> administrative domain, to which you have been added as a 
> target. These 
> relays have little incentive at all to do much work on your 
> behalf. The 
> are only incented to send or not send traffic in order to protect 
> themselves against amplification attacks. Doing filtering on 
> behalf of 
> the subscriber seems to go beyond what they might be willing 
> to do. As 
> such, I think we should restrict this to just yes/no.
> 
> If there is a desire for more substantive filtering, that should be 
> treated more like a feature that runs on behalf of the 
> recipient on sip 
> servers in their own network. I think we decided that this 
> was separate 
> and not in scope here.
> 
> Thanks,
> Jonathan R.
> 
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Wed, 09 Nov 2005 18:03:15 +0100

Hi,
reading the requirements  document, I really though this kind of 
"filtering" operations would be taken into account in
Consent framework:

>  REQ 1: The solution must keep relays from delivering a SIP message to
>      a recipient unless the recipient has explicitly granted permission
>      for receipt of that type of message.
>   REQ 5: The permissions shall be capable of specifying that only
>      certain types of messages, such as INVITE or MESSAGE request, are
>      permitted from a user.

At first, it was possible to imagine an even more generic and "substantive filtering" framework:
why not design a consent document allowing advanced target/sender filtering (e.g. with Header key name/values
instead of just "identity") and a logical combination (or/and/not) of them?
In fact, I am not sure to understand Jonathan statement: "The main one that is the focus of this work are relays 
outside of your  administrative domain, to which you have been added as a  target.
These relays have little incentive at all to do much work on your behalf". 

If your administrative domain is supporting Consent, and you assume the "relay outside of your administrative domain" also support it
(your two domains are interoperating, supporting Consent) I do not see why this relay cannot support as much "advanced" filtering functions
as you.

In any case, I suppose removing <operations> mandates to update Requirements document to remove REQ 5 and modify REQ 1, ...
 
Thomas

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 9 Nov 2005 18:33:22 +0100

Thomas,

I would say that this '[...] even more generic and "substantive filtering" 
framework' would go beyond the purpose of the consent framework.

An argument for removing the <operations> could be the following: suppose 
you were to give permission to someone to send you INVITEs but not MESSAGEs 
via a given relay. That person could then simply send an INVITE, get your 
Contact, and then send you a MESSAGE directly. So this type of filtering 
logic at the relay could easily be bypassed.

That being said,  the XSD for consent documents (TBD I suppose) could allow 
extension elements. One could then add a "<sf:filter>" section as needed 
(something resembling initial filter criteria for example)

Jeroen

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 09, 2005 6:03 PM
Subject: Re: [Sipping] Consent: Do we need <operations>?

> why not design a consent document allowing advanced target/sender 
> filtering (e.g. with Header key name/values
> In fact, I am not sure to understand Jonathan statement: "The main one 
> that is the focus of this work are relays outside of your  administrative 
> domain, to which you have been added as a  target.
> If your administrative domain is supporting Consent, and you assume the 
> "relay outside of your administrative domain" also support it
> (your two domains are interoperating, supporting Consent) I do not see why 
> this relay cannot support as much "advanced" filtering functions
> as you.
>
> In any case, I suppose removing <operations> mandates to update 
> Requirements document to remove REQ 5 and modify REQ 1, ...
>
> Thomas
>
>>I agree with Jonathan's comment. The main purpose of doing consent at the 
>>source (i.e., a relay in a different domain than where the recipient is) 
>>rather than at recipients home domain is to protect against amplification 
>>attacks. In that case it does not matter that much what actual content 
>>(INVITE, MESSAGE, ...) is carried, and that level of filtering can be left 
>>to recipients home domain or UAS.
>>
>>Markus
>>
>>
>>>The main one that is the focus of this work are relays outside of your 
>>>administrative domain, to which you have been added as a target. These 
>>>relays have little incentive at all to do much work on your behalf. The 
>>>themselves against amplification attacks. Doing filtering on behalf of 
>>>the subscriber seems to go beyond what they might be willing to do. As 
>>>treated more like a feature that runs on behalf of the recipient on sip 
>>>servers in their own network. I think we decided that this was separate 
>>>and not in scope here.
>>>
>>>Thanks,
>>>Jonathan R.
>>>
>>>
>>>
>>>-- 
>>>Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
>>>Cisco Systems

---

From: [email-masked]
Date: Thu, 10 Nov 2005 13:39:02 +0100

see inline...

Jeroen van Bemmel wrote:

> Thomas,
>
> I would say that this '[...] even more generic and "substantive 
> filtering" framework' would go beyond the purpose of the consent 
> framework.

I agree with you, in fact I would say more:
if we want to perform substantive filtering operations, <operations> tag
is far from being sufficient, thus it is better to remove it from
current spec.
Next question for me is: do we need something more advanced than 
<operations> somewhere? (not in Consent framework).
I would be *very* interested to see IETF specifying a way to
make this kind of filtering operations. I think this kind of function
is actually at a different level than consent, since it could be
possible to ask a relay to perform different anti-spam operations,
depending on its preferences:
why not imagine a UA configuring an "anti-spam" XML document allowing to 
to ask a relay to either "Block" (blacklist), "Mark as spam", "Ask for 
Consent", or any other anti-spam technique ("Ask for Puzzle"?...).
Is there any track to specify this kind of things (reusing
draft-ietf-sipping-spam-01, and, I suppose, XCAP for the anti-spam XML
stuff...) ?

> An argument for removing the <operations> could be the following: 
> suppose you were to give permission to someone to send you INVITEs but 
> not MESSAGEs via a given relay. That person could then simply send an 
> INVITE, get your Contact, and then send you a MESSAGE directly. So 
> this type of filtering logic at the relay could easily be bypassed.

That's true, however, if we assume the caller is a spammer *and* he can
send you directly a SIP message without going through your relay, that
means you are already a really good target for spammers (any
port-scanning spammer will be able to reach you without any consent :)...)

Thomas

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 23 Nov 2005 15:06:27 +0200

Hi Thomas,

> Requirements document to remove REQ 5 and modify REQ 1, ...

yes, I will remove REQ 5 and modify REQ 1.

Thanks,

Gonzalo