Re: Expose capabilities / Allow for IP:Post based connections / Better abstraction

Hi

I see two almost identical replies so I'll reply to the newest one. :)

On 2013-07-08 14:01, Johannes Hange wrote:
> Dear Adam, two comments inline.
>
> Kind Regards
> Johannes
>
> On 07/08/2013 10:27 AM, Adam Bergkvist wrote:
>> On 2013-07-08 09:28, piranna@gmail.com wrote:
>>> +1, maybe not the best API, but I have always criticed why is so
>>> complicated to establish a DataChannel. On my polyfill, following the
>>> spec, it didn't seems that you require candidate messages, and common
>>> sense say it too.
>>
>> I assume that your polyfill uses WebSocket as the transport? In that
>> case you connect the two peers via a server (and not peer-to-peer);
>> hence no need to exchange candidates. The majority of the code (and
>> the complicated parts) in the DataChannel example (in the spec), is
>> actually connecting the two peers. Once you have that, creating a
>> DataChannel is rather easy.
> But isn't there an underlying issue for you in the current approach? As
> an example, you can ignore the part "Towards ICE" in my last mail,
> because there actually seems to be a way to circumvent the ICE logic
> entirely. Set the constructor value to null and ignore all ICE related
> stuff.
>
> But that realization brought me right back to my original point:
> ICE (especially TURN) seems to be totally unneeded for the core
> functionality, yet it's deeply baked into the PeerConnection object.
> Shouldn't it be on its own abstraction and passed in if needed?

ICE provides the consent-to-receive mechanism. That is, when you load a 
page, your browser can't be used in an attack to bombard an "innocent" 
machine that's not expecting data.

> Additionally, shouldn't it be possible to instantiate channels without
> caring about the pooling (do it under the hood unless I care?)? So I can
> write new DataChannel(sdp) (or better, ip based).
>
> RTCPeerConnection is not only a transport pool, it's also the factory,
> not for one but numerous things. It has the ICE logic baked in, it has
> the SDP logic baked in, it has all the create* logic.
> If this object has to stay, to push the standard out, ... I understand.
> But it for a standard I believe to stay a long time and have a good deal
> of influence, it seems to have some flaws (separation of concerns,
> simplicity in use).

I agree that a lot of stuff have been baked into PeerConnection. But I 
think the general way DataChannels are created is rather OK. 
PeerConnection represents (among other things) a connection/transport 
between two peers; and you create a DataChannel to that peer via that 
object. However, I think we would be better off with more separation 
between transport and deciding what media and data to send/receive.

>>
>> What info do you need to interchange after doing the
>>> offer/answer? And also, the direct connection using IP:port using the
>>> STUN data would be a good idea (using WebRTCSocket as you propose not).
>>>
>>> El 08/07/2013 07:15, "Johannes Hange" <moooitic@mailbox.tu-berlin.de
>>> <mailto:moooitic@mailbox.tu-berlin.de>> escribió:
>>>
>>>     Dear WebRTC,
>>>
>>>     you are the future, and should be carefully build. The current
>>>     proposal does not expose the capabilities gained very well.
>>>
>>>     In general, the standard puts capabilities into a monolithic (pool)
>>>     object (for the sake of performance and probably due to SIP
>>>     influences). This may be due to a focus on video and audio in the
>>>     initial development phase of the protocol, for which this setup is
>>>     probably a good idea and common practice.It currently has the
>>>     disadvantaged that the developer can't access and use the
>>>     functionality separately, has to write complicated code for simple
>>>     things and is restricted by predefined flows.
>>>
>>>     - Objects should be independent from an API perspective:
>>>          - Resources (streams) should be pooled under the hood and have
>>>     nothing to do with the API
>>>          - If necessary expose "pools" the developer can "add" to, not
>>>     require them
>>>     - Added protocols and gained features should be exposed to the
>>>     developer (if there are use cases)
>>>          - So he can invent what to do with them
>>>          - Example below
>>>     - Higher level objects are a good addition, but not a good base
>>>     abstraction.
>>>          - Once you have a monolith, breaking it up in a lib is ugly,
>>>     the other way around is not (Look at the code that exists today to
>>>     do this ...)
>>>
>>>     This was written under the assumption that much of the existing
>>>     infrastructure is used and little adapted. I suggest a dual approach
>>>     where small exposed objects and the current big monolith co-exist
>>>     (lets see who wins in 2.0 by analyzing usage ...).
>>>
>>>      From a data channel / web developer perspective the API and
>>>     requirements are overly complicated and lack the abilities to:
>>>          1 - Establish a connection to another user directly, based on
>>>     the exchange of ip:port pairs (not large SPD)
>>>              - [RTCPeerConnection.]connect(ip, port, [timeout], [number]
>>>     ...)
>>>                  - punches holes until [timeout], [number] may be useful
>>>     to regulate the number of punches
>>>                  - various security restrictions to address flooding /
>>>     miss-use, but does not differ from current attack vectors
>>>              - onconnect / callback
>>>                  - continue flow (exchange SDP)
>>>          2 - Find out the IP of the current system
>>>              - getIPAddresses(['stun: ...', 'stun: ....'], ...)
>>>                  - Provide a call outside of the webrtc object
>>>          3 - Provide a simple WebRTCSocket alternative to send data
>>>              - WebRTCSocket("to_ip:to_port", "my_ip:my_port" /*obtained
>>>     via navigator.getIPAddress(stunServers)*/)
>>>                  - Which does the following (probably implemented more
>>>     efficiently):
>>>                      - RTCPeerConnection.connect(to_ip, to_port);
>>>                      - createDataChannel
>>>                      - Expose events of the data channel
>>>              - This can be done for audio/video too in order to break up
>>>     the monolithic nature ...
>>>
>>>     Towards ICE:
>>>          - Build own Http flows and provide the ability to solve the
>>>     problem without ICE:
>>>              - {'iceServers': [{'url': 'https://example.org/myip'}]};
>>>                  - For most clients this will provide me a valid address
>>>     for later hole punching and it's easy to create
>>>                  - Return any answer format the developer chooses,
>>>     client code knows what to do
>>>                  - I can start signaling logic at this point already
>>>     (and close my server to the public)
>>>              - Client must convert IP into a SPD format for exchange
>>>                  - createOffer(ip, function(description) {....})
>>>
>>>     Kind regards and thanks for reading
>>>     Johannes H.
>>>
>>>     PS: I am glad to answer anything unclear or address issues
>>>     (participate in discussions)
>>
>> The web app can't set it's own ports and the receiver ip/ports for
>> security reasons. Compare WebSockets [1], which similarly to WebRTC is
>> exposed in regular browsers, to the Raw Socket API [2] that developed
>> in SysApps which is targeting packaged applications and other cases
>> where you have a manifest and the app runs in an elevated security mode.
>>
>> /Adam
>>
>> [1] http://dev.w3.org/html5/websockets/
>> [2] http://www.w3.org/2012/sysapps/raw-sockets/
>>
> Thank you very much! I suspected that this would be problematic. But
> couldn't you do a handshake on a pre-set port and automatically switch
> to another by negotiating? So connect("ip", [time]). I will read the
> links asap.!
> Isn't this also a problem with SDP files? To freely change connection
> details? Can't I write a local js attack that does exactly this?

I still don't think that model would work for the web. You can make a 
real low-level API and still let the browser allocate the ports as long 
as you tell the other side how you can be reached.

/Adam

Received on Tuesday, 9 July 2013 06:05:06 UTC