[Devel] [ openser-Patches-1642890 ] 'bye2bye' UA module prototype

[SourceForge.net]

Patches item #1642890, was opened at 2007-01-23 12:41
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1642890&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver devel
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kobi Eshun (ekobi)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'bye2bye' UA module prototype

Initial Comment:
Hi,

Attached are two patches implementing a prototype 'bye2bye' UA module that cheaply fakes end-to-end BYE requests -- it's a watchdog that enforces metered call duration. One of the patches augments the existing dialog module so that it caches to/from contact and CSeq values; the other implements the new module.

I'm soliciting feedback, in particular:

Q1 - is there enough general interest in this functionality to warrant further development?

Q2 - is there some additional functionality that makes sense?

Q3 - would it be better implemented as an integrated extention to the existing dialog module?

Use of the module is very straightforward:

- Define the module flag parameter that will enable the watchdog on a per-dialog basis. This is used in conjunction with the dialog module flag defined by 'dlg_flag.'

- Optionally define the module parameters 'bye2bye_headers,' 'bye2bye_to_next_hop,' and 'bye2bye_from_next_hop.'

- set the value of the dialog 'timeout_avp' as required for each dialog that will be monitored.
--
kobi

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-01-25 02:19

Message:
Logged In: NO 

Hello Klaus, Bogdan, Dan, everyone :-)

I would say that what Klaus is saying makes great sense, however I think
the "I want a system that cannot be hacked, not one that punishes you when
you try to hack it." part is a bit pointless an polemical. We could argue
on that for days, so I would advise to let that part go away. What matters,
I believe, is in that order :

- robustness (a corrolary of which is RFC compliance, an other one
security)
- performance (historically, SER/OpenSER systems based a large part of
their popularity on that)
- functionnality

IMHO, Klaus suggestion is a better approach as it is more
RFC3261-compliant than what we have ( quote from the RFC : "The combination
of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP
relationship [...] and is referred to as a dialog.") and gives us some
additional peace of mind about dialog-matching robustness.

However, the question is "What is the performance overhead of Klaus
suggestion vs. cookie matching + double check". I consider the cookie part
as being only an implementation artifact, acceptable if it helps getting
better performances and does not limit RFC compliance. So I would say can't
we just add tags checks after cookie-matching ? What are the implications
?

The remaining problem is what to do for in-dialog REQUESTs lacking the
cookie ? I would be tempted to add an OPTIONAL compatibility mode ONLY if
we can find some popular AND broken UACs/UASs that remove some RR parts,
but that would be soooo damn broken that I doubt we find any widely-spread
products which behave so badly. That mode would just deactivate the
cookie-related stuff and just plain check dialog Call-ID + tags. But the
default behaviour should IMNSHO be to drop those REQUESTs, terminate the
dialog, and send the special "666 Burn in hell" answer code to the faulty
UA.

Cheers,
Jerome

----------------------------------------------------------------------

Comment By: Dan (dan_pascu)
Date: 2007-01-24 12:27

Message:
Logged In: YES 
user_id=1296758
Originator: NO

The problem is that I do not want to reject requests that do not have the
cookie. I want a system that cannot be hacked, not one that punishes you
when you try to hack it. Those requests are valid in-dialog requests and if
I drop them the call setup will be affected. Moreover I have no idea if the
user is trying to hack the system by manipulating the cookie, or it is just
an implementation that is flawed and doesn't copy all the parameters from
the Request-Route in the subsequent Route headers.

And a system that is based around a parameter that is part of the message
and can be altered by the endpoints is not a secure system by any means. No
matter how many checks you put around that cookie.

Moreover, not including the cookie is not the only way to try to fool the
system. I can for example start 2 dialogs. One being a prepaid call and the
other being a SIP-to-SIP call which is free. I can then use the cookie from
the free call into re-INVITE requests from the prepaid call fooling the
system believe that they belong to the free call. Thus the proxy will be
unable to generate valid BYE requests for the prepaid call when the credit
will expire because it's knowledge of the CSeq will be invalid.

Now you may say that you can activate the call-id check as well and it
won't be fooled, but then again, you compare the cookie and the call-id,
how is that more expensive than comparing the call-id and the from-tag
which is what is needed to do server based dialog identification without
relying on user modifiable cookies in the requests. Even more, with the
cookie+call-id checks, you can only detect that the request was manipulated
and doesn't belong to the dialog it claims to belong to, but you still do
not know to which dialog it realy belongs to and will be left with only 1
choice: to reject it, which is not a good choice.

However, if real dialog identification is performed in the server that
won't be more expensive than the cookie+call-id checks and will be much
more secure allowing me to have a system that cannot be hacked and I do not
have to worry about rejecting requests because they look like possible
forging attempts.

As I said in the beginning, a good system IMO is one that doesn't give you
the oportunity to hack it, not one that leaves doors open but punishes you
if you try to use them.


----------------------------------------------------------------------

Comment By: Bogdan (bogdan_iancu)
Date: 2007-01-24 09:59

Message:
Logged In: YES 
user_id=1275325
Originator: NO

First, Jerome, sorry for the mix up :(...

Secondly, Klaus, you can already have this behaviour with the current
impl. .If a sequential dialog does notmatch to any current dialogs (cookie
and/no tight matching), you can check from script the PV $DLG_status - this
this doee not exists, just negatively reply.

regards,
bogdan

----------------------------------------------------------------------

Comment By: Klaus Darilion (klaus_darilion)
Date: 2007-01-24 07:52

Message:
Logged In: YES 
user_id=1318360
Originator: NO

Yes - we need some functions for security checks

- check if request contains a valid dialog cookie
- check if request matches a ongoind dilaog (cookie+callid+tags)

Then, a secure system would reject in.dialog messages if the request does
not exist in the dialog table.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-01-24 07:43

Message:
Logged In: NO 

Bogdan,

Thanks for the expanation. From what you're saying, the only logic missing
to reach Dan's safety target would be "If there is no cookie in an
in-dialog REQUEST, then either terminate the dialog (on the assumption
someone is trying to manipulate the call flow - I am envisioning something
like "Internal proxy error" ala sl_reply_error) or just fall back to "slow
matching", like the double checking but done upfront. Is that right ? 

also, as a sidenote, guys, my first name is "Jérôme", Martin being the
last name, so please call me "Jérôme" (I don't care that much about the
accents :-)).

Cheers,
Jerome

----------------------------------------------------------------------

Comment By: Bogdan (bogdan_iancu)
Date: 2007-01-24 07:28

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Martin,

the cookie is used to locate for a fast location of the internal dialog
record. Once found, you have the option to double check the matching by
seting the "use_tight_match"module param - this will force the checking of
callid also. So there is a safety mechanism :)... Klaus already suggested
to add more extra checks (like tags).

The advantage of using the cookie, even with the tigh matching, is that
you so not try to match the request to N dialogs by doing expensive string
comps, but you do it only once, to double check the result.

regards,
bogdan

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-01-24 06:33

Message:
Logged In: NO 

Dan,

Are you suggesting that the dialog module should use the cookie if present
(for optimization purposes) but still check the CallID: and To: field to
make sure it does not miss an altered request in case the dialog cookie is
missing ? 

Or do you think we need to go even further and totally remove the dialog
cookie and only use pristine header to identify the dialog matching a
particular request ?

I don't see all the implications in terms of speed, but from what I
understand the cookie method was chosen for performance reasons, because we
benefit from the fact that the RR: header is already parsed and stored.
What do you think ?

Cheers,
Jerome Martin

----------------------------------------------------------------------

Comment By: Dan (dan_pascu)
Date: 2007-01-24 06:21

Message:
Logged In: YES 
user_id=1296758
Originator: NO

There is another thing that needs to be considered when building
functionality that needs strict control over the message flow in a dialog,
like the one that this patch wishes to implement. The dialog module has a
serious shortcoming that prevents such functionality to be reliable. The
dialog module identifies in-dialog requests by using a cookie in the
Record-Route header. This cookie can be removed or altered by the endpoints
(on purpose or because of a flawed implementation). If this happens those
requests will not be identified as belonging to the dialog and will be
ignored in computing dialog related state.

Now any functionality that needs strict control over the message flow in a
dialog (like for example implementing a prepaid system where fake BYEs need
to be sent when the user credit has expired) cannot be reliably based on
the dialog module in its current form. For example if the endpoints send
some in-dialog requests with the cookie missing or altered, they will not
be identified by the proxy as belonging to the dialog and the CSeq
information will not be updated. Then later when the fake BYEs are sent,
they will have an old CSeq number which will be rejected by the endpoints
because it was already used and the call will not be closed. In this case
the call will continue past the credit limit and there is nothing the proxy
can do to close it.

All of this happens because in the current implementation of the dialog
module, the endpoints have control over which messages will be detected as
being part of the dialog and which not.


----------------------------------------------------------------------

Comment By: Klaus Darilion (klaus_darilion)
Date: 2007-01-24 05:38

Message:
Logged In: YES 
user_id=1318360
Originator: NO

I agree with Dan. Please see my feature request with some details about
the data which should be stored inside the dialog structure.

https://sourceforge.net/tracker/index.php?func=detail&aid=1632996&group_id=139143&atid=743023

----------------------------------------------------------------------

Comment By: Dan (dan_pascu)
Date: 2007-01-24 05:32

Message:
Logged In: YES 
user_id=1296758
Originator: NO

For this functionality to be really useful, much more information needs to
be stored per dialog and be put in the faked BYEs. One thing that comes to
mind is the Route headers that would be present in the BYEs sent by the
endpoints themselves as a result of Record-Route information added by
proxies that wish to stay in the path. The fake BYEs must follow the same
path that the native BYEs sent by the endpoints would have, for 2 reasons:

1. You may not have direct access to the endpoints because you do not have
the NAT with them open, so you need to send via the proxies that have.
2. If you send directly to the endpoints, the other proxies that wished to
stay in the path by using Record-Routes will be unaware of the dialog that
just ended and may make wrong assumptions and wrong decisions about the
call.

Without adding the Route heders, the functionality's usefulness is limited
to calls where there is only 1 proxy between the endpoints.


----------------------------------------------------------------------

Comment By: Bogdan (bogdan_iancu)
Date: 2007-01-24 04:07

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi Martin,

I do not disagree with you, but 'm exploring the possibilities :). My
thoughs were to keep dialog module as a container for the basic dialog
functionalities - creating, tracing and terminating them. Based on this, I
see the existing module a good place to have a geenric function for ending
a dialog. Maybe more new modules will want to do dialog cancelling and I
see no reason not to have everything together.
If more complex dialog-processing modules will show in time, they will all
use the basic dialog functions from "dialog" module.
At least this is my personal view on the matter. Shortly :
   1) keep in dialog module all the basic functionlities (add, view,
delete)
   2) add more modules for complex dialog-based scenarios

Regards,
Bogdan




----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-01-24 03:06

Message:
Logged In: NO 

Hi Bogdan,

It seems you disagree with my point of keeping things separate, which is
fine by me. I understand the reasons, but still I am afraid this can grow
out of reach quick. As I mentionned before, I perceive the dialog-related
features as having the highest growth-potential of the whole OpenSER
codebase, and I would not like to see it become nuclear-factory-sized as I
am sure many people will have "related features" to add. However, you're
the one with CVS access so you probably know better :-) Still, I would
appreciate if you took some time when you're a bit less busy to share your
thoughts in more depth on that matter.

Still, the important thing is that Kobi initiative is really one of those
that WILL attract users and typically enhances OpenSER in a manner that
will seduce many people. Way to go ! (and in fact, I'm happy disregarding
if this ends up in a separate module or in dialog :-)

Best Regards,
Jerome Martin

----------------------------------------------------------------------

Comment By: Bogdan (bogdan_iancu)
Date: 2007-01-24 02:52

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi Kobi,

yes, the interes exists and it si huge :)

my original plan was to have the dialog module to encapsulate
dialog-related functionalities. First was to be able to track down  dialogs
and possible to do count based on different criteria (see the features
request comming from Klaus).

I would prefer to stick to this original plan and continue extending the
dialog module (instead of adding small new modules) as time as there is
related functionality.

regards,
bogdan


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-01-24 02:21

Message:
Logged In: NO 

Hello Kobi,

I am myself in the process of writing some code to implement this
functionnality myself, so I am very enthusiastic about you submission. If
you want to talk about it (help, debugging, ideas, discussion), I can be
reached at jmartin at longphone.fr.

My own code is not a module but an external piece of code called by
exec(), so I'll probably dump it in favor to your approach which is of
course cleaner.

As of your questions, here are my answers :

Q1 - is there enough general interest in this functionality to warrant
further development?

Well, given the number of threads I've seen on SER/OPENSER MLs, I would
say everybody's looking for a way to cut calls. Currently, I've only seen
external perl scripts using FIFO UA features to acheive this (and I'm doing
the same thing). 

Q2 - is there some additional functionality that makes sense?

In order to enlarge the module's userbase, an ideal addition would be
being able to trigger the end2end BYE messages from an external source in
addtion to timed calls.

Q3 - would it be better implemented as an integrated extention to the
existing dialog module?

I would keep both modules separate for now, as I suspect many more
functionnalities will arise that use dialog statefullness, and a global
policy that makes sense would rather be keeping things clean, small and
maintainable. But that's just IMHO.

Cheers,
Jerome Martin

----------------------------------------------------------------------

Comment By: Kobi Eshun (ekobi)
Date: 2007-01-23 12:42

Message:
Logged In: YES 
user_id=1039134
Originator: YES

File Added: dialog.patch

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1642890&group_id=139143