[Users] NEW FEATURE: NAPTR lookup

[Bogdan-Andrei Iancu]

Hi,

A new feature is available in openser, devel version : NAPTR lookup.

Overview
=========

OpenSER is now RFC3263 (Locating SIP Server) compliant. See 
http://www.ietf.org/rfc/rfc3263.txt

NAPTR queries are used to discovered the transport protocols for SIP 
that are supported (and a preference order) by a SIP server. Combining 
the protocols that are supported by the remote server and the protocols 
that re locally implemented, the local server will choose the protocol 
to be used (if an explicit one is not provided). One the protocol is 
selected, SRV queries are used to discover the port to be used; after 
that A record query is made to get the IP address.

This will make possible for a proxy to advertise its preferred 
protocols. Like : if supported, use TLS, otherwise try TCP and if not 
UDP. Establishing relationships/connections via TLS will be much simpler 
to configure and it would be dynamically done - if both proxies supports 
TLS they will use TLS, but this will not exclude UDP and TCP to be used 
as alternatives....


How it works
============

If NAPTR / SRV lookup is used depends if the proto and port are known. 
Here is a small diagram:


    if port specify
        then -> do just A record lookup and use defaults protos (UDP for 
SIP and TLS for SIPS) if not specified; done

    # no port
    if no proto
        then -> do NAPTR to get proto; if no results, use defaults 
protos (UDP for SIP and TLS for SIPS); continue

    # we have proto now
    do SRV to get port; if no results, use defaults ports (5060 for SIP 
and 5061 for SIPS); continue

    # we have proto and port
    do A record lookup to get IP


The resolver will sequentially try all NAPTR and SRV results until it 
successfully gets an IP address. NAPTR / SRV records which cannot be 
completely followed (resolved) will be skipped.
If the TLS / TCP support is compiled and enabled, the proxy will 
consider this protos to use; otherwise it will skip them.


How to use
==========

NAPTR will be used only if proto is not specify neither via the relaying 
function nor via the RURI. Ex:

    t_relay("openser.org"); # send to openser.org and use NAPTR and SRV 
to resolve the address
    t_relay(); # RURI=sip:user at domain.org
    forward(uri:host,uri:port); # RURI=sip:user at domain.org

NOTE: these will not use NAPTR
    t_relay("tcp:openser.org");
    t_relay(); # RURI=sip:user at domain.org;transport=udp

NOTE: these will not use NAPTR/SRV
    t_relay("openser.org:5060");
    t_relay(); # RURI=sip:user at domain.org:5060



Still under discussion
======================

According to the RFC, for a SIPS uri, the only protocol to be used is 
TLS. My question is : if SIPS is found force TLS as proto and do SRV 
lookup or perform NAPTR lookup and look for TLS entries.

The difference may be: one extra query (from NAPTR) versus the fact that 
the NAPTR query may lead to a SRV into another domain.

Ex: for sips:user at domainA
    If forcing TLS -> do SRV for "_sips._tcp.domainA." -> port 
server1.domainA:5061

    If using first NAPTR -> do NAPTR on "domainA" and get  
"_sips._tcp.domainB." which will lead somewhere else than using directly 
SRV. According the RFC this is possible.


What I'm not sure about is if this cross domain NAPTR records are 
allowed for TLS: see chapter 4.1 :

   For NAPTR records with SIPS protocol fields, (if the server is using
   a site certificate), the domain name in the query and the domain name
   in the replacement field MUST both be valid based on the site
   certificate handed out by the server in the TLS exchange.  Similarly,
   the domain name in the SRV query and the domain name in the target in
   the SRV record MUST both be valid based on the same site certificate.
   Otherwise, an attacker could modify the DNS records to contain
   replacement values in a different domain, and the client could not
   validate that this was the desired behavior or the result of an
   attack.


for the moment, NAPTR and SRV are used for SIPS....but any other 
opinions on this TLS matter are welcomed...


regards,
Bogdan

PS: feedback is welcomed :D