[Users] NEW FEATURE: NAPTR lookup

[Joachim Fabini]

Hi Bogdan,

Excellent news! Many, many thanks for this feature, 
I'll integrate and test it at the beginning of next week. 
And if I read Daniel's email correctly we can expect 
dynamic AVP names to be available within the next weeks, 
too. :)

> 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.

Hmmh, I did not yet deploy TLS. My personal opinion is that 
doing NAPTR is the safer way - OpenSER can, e.g., detect 
that a given domain does _not_ support sips. Reusing your 
example: a direct SRV query on "_sips._tcp.domainA" might 
be negative but NAPTR on "domainA" might return, as you
wrote "_sips._tcp.domainB". I.e., if you rely on the SRV
query you might get a negative response, although domainA
_does_ support TLS.

Thanks again and have a nice weekend,
best regards
--Joachim

> -----Original Message-----
> From: users-bounces at openser.org 
> [mailto:users-bounces at openser.org] On Behalf Of Bogdan-Andrei Iancu
> Sent: Freitag, 03. Februar 2006 21:35
> To: devel; users openser.org
> Subject: [Users] NEW FEATURE: NAPTR lookup
> 
> 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
> 
> 
> 
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>