17 Feb
2005
17 Feb
'05
4:10 p.m.
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
17 Feb
17 Feb
6:18 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Voice System
http://www.voice-system.ro
10:27 p.m.
New subject: [Serusers] how to get TLS into free part of ser?
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
10:58 p.m.
New subject: [Serusers] how to get TLS into free part of ser?
At 10:27 PM 2/17/2005, Juha Heinanen wrote:
Marian Dumitru writes:
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.
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.
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
18 Feb
18 Feb
10:51 a.m.
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
8:12 p.m.
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.
8:53 p.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Voice System
http://www.voice-system.ro
21 Feb
21 Feb
11:30 a.m.
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(a)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
7241
days inactive
7245
days old
7 comments
5 participants
participants (5)
-
Alan Litster -
Jan Janak -
Jiri Kuthan -
Juha Heinanen -
Marian Dumitru