[Standards-JIG] Jingle vs. Zoep

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


Jean-Louis Seguineau wrote:

>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?
>
>  
>
No - this was, less eloquent, my point exactly in an earlier mail.

>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?
>
>  
>
Same here.

>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
>cost?).
>
Would then signing the payload be an idea?  And to  make key exchange 
part of the session setup? We were thinking along those lines: to get 
secure streams, we would need key exchange anyway - so why not extend 
that to signalling?

> 
>
>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.
>
>  
>
Couldn't a naive gateway handle this something like:
pstnout:

pstnin:

In the case of  pc2pc, once again, the sip stack is only used for 
state&callback. So there are no addressing issues other then XMPP itself 
has.

>Jean-Louis
>
>-----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.
>
>Richard
>
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060216/6896b931/attachment.html>


More information about the Standards mailing list