Presentation is loading. Please wait.

Presentation is loading. Please wait.

STUN Open Issues Jonathan Rosenberg dynamicsoft. Changes since -00 Answered UNSAF considerations –Still awaiting response from Leslie on whether they.

Similar presentations


Presentation on theme: "STUN Open Issues Jonathan Rosenberg dynamicsoft. Changes since -00 Answered UNSAF considerations –Still awaiting response from Leslie on whether they."— Presentation transcript:

1 STUN Open Issues Jonathan Rosenberg dynamicsoft

2 Changes since -00 Answered UNSAF considerations –Still awaiting response from Leslie on whether they were OK Alignment of params on natural boundaries –Will break backwards compatibility Added missing parameter code Clarified meaning of changed-address Added security

3 TCP and Fragmentation STUN recommends that UDP response never contain certs If you want certs, do a separate TCP query to fetch them –UDP may fragment –Fragmentation support in NATs are questionable ISSUE: can use UDP if you know your NAT supports fragmentation? –How to know? –Detection algorithms not reliable –Please let us use TCP STUN UDP STUN UDP w/o certs STUN TCP STUN TCP w/ certs (all other info ignored)

4 Security STUN is susceptible to a theft attack –Attacker can snoop request –Inject fake response –MAPPED-ADDRESS points to itself –Victim thinks its its own address, hands it out –Media, signaling applications go to attacker Why is this BAD –Back Door to attack MANY applications –But, if application is secure, this will be detected Authenticated key exchange for SRTP –Too many are not protected

5 Solution Requirements Server authenticates itself to client –Same domain as one client launched request to Client can validate the integrity of the entire response No encryption – utility is not clear Server to client authentication typically based on PK –Web model –Want to work with servers with which you have no shared secret –Want only one mecahnism

6 Solution Approach Cryptographic Message Syntax (CMS) RFC 2630 –Heart of SMIME –Syntax for signatures, certs, etc. Problem: dont want to sign responses for ANY request –DDoS attack, force CPU cycles to be eaten on PK operations Solution is four-way SYN handshake cookie approach –Client asks server –Server sends cookie to client –Client asks server with cookie –Server performs operation Guarantees there is no source address spoofing, avoids DDoS attacks

7 Whats the Issue? CMS implementation is probably times more work than STUN itself Kind of sad However, security is hard Other approaches?

8 Whats left? Not much Lots of implementations underway, products are shipping soon (months away) Will rev with draft-ietf-midcom-stun-00 after blackout period Then ready for WGLC AFAIK


Download ppt "STUN Open Issues Jonathan Rosenberg dynamicsoft. Changes since -00 Answered UNSAF considerations –Still awaiting response from Leslie on whether they."

Similar presentations


Ads by Google