3 Feb
2006
3 Feb
'06
10:35 p.m.
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
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@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
4 Feb
4 Feb
12:17 a.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
11:46 a.m.
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. :)
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
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.
-----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
12:53 a.m.
Bogdan,
This is great news! Thank you! I've got
a questions about retries.
I'm curious if retries are built in, or do I employ t_on_failure?
What I mean is...
How do I get the t_relay() to try subsequent naptrs and/or srvs in the
event the current one fails? Is all of that automatic, or do I need
a t_on_failure?
I think I understand that you skip ones that don't resolve, but, what if
they resolve but the transaction times out either on the naptr or on the srv?
Best,
-g
--
Greg Fausak
greg(a)thursday.com
12:01 p.m.
Hi Greg,
at the moment there is no retry support for neither NAPTR nor SRV. The
resolver loops through all NAPTR/SRV records and looks for the first
NAPTR|SRV|A pair of records that can be successfully resolved to IP address.
The biggest problem with having retry support for the resolve is the
combination between parallel and serial forking. Lets supposed the
following scenario:
uriA parallel forks to uriX and uriY
both uriX and uriY leads to distinctive sets of NAPTR/SRV records.
in such a case, even if it's a single transaction, you have to keep the
state of the resolver for each branch to be able to do serial forking
independently on each of them.
Another problem is detecting the failures. According to "4.3 Details of
RFC 2782 Process" specifies usage on ICMP for UDP failures...and ICMP
support is not reliable (depends on OS) and tricky to implement.
Do not get me wrong, I am not saying it's impossible, but it will take
some time to get to it... :)
regards,
Bogdan
Greg Fausak wrote:
Bogdan,
This is great news! Thank you! I've got
a questions about retries.
I'm curious if retries are built in, or do I employ t_on_failure?
What I mean is...
How do I get the t_relay() to try subsequent naptrs and/or srvs in the
event the current one fails? Is all of that automatic, or do I need
a t_on_failure?
I think I understand that you skip ones that don't resolve, but, what if
they resolve but the transaction times out either on the naptr or on the srv?
Best,
-g
--
Greg Fausak
greg(a)thursday.com
3:14 p.m.
Bogdan,
Thanks for the reply.
Will this work:
here are some examples of how to uses this new functionality:
1) enum doing serial forking:
{
.....
enum_query("e164.arpa.","voice");
serialize_branches(1);
if (!next_branches()) {
sl_send_reply(...no enum found...);
exit;
}
t_on_failure("1");
t_relay();
}
failure_route[1] {
if (next_branches()) {
t_relay();
}
}
I haven't tried it yet. But I think it is an example
of serial forking using naptrs.
Have a great weekend!
---greg
On Feb 4, 2006, at 4:01 AM, Bogdan-Andrei Iancu wrote:
Hi Greg,
at the moment there is no retry support for neither NAPTR nor SRV.
The resolver loops through all NAPTR/SRV records and looks for the
first NAPTR|SRV|A pair of records that can be successfully resolved
to IP address.
The biggest problem with having retry support for the resolve is
the combination between parallel and serial forking. Lets supposed
the following scenario:
uriA parallel forks to uriX and uriY
both uriX and uriY leads to distinctive sets of NAPTR/SRV records.
in such a case, even if it's a single transaction, you have to keep
the state of the resolver for each branch to be able to do serial
forking independently on each of them.
Another problem is detecting the failures. According to "4.3
Details of RFC 2782 Process" specifies usage on ICMP for UDP
failures...and ICMP support is not reliable (depends on OS) and
tricky to implement.
Do not get me wrong, I am not saying it's impossible, but it will
take some time to get to it... :)
regards,
Bogdan
Greg Fausak wrote:
Bogdan,
This is great news! Thank you! I've got
a questions about retries.
I'm curious if retries are built in, or do I employ t_on_failure?
What I mean is...
How do I get the t_relay() to try subsequent naptrs and/or srvs in
the
event the current one fails? Is all of that automatic, or do I need
a t_on_failure?
I think I understand that you skip ones that don't resolve, but,
what if
they resolve but the transaction times out either on the naptr or
on the srv?
Best,
-g
--
Greg Fausak
greg(a)thursday.com
5:15 p.m.
Greg,
this is the happy case where parallel forking is involved. The serial
forking works by keeping in AVPs the next uris to be tried (in case of
negative replies). But the AVPs are per transaction and you cannot say
on which specific branch to be used (in case of parallel forking).
Also, from performance reasons, the best approach will be to try to
perform the sequential queries only if the previous tried failed...
I will try to put tougher a plan about how to have failover in the resolver.
regards and nice weekend to you also,
bogdan
Greg Fausak wrote:
Bogdan,
Thanks for the reply.
Will this work:
here are some examples of how to uses this new functionality:
1) enum doing serial forking:
{
.....
enum_query("e164.arpa.","voice");
serialize_branches(1);
if (!next_branches()) {
sl_send_reply(...no enum found...);
exit;
}
t_on_failure("1");
t_relay();
}
failure_route[1] {
if (next_branches()) {
t_relay();
}
}
I haven't tried it yet. But I think it is an example
of serial forking using naptrs.
Have a great weekend!
---greg
On Feb 4, 2006, at 4:01 AM, Bogdan-Andrei Iancu wrote:
Hi Greg,
at the moment there is no retry support for neither NAPTR nor SRV.
The resolver loops through all NAPTR/SRV records and looks for the
first NAPTR|SRV|A pair of records that can be successfully resolved
to IP address.
The biggest problem with having retry support for the resolve is the
combination between parallel and serial forking. Lets supposed the
following scenario:
uriA parallel forks to uriX and uriY
both uriX and uriY leads to distinctive sets of NAPTR/SRV records.
in such a case, even if it's a single transaction, you have to keep
the state of the resolver for each branch to be able to do serial
forking independently on each of them.
Another problem is detecting the failures. According to "4.3 Details
of RFC 2782 Process" specifies usage on ICMP for UDP failures...and
ICMP support is not reliable (depends on OS) and tricky to implement.
Do not get me wrong, I am not saying it's impossible, but it will
take some time to get to it... :)
regards,
Bogdan
Greg Fausak wrote:
Bogdan,
This is great news! Thank you! I've got
a questions about retries.
I'm curious if retries are built in, or do I employ t_on_failure?
What I mean is...
How do I get the t_relay() to try subsequent naptrs and/or srvs in the
event the current one fails? Is all of that automatic, or do I need
a t_on_failure?
I think I understand that you skip ones that don't resolve, but,
what if
they resolve but the transaction times out either on the naptr or
on the srv?
Best,
-g
--
Greg Fausak
greg(a)thursday.com
8 Feb
8 Feb
4:38 p.m.
Howdy,
Back from the west coast...
Concerning this, inline:
On Feb 4, 2006, at 9:15 AM, Bogdan-Andrei Iancu wrote:
Greg,
this is the happy case where parallel forking is involved. The
serial forking works by keeping in AVPs the next uris to be tried
(in case of negative replies). But the AVPs are per transaction and
you cannot say on which specific branch to be used (in case of
parallel forking).
I think that's OK. From what I can tell, the parallel fork branches
are serialized, then put into AVPs. I thought the order was maintained
with q values, but, initially I can deal with a random order I think. I
was just wondering if it does what I think it does. If so, it is
exactly what I need!
Also, from performance reasons, the best approach will
be to try to
perform the sequential queries only if the previous tried failed...
I thought that is what happened here. That is, the branches are
serialized (serialize_branches()), then the next brand is made the
current one (next_branches()), and finally, t_on_failure() is fired
up and the packet is relayed with t_relay(). The next branch would only
be tried if there is a failure, right? Am I missing the point?
-g
I will try to put tougher a plan about how to have
failover in the
resolver.
regards and nice weekend to you also,
bogdan
Greg Fausak wrote:
Bogdan,
Thanks for the reply.
Will this work:
here are some examples of how to uses this new functionality:
1) enum doing serial forking:
{
.....
enum_query("e164.arpa.","voice");
serialize_branches(1);
if (!next_branches()) {
sl_send_reply(...no enum found...);
exit;
}
t_on_failure("1");
t_relay();
}
failure_route[1] {
if (next_branches()) {
t_relay();
}
}
I haven't tried it yet. But I think it is an example
of serial forking using naptrs.
Have a great weekend!
---greg
On Feb 4, 2006, at 4:01 AM, Bogdan-Andrei Iancu wrote:
Hi Greg,
at the moment there is no retry support for neither NAPTR nor
SRV. The resolver loops through all NAPTR/SRV records and looks
for the first NAPTR|SRV|A pair of records that can be
successfully resolved to IP address.
The biggest problem with having retry support for the resolve is
the combination between parallel and serial forking. Lets
supposed the following scenario:
uriA parallel forks to uriX and uriY
both uriX and uriY leads to distinctive sets of NAPTR/SRV
records.
in such a case, even if it's a single transaction, you have to
keep the state of the resolver for each branch to be able to do
serial forking independently on each of them.
Another problem is detecting the failures. According to "4.3
Details of RFC 2782 Process" specifies usage on ICMP for UDP
failures...and ICMP support is not reliable (depends on OS) and
tricky to implement.
Do not get me wrong, I am not saying it's impossible, but it
will take some time to get to it... :)
regards,
Bogdan
Greg Fausak wrote:
Bogdan,
This is great news! Thank you! I've got
a questions about retries.
I'm curious if retries are built in, or do I employ t_on_failure?
What I mean is...
How do I get the t_relay() to try subsequent naptrs and/or srvs
in the
event the current one fails? Is all of that automatic, or do I
need
a t_on_failure?
I think I understand that you skip ones that don't resolve,
but, what if
they resolve but the transaction times out either on the naptr
or on the srv?
Best,
-g
--
Greg Fausak
greg(a)thursday.com
6868
days inactive
6873
days old
7 comments
3 participants
participants (3)
-
Bogdan-Andrei Iancu -
Greg Fausak -
Joachim Fabini