Subject: [Sipping] Issues with draft-ietf-sipping-consent-framework-03.txt

From: [email-masked]
Date: Tue, 08 Nov 2005 08:09:10 +0100

Hello,
I'm studying the draft sipping-consent-framework as a possible way to 
fight SPAM, and I have some questions about it.

1. In the "Two-party Scenario", if the UAC doesn't start the 
communication by sending a CONSENT message, what will be the case if the 
UAC is a spammer, what does have the UAS to do? The biggest problem is: 
  if an UAS is able to identify a spammer so as to return him a "470 
Consent Needed", he can as well just avoid returning the 100 Trying/180 
Ringing, and ban this spammer (!)... Note: I do not talk about the case 
where a permission server is deployed, I only try to understand what 
*could* be the usage of a two party scenario, is there any?

2. A first problem between the 'Consent Requirements' and the 'Consent 
Framework':
'Consent Requirements' says
"REQ 19: The solution should not, in and of itself, create substantial 
additional messaging.  Doing so defeats some of the purpose of the 
solution."

However, 'Consent Framework' says:
"A user adds a large number of URIs to a relay's translation rules and 
has the relay request permissions for all of them.  In this case, the 
relay would generate a large number of CONSENT requests and send them to 
the URIs provided by the user.  These URIs are the victims of the 
attack. To prevent this attack, a user adding URIs to a relays 
translation rules is requested to generate an amount of bandwidth that 
is comparable with the bandwidth the relay will generate to request 
permissions for those URIs.  The user needs to send a REFER request to 
the relay for each recipient URI.  Each REFER request requests the relay 
to generate a CONSENT request towards one of the recipient URIs."

This technique generates a lot of traffic! It seems to me that there is 
a paradox: the spammer is forced to generate traffic to avoid the 
"amplification problem", but this leads to violate the 'Consent 
Requirements'! On the other hand, respecting the 'Consent Requirements' 
opens a vulnerability to a potential attack!

4. A second problem with 'Consent Requirements' and 'Consent Framework':
The classic schema of a registration "creates some potential attacks 
which relate to third-party registrations". To correct it, CONSENT is 
used in the schema. However, this leads to an increase of the number of 
messages, 12 instead of 2!!! This move to counter an attack 
vulnerability leads again to violate previously described 'Consent 
Requirement'.

I would humbly suggest two ideas to solve the "amplification prevention":

1. The method used to add recipients to a diffusion list is XCAP. We 
would extend XCAP to force a user to add a limited number of recipients 
(1, 2 or 3) to his list. If he tries to add 500,000 users through a 
single request, we would use the "constraint failure (or another [TO BE 
DEFINED] error code)" from the XCAP draft to answer "too many users 
added in only one request".    In a classic case, a spammer could send 
500,000 "Add recipients", and we would have the same problem as before. 
But since XCAP requests are ITERATIVE, a given thread cannot send 
another "Add Recipient" before having received the answer to the 
previous request. It would slow down the "Add Recipient" speed without 
flooding the XCAP server.

2. Why not use the "throttle" technique to avoid a server to receive 
multiple copies of the same requests, when these requests are sent 
during a short interval of time. If, lets' say '15,' identical requests 
are sent within a short time interval, the server will only receive one 
of them. With this technique, even if the spammer tries to flood a 
server, it won't be possible.

Any thoughts?

Thank you very much and best regards,
Geoffrey Dawirs

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Wed, 23 Nov 2005 15:05:23 +0200

Hi Geoffrey,

> *could* be the usage of a two party scenario, is there any?

As you suggest, the two-party scenario with no relay is not very 
interesting. A 470 would inform a well-behaved client that it needs to 
obtain permission.

> additional messaging.  Doing so defeats some of the purpose of the 

The spirit of REQ 19 was to avoid relays sending too much traffic to 
recipients in order to ask for consent. However, that is already stated 
in a clearer way in REQ 2. Therefore, I will go ahead remove REQ 19.

Thanks,

Gonzalo