ICE, STUN, TURN. Mészáros Mihály NIIF Institute. Federated STUN/TURN service PoC/Pilot experiences. 4th TF-WEBRTC meeting - DFN Berlin 2016

Transcription

1 ICE, STUN, TURN Federated STUN/TURN service PoC/Pilot experiences Mészáros Mihály NIIF Institute 4th TF-WEBRTC meeting - DFN Berlin 2016

2 STUN, TURN, ICE STUN Classic - RFC 3489 (2003 March) Simple Traversal of UDP Through NATs STUN - New - RFC 5389 (2008 October) Session Traversal Utilities for NAT TURN - RFC 5766 (2010 April) Traversal Using Relays around NAT (Relay Extensions to STUN) ICE RFC 5245 (2010 April) Interactive Connectivity Establishment

3 Table of Contents Overview: Firewall vs. Real Time Communication (RTC) WebRTC and ICE/STUN/TURN Types of NAT and NAT behavior Discovery ICE, STUN, TURN Auth Methods and implementation overview. GÉANT 4 SA8 T2 Proof of Concept STUN/TURN experiences Lessons learned Symposium demos Summary

4 WebRTC

5 WebRTC & Firewall / NAT Traversal

6 WebRTC WebRTC transport draft ICE is mandatory 10% 2% 7% 13% ICE depend on STUN/TURN service Direct STUN/NAT TURN/UDP TURN/TCP TURN/TLS WebRTC is not only Web Mobil, Native application WebRTC isn't only Video Call WebRTC in every browser and beyond.. 68% Datasource:callstats.io

7 Firewall vs RTC

8 Firewall keeps the unwanted traffic Outside

9 But also adds barriers to RTC

10 The Goal: Standard based solution that solves RTC Firewall/NAT traversal

11 Firewall Traversal Traversal is getting more and more complicated Moving target Today Internet: NAT (different types), Firewall (packet filters), IPv4 => IPv6 transition, Multi homing, etc. TCP not ideal for RTC

12 NAT

13 NAT types (RFC 3489) Full-cone NAT "Restricted Cone" NAT Address-restricted-cone NAT Server 1 NAT Client Port-restricted cone NAT Server 2 Symmetric NAT "Full Cone" NAT Server 1 "Port Restricted Cone" NAT NAT Server 1 NAT Client Client Server 2 Server 2

14 Symmetric NAT "Symmetric" NAT Server 1 NAT Client Server 2

15 RFC 4787 and RFC 5780 vs RFC 3489 Mapping EIM ADM APDM Filtering EIF ADF APDF Source:

16 Map Detection TEST I Primary IP, Primary Port TEST II Alternate IP, Primary Port TEST III Alternate IP, Alternate Port Image Source:

17 Filtering Detection TEST I Primary IP, Primary Port TEST II Change Request IP and Port TEST III Change Request Port Image Source:

18 Linux NAT Allow IP forwarding sysctl net.ipv4.ip_forward=1 Symmetric NAT Address and Port dependent Mapping Address and Port dependent Filtering iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE --random Port restricted Cone NAT Endpoint Independent Mapping Address and Port dependent Filtering iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

19 RFC5780 and coturn NAT behavior is not always constant in time! NAT could change characteristics during attacks, or high load, etc. Still worth to understand the current behavior. RFC NAT Behavioral Requirements for Unicast UDP coturn provides a brilliant stun client library Based on it I created a utility to detect NAT type according RFC5780 bin/turnutils_natdiscovery -f -m

20 Example symmetric NAT output bin/turnutils_natdiscovery -f -m ======================================== NAT with Address and Port Dependent Mapping! ======================================== ======================================== NAT with Address and Port Dependent Filtering! ========================================

21 ICE, STUN, TURN

22 ICE step by step Discovery and Candidate gathering Allocation Prioritisation Exchange Connectivity Check Frozen Algorithm Coordination Communication

23 IP address, and port discovery Candidate pair IP address, port, protocol Types Relayed Reflexive Server, Peer Host Y:y TURN Server Public Internet X':x' NAT X:x UA

24 Why cause problem gathering all addresses? ICE gathers ALL(!) Fix is under way By Design draft-ietf-rtcweb-ip-handling to find the best way Chrome IP address leakage expose your IP addresses Private, Public, VPN etc. Solution: Limit candidate discovery Limit interface and address gathering Opt-In: Network limiter extension Step two: build in the core, and make it default Firefox New UI tools to restrict candidates

25 Trickle ICE Slide from: trickle-ice-iet86-orlando.pptx STUN Server Alice disco STUN Server Bob disco offer and candidates answer and candidates Alice STUN Server disco connectivity checks Vanilla ICE as per RFC 5245 Bob O/A with host or no cands more cands & conn checks STUN Server disco

26 RETURN RETURN Recursively Encapsulated DNS Auto-Discovery Corporate Border Proxy Corporate and Application Leakiness Leaky: Use all possible Sealed: force only enterprise TURN Proxy-t inside network / \ NAT/FW host O / \ srflx......o relay / \ relay srflx O host O \ / \ / \ / Browser Border TURN Proxy server KEY outside network / \ O O \ / Application TURN server O Candidate... Non encapsulated TURN encapsulated Double TURN encapsulated Network edge

27 STUN Auth Methods

28 Long Term vs Short Term STUN (RFC5389) define to Credential Auth Mechanism Short-term Credential mechanism Use once Every-time new encryption key ICE using it for connection check sdp (a=ice-ufrag and a=ice-pwd) Long-term Credential mechanism Credential is not limited in time. Main Usage STUN reflexive address detection and TURN relay allocation Stored in a User Database (HA1)

29 Long Term Credential User, Realm, Password Origin based REALM (draft-ietf-tram-stun-origin) /WebRTC/ User Database stores HA1 HA1=MD5( user:example.com:mysecret ) Message Integrity Algorithm (SHA1) HMAC(M, MD5( user:example.com:mysecret )) Protection against reply based attacks It is the base auth method for STUN

30 WebRTC & LTC = not perfect match Long Term Credential Summary of problems: draft-reddy-behave-turn-auth Keeping password in secret is difficulty for Web Apps Message Integrity is not protected against Off-line dictionary attacks. The Server makes lookup in the User Database for the credential. The username is not encrypted in STUN message and this way could be used for tracking. Short Term Credential (only for one connection) No protection against reply attacks Designed for short term

31 STUN auth for WebRTC = REST API (Time Limited Long Term Credential) draft-uberti-rtcweb-turn-rest-00 REST API and STUN/TURN server shared secret. The Service Provider Identified by an api_key and get on behalf the end-user request and get a time limited credential. The web application transfer this credential to the end-user browser JS API. username = timestamp and an application specific data seperated by a :.

32 REST API Operation Overview (Time Limited Long Term Credential) REST API Web App Shared Secret Turn Server

33 OAuth RFC 7635

34 Proof of Concept

35 PoC Overview Web Frontend After AAI: edugain get (LTC) usr/pwd credential get key to REST API Distributed service NIIF, UNINETT, FCT/FCCN Closest Server (GeoIP) Auth methods LTC,REST API, OAuth (coming soon)

36 Ansible Automated install central Configure even more OS (firewall,ntp,fail2ban,etc.) Certs Web Server and PHP Configure SimpleSAMLPHP EduGAIN privacy statement Install Composer MySQL master Automated install slaves OS (firewall,ntp,fail2ban,etc.) MySQL slave coturn Update php libs Checkout git Frontend REST API Setup replication Master and Slave sides

37 Design Goals Only Open Source components (Debian Jessie, etc.) Supporting all possible Authentication methods LTC, REST, OAuth AAI enabled edugain front-end site Distributed back-end database Secure Communication, IPv6, DNSSEC Support wide range of STUN/TURN transport protocols Automated deployment

38 Security Design Principles LTC user password is generated to avoid any Offline dictionary attacks. According STUN RFC recommendation the password SHOULD have at least 128 bits of randomness We use 32 alphanumeric ~190 bit (hackzilla/password-generator) REST API_KEY is generated random key and has one year expiration 32 alphanumeric char ~190 bit (hackzilla/password-generator) Shared Secret between API and coturn is rotated daily

39 TURN servers Technology Scouting Open source implementations: Commercial implementations: stun-turn-server/ /procall/5/erestunservice/dokume ntation/index.htm Etc. Commercial Services: Etc.

40 coturn TURN with co-location of multiple realms coturn.net - Open Source STUN/TURN implementation Written in C, Rock Solid and, low HW intensity It follows IETF TRAM WG works very closely. Supports multiple backend database types (5) STUN over UDP/TCP/TLS/DTLS/SCTP TCP/UDP (Relay) Auth methods: LTC, REST (Time limited LTC), OAuth IPv4 and IPv6

41 User Frontend Landing Web Page SimpleSAMLphp, edugain Auth, we request 4 attributes Bootstrapzero design Quick&Dirty PoC level implementation REST API "slim/slim": "^2.6" "zircote/swagger-php": "^2.0" "geoip/geoip": "~1.14" (IPv6) mjaschen/phpgeo": "^0.3.0"

42 Live Demo:

43 Pick the closest STUN/TURN LTC REST DNS GeoIP based Views Based on Location of DNS resolver not the client (!) OpenDNSSEC not yet supporting views! Issue: OPENDNSSEC-232 AnyCast Provider independent IPv4 /24 IPv6 /64 Input the user IP address the web server side application Local GeoIP database IP => Coordinate Vincenty's formulae Coordinates => Distance

44 Auth methods LTC and REST client behavior is not changed. Only Server side differs. coturn doesn't support both mechanism in one daemon We used that simple design approach to separate auth methods VM level. Avoiding repackaging Multiple deamon could also work on the same VM. Drawback: normal Debian package designed to run on daemon on one host. To exploit the latest coturn implementation features we deciced to use jessiebackports repository

45 IPv6 Ready service smooth IPv6 transition All service IPv6 READY and works in dual stack STUN/TURN services Dual Allocation MySQL NTP SSH DNS Resolvers Web Server Frontend, REST API

46 MySQL Separated DB for different auth methods MySQL Replication Encrypted netfilter protects ports IP address based access controll Generated passwords Replication filtered based on DB (auth method) MySQL Events: LTC Revoking LTC back after a year REST Generating daily new shared secrets Revoking API token after a year. Shared Key aging Cause a limited problem if a REST TURN server is compromised.

47 MySQL DB Schemas

48 STUN & Long Term Credential STUN LTC authentication is optional according the RFC Pros: Use the same Auth policy for STUN and TURN Avoid attacks and server discovery. Avoid crawler robots that tracking Internet for vulnerable open STUN/TURN services. (Version) Avoid detect STUN server topology alternate address and port. Contra Work involved in authenticating the request is more than the work in simply processing it. Reality: Lack of Browser implementation

49 STUN & LTC chrome Log [1:12:0418/145114:ERROR:stunport.cc(79)] reason='unauthorized' [1:12:0418/145114:ERROR:stunport.cc(79)] reason='unauthorized' [1:12:0418/145114:ERROR:stunport.cc(79)] reason='unauthorized' [1:12:0418/145114:ERROR:stunport.cc(79)] reason='unauthorized' [1:12:0418/145114:ERROR:stunport.cc(79)] reason='unauthorized' Binding error response: class=4 number=1 Binding error response: class=4 number=1 Binding error response: class=4 number=1 Binding error response: class=4 number=1 Binding error response: class=4 number=1 Turned out from source Not handled of STUN auth challenge in stunport.cc

50 nicer: TODO src/stun/stun_client_ctx.c

51 OAuth Browser Implementation Status Chrome Open Issue 4907: Not happen in Q1 Firefox Open Bug : Not implemented warning for App Devs from Mozilla 47

52 OAuth & TURN No PHP library that supports the Authenticated-Encryption with Associated-Data (AEAD) OpenSSL samples: CoTURN self-contained OAuth token validation implemented src/client/ns_turn_msg.c Function: int encode_oauth_token(const u08bits *server_name, encoded_oauth_token *etoken, const oauth_key *key, const oauth_token *dtoken, const u08bits *nonce)

53 Built in STUN Chrome stun.l.google.com:19302 No Service Agreement about service long term availability It is up to Browser vendor Firefox media.peerconnection.default_iceservers;[] media.peerconnection.ice.tcp;false stun.services.mozilla.com Default stun server removed from ver 41 Bug: , Built-in STUN SLA is not well defined

54 Lesson Learned STUN binding with LTC is not supported in Browsers. Port numbers Standard ports Standard Alternate port 80, 443 for strict firewalls NAT discovery Multiple IP addresses required Decisions & Lessons LTC GeoIP vs Anycast OpenDNSSEC is not supporting views. REST API GeoIP and Vincenty vs Google Maps API OAuth (coming soon..) Wait for Browser support.

55 Future directions Utilize untapped coturn features STUN origin Quotas Bandwidth, Session Admin interface Monitoring Improve User interface Frontend, REST API coturn Logging file central collection Analytics, Anomaly detection Support, Helpdesk App developer API examples Investigation problems Service Monitoring (SLA) VM, OS, DB, coturn Alerts

56 Make or Buy? We in place Infrastructure Virtual/Physical Machine Small instance required Networking Service High bandwidth capacity Non technical reasons Trust Transparency Time spent following market players offerings (moving) IPv6 Time spent negotiate price Secure and encrypted Procurement fees updated Open Source From Public Money NREN & Commercial market different priorities Education market is not big enough to implement feature

57 Symposium Demos

58 GN4 Symposium Demo WebTut Teacher <=> Student Symmetric NAT Tablet and PC What happens 1. Without STUN/TURN 2. With STUN/TURN 3. Two endpoints in the same LAN segment

59 In practice

60 Summary ICE if possible provides E2E communication (lowest latency) Standard based NAT Firewall Traversal and smooth IPv6 transition According WebRTC transport draft ICE is MUST. ICE [RFC5245] MUST be supported. ICE needs STUN/TURN server infrastructure. A GÉANT4 PoC service is up and running. Next step? Pilot... Leading edge collaboration technologies serving the NREN community communications needs.

61 Questions? CONTACT: