Hi,
When providing PSTN termination of calls that originate from a SIP source how do you go about validating the identity of where the calls originated from - the SIP Proxy or the SUA.
PSTN ---- SIP Proxy 1--- + --- SIP Proxy 2 ---- PSTN
So the calls originate from the PSTN in a country, get transported across the internet and terminated in a different country via another company. Other than source IP address, what method could you use to validate the origin of the calls? Also in question is security for trunk services for companies that simply want to terminate calls out onto the PSTN. How can you setup a trust relationship between the two proxies?
Is any one here in a similar situation??
Regards,
Alan
------------------------------------------------------------------------------------------------------- This email, and any files transmitted with it, is copyright and may contain confidential information. The contents are intended for the use of the addressee(s) only. Unauthorized use may be unlawful. If you receive this email by mistake, please advise sender immediately. The views of the author may not necessarily constitute the views of Telco Electronics Limited. Nothing in this mail shall bind Telco Electronics Limited in any contract or obligation.
Telco Electronics Limited 6-8 Oxford Court Brackley Northants NN13 7XY
Tel 01280 761600 Fax 01280 841174
Hi Alan,
Excepting source IP check (which is not reliable), you can also use authentication between server - SIPproxy2 authenticates all request sent to SIP proxy1 and vice-versa.
Since the end points are fixed (PSTN GWs), you can create IPSEC tunnels to transport the signaling part. Tunneling also the media will probably introduce delay and will require some really performat machines :-).
Also you can go for TLS, which is as concept basically the same thing IPSEC tunnels. The major difference is that TLS is not free as IPSEC is.
Best regards, Marian
Alan Litster wrote:
Hi,
When providing PSTN termination of calls that originate from a SIP source how do you go about validating the identity of where the calls originated from - the SIP Proxy or the SUA.
PSTN ---- SIP Proxy 1--- + --- SIP Proxy 2 ---- PSTN
So the calls originate from the PSTN in a country, get transported across the internet and terminated in a different country via another company. Other than source IP address, what method could you use to validate the origin of the calls? Also in question is security for trunk services for companies that simply want to terminate calls out onto the PSTN. How can you setup a trust relationship between the two proxies?
Is any one here in a similar situation??
Regards,
Alan
This email, and any files transmitted with it, is copyright and may contain confidential information. The contents are intended for the use of the addressee(s) only. Unauthorized use may be unlawful. If you receive this email by mistake, please advise sender immediately. The views of the author may not necessarily constitute the views of Telco Electronics Limited. Nothing in this mail shall bind Telco Electronics Limited in any contract or obligation.
Telco Electronics Limited 6-8 Oxford Court Brackley Northants NN13 7XY
Tel 01280 761600 Fax 01280 841174
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Marian Dumitru writes:
Also you can go for TLS, which is as concept basically the same thing IPSEC tunnels. The major difference is that TLS is not free as IPSEC is.
TLS not being part of free ser is indeed a problem. i think it is the only feature mandated by rfc3261 that is not included in free ser.
i fully understand that iptel needs to make money somehow in order to keep its developers on the payroll, but i feel that a mandatory feature should not be hold back. there still is plenty of other value add that iptel can produce even if tls would be in public domain.
so what can be done about it? the easiest thing would, of course, be that iptel changes its policy and makes their tls implementation as part of free ser. if that is not acceptable to iptel, then i guess the only remaining alternative is that other ser developers try to implement TLS support for ser and commit it to cvs.
any comments?
-- juha
At 10:27 PM 2/17/2005, Juha Heinanen wrote:
Marian Dumitru writes:
Also you can go for TLS, which is as concept basically the same thing IPSEC tunnels. The major difference is that TLS is not free as IPSEC is.
TLS not being part of free ser is indeed a problem. i think it is the only feature mandated by rfc3261 that is not included in free ser.
i fully understand that iptel needs to make money somehow in order to keep its developers on the payroll, but i feel that a mandatory feature should not be hold back. there still is plenty of other value add that iptel can produce even if tls would be in public domain.
To be candid, the suggestion to release some of money-generating features freely and begin working on some other money-generating feature is easier said than executed.
so what can be done about it? the easiest thing would, of course, be that iptel changes its policy and makes their tls implementation as part of free ser.
I do not see that as feasible, at least not at short-term. The feature is commercially available to those with a compelling need for it.
-jiri
Marian,
When you say to use authentication between server are you suggesting that the proxy that the users are hanging off authenticates all INVITE requests before forwarding them onto the proxy that controls access to the gateway? Or are you referring to some form of proxy to proxy authentication mechanism? If so what is it, as I've never come across one before and would be very interested in knowing more about it. I think using IPSEC/TLS is a little heavy duty for our needs. We require some means of verifying the identity of the remote SIP proxy that does not go by source IP address.
Regards,
Alan
-----Original Message----- Hi Alan,
Excepting source IP check (which is not reliable), you can also use authentication between server - SIPproxy2 authenticates all request sent to SIP proxy1 and vice-versa.
Since the end points are fixed (PSTN GWs), you can create IPSEC tunnels to transport the signaling part. Tunneling also the media will probably introduce delay and will require some really performat machines :-).
Also you can go for TLS, which is as concept basically the same thing IPSEC tunnels. The major difference is that TLS is not free as IPSEC is.
Best regards, Marian
------------------------------------------------------------------------------------------------------- This email, and any files transmitted with it, is copyright and may contain confidential information. The contents are intended for the use of the addressee(s) only. Unauthorized use may be unlawful. If you receive this email by mistake, please advise sender immediately. The views of the author may not necessarily constitute the views of Telco Electronics Limited. Nothing in this mail shall bind Telco Electronics Limited in any contract or obligation.
Telco Electronics Limited 6-8 Oxford Court Brackley Northants NN13 7XY
Tel 01280 761600 Fax 01280 841174
On 18-02 09:51, Alan Litster wrote:
Marian,
When you say to use authentication between server are you suggesting that the proxy that the users are hanging off authenticates all INVITE requests before forwarding them onto the proxy that controls access to the gateway? Or are you referring to some form of proxy to proxy authentication mechanism? If so what is it, as I've never come across one before and would be very interested in knowing more about it. I think using IPSEC/TLS is a little heavy duty for our needs. We require some means of verifying the identity of the remote SIP proxy that does not go by source IP address.
The problem here is that SER cannot respond to digest challenge. Therefore you cannot use digest authentication between the proxies.
If your PSTN gateway supports digest authentication, then you could possibly configure it with the credentials of the remote SIP proxy and the proxy which is "close" to the gateway would just forward the digest challenge to the pstn (401/407).
Jan.
Hi Alan,
I was referring to proxy to proxy authentication. We, Voice System, prepare to launch in terms of days a new SER module that will enhance SER with the capability of performing UAC authentication. With this feature, your SER proxies will be able to authenticate between them totally transparent for the end users.
Best regards, Marian
Alan Litster wrote:
Marian,
When you say to use authentication between server are you suggesting that the proxy that the users are hanging off authenticates all INVITE requests before forwarding them onto the proxy that controls access to the gateway? Or are you referring to some form of proxy to proxy authentication mechanism? If so what is it, as I've never come across one before and would be very interested in knowing more about it. I think using IPSEC/TLS is a little heavy duty for our needs. We require some means of verifying the identity of the remote SIP proxy that does not go by source IP address.
Regards,
Alan
-----Original Message----- Hi Alan,
Excepting source IP check (which is not reliable), you can also use authentication between server - SIPproxy2 authenticates all request sent to SIP proxy1 and vice-versa.
Since the end points are fixed (PSTN GWs), you can create IPSEC tunnels to transport the signaling part. Tunneling also the media will probably introduce delay and will require some really performat machines :-).
Also you can go for TLS, which is as concept basically the same thing IPSEC tunnels. The major difference is that TLS is not free as IPSEC is.
Best regards, Marian
This email, and any files transmitted with it, is copyright and may contain confidential information. The contents are intended for the use of the addressee(s) only. Unauthorized use may be unlawful. If you receive this email by mistake, please advise sender immediately. The views of the author may not necessarily constitute the views of Telco Electronics Limited. Nothing in this mail shall bind Telco Electronics Limited in any contract or obligation.
Telco Electronics Limited 6-8 Oxford Court Brackley Northants NN13 7XY
Tel 01280 761600 Fax 01280 841174
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Marian,
That sounds very interesting, I was thinking about writing one myself to authenticate invites between our own proxies for outbound pstn calls. Will this module be released in the same way that your avpops was?
If feel that that's one of the main missing fetaures of SIP, some kind of proxy-to-proxy auth. We've used a RADIUS auth model previously to authenticate UAC from one domain on another although this does not work under all circumstances.
Regards,
Alan
-----Original Message----- From: Marian Dumitru [mailto:marian.dumitru@voice-sistem.ro] Sent: 18 February 2005 19:53 To: Alan Litster Cc: SER Mailing List Subject: Re: [Serusers] Security methods for PSTN termination of SIP calls
Hi Alan,
I was referring to proxy to proxy authentication. We, Voice System, prepare to launch in terms of days a new SER module that will enhance SER with the capability of performing UAC authentication. With this feature, your SER proxies will be able to authenticate between them totally transparent for the end users.
Best regards, Marian
Alan Litster wrote:
Marian,
When you say to use authentication between server are you suggesting that the proxy that the users are hanging off authenticates all INVITE requests before forwarding them onto the proxy that controls access to the gateway? Or are you referring to some form of proxy to proxy authentication mechanism? If so what is it, as I've never come across one before and
would
be very interested in knowing more about it. I think using IPSEC/TLS is a little heavy duty for our needs. We require some means of verifying the identity of the remote SIP proxy that does not go by source IP address.
Regards,
Alan
-----Original Message----- Hi Alan,
Excepting source IP check (which is not reliable), you can also use authentication between server - SIPproxy2 authenticates all request sent to SIP proxy1 and vice-versa.
Since the end points are fixed (PSTN GWs), you can create IPSEC tunnels to transport the signaling part. Tunneling also the media will probably introduce delay and will require some really performat machines :-).
Also you can go for TLS, which is as concept basically the same thing IPSEC tunnels. The major difference is that TLS is not free as IPSEC is.
Best regards, Marian
-----------------------------
This email, and any files transmitted with it, is copyright and may
contain confidential information.
The contents are intended for the use of the addressee(s) only. Unauthorized use may be unlawful. If you receive this email by mistake, please advise sender immediately. The views of the author may not necessarily constitute the views of Telco
Electronics Limited.
Nothing in this mail shall bind Telco Electronics Limited in any contract
or obligation.
Telco Electronics Limited 6-8 Oxford Court Brackley Northants NN13 7XY
Tel 01280 761600 Fax 01280 841174
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Voice System http://www.voice-system.ro
------------------------------------------------------------------------------------------------------- This email, and any files transmitted with it, is copyright and may contain confidential information. The contents are intended for the use of the addressee(s) only. Unauthorized use may be unlawful. If you receive this email by mistake, please advise sender immediately. The views of the author may not necessarily constitute the views of Telco Electronics Limited. Nothing in this mail shall bind Telco Electronics Limited in any contract or obligation.
Telco Electronics Limited 6-8 Oxford Court Brackley Northants NN13 7XY
Tel 01280 761600 Fax 01280 841174
-
Alan Litster -
Jan Janak -
Jiri Kuthan -
Juha Heinanen -
Marian Dumitru