[Standards-JIG] Jingle vs. Zoep

dirk.griffioen@voipster.com dgriffioen at voipster.com
Wed Feb 15 23:08:23 UTC 2006

Richard Dobson wrote:

>>>> 4. Content validation. Some very significant adopters of XMPP like the
>>>> technology because it is pure XML and they can validate all the XML 
>>>> that
>>>> flows across the wire using standard XML tools. It is much more
>>>> difficult to parse SIP as it goes over the wire (yes, there are
>>>> SIP-specific firewall products, but they are specialized and 
>>>> expensive).
>>>> So if we send SIP over XMPP, it is quite likely that these adopters 
>>>> will
>>>> not use it.
>>> There is also the fact that if you are just wrapping the SIP packets 
>>> without validating them somehow and simply passing them to a SIP 
>>> stack, so you have no control (without adding lots of complexity to 
>>> the code to validate the SIP packets which voids the benefits of 
>>> just blindly passing the SIP packets to the SIP stack and allowing 
>>> it to deal with it) over what the other end will ask your SIP stack 
>>> to do, it also opens up quite a large surface for attack (i.e. a 
>>> whole SIP stack, which is what I would expect most people would use 
>>> with this kind of solution).
>> Would this not apply for every payload in the XMPP world?
> Not really no, the vast majority of protocols can be quickly and 
> easily validated against an XML schema and dropped if they arnt valid, 
> SIP packets cant. To validate those you would have to add a SIP packet 
> parser to your application, rather than just being able to use the 
> existing built in functions of your XML parser.

Can I refer to the remarks of Jean-Louis? Validating XML is only syntax, 
not application level.

>> And secondly, the application is in charge of the SIP stack over a 
>> secure connection. Not the user.  The is no way to inject malicious
>> content:
> Urm yes there is, if you arnt validating the packets before you pass 
> them to the SIP stack anyone can send potensially malicious content as 
> there is nothing in place to prevent that.
How? There is no 'door' to open. The connection is secure, the user 
cannot pass data to the SIP-stack; sure if you reengineer or patch the 
binary, then you maybe could - but then what? The SIP stack is rather 
robust, and validates ... It's not like you will be able to do buffer 
overruns or anything (I guess).

And for hijacking addresses, adding checks is possible:
- correleation of JID with URI
- extra lookups of either with a trusted party on gateway level
- more funky security stuff

To cut things short, I dont 'see' your concern as much

>> with pc2pc the SIP address is the same as the XMPP JID (all rules 
>> apply), for pc2pstn only qualified numbers are allowed (things like 
>> 00 44 123456789).
> Huh? Im confused, what does this have to do with validating the SIP 
> packets?
It tries to show validating is not really needed.

>>> To make this solution secure as far as I can see would make it 
>>> rather complex, i.e. you would have to add in parsers to validate 
>>> the SIP packets either in the XMPP layer before they get passed to 
>>> the SIP layer or will need to modify the SIP stack to add this stuff 
>>> in.
>> Why the duplication? The sip stack WILL parse & validate messages - 
>> which means the message passed
> Because you cant trust the SIP stack to validate its own messages if 
> its just standard SIP stack, as there are all sorts of security 
> problems with a default implementation like the lack of a required 
> validated from address, there are all sorts of things like that which 
> you will want to prevent your SIP stack from being able to do which 
> are perfectly valid things for the SIP stack to do, but there are 
> things you would never want it to be able to do because of the 
> security problems people have already pointed out that you have yet to 
> respond to, and the only way to prevent these things would be to as I 
> pointed out validate the SIP packets before they get to the SIP stack, 
> or alter the SIP stack to perform this validation.
On a pc2pc level I would argue there is no security issue more then XMPP 

And for pc2pstn, Jingle does not know how to do this either, so lets try 
to figure out how to do that ...


> Richard

More information about the Standards mailing list