[OpenSIPS-Users] RLS services content validation?

[Iñaki Baz Castillo]

El Jueves, 9 de Julio de 2009, Adrian Georgescu escribió:

> Scenario 1
>
> 1. I upload a million entry list of SIP uris into a rls-services
> document on the xcap server
> 2. I send a Subscribe to the address of the list I uploaded above
> 3. The server starts sending one million Subscribes amplifying my
> single SIP subscribe into a DOS attack on its own resources or a
> foreign domain

Solution 1: Validate document on the XCAP server (already possible in 
OpenXCAP) and reject it if it has more than XXX entries (configurable).

Solution 2: Set the limit in the PU, so it will never generate more than XXX 
subscriptions per RLS.



> Scenario 2
>
> 1. I create a RLS list with pointers to resource lists document (which
> are HTTP URIs) to other domains
> 2. I send a Subscribe to the list
> 3. The server starts sending one million HTTP GETS amplifying my
> single SIP Subscribe into a DOS attack on its own resources or a
> foreign HTTP domain

I can't understand the purpose of HTTP URI's here. Even if IETF documents 
define URI's in a very happy manner (by allowing *any* kind of URI) the fact 
is that a SIP SUBSCRIBE is just allowed for a presentity with scheme sip, tel? 
or press.
Being realistic I would ignore other URI's.

Solution 1: PU ignores "exotic" URI's (however it coudln't send the 
subscription there).

Solution 2: The XCAP server rejects a RLS with "happy" URI's.


> Scenario 3
>
> 1. I simply upload bogus data like bogus SIP URIs that might not
> resolve or point back to the server rls-services lists generating
> loops imposible to detect the reasons for
> 2. The server kills itself Subscribing to itself

Solution 1: The PA doesn't subscribe to the same list identifier (list SIP 
URI) when readin it from that list.

Solution 2: The XCAP server rejects the creation of a RLS if the name of the 
list (a SIP URI) is in fact an entry of the list. Well, not 100% correct, but 
you understand me :)



Just my 2 €


-- 
Iñaki Baz Castillo <ibc at aliax.net>