[Jingle] Comments on XEP-0251 standard

Dawid Nowak dawid.nowak at nortel.com
Mon Apr 27 04:56:41 CDT 2009


Hi, 

1.

"In jingle if Carol wants to avoid Mallory, she will deny the call
either way because the call request is comming from Mallory. That's the
entire point, the transfer in jingle does exactly what is says, notify
the other end where the real destination should be."


This is true if Carol knows Mallory, what if she doesn't know him and
she doesn't know that Mallory wants to ring her. All Mallory has to do
is to guess that Carol and Jane are friends and create a
"session-initiate" packet with transfer field from Jane. Such packet
will be valid and should get processed by Carol (ie. The software on
both switch and her PC should accept it). Now if Mallory is vicious
enough it will create as many of these packets as possible, flood the
switch with them and render Carol out of service. Without additional
intelligence the switch has no option as to pass it on.


As I mentioned in an earlier post :

The XEP0166 says that the error should be returned if :
	"The initiator is unknown to the responder and the responder
does not communicate with unknown entities."

When Callee receives "session-initiate" from an unknown user it might
drop it straight away, but than it will never know that the call has
been transferred as it would have to inspect the packet in order to find
the "transfer" part. 

If we accept that the call should be accepted only if Callee trusts the
person who initiated the transfer (Attendant) than Callee would have to
inspect every "session-initiate" packet in search for the "transfer"
part and reject the call only if the "transfer" part is not present.
This put extra responsibility on the client, is inefficient and
potentially can lead to abuse of trust.

If Callee accepts calls from unknown entities by default, than there is
no real need for the "transfer" part in "session-initiate". Surely, all
it has to happen is that Attendant gives Caller Callee's address.


2.
"There was a huge effort put into making jingle a better protocol than
SIP. I believe that it is wrong to make jingle as complicated as SIP."
Let's say I am not convinced about it. Jingle handles only a normal call
scenario at this stage. With SIP you can handle all complex call
scenarios ( 3rd party calls, call transfers, call conferences, call
forward). I would expect that Jingle will be as complex as SIP fairly
quickly if all these are to be supported.

3.
"I know that is hard in the beginning for implementors to handle some of
the tricky situations, but it's doable. The company I'm working for has
a jingle PBX with queues support that uses jingle presence and i know
from experience that it can be done."

"If you want to hide that, you should use an intelligent server as you
do in SIP with a smart proxy or a decent B2BUA"

Everything can be done, it is all just the matter of resources. From my
perspective I would rather have a good and safe protocol that gives
clear outlines on what to do, than rely on proprietary code and
intellingent or not switches to implement/or not all the necessary
safety features. 

4.
"Please remember that in jingle there is always a server on the way, and
always Carol is client to a server."
I suppose the SIP is using SIP proxies these days. Also as you pointed
out, there is always a switch so the switch should handle the access and
security aspects. If the switch can detect the potential breach it has a
chance to react early and hence the whole system is more secure and more
robust. If protocol is drafted in such a way that it will require an
action from the than ceratin safety policies can be enforced from the
beginning. 


Regards
D


-----Original Message-----
From: jingle-bounces at xmpp.org [mailto:jingle-bounces at xmpp.org] On Behalf
Of Diana Cionoiu
Sent: 24 April 2009 17:03
To: XMPP Jingle
Subject: Re: [Jingle] Comments on XEP-0251 standard

Hello Dawid,

I disagree with you.
In jingle if Carol wants to avoid Mallory, she will deny the call either
way because the call request is comming from Mallory. That's the entire
point, the transfer in jingle does exactly what is says, notify the
other end where the real destination should be. The rest of the
verification like for example if Carol is available for Mallory is done
by other parts of the XMPP protocol. If you want to hide that, you
should use an intelligent server as you do in SIP with a smart proxy or
a decent B2BUA.
Anyway for a call center you are suppose to use a B2BUA for other
several good reasons like early media.

There was a huge effort put into making jingle a better protocol than
SIP. I believe that it is wrong to make jingle as complicated as SIP.

I know that is hard in the beginning for implementors to handle some of
the tricky situations, but it's doable. The company I'm working for has
a jingle PBX with queues support that uses jingle presence and i know
from experience that it can be done.

Regards,
Diana Cionoiu

P.S. Please remember that in jingle there is always a server on the way,
and always Carol is client to a server.

Dawid Nowak wrote:
> Hi,
>
> This is a grea learning experience :) Anyway I don't think it will
make it any safer. To prove the point check "The Session Initiation
Protocol (SIP) Refer Method" Section 5.2 Authorization Considerations
for REFER. Here is a citation that higlights my point.
>
> 5.3.1 Circumventing Privacy
>
>    Suppose Alice has a user agent that accepts REFER requests to SIP
>    INVITE URIs, and NOTIFYs the referrer of the progress of the INVITE
>    by copying each response to the INVITE into the body of a NOTIFY.
>
>    Suppose further that Carol has a reason to avoid Mallory and has
>    configured her system at her proxy to only accept calls from a
>    certain set of people she trusts (including Alice), so that Mallory
>    doesn't learn when she's around, or what user agent she's actually
>    using.
>
>    Mallory can send a REFER to Alice, with a Refer-To URI indicating
>    Carol.  If Alice can reach Carol, the 200 OK Carol sends gets
>    returned to Mallory in a NOTIFY, letting him know not only that
Carol
>    is around, but also the IP address of the agent she's using.
>
> Also SIP relies on Proxies where a proxy can interpret, and, if
necessary, rewrite specific parts of a request message before forwarding
it. 
>
> My problem with this is that the protocol is not secure and we have to
rely on intelligent servers to make the whole system secure. If the
protocol was secured that the intelligent servers could be less
intelligent and less complex I think. Also since implementation of
servers is not standardized some servers are better than others but as a
customer I don't really have knowledge about it. Where as if safety
mechanisms are put into the protocol all entities would have to
implement the same set of functionality.
>
> Regards
> D
>
> -----Original Message-----
> From: jingle-bounces at xmpp.org [mailto:jingle-bounces at xmpp.org] On 
> Behalf Of Unnikrishnan V
> Sent: 23 April 2009 20:18
> To: XMPP Jingle
> Subject: Re: [Jingle] Comments on XEP-0251 standard
>
> Have look on
> http://www.tech-invite.com/Ti-sip-service-5.html
>
> and
>
> http://www.tech-invite.com/Ti-sip-service-4.html
>
> As  a standard, the missing thing may be the notification after
disconnect of the call.
>
> thanx
> unni
>
>   



More information about the Jingle mailing list