[Serusers] Re: [Serdev] ENUM issues - req. for discussion
Samuel Osorio Calvo
samuel.osorio at nl.thalesgroup.com
Tue Jun 7 14:56:03 CEST 2005
Hi Klaus,
responses inline...(command and file names are taken from my memory, so don't pay much attention at the spelling)
Samuel.
Unclassified.
>>> Klaus Darilion <klaus.mailinglists at pernau.at> 06/07/05 01:43PM >>>
>Hi all!
>
>Some time of using ser with ENUM revealed several problems which I would
>like to dicuss with you. Be aware - this email is long!
>
>ENUM is a wonderful thing for call routing nevertheless, as it is DNS
>based there are some important things an ENUM aware application has to
>consider:
> 1. You never know how long the lookup takes
> 2. You never know if the lookup will fail or succeed
> 3. If the lookup was successful, you never may trust the result>
>
>I will explain this points in detail know:
>
>1+2:
>Using enum, the application is giving control to the DNS resolver of the
>OS and the DNS infrastructure. Thus, the ser thread which performs the
>ENUM lookup will be blocked until there is a result from the system's
>DNS resolver.
>
>If DNS is slow, or misconfigured (e.g. a zone is delegated to a
>nameserver which is down), the thread will be blocked for several
>seconds. E.g. if you use debian woody and 2 nameservers in
>/etc/resolv.conf, the timeout is 20 seconds. If you are lucky, the OS
>allows configuration of the DNS timeouts. Nevertheless, you have to
>consider that a ser thread will be blocked up to 20 seconds. This has
>impacts on your configuration:
I don't know the details but would it be really difficult to use an asyncrhonous resolver, such as resiprocate SIP stack does with ARES?? Besides exec_* calls, the main SER's performance bottelneck is the DNS resolving step thus it would be a great improvement adding asyncronous DNS queries.
>Typically, you use some kind of the following logic:
>if (uri =~ "+[0-9].") {
> if (enum_lookup()) {
> t_relay(); break;
> } else {
> forward to PSTN gateway; break;
> }
>}
>
>Thus, the INVITE will be received and the ENUM lookup will be performed.
>If the lookup will take longer than 0.5s, the SIP client will start
>restransmitting the INVITE. Thus, another thread will process this
>INVITE and enother ENUM lookup will be performed. After several seconds,
>all of ser's threads will be blocked with ENUM lookups and your SIP
>proxy will not handle any requests until the DNS query times out. Thus,
>it is very easy to generate a DoS attack against the proxy.
>Another funny thing is, that the SIP client will detect a proxy error
>and hangs up, but the INVITEs are still processed in the SIP proxy and
>after the timeout forwarded to the PSTN gateway.
>
>A solution to stop the retransmission is to immediatle
>sl_send_reply("100","Trying"), But this rises another problem. Now, if
>the caller hangs up before the DNS timeout, the SIP client will send
>CANCEL (as it received 100) to the SIP proxy. But the SIP proxy can not
>cancel the transaction, as it is not genereated yet - the INVITE thread
>is still waiting for the ENUM lookup and the transaction will be
>generated after the ENUM lookup (after 20s timeout). Thus, we still end
>up with an INVITE forwarded to the PSTN gateway although the SIP client
>already hang up.
>
>I thought of using t_newtran and t_forward_nonack_uri instead of t_realy
>to generate the transaction before doing the ENUM lookup. Thus, the
>thread which will process the CANCEL should find a transaction and stop
>it. But will this really prevent the INVITE sent to the PSTN gateway,
>once the DNS times out? (not tested)
I think the best way would be to add a reply(100) AND t_forward_nonack, something like:
sl_send_reply("100","Trying");
t_newtran();
uri =~ "+[0-9].") {
if (enum_lookup()) {
t_forward_nonack(); break;}
else{
t_forward_nonac();break;
}
But it adds a complexity level which will lead to many non-working config files......but I vote for it!
>
>btw: this problem does not only occour for ENUM lookups, but for all DNS
>lookups (SRV, A, AAAA).
>
>3:
>If the ENUM lookup succeeds, you never may trust the result. It may be a
>invalid SIP URI, or a tel: URI, or anything else a user puts into its
>NAPTRs. This may result in a failed transaction, or like revealed at the
>ENUM plugtest in failed accounting. Even worse, maybe it is possible to
>complete crash ser using realy bad formated URIs?
>
>Thus you can't avoid doing some URI checks against the URI received from
>the ENUM lookup. Perfomance issues are no valid arguements! Once I give
>control to external services (DNS, radius, exec), the perfomance
>penalties due to parsing the SIP URI are much more less than due to the
>ENUM lookup.
>
>In case of ser, I would do the URI parsing in the ENUM module, or maybe
>generate a dedicated function/module for checking SIP URIs inside the
>routing logic. Thus, I can also check the result of exec calls.
Since URI check is a really global action, it should be implemented in SER's core, providing commands to the config file (something like uri_check(To|From|Req-URI|Contact) ) and functions to be called from any module.
>
>I'm eagerly waiting for your opinions.
>
>regards,
>Klaus
_______________________________________________
Serdev mailing list
serdev at lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
More information about the sr-users
mailing list