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 ?

misi@niif.huCONTACT: