[Serusers] ENUM issues - req. for discussion

[Iqbal]

Hi

Have been using ENUM for a month or so now, and point 3 is a problem, 
since I found some users not properly formatting their entries, which 
meant I got no route to them, no to test this for every single entry 
is/will be a pain.

Lookups here didnt really take much time I found, I dropped freenum, 
cause it just went pear shaped, and started to hang. i.e got no reply.

Dont really have much other opinions, except that URI parsing for 
correct format is great idea.

Iqbal

Klaus Darilion wrote:

> 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:
>
> 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)
>
> 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.
>
> I'm eagerly waiting for your opinions.
>
> regards,
> Klaus
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
> .
>