Stun turn poc_pilot
-
Upload
mihaly-meszaros -
Category
Technology
-
view
494 -
download
1
Transcript of Stun turn poc_pilot
ICE, STUN, TURNFederated STUN/TURN service PoC/Pilot experiences
Mészáros MihályNIIF Institute
4th TF-WEBRTC meeting - DFN Berlin2016
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 ICESlide 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
STUNAuth 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)
RESTAPI
Web App
Turn Server
SharedSecret
OAuthRFC 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 serversTechnology 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/dokumentation/index.htm
· Etc.
· Commercial Services:
· http://numb.viagenie.ca/
· http://xirsys.com/
· https://www.twilio.com/stun-turn
· Etc.
coTURNTURN 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 servicesmooth 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: TODOsrc/stun/stun_client_ctx.c
OAuthBrowser 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
SymposiumDemos
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 ?