3 Feb
2006
3 Feb
'06
5:17 p.m.
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(a)openser.org
[mailto:users-bounces@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@domain.org
forward(uri:host,uri:port); # RURI=sip:user@domain.org
NOTE: these will not use NAPTR
t_relay("tcp:openser.org");
t_relay(); # RURI=sip:user@domain.org;transport=udp
NOTE: these will not use NAPTR/SRV
t_relay("openser.org:5060");
t_relay(); # RURI=sip:user@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@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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users