Webrtc-pc: Use of icecandidateerror in port scanning

[aboba]

https://medium.com/tenable-techblog/using-webrtc-ice-servers-for-port-scanning-in-chrome-ce17b19dd474

[fippo]

this one is a bit tricky. One of the advantages of onicecandidateerror is that it returns a concrete STUN error code, e.g. when the credential is wrong. We could restrict it to STUN errors. Note that at least for UDP its possible to infer wrong credentials.

The other important use case is discovering whether a client can not connect to a certain TURN server. Not gathering a relay candidate is an indication for this but I would have preferred an explicit error. Unfortunately this is the case that can be used for portscanning.

[alvestrand]

I think we should state that ICE-TCP ports should not connect to ports on the Fetch "bad ports" list - https://fetch.spec.whatwg.org/#port-blocking
I'm not clear on exactly what should happen instead - the platform might just silently ignore the candidate, or the platform might return a NotAllowedError to AddIceCandidate or SetRemoteDescription - but we shouldn't send out a TCP SYN across the network for those ports.

For non-blocked ports, mitigation isn't that easy.

[alvestrand]

Would be nice if addIceCandidate()'s promise was rejected if the port is not acceptable.

[alvestrand]

There's a problem if we increment bytesReceived on port scans. Either portscans should not result in candidate pairs at all, or the counters must remain at the same values as long as we don't get a valid answer.

[dontcallmedom]

@alvestrand can this be closed now that #2540 was merged?