Proof of Concept STUN/TURN service

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

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
· Address-restricted-cone NAT
· Port-restricted cone NAT
· Symmetric NAT
Server 1
Server 2
Client
NAT
"Full Cone" NAT
Server 1
Server 2
Client
NAT
"Restricted Cone" NAT
Server 1
Server 2
Client
NAT
"Port Restricted Cone" NAT

14. Symmetric NAT
Server 1
Server 2
Client
NAT
"Symmetric" NAT
https://upload.wikimedia.org/wikipedia/commons/7/73/Symmetric_NAT.svg

15. RFC 4787 and RFC 5780 vs RFC 3489
· Mapping
· EIM
· ADM
· APDM
· Filtering
· EIF
· ADF
· APDF
Source:
http://www.netmanias.com/en/?m=view&id=techdocs&no=6065

16. Map Detection
Image Source:
http://www.netmanias.com/en/post/techdocs/6067/nat-stun/nat-behavior-discovery-using-stun-rfc-5780
· TEST I
· Primary IP, Primary Port
· TEST II
· Alternate IP, Primary Port
· TEST III
· Alternate IP, Alternate Port

17. Filtering Detection
Image Source:
http://www.netmanias.com/en/post/techdocs/6067/nat-stun/nat-behavior-discovery-using-stun-rfc-5780
· TEST I
· Primary IP, Primary Port
· TEST II
· Change Request IP and Port
· TEST III
· Change Request Port

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 4787 - 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 193.224.47.74

20. Example symmetric NAT output
misi@csiga:~/work/coturn$ bin/turnutils_natdiscovery -f -m 193.224.47.74
…
========================================
NAT with Address and Port Dependent Mapping!
========================================
…
========================================
NAT with Address and Port Dependent Filtering!
========================================
misi@csiga:~/work/coturn$

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
TURN
Server
NAT
UA
Y:y
X':x'
X:x
Public Internet

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

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

26. RETURN
____________ inside network || outside network
/ || NAT/FW
| host O ________||________
| | / ||
| srflx|.............|..................O ___________
| | | || | /
| relay|- - - - - - -|- - - - - - - - - |- - -|- - - - - -O
| | | _____||_____ | | |
| | | / || | | |
| relay2|-------------|--|------------| -|- - -|- - - - - -O
| | | | || | | ___________/
| srflx2|- - - - - - -|- |- - - - - - O |
| | | | || | | Application TURN
| host2 |- - - - - - -|- |- - - - - - O | server
| | | _____||_____/ |
____________/ ________||________/
||
Browser Border TURN Proxy ||
server ||
KEY O Candidate
..... Non encapsulated
- - - TURN encapsulated
----- Double TURN encapsulated
|| Network edge
· RETURN
· Recursively Encapsulated
· DNS „Auto-Discovery”
· Corporate Border Proxy
· Corporate and Application
· Leakiness
· Leaky: Use all possible
· Sealed: force only enterprise
TURN Proxy-t

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
Turn Server
Shared
Secret

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
· OS (firewall,ntp,fail2ban,etc.)
· Web Server and PHP
· EduGAIN privacy statement
· MySQL master
· Automated install slaves
· OS (firewall,ntp,fail2ban,etc.)
· MySQL slave
· coTURN
· Configure even more
· Certs
· Configure SimpleSAMLPHP
· Install Composer
· 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:
· http://sourceforge.net/projects/stun/
· http://turnserver.sourceforge.net/
· https://github.com/jitsi/turnserver
· https://www.resiprocate.org/
· http://www.creytiv.com/restund.html
· https://github.com/coTURN/rfc5766-
turn-server/
· https://github.com/coTURN/coTURN
· Commercial implementations:
· http://www.eyeball.com/products/
stun-turn-server/
· http://help.estos.com/help/en-US
/procall/5/erestunservice/dokume
ntation/index.htm
· Etc.
· Commercial Services:
· http://numb.viagenie.ca/
· http://xirsys.com/
· https://www.twilio.com/stun-turn
· Etc.

40. coTURN
TURN with co-location of multiple realms
· coturn.net - https://github.com/coturn/coturn
· 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:
https://brain.lab.vvc.niif.hu

43. Pick the closest STUN/TURN
· LTC
· 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
· REST
· 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 jessie-
backports 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)] Binding error response: class=4 number=1
reason='Unauthorized'
[1:12:0418/145114:ERROR:stunport.cc(79)] Binding error response: class=4 number=1
reason='Unauthorized'
[1:12:0418/145114:ERROR:stunport.cc(79)] Binding error response: class=4 number=1
reason='Unauthorized'
[1:12:0418/145114:ERROR:stunport.cc(79)] Binding error response: class=4 number=1
reason='Unauthorized'
[1:12:0418/145114:ERROR:stunport.cc(79)] Binding error response: class=4 number=1
reason='Unauthorized'
· 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:
https://goo.gl/Z69q6I
· Not happen in Q1
· Firefox
· Open Bug 1247616:
https://goo.gl/6n78rL
· 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: https://goo.gl/UfuqTr
· 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
· Firefox
· media.peerconnection.default_iceservers;[]
· media.peerconnection.ice.tcp;false
· stun.services.mozilla.com
· Default stun server removed
from ver 41
· Bug: 1167922, 1143827
· No Service Agreement about
service long term availability
· It is up to Browser vendor
· 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
· IPv6
· Secure and encrypted
· updated
· Open Source
· From Public Money
· Non technical reasons
· Trust
· Transparency
· Time spent following market
players offerings (moving)
· Time spent negotiate price
· Procurement fees
· 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 ?
misi@niif.hu
CONTACT: