[Devel] Re: [Users] NEW FEATURE: NAPTR lookup

[Bogdan-Andrei Iancu]

Hi Joachim,

Joachim Fabini wrote:

>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.
>
>  
>
indeed, if It will be to ignore the TLS special requirements, I will 
100% be for NAPTR.
BUT there is this paragraph in the RFC 3263 :

   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.


If I understand / interpret correctly this, I would say that for TLS 
cross-domain references are forbidden..And in this case the base domain 
in original domain and in NAPTR and SRV results must be the same....

Regards and nice weekend to you too ;)
bogdan

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