Multimedia Communication in the Internet. SIP: Advanced Topics. Dorgham Sisalem, Sven Ehlert Mobile Integrated Services FhG FOKUS

Transcription

1 Multimedia Communication in the Internet SIP: Advanced Topics Dorgham Sisalem, Sven Ehlert Mobile Integrated Services FhG FOKUS

2 SIP and NAT

3 NAT Concept NAT = Network Address Translation Share one IP address among many hosts Conceal internal structure of intranet NAT solution to map between private and public addresses Scenarios IP Company with an address block of insufficient size Private DSL line sharing : : :80 NAT :20080

4 NAT Classification RFC 2663: IP NAT Terminology and Considerations Full Cone Restricted Cone Port Restricted Cone Symmetric NAT Generally dynamic mappings for a short time Contact Source User Client Contact Target

5 Full Cone NAT Mappings well established A: P:20100 A: P:8000 A: P:12000

6 Full Cone NAT Mappings well established Connection from public Internet possible if mapping known A: P:20200 A: P:20100 A: P:8000 A: P:12000

7 Restricted NAT Mappings established on client request A: P:20100 A: P:8000 A: P:12000

8 Restricted NAT Mappings established through client connection Connection from public Internet only possible after client request A: P:20200 A: P:20100 A: P:8000 A: P:12000

9 Restricted NAT Mappings established through client connection Connection from public Internet only possible after client request Port Restricted NAT applies also to different ports on same host! P:20100 P:20101 A: P:8000 A: P:12000

10 Symmetric NAT Mappings depend on target IP Every new target establishes a new mapping Connection from public Internet only possible after client request P:12000 P:12001 A: P:20200 A: P:20100 A: P:8000 A:

11 SIP Traffic Flow Signaling Protocol Media Transport End Users Call Server End Users IP Router Signaling and Media traffic might pass different hosts

12 SIP Through NAT UA1 NAT Proxy UA IPSRC :5060 IP Source with Port INVITE Via: SIP/2.0/UDP :5060 Contact: Content-Type: application/sdp c=in IP m=audio 8000 RTP/AVP 4 SIP Message with SDP

13 SIP Through NAT UA1 NAT Proxy UA ? IPSRC :5060 INVITE Via: SIP/2.0/UDP :5060 Contact: Content-Type: application/sdp c=in IP m=audio 8000 RTP/AVP 4 IPSRC :1234 INVITE sip:user@ Via: SIP/2.0/UDP :5060 Contact: user@ Content-Type: application/sdp c=in IP m=audio 8000 RTP/AVP 4

14 SIP Through NAT UA1 NAT Proxy UA ? IPSRC :1234 INVITE Via: SIP/2.0/UDP :5060 Contact: Content-Type: application/sdp c=in IP m=audio 8000 RTP/AVP 4 IPSRC :1234 INVITE sip:user@ Via: SIP/2.0/UDP :5060; \ received: ;rport:1234 Contact: user@ Content-Type: application/sdp c=in IP m=audio 8000 RTP/AVP 4

15 SIP Through NAT UA1 NAT Proxy UA ? IPSRC :1234 INVITE Via: SIP/2.0/UDP :5060 Contact: Content-Type: application/sdp c=in IP m=audio 8000 RTP/AVP 4 IPSRC :5060 INVITE sip:user@ Via: SIP/2.0/UDP :5060 Via: SIP/2.0/UDP :5060 Contact: user@ Content-Type: application/sdp c=in IP m=audio 8000 RTP/AVP 4

16 SIP / NAT Problems Signaling traffic Routing back to the NATed UA Future requests to a NATed contact Media Traffic Payload SDP address does not match contact address And more!

17 SIP NAT Solutions Messages have to be altered to reflect present address Responsibility of NAT or UA? NAT: Application Layer Gateway Needs access to the NAT / firewall Needs special configuration Cascading NATs? UA Needs enhanced UAs Needs means to detect real IP Query NAT, e.g. UPnP Query external Server, e.g. STUN Can recognize cascading NAT

18 NAT + ALG UA1 NAT+ALG Proxy UA INVITE sip:user@ Via: SIP/2.0/UDP :5060 Contact: user@ Content-Type: application/sdp c=in IP m=audio 8000 RTP/AVP 4 INVITE sip:user@ Via: SIP/2.0/UDP :1234 Contact: user@ Content-Type: application/sdp c=in IP m=audio 3456 RTP/AVP 4

19 STUN Simple Traversal of UDP Through NATs RFC 3489 Simple client-server protocol Detects type of NAT used and public visible addresses Does not work with Symmetric NATs!... Client NAT's STUN server Public Address Space

20 SIP with STUN STUN UA1 NAT Proxy UA use STUN to find out public RTP address: c=in IP c=in IP m=audio 8000 RTP/AVP 4 m=audio 3456 RTP/AVP 4

21 NAT and RTP Symmetric NAT client cannot detect its public address with a NAT probe Different types of NAT need to send traffic before they can receive traffic (Port) Restricted NAT, symmetric NAT Connection Oriented Media Send before receive What if both UA's are behind a restricted NAT? RTP Proxy / Relay Intermediate RTP connection between two Uas Located in public Internet

22 RTP Relay DeltaThree 1) UA sends INVITE to proxy 2) Proxy contacts Relay to setup RTP session 3) Relay assigns Port and forwards it to proxy 4) Proxy modifies SDP and forwards this to destination

23 RTP Relay DeltaThree 5) OK from destination with its own SDP 6) Proxy delivers SDP information to relay (or instructs to setup a new session if destination is also behind symmetric NAT) 7) Relay informs proxy of new port 8) Proxy forwards OK to UA with modified SDP

24 RTP Relay DeltaThree 9) RTP traffic to RTP relay 10)Relay notes first incoming packet for further use 11)Destination sends RTP 12)RTP traffic is sent to address captured in 10)

25 NAT Summary SIP and NAT are not meant for each other! NAT won't disappear in the short term IPv6 still not deployed yet No standardized NAT established Workaround for SIP exist, but it's no perfect solution Signaling information has to be patched Media information has to be patched Media traffic needs to be relayed

26 SIP Security

27 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 Authorization 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 Authentication, Accounting

28 Disclaimers & Problems Disclaimer #1: Protocol security is only a piece of the big picture; security of a system may always be compromised by naive 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.

29 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

30 Policy Based Security Authenticate the user only for certain services Calling another VoIP user is free of charge No need for authentication Calling an ISDN user is not free Authenticate the user first Require am authentication, authorization and accounting server for: Maintaining information about the user s Privileges Account information Used resources Request Proxy AAA PSTN GW

31 SIP Digest Authentication Required for user identification and admission control for services. Based on HTTP Digest (RFC2617) Sender: Sends Realm, Nonce (with optional timestamp embedding) User: generates Hash over User, Realm, Password, Method, Request URI If Hash at server match, access is granted Hash: Algorithm generating small output One way generation Collision resistant Computationally simple Request Challenge (nonce,realm) ACK Request w/credentials

32 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

33 Media Security Encryption of media content May take place either at IP or RTP layer Performance overhead considerable No established solutions for keying

34 Social Issues! SIP INVITE w/jpeg INVITE SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy Call-ID: 200 OK w/jpeg SIP/ OK Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy Call-ID:

35 Peering & Inter- Provider Security General: To reach a wider user population providers need to cooperate, however IP-Technology offers various attack possibilities and security holes Use chained trust relations 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 Similar to web security A and B exchange certificates which are authenticated either directly or through a third trusted party Example user@iptel.org 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 Remote party ID Fun: Allow for distinctive ringing Not trusted calls have a distinctive ringing at the receiver

36 Object 1 Remote Party ID (RPID) User ID/phone number database INVITE sip:1234@gw.com From: sip:a@bc.de;tag=12 To: sip:1234@gw.com a INVITE sip:1234@gw.com From: sip:a@bc.de;tag=12 To: sip:1234@gw.com Remote-Party-ID: <sip: @gw.com> PSTN SER with RPID support PSTN gateway

37 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?

38 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

39 More on TLS 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.