[Standards-JIG] Jingle vs. Zoep

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Tue Feb 14 09:16:34 UTC 2006

It is perfectly true that there is nothing similar to schema validation on
the SIP side, and that validating SIP parsers are still to come ;) On the
SIP side, the SIP stack usually takes care of validating the syntax and
grammar of the headers, and maybe the Zoep stack has been enhanced to do a
little more (as they said they developed their own stack). But even with a
schema validating XML parser, you only ensure the XML correctness. Real
control usually needs application level validation beyond this. And when the
application is needed, I do not see any difference checking the packets
content once we have ensured the protocol grammar validity. In a properly
designed application, the transport layer would have been abstracted anyway,
and we would be using abstract objects. Am I missing something here?

That said, going back to the context of P2P communication between two Zoep
clients, the stanza SIP payload will be going through the SIP stack anyway,
and the target client could easily apply simple checks, such correlating the
from JID with the From URI of the SIP request (and more...) As the from JID
is supposed to be valid per XMPP, it will bring a certain level of
confidence. I am not saying this also applies to the SDP payload within the
SIP packet.
To that effect, I would be interested to know what you define as '
potensially malicious content" in this context?

Now, if this control is done 'a priory', this same validation would have to
be carried out at the ingress into the XMPP network. This in turn would
require that the client connector implements the SIP validation, and
correlate properly the address as it is required to do for XMPP. This would
definitively result in a 'complex' implementation ;)

We also know other ways to guarantee content has not been modified, such as
signature. This also adds complexity (but isn't security achieved at this

The major drawback I see in the Zoep approach is that in XMPP, the client
does not have to know it's own JID. The connector needs to know the
connected client JID in order to ensure the from. In SIP the client has to
know the SIP AOR (address of record) because SIP is not deriving any state
from the connection as XMPP does. The major issue Zoep is facing is in fact
the addressing part. And I am not only mentioning the invalid syntax
incurred by just adding "sip:" in front of a fully qualified JID... 
This may be without consequence in a P2P scenario, but when dealing with
gateways to SIP, or dealing with different XMPP and SIP address handles, it
is an altogether different story.


-----Original Message-----
Message: 3
Date: Tue, 14 Feb 2006 01:57:06 +0000
From: Richard Dobson <richard at dobson-i.net>
Subject: Re: [Standards-JIG] Jingle vs. Zoep
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <43F138F2.9060309 at dobson-i.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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

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

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

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


More information about the Standards mailing list