Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebRTC: Not Quite Magic

alexfreska.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: WebRTC: Not Quite Magic

#31

Post by AshleysBrain »

yperr_string wrote: post #28
AshleysBrain wrote: post #12

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use…

You make the problem sound like it's lack of IPv4 address space. That is true in some respects because the method of allocation of these addresses is not straightforward and has its own set of problems. But in actuality "the problem" the OP is encountering is that for the RTC developer/user, a publicly reachable IPv4 address block is too expensive. With a publicly reachable IP address (most ISP's will provide one, of…

UDP hole punching does not work with all types of NAT, e.g. symmetric NAT where a user can appear from the outside to be coming from multiple different IP addresses. (This makes the STUN server useless for telling the other peer where to connect.) Symmetric NAT is common in corporate networks, which I suppose is not the first place you'd find gamers (or you could just run LAN games with co-workers). I guess WebRTC is the first place you'd run in to networking problems with NAT outside of gaming, torrents and bitcoin - and is perhaps the first developer-accessible peer-to-peer tech which is obviously useful in the workplace.

Re: WebRTC: Not Quite Magic

#32

Post by AshleysBrain »

simon_vetter wrote: post #20
AshleysBrain wrote: post #12

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use…

Work is in progress to make webrtc implementations work over ipv6 but it's not ready yet. Chrome 34 will implement it behind a feature flag (googIPv6:true) [1], and hopefully Firefox will follow suit. When they do, most pain points caused by NATs will go away, and that's not webrtc specific. While you'll always encounter some (intentionally?) broken network which only allows 80/tcp and 443/tcp from time to time, ther…

Thanks for the heads up, this does look like it will help a lot! (Assuming IPv6 reaches most people eventually)

Re: WebRTC: Not Quite Magic

#33

Post by derefr »

AshleysBrain wrote: post #17
alexfreska wrote: post #13

Earlier quoted context omitted.

Yeah IPv6 is valuable but it seems NAT is the smallest inconvenience since a p2p connection can usually still be made. Briefly giving it thought, I don't think IPv6 could rid the use of TURN servers or close the other 5% of anomalies. Am I wrong?

NAT only exists to workaround IPv4 address exhaustion. I think it's more likely the 5% edge cases have firewalls that block anything that doesn't look like normal HTTP traffic.

> NAT only exists to workaround IPv4 address exhaustion.

Untrue; people were using NATs long before they were concerned with running out of IPv4 addresses. I think it was a bit of paranoia combined with lack of trust in firewalls: corporate sysadmins just didn't want their internal networks to have routable addresses.

This seems to have been mostly calmed by the explosion of "cloud" IaaS offerings, which need publically-routable addresses to do much of anything.

Re: WebRTC: Not Quite Magic

#34

Post by vladimirralev »

AshleysBrain wrote: post #16
geocar wrote: post #14

Earlier quoted context omitted.

NAT has been around for twenty years now, so there's no excuse for having anything less than robust, any-direction-any-path in every new protocol. I'm honestly more than a bit disappointed that WebRTC has pushed this down into the application leaving every application to work it out for itself. The smart thing to do would have been to make the signalling layer use IPv6 and insist on configured 6in4-configured gateway…

Maybe NAT has been around a long time but there is still a lot of broken NAT, e.g. symmetric NAT on corporate networks (where one user might appear to come from two different IPs from the outside). This is not WebRTC's fault, it makes any peer-to-peer connections over the Internet hard, and given IPv6 adoption stands at around 3% right now insisting on IPv6 support would probably have been sufficient to prevent wides…

TURN/ICE is supposed to work just fine on symmetric NATs. Chrome even supports single-socket TCP relays, which can't be broken easily by any sane firewall. I personally have a few boxes testing it with only TCP 80 port allowed and it still finds a way to connect. A few tricks on the TURN side have to be employed but it's pretty robust. Whatever issue the OP has to be a bug or configuration issue. There are known problems and I still see a lot of freezes, protocol or hardware compatibility issues, CPU overload and so on, but straight Chrome to Chrome connections seem robust.

Re: WebRTC: Not Quite Magic

#35

Post by ryanseys »

higherpurpose wrote: post #6

I'm interested in the security of WebRTC. Is it end to end? Can it be easily MITMed? What are its main flaws from a security design point of view?

I worked as an intern with Mozilla last summer on helping to improve the issues around security in WebRTC specifically related to authentication and the possibility of MITM attacks. You can watch my intern presentation at [1] which goes through a very high level overview of the state of authentication in WebRTC and an example implementation of how WebRTC could be built into the browser to include authentication:

[1]: https://air.mozilla.org/intern-presentation-seys/

TLDR: E2E encryption is included, but authentication is currently non-existent, allowing for pretty easy MITM attacks if you have control of the relaying website.

Re: WebRTC: Not Quite Magic

#36

Post by bryanpaluch »

bruun wrote: post #30

Tip if you feel like you have to maintain a lot of infrastructure with your TURN server: You can scrap your STUN server, since TURN is an extension of STUN. The TURN server will produce the same server reflex candidate as your STUN server. What port(s) were you using on your TURN server endpoint? Keep in mind that port 80 is often filtered, and many corporate networks often block non-HTTP(S) ports. At the WebRTC-util…

TURN over port 443 specifically using TCP not UDP should get around most firewalls.

If a provider is using DPI and trying to disable ssl network wide, you will still have a problem.

Re: WebRTC: Not Quite Magic

#37

Post by cpncrunch »

caio1982 wrote: post #8

While I think WebRTC is so fantastic it's nearly magical, I find it incredible how people using/creating it overlook networks' topologies problems that SIP and other VoIP folks already had to deal with (and went crazy doing so) a whole decade ago. NAT issues, STUN, all that is long known and yet I've never seen a fully working solution for peer-to-peer communication that won't be stopped by the simplest firewalls. Do…

The problem is that peer-to-peer isn't a very efficient way of doing group video chat to begin with...much better and simpler to just use a central server in that case.

Re: WebRTC: Not Quite Magic

#38

Post by penguindev »

I don't think even ipv6 without nat would guarantee 100% (not that we can count on ipv6 coverage in the next decade anyway).

1. Stateful IPV6 firewalls still need hole punching to connect peers, thus a stun server. 2. Think about a corporate network with complex routes and potentially multiple firewalls (for load balancing or route optimization). No guarantee you use the same gateway to get to the stun server and the other peer. Thus, punching fails.

At least that's my uneducated guess. PS there's nat for ipv6 too (linux supports it). Misery is not going to end.

Re: WebRTC: Not Quite Magic

#39

Post by zanny »

yperr_string wrote: post #28
AshleysBrain wrote: post #12

As far as I understand it, this is not a problem with WebRTC. It's a problem with the Internet itself. We ran out of IPv4 addresses years ago and now the Internet is heavily hacked together with various kinds of NAT which all work differently and sometimes break things. It seems a lot of engineers/IT admin out there have designed their networking setups assuming people only connect to central servers which don't use…

You make the problem sound like it's lack of IPv4 address space. That is true in some respects because the method of allocation of these addresses is not straightforward and has its own set of problems. But in actuality "the problem" the OP is encountering is that for the RTC developer/user, a publicly reachable IPv4 address block is too expensive. With a publicly reachable IP address (most ISP's will provide one, of…

> One wonders if every ISP customer were willing to pay the extra fees (if any) and requested a publicly reachable IP address, could the ISP's meet the demand?

Well no, that is why all ISPs are using DHCP. Most offer static IPs for extra fees, but like fractional reserve banking that only works if all possible subscribers aren't trying to claim unique IPs each.

Re: WebRTC: Not Quite Magic

#40

Post by zanny »

pdkl95 wrote: post #27
rictic wrote: post #22

Earlier quoted context omitted.

I don't think that's so. A NAT also prevents random hosts from directly opening connections to the machines that it's obfuscating (module port forwarding), which serves a nice security purpose.

You're confusing NAT with the firewall. Without a firewall, a pure-NAT will often let you route to the internal network addresses from the outside. There isn't really much "obfuscation" of the LAN addresses either, as they are almost certainly a 1/256-guess away on the 192.168.1.x network. This confusion is very common, probably because it's incredibly rare to find NAT by itself. Every home router is basically guaran…

And every modern IP stack also provides a firewall, be it iptables or whatever the Windows Firewall is. I don't think the "NAT is necessary because putting our computers on the public internet is scary" is anything close to a reason to keep the hodge podge mess we have.
Post reply on HN