3 Apr
2016
3 Apr
'16
7:09 p.m.
Dear SIP-experts and DNS-SRV gurus;
I have some questions to the deployers of SER/Kamailio and
best current practice for multiple SIP-servers with SRV-records
and authentication. This is not a question about Kamailio itself
but rather experience with deployment of it in the field.
The current usecase is:
1. Multiple SIP-servers are deployed for the same domain
2. The DNS is configured with SRV-records for load balancing,
example: (lets call the domain "example.com")
$ host -t SRV _sip._udp.example.com
_sip._udp.example.com has SRV record 20 0 5080 alpha1.example.com.
_sip._udp.example.com has SRV record 20 0 5080 alpha2.example.com.
3. when a SIP client registers, it resolves the domain using RFC3263 [1]
and the first REGISTER request is sent to SIP-Server #1
4. SIP-server #1 replies with 401 containing the authentication challenge
5. The SIP Client adds the authentication header to the REGISTER
request and re-sends it, but this time also using RFC 3263, and due
to DNS rotation the request is sent to SIP-Server #2
6. Now, because the SIP-Servers are configured with _different_
secrets in the "auth" module [2], the REGISTER request
fails with authentication error.
Now, I know that it is common for SIP user-agents to send both requests
to the same SIP-server instance. Baresip [3] is not doing that, it does
a new RFC 3263 lookup for all requests (except e2e ACK/CANCEL).
so here are my questions:
- What is common practice in the field, to configure auth module
with the same "secret" or different "secret" values?
- Do you know if there is any reference to IETF documents about how
this should be handled? RFC 3263 says that every request should be
resolved, except:
"The procedures here MUST be done exactly once per transaction, where
transaction is as defined in [1]. That is, once a SIP server has
successfully been contacted (success is defined below), all
retransmissions of the SIP request and the ACK for non-2xx SIP
responses to INVITE MUST be sent to the same host. Furthermore, a
CANCEL for a particular SIP request MUST be sent to the same SIP
server that the SIP request was delivered to."
- What is common practice for SIP user-agents to do in this case?
/alfred
[1] https://tools.ietf.org/html/rfc3263#section-4.4
[2] http://www.kamailio.org/docs/modules/3.4.x/modules/auth.html#auth.secret
[3] https://github.com/alfredh/baresip/issues/39
4 Apr
4 Apr
2:37 a.m.
New subject: Multiple SIP-servers with SRV-records and authentication secrets
>>>> "AH" == Alfred E Heggestad
<aeh(a)db.org> writes:
AH> 1. Multiple SIP-servers are deployed for the same domain
AH> 2. The DNS is configured with SRV-records for load balancing,
AH> example: (lets call the domain "example.com")
AH> 3. when a SIP client registers, it resolves the domain using RFC3263 [1]
AH> and the first REGISTER request is sent to SIP-Server #1
AH> 4. SIP-server #1 replies with 401 containing the authentication challenge
AH> 5. The SIP Client adds the authentication header to the REGISTER
AH> request and re-sends it, but this time also using RFC 3263, and due
AH> to DNS rotation the request is sent to SIP-Server #2
AH> 6. Now, because the SIP-Servers are configured with _different_
AH> secrets in the "auth" module [2], the REGISTER request
AH> fails with authentication error.
I don't see how that can ever work.
Every uac I've used took a single name/passwd tuple for a given target.
Does blink do something different? How can you specify that it should
use different credentials depending on which srv target it happens to
follow?
In every scenario I've looked at, all of the load-balanced backend
servers have to have a shared credential store of some sort, such as
a replicated sql or ldap cluster, to hold the users' creds, so the
digest (in sip's case) should work on any backend server.
-JimC
--
James Cloos <cloos(a)jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
8:51 a.m.
New subject: Multiple SIP-servers with SRV-records and authentication secrets
Hello,
are you using also a different realm per server? Because, iirc, the
username/password must be the same for a realm.
On the other hand, for many kamailio in a farm should not matter much,
because the relevant attribute in the 401 is the nonce. If you set the
secret for generating the nonce to be the same in the two servers and
use the mechanism with time interval validity for nonce (not one time
nonce), it should work, given that the time on the both servers is the
same (sync'ed).
Cheers,
Daniel
On 03/04/16 18:09, Alfred E. Heggestad wrote:
Dear SIP-experts and DNS-SRV gurus;
I have some questions to the deployers of SER/Kamailio and
best current practice for multiple SIP-servers with SRV-records
and authentication. This is not a question about Kamailio itself
but rather experience with deployment of it in the field.
The current usecase is:
1. Multiple SIP-servers are deployed for the same domain
2. The DNS is configured with SRV-records for load balancing,
example: (lets call the domain "example.com")
$ host -t SRV _sip._udp.example.com
_sip._udp.example.com has SRV record 20 0 5080 alpha1.example.com.
_sip._udp.example.com has SRV record 20 0 5080 alpha2.example.com.
3. when a SIP client registers, it resolves the domain using RFC3263 [1]
and the first REGISTER request is sent to SIP-Server #1
4. SIP-server #1 replies with 401 containing the authentication challenge
5. The SIP Client adds the authentication header to the REGISTER
request and re-sends it, but this time also using RFC 3263, and due
to DNS rotation the request is sent to SIP-Server #2
6. Now, because the SIP-Servers are configured with _different_
secrets in the "auth" module [2], the REGISTER request
fails with authentication error.
Now, I know that it is common for SIP user-agents to send both requests
to the same SIP-server instance. Baresip [3] is not doing that, it does
a new RFC 3263 lookup for all requests (except e2e ACK/CANCEL).
so here are my questions:
- What is common practice in the field, to configure auth module
with the same "secret" or different "secret" values?
- Do you know if there is any reference to IETF documents about how
this should be handled? RFC 3263 says that every request should be
resolved, except:
"The procedures here MUST be done exactly once per transaction, where
transaction is as defined in [1]. That is, once a SIP server has
successfully been contacted (success is defined below), all
retransmissions of the SIP request and the ACK for non-2xx SIP
responses to INVITE MUST be sent to the same host. Furthermore, a
CANCEL for a particular SIP request MUST be sent to the same SIP
server that the SIP request was delivered to."
- What is common practice for SIP user-agents to do in this case?
/alfred
[1] https://tools.ietf.org/html/rfc3263#section-4.4
[2]
http://www.kamailio.org/docs/modules/3.4.x/modules/auth.html#auth.secret
[3] https://github.com/alfredh/baresip/issues/39
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com
11:27 a.m.
New subject: Multiple SIP-servers with SRV-records and authentication secrets
On 03 Apr 2016, at 18:09, Alfred E. Heggestad
<aeh(a)db.org> wrote:
Dear SIP-experts and DNS-SRV gurus;
I have some questions to the deployers of SER/Kamailio and
best current practice for multiple SIP-servers with SRV-records
and authentication. This is not a question about Kamailio itself
but rather experience with deployment of it in the field.
The current usecase is:
1. Multiple SIP-servers are deployed for the same domain
2. The DNS is configured with SRV-records for load balancing,
example: (lets call the domain "example.com")
$ host -t SRV _sip._udp.example.com
_sip._udp.example.com has SRV record 20 0 5080 alpha1.example.com.
_sip._udp.example.com has SRV record 20 0 5080 alpha2.example.com.
3. when a SIP client registers, it resolves the domain using RFC3263 [1]
and the first REGISTER request is sent to SIP-Server #1
4. SIP-server #1 replies with 401 containing the authentication challenge
5. The SIP Client adds the authentication header to the REGISTER
request and re-sends it, but this time also using RFC 3263, and due
to DNS rotation the request is sent to SIP-Server #2
6. Now, because the SIP-Servers are configured with _different_
secrets in the "auth" module [2], the REGISTER request
fails with authentication error.
Now, I know that it is common for SIP user-agents to send both requests
to the same SIP-server instance. Baresip [3] is not doing that, it does
a new RFC 3263 lookup for all requests (except e2e ACK/CANCEL).
so here are my questions:
- What is common practice in the field, to configure auth module
with the same "secret" or different "secret" values?
Within
the same realm the user has the same credentials. As long as
you have the same realm, one user name should NOT have different
secrets. If the two servers have different secrets for the same user, the
realm should be different.
I am not sure if there’s a document stating that every server in the same
realm has to handle the same set of nonces, i.e. accept an authentication
based on a nonce from another server, but in my world that follows
the idea of a realm.
- Do you know if there is any reference to IETF documents about how
this should be handled? RFC 3263 says that every request should be
resolved, except:
"The procedures here MUST be done exactly once per transaction, where
transaction is as defined in [1]. That is, once a SIP server has
successfully been contacted (success is defined below), all
retransmissions of the SIP request and the ACK for non-2xx SIP
responses to INVITE MUST be sent to the same host. Furthermore, a
CANCEL for a particular SIP request MUST be sent to the same SIP
server that the SIP request was delivered to.”
I think many developers are confused about REGISTER. It does not
create a dialog but some software handles it like one. It’s easy to
fall into a trap thinking about REGISTER as a dialog.
- What is common practice for SIP user-agents to do in this case?
Not many does
what baresip does, which I think is correct. In Kamailio
multiple servers can handle the same nonce, so this behaviour works
very well with multiple Kamailios .
/O
/alfred
[1] https://tools.ietf.org/html/rfc3263#section-4.4
[2] http://www.kamailio.org/docs/modules/3.4.x/modules/auth.html#auth.secret
[3] https://github.com/alfredh/baresip/issues/39
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
9 Apr
9 Apr
10:25 p.m.
New subject: Multiple SIP-servers with SRV-records and authentication secrets
On 04/04/16 10:27, Olle E. Johansson wrote:
Hej Olle, thanks for your answer :)
perhaps my description was a bit vague. The username and password is
obviously the same for the given SIP domain and for all SIP-server
instances. I am talking about the auth "secret" which is part of the
random "nonce" included in the Challenge.
one example where it is not working can be found here,
with a full SIP trace:
https://github.com/alfredh/baresip/issues/39
i think my question boils down to; should the auth-secret on the SIP-server
be the same for all instances, or can it be different ?
the Kamailio documention specifies:
"Any clients should send the authenticated request to the server that issued the
challenge."
this seems to hint at the possibility of different secrets.
But in which RFC is this specified, or it is simply a matter of
common sense ?
a SIP client can also cache the challenge, which can be used
for example in the un-REGISTER message. Does that mean that in such
a configuration you also have to send un-REGISTER to the same
SIP-Server instance ?
/alfred
On 03 Apr 2016, at 18:09, Alfred E. Heggestad
<aeh(a)db.org> wrote:
Dear SIP-experts and DNS-SRV gurus;
I have some questions to the deployers of SER/Kamailio and
best current practice for multiple SIP-servers with SRV-records
and authentication. This is not a question about Kamailio itself
but rather experience with deployment of it in the field.
The current usecase is:
1. Multiple SIP-servers are deployed for the same domain
2. The DNS is configured with SRV-records for load balancing,
example: (lets call the domain "example.com")
$ host -t SRV _sip._udp.example.com
_sip._udp.example.com has SRV record 20 0 5080 alpha1.example.com.
_sip._udp.example.com has SRV record 20 0 5080 alpha2.example.com.
3. when a SIP client registers, it resolves the domain using RFC3263 [1]
and the first REGISTER request is sent to SIP-Server #1
4. SIP-server #1 replies with 401 containing the authentication challenge
5. The SIP Client adds the authentication header to the REGISTER
request and re-sends it, but this time also using RFC 3263, and due
to DNS rotation the request is sent to SIP-Server #2
6. Now, because the SIP-Servers are configured with _different_
secrets in the "auth" module [2], the REGISTER request
fails with authentication error.
Now, I know that it is common for SIP user-agents to send both requests
to the same SIP-server instance. Baresip [3] is not doing that, it does
a new RFC 3263 lookup for all requests (except e2e ACK/CANCEL).
so here are my questions:
- What is common practice in the field, to configure auth module
with the same "secret" or different "secret" values?
Within
the same realm the user has the same credentials. As long as
you have the same realm, one user name should NOT have different
secrets. If the two servers have different secrets for the same user, the
realm should be different.
I am not sure if there’s a document stating that every server in the same
realm has to handle the same set of nonces, i.e. accept an authentication
based on a nonce from another server, but in my world that follows
the idea of a realm.
- Do you know if there is any reference to IETF documents about how
this should be handled? RFC 3263 says that every request should be
resolved, except:
"The procedures here MUST be done exactly once per transaction, where
transaction is as defined in [1]. That is, once a SIP server has
successfully been contacted (success is defined below), all
retransmissions of the SIP request and the ACK for non-2xx SIP
responses to INVITE MUST be sent to the same host. Furthermore, a
CANCEL for a particular SIP request MUST be sent to the same SIP
server that the SIP request was delivered to.”
I think many developers are confused about REGISTER. It does not
create a dialog but some software handles it like one. It’s easy to
fall into a trap thinking about REGISTER as a dialog.
- What is common practice for SIP user-agents to do in this case?
Not many does
what baresip does, which I think is correct. In Kamailio
multiple servers can handle the same nonce, so this behaviour works
very well with multiple Kamailios .
/O
/alfred
[1] https://tools.ietf.org/html/rfc3263#section-4.4
[2] http://www.kamailio.org/docs/modules/3.4.x/modules/auth.html#auth.secret
[3] https://github.com/alfredh/baresip/issues/39
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3152
days inactive
3158
days old
4 comments
4 participants
participants (4)
-
Alfred E. Heggestad -
Daniel-Constantin Mierla -
James Cloos -
Olle E. Johansson