ICE, STUN, TURN
Federated STUN/TURN service PoC/Pilot experiences
Mészáros Mihály
NIIF Institute
4th
TF-WEBRTC meeting - DFN Berlin
2016
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
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
WebRTC
WebRTC & Firewall / NAT Traversal
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..
Firewall vs RTC
Firewall keeps the unwanted traffic
Outside
But also adds barriers to RTC
The Goal: Standard based solution that
solves RTC Firewall/NAT traversal
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
NAT
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
Symmetric NAT
Server 1
Server 2
Client
NAT
"Symmetric" NAT
https://upload.wikimedia.org/wikipedia/commons/7/73/Symmetric_NAT.svg
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
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
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
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
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
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$
ICE, STUN, TURN
ICE step by step
· Discovery and Candidate gathering
· Allocation
· Prioritisation
· Exchange
· Connectivity Check
· Frozen Algorithm
· Coordination
· Communication
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
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
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
…
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
STUN
Auth Methods
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)
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
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
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 „:”.
REST API Operation Overview
(Time Limited Long Term Credential)
REST
API
Web App
Turn Server
Shared
Secret
OAuth
RFC 7635
Proof of Concept
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)
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
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
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
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.
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
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"
Live Demo:
https://brain.lab.vvc.niif.hu
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
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
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
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.
MySQL DB Schemas
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
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
nICEr: TODO
src/stun/stun_client_ctx.c
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
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)
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
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.
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
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
Symposium
Demos
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
In practice
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.
Questions ?
misi@niif.hu
CONTACT:

Stun turn poc_pilot

  • 1.
    ICE, STUN, TURN FederatedSTUN/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.
  • 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 transportdraft · 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.
  • 8.
    Firewall keeps theunwanted traffic Outside
  • 9.
    But also addsbarriers to RTC
  • 10.
    The Goal: Standardbased solution that solves RTC Firewall/NAT traversal
  • 11.
    Firewall Traversal · Traversalis 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.
  • 13.
    NAT types (RFC3489) · 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.
  • 15.
    RFC 4787 andRFC 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 · AllowIP 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 NAToutput 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.
  • 22.
    ICE step bystep · Discovery and Candidate gathering · Allocation · Prioritisation · Exchange · Connectivity Check · Frozen Algorithm · Coordination · Communication
  • 23.
    IP address, andport 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 problemgathering 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.
  • 28.
    Long Term vsShort 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 forWebRTC = 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 OperationOverview (Time Limited Long Term Credential) REST API Web App Turn Server Shared Secret
  • 33.
  • 34.
  • 35.
    PoC Overview · WebFrontend · 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 installcentral · 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 · OnlyOpen 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-locationof 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 · LandingWeb 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.
  • 43.
    Pick the closestSTUN/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 · LTCand 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 smoothIPv6 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 DBfor 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.
  • 48.
    STUN & LongTerm 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 & LTCchrome · 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.
  • 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 · STUNbinding 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 · Utilizeuntapped 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.
  • 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.
  • 60.
    Summary · ICE ifpossible 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.