IP_tec - iptel.org

Download Report

Transcript IP_tec - iptel.org

SIP: Advanced Topics
Dr. Dorgham Sisalem
Interworking with PSTN
Interoperability Issues
•
IP-PSTN Gateways make the conversion job
 convert both signaling and media
 may be split into media and signaling gateways (MGCP/Megaco)
 many pains: DTMF, IVRs, overlapped dialing, national signaling dialects
 gateways act as UAs from SIP perspective
•
Convergent Services
 PINT


allow Internet users to trigger PSTN services
e.g., click to PSTN-dial
 SPIRITS


•
allow PSTN events to trigger Internet services
e.g., Internet Call Waiting
Sigtran - Trunk replacement
 Carry SS7 messages over IP
 Map SS7 protocols to equivalent protocols running over IP
Tekelec Confidential
PSTN Gateways
•
Basic building block of PSTN interworking scenarios: gateways convert
signaling and media
•
The gateway can be split in media and signaling components and connected
through MGCP or Megaco
•
They need to be found on the Internet: problem similar to that of IP routing.
Methods include:
 Static configuration

Define which numbers belong should be routed to which gateway
 TRIP routing protocol

Discover dynamically which gateways are available and their characteristics
 ENUM -- used to map digits into SIP URIs
Tekelec Confidential
PSTN Gateways
IP world
SIP
RTP
PSTN
SIP
SS7/ISDN
Internal Logic
RTP/IP
TDM
Tekelec Confidential
Telephony Routing over IP (TRIP)
•
Exchange of call routing information between cooperating providers
•
Eouting services (e.g. ‘find cheapest gateway to China) may be
provided by third parties
•
Design
 follows IP routing protocols (BGP4, IS-IS)
 exploits scalable techniques: routing information is aggregated and
redistributed, incremental updates, soft-state design
 TRIP used to send, receive or send&receive
•
References
 RFC2871, draft-ietf-iptel-trip
Tekelec Confidential
Call Flow SIP to PSTN
•
Request-URI in the INVITE contains a
Telephone Number which is sent to
PSTN Gateway.
•
The Gateway maps the INVITE to a
SS7 ISUP IAM (Initial Address
Message)
•
183 Session Progress establishes
early media session so caller hears
Ring Tone.
•
Two way Speech path is established
after ANM (Answer Message) and 200
OK
Tekelec Confidential
Slide courtesy of Alan Johnston,
WorldCom. (See reference to Alan’s
SIP book.)
PSTN GW != SIP proxy
•
PSTN gateways are adapters
between two different
technologies.
•
From SIP perspective, PSTN
gateways are SIP termination
devices, i.e., SIP User Agents just
like IP phones.
•
•
[email protected]
media
SIP
PSTN gateway functionality
separate from call processing
logic residing at a proxy.
Gateway operator != proxy
operator.
PSTN Gateway
na.pstn.com
call processing logic:
If ($destination in PSTN) then
route_to_least_cost_gateway();
elseif local(“sipforfree.com.au”) then
lookup_registry;
else proxy_to_foreign_domain();
Frequently
SIP Proxy & Registrar
Misunderstood
sipforfree.com.au
Issue
Tekelec Confidential
ENUM
RFC2916
•
Problem: caller is in PSTN (can use only digit keys) and would like to
reach a SIP callee
•
Answer: ENUM. Create a global directory with telephone numbers
that map to SIP addresses (or e-mail, etc.).
•
Lookup mechanism: DNS maps E.164 numbers to a set of userprovisioned URI
Tekelec Confidential
ENUM Call Flow
•A gateway is assigned a range of E.164 numbers
•DNS/ENUM helps ingress gateway to resolve SIP address from E.164
number
•Typically, owner of an ENUM entry can manipulate the address
association through a web provisioning interface
?...7.1.9.4.e164.arpa
PSTN: +4917…
DNS/
ENUM
! sip:[email protected]
INVITE sip:[email protected]
Gateway with
ENUM resolution
Tekelec Confidential
Other Issues
•
SIP-T:





Similar to SIGTRAN
Transfer SIP messages between gateways
Translate as far as possible between SIP messages and SS7 messages (Invite—IAM ..)
Add SS7 content as message body to SIP messages
Advantage

•
Support trunking and SIP end devices
DTMF


Needed to control services in PSTN and phones with only a numeric pad
Can be carried in:



INFO requests: This is number 1
Part of audio (RTP stream): Only works for PCMU, more efficient compression styles can not carry the tones in a correct and
reconstructable manner
RTP messages describing the DTMF codes
Tekelec Confidential
SIP Security
Security Services
•
Availability
 subject to Denial of Service Attacks: burdening servers with enormous
load, uploading hostile applications, physical violence
 difficult to beat: self vs. non-self problem
•
Privacy
 prevents unauthorized persons from inspection of both signaling and
media
 can be solved using encryption
 problems: encryption computationally expensive; key exchange
protocols needed; no PKI available
Tekelec Confidential
Security Services
•
Message Integrity
 prevents unauthorized users from changing packets
 can be solved using Message Authentication Checks
•
User Authenticity
 prevents unauthorized users from using someone’s else identity to fool
other users or accounting & charging systems
• Anonymity
 prevents other call parties from knowing who is calling
Tekelec Confidential
Disclaimers & Problems
•
Disclaimer #1: Protocol security is only a piece of the big picture; security of a
system may always be compromised by naïve implementation or
administration.
•
Disclaimer #2: Security of a single protocol does not help; all participating
protocols have to be made secure.
•
Disclaimer #3: Physical security counts as well!!!
•
Disclaimer #4: Security protocols cannot solve social-layer issues.
Tekelec Confidential
Media Security
•
Encryption of media content
•
May take place either at IP or RTP layer
•
Performance overhead considerable
•
No established solutions for keying
Tekelec Confidential
SIP Security Tools
•
Need to protect registrations
 User A should not be allowed to register as user B
•
Need to protect service usage
 User A should not be allowed to use the PSTN gateway
•
Need to ensure the identity of the server
 Avoid contacting insecure servers
•
Need to secure content
 Do not allow servers to manipulate content not meant for them
Tekelec Confidential
SIP Security Tools
•
Most commonly used security protocol: digest
 Based on private secret
 Allows to establish user identity
 Does not provide message integrity or privacy
•
TLS – addresses shortcomings of digest, but not widely deployed yet
•
End-2-end security: S/MIME
•
Alternate security protocols for 3GPP
Tekelec Confidential
SIP Digest Authentication
•
•
Required for user identification and
admission control for services.
Request
challenge-response using MD5
Challenge
(nonce,realm)
ACK
Request
w/credentials
Tekelec Confidential
Proxy
Policy based security
•
Authenticate the user only for certain
services
 Calling another VoIP user is free of
charge

AAA
No need for authentication
 Calling an ISDN user is not free

•
Proxy
Authenticate the user first
Require am authentication,
authorization and accounting server
for:
 Maintaining information about the
user‘s



Privileges
Account information
Used resources
Tekelec Confidential
Request
PSTN GW
Can not solve social issues!!!
SIP INVITE w/JPEG
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP here.com:5060
From: BigGuy <sip:[email protected]>
To: LittleGuy <sip:[email protected]>
Call-ID: [email protected]
...
200 OK w/JPEG
SIP/2.0 200 OK
Via: SIP/2.0/UDP here.com:5060
From: BigGuy <sip:[email protected]>
To: LittleGuy <sip:[email protected]>
Call-ID: [email protected]...
Tekelec Confidential
Message Security
•
Users can encrypt the content of their messages to prevent SIP proxies from
reading or changing the content
•
Can only encrypt parts that are not used by proxies
 VIA, recordroute, ...
•
Encryption might prevent some functions
 Firewall/NAT traversal
•
Hop-by-Hop Signaling Security





requires belief in transitive trust
immense computational stress on servers if public-key used
can deal with firewalls/NATs
may cover entire signaling
mechanisms: ipsec, TLS
•
Combination of both may be used
•
Keying: no established solution
Tekelec Confidential
Peering & Inter-Provider Security
•
General:

To reach a wider user population providers need to cooperate, however


Use chained trust relations





Similar to web security
A and B exchange certificates which are authenticated either directly or through a third trusted party
Example

[email protected] would like to call to PSTN through his gateway operator


which telephone number to display at the receiver?
Proxies need to link SIP address to a phone number

•
Provider A authenticates and authorizes his users
Provider A has a trust relation with provider B
All requests arriving on the secure tunnel are trusted
Secure tunnels established using TLS

•
IP-Technology offers various attack possibilities and security hole
Remote party ID
Fun:

Allow for distinctive ringing

Not trusted calls have a distinctive ringing at the receiver
Tekelec Confidential
Remote Party ID (RPID)
+49-179-123123
INVITE sip:[email protected]
From: sip:[email protected];tag=12
To: sip:[email protected]
a
User ID/phone number database
INVITE sip:[email protected]
From: sip:[email protected];tag=12
To: sip:[email protected]
Remote-Party-ID:
<sip:[email protected]>
PSTN
SER with RPID support
Tekelec Confidential
PSTN gateway
Problem of Trust
•
Displaying proper caller ID is a legal requirement for operators.
 What happens if someone fakes the RPID and operator displays a wrong number?
 Gateway should only display caller ID issued by a trustworthy source.
•
Trust needed to solve other problems too: Does the call come from a source
to whom my gateway can credit international calls?
•
Establishing trust to individual users within a single domain almost easy…but
what if multiple domains comes in?
Tekelec Confidential
Trust: Interdomain versus Intradomain
•
Within single administrative domain, trust can be implemented using physical
security and knowledge of identity of local users – proxy servers verify identity
of local users using digest and gateways trust local proxies.
•
Interdomain scenario example: iptel.org users terminate calls to US PSTN
with National Gateways Inc. How do you export the trust then?
 The terminating provider can’t verify identity of remote users and can’t trust
information passed over the public Internet. RPID alone can’t be trusted as it can
be changed anywhere on the transit. Stronger security protocols come in for
interdomain operation: TLS.
Tekelec Confidential
TLS Use for Interdomain Security
Internet
PSTN
#1
#2
TLS
Originating domain
Public
Internet
•
Assumption: target domain trusts source domain to display proper CallerID and settle incurred
costs.
•
Step 1: originating domain verifies identity of local user (digest). If ok, it appends RPID and
uses TLS for secure inter-domain communication.
•
Step 2: terminating proxy verifies incoming TLS connection against list of trustworthy
domains. If ok, SIP request is forwarded to PSTN gateway.
Tekelec Confidential
More on TLS Use
•
TLS use for SIP solves other trust problems too:
 With trust mechanisms, interdomain accounting can be also implemented
securely
 Signaling can be no longer sniffed during transport.
•
Security Disclaimers:
 Trust established hop-by-hop – it implies transitive trust along arbitrarily
long proxy chains. Remember a chains is as strong as the weakest
element in it. You have to trust next-hop not to pass your requests to
questionable servers.
 Privacy is not end-to-end: proxy servers along the signaling path do see
SIP in plain-text,
Tekelec Confidential
SIP Service Space
What’s the Killer App?
•
Q: Added-value services expected to be major source of revenues. So what
is the killer app?
•
A: If I saw raw gold on the street I would not tell you either.
•
It is believed that the convenience of integrated services will be the killer.
•
Couple of examples follow...
Tekelec Confidential
IN-like Services with SIP
•
Most of IN services may be easily
implemented with SIP in proxies/redirect
servers/UAs:







•
(Un)conditional call forwarding
abbreviated dialing
Screening
distinctive ringing
call distribution
call transfer
etc.
Sometimes, implementation logic may
completely differ.



Televoting and IVRs likely to be replaced by Web
in the long run.
Call-waiting is end-device implementation issue
with no protocol support.
Music-on-hold may be played localy.
The real benefit is those services beyond IN: straight-forward
integration with web, email, instant messaging, etc.
Tekelec Confidential
draft-ietf-sip-cc-transfer
Call Transfer
•
Accomplished using the REFER method.
•
The REFER method indicates that the recipient (identified by the Request-URI) should
contact a third party using the contact information provided in the method.
•
New header fields: Refer-To, Refer-By.
•
NOTIFY method used to report on result of referral.
•
Note: No changes to proxy behavior required.
•
Variants:


With Consultation Hold (SIP Hold and unattended transfer)
Attended Transfer, I.e., with a short conference
Tekelec Confidential
Example:
Call Transfer Call Flow
#1
A
REFER B
To: B
Refer-To: C
Referred-By: A
A is having a call with B. A decides to
transfer B to C. It sends a “REFER” to
B with C’s address. Eventually, A is
notified on successful transfer using
NOTIFY (#6).
B
#2 202 Accept
#3
#4
#6
NOTIFY (OK)
#7
#5
INVITE C
Referred-By: A
200 OK
200 ACK
200 OK
media
Tekelec Confidential
C
3rd Party Call
Control (3pcc)
•
3pcc = Ability of a party to establish a session between other parties.
•
Examples of use:



a click-to-dial service within a web phone-book
Operator services
Scheduled calls
•
Design objective: use SIP “as is”
•
Solution: send “empty INVITES”, and swap replies with SDP ACKs
•
Controller may issue either its own or other’s party “forged” From address. (Its real
identity may be still verified using authentication.)
•
Controller often called back-2-back user agent
 Act as two user agents acting back-2-back
 Manipulate messages coming from one agent before sending to the other
 Main state information about the two sessions
draft-rosenberg-sip-3pcc
Tekelec Confidential
draft-rosenberg-sip-3pcc
Example: 3pcc call flow
#1
Controller C (e.g., co-located
With a web server)
INV w/o SDP
#2
A
200 SDP A1
#3 ACK on-hold
#6
#4
#5
INV SDP B
#7
#8
200 SDP A2
#9 ACK
media
timeline
Tekelec Confidential
INV w/o SDP
200 SDP B
200 ACK w/A2’
B
Answering Machine
•
Old-times behavior: set-up number of rings, plug-in, if you do not answer the machine will
•
Easy to mimic with SIP: AM acts as a SIP UA; you need to set-up an answer timer, let the answering
machine register using your credentials; when an invitation arrives it is forked both to your phone
and your answering machine
•
Added value examples:


Unified messaging: SIP answering machine can turn voice messages into email messages that follow you or
comprehensive web-pages (cf. voice navigation)
Programmability allows to play variety of customized prompt messages:

If (caller  friends) then play (“You can reach me at Venice beach or leave a message”) else play (“leave a message
please”);
#1 INVITE
#2 Trying
#3 INVITE
#4 Ringing
#5 CANCEL
#6 OK
Tekelec Confidential
#7 INVITE
AM