IPFS IPFS þing 2022, 10 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Challenges in Browser Connectivity - @marten-seemann - Browsers and the Web Platform

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Hello: everyone, I'm martin ziemann working at protocol labs in the on on lippy2b, and um I want to bring bring in this talk. I want to talk about the p2p and what options we have there to improve the connectivity situation across across the network, and this is mostly mostly focusing on browsers, because this is where libido.

B

A

um Doesn't perform as well at the moment, so in general. What is the libi2p connection? It's a point point-to-point connection between two libid2p nodes since there's, no one-size-fits-all, as we will see later, each lippy2p host has offers different connection options. They are encoded in multi-addresses.

A

You can see, there's a multi-address for a tcp listener and port 10 000 and for a quick listener on port 20, 20 000.

A

in general. The p2p connections are encrypted. We run a security handshake and we have multiple options. There. um We use noise and tls 1.3 that bring that gives us well. First of all, an encrypted connection and knowledge of the remote psid.

A

After a connection is encrypted after a tcp connection is encrypted, we apply a stream multiplexer, something like yamax, mplex or hopefully soon, something something better than that for quick. We don't need to do do all of this, because quick connections are encrypted and and stream multiplexed on the transport level.

A

So this this table shows um shows the connection options that we have so I've been talking about tcp and quick and.

C

A

Are only available in in full nodes, let's call them full noids, namely in goalie p2p and in rustly. P2P quick is still work in progress in roughly pvp, but we should we should get there pretty soon in the browser.

A

You can't just open a tcp or a quick connection.

A

Why is that browsers, open tcp and quick connections all the time to run http on top of that? But in order to comply with the security model, they don't allow. They don't allow the user to open a raw tcp or a raw quick connection.

A

This is a problem for us, because we want to connect browsers to um go, live, p2p nodes. Imagine um browser wants to go to the dht and find where, where a certain file is a certain cid is and then download it from there.

A

We can't use tcp and quick for that. Browsers, therefore have developed a bunch of different protocols that you can use instead.

A

That more or less make it possible for the browser to control the security properties of that connection.

A

And these are websockets web transport and webrtc and I'll go into the problems that each of those that each of those pose for the p2p later, as you can see, none of those are fully implemented in libi2p yet, but this is what the p2p team is focusing on right now and you will see a lot of progress in this table over the next over the next month.

A

So, let's start with websocket websocket is a pretty old protocol was specified in in 2011. It basically converts a http connection into a full duplex tcp connection. So what you do is you establish a tcp connection to it? No, you disturb http connection to the server. Then you have this special.

A

The special websocket upgrade http request, and if the server agrees to this, this basically means like we are not doing http anymore. We are now using the raw tcp underlying tcp connection from that moment on and there's also a way to do this over http 2. So you can have you can have multiple streams on top of um or with the same connection.

A

The problem with this is, we can use this in in the p2p, but the browser will enforce the um enforce encrypted connections.

A

So if you loaded a website via https, which is basically every website that you load nowadays, um the browser won't will just not let you establish a websocket connection you need to, and this is the error that you get when you do it. When you try to do it, um you need to do a web socket, secure connection.

A

Which is a websocket running on not an http connection but an https connection.

A

The problem for lippy2p is our nodes, usually don't have certificates well, we do have certificates, but we have self-signed certificates and, of course the browser will not trust a self-signed certificate. A browser will require a certificate from from a ca that it trusts. Let's say: let's encrypt, you can get those let's encrypt certificates for free, but you need the domain name to get them. Let's encrypt doesn't issue, um it doesn't issue certificates for ip addresses, so it's feasible for some nodes in our networks to get a domain name like.

A

If you are an operator like a pinning service or something, then you probably already have a domain name. You probably also already have a tls certificate and you can use that for your websocket connection, there's an option in the p2p where you pass in the dls config and your node will be reachable via secure web sockets.

A

But this is this is only a minority of the nodes in the network like probably 90 and 95. 99 will not have this certificate and won't be won't, be able to obtain the certificate because they have the domain name. So websocket will will be a fringe fringe use case in lib p2p.

A

There's another problem with this approach and it's the number of round trips it takes. So if we, if we count them, um we do one tcp handshake takes a roundtrip. We do a tls handshake takes another round trip. We do the websocket upgrade http request takes a round trip. We then negotiate the security protocol for the lib p2p handshake takes another round trip. We do that. We do that. Handshake takes another round trip. We then negotiate. Amplex or yamax takes yet another round trip. So we are at six round trips.

A

We can optimize this a little bit with protocol select. I don't want to go into detail details about this. This might save us two network routers, but we are still at four run trips, which is uh quite a bit and we're doing double encryption here, because the tier, the the underlying tcp connection is encrypted, and then we run noise, noise or another tls. On top of that, and double encryption obviously is not great for for performance.

A

Yes, I think I already already explained like getting getting a certificate is is difficult. There might be a way around this. I've seen that xero ssl does issue ip certificates.

A

um I haven't looked into this in in detail, but this might be a way to a way to move this forward. So let's look at web transport. um Web transport is a new protocol, um there's not even an rfc. Yet it's at the it's under development at the itf there's a there's, a web transport working group.

A

um It is you get like conceptually, you can think of it as websocket, but done over quick. So you get a lot of the benefits of of quick right out of the box. Yes, stream multiplexing, you have a very fast handshake. You have quick advanced loss, recovery and and congestion control.

A

So if, if you have the choice between websocket and web transport, you probably want to use web transport like when you have the choice between tcp and quick, you probably want to use quick.

A

It also works by sending a kind of upgrade request. It looks a little bit different because this is http 3 and not http, 1 1.1, but conceptually it's the same thing.

A

It does, however, have the same same security requirements from the browser side. The browser also wants to see a certificate that it can trust, at least that's what we thought january this year, which, which is why we thought like okay. This will be like the same fringe use case that we have for websocket, not very interesting for the p2p, but then the w3c changed the standard and they said we we want to.

A

Of course we want to support normal tls certificates, but we also want to support like really short-lived virtual machine deployments, where the node doesn't go to let's encrypt and gets a certificate.

A

So what you can do now is you can tell the browser connect to the server if the server gives you a ca, signed certificate, fine just validate that one, but you can also tell the browser if the certificate has the following hash and that's a sha 256 hash, then just regard it as a valid certificate as well.

A

And this is exactly what we need for lip p2p right. We have. These multi addresses that we can encode stuff into so now we can have an a web transport address. That doesn't only say like this. Is this ip address and this port, but we can also say like this: node has the following hash, and here we have, we can specify two hashes.

A

um Well, actually you can in the multi address you can specify as many hashes as you want, um because web transport does post some some restrictions on the certificate that you can use. As I said earlier, this is intended for short lived for short-lived vms, so one of the things that the browser will do when it gets the certificate, it will not only verify the hash of the certificate. It will also verify that it's not rsa, okay, fine, we can.

A

We can do that, but it will also say, like the certificate cannot be long valid for longer than 14 days, which means if we want to build this into lib p2p, and we have nodes that run a lot longer than just 14 days. We will need to rotate the certificate while the node is running to keep us accessible via web transport.

A

So the idea is to to generate one certificate valid for the first 14 days and another certificate for the next 14 days and then after 14 days, you switch over the certificate and generate a new one, and and as long as the browser got the the addre, it got your address less than 14 days ago. It will be able to connect to you no actually less than well between 14 and 28 days.

A

So this is all this is stuff that we are working on right now we haven't finalized this back yet so, if you want to get involved, that's the specification. Please review.

A

Let's do the same, the same thing we did for web for websocket and count the round trips, so we have one round trip for the the quick handshake.

A

Then we have another round trip for the web transport request, and then we have one round trip for the noise handshake that we run on top of that web transport stream. We need to do this, this noise handshake, because we need to make we need to to learn about the pspr id and in this noise handshake. This is the first time we can actually control the certificate that um that we are well.

A

I should say the other way around like we can't control the certificate, um that's used for the quick handshake, but we can only. We only have full control over noise handshake, and this is the first place where we can, where the client can authenticate itself towards the server.

A

It should be possible to run step two and three. At the same time, the specification allows it but, as I said like, this is still the itf is still working on this protocol, and the browser manufacturer is also still working on this protocol. So at the moment it takes three round trips, but in principle it should be. It should be possible to to do a step two and three at the same time, which would bring us down to just two network round trips to have a fully functioning p2p connection set up. So this is huge.

A

So web transport allows us to connect browser nodes to go le p2p nodes and to rustler b2p nodes. What web transport doesn't allow? You is to connect two browser nodes to each other. Why is that? Because you can't start a web transport server inside your browser, there's just no no api for that.

A

So for the browser to browse a use case, there's just one protocol that you can use, which is webrtc and you all know webrtc, because it's used by by tools like like zoom or google, google meet or google video hangout. However, it's called today um it's a it's. It's been defined um since 2014.

A

There are actually quite a lot of rc's that define this protocol and webrtc combines a lot of other protocols to to make it work.

A

It's mainly built for audio and video conferencing, but there's also this thing called rtc data channels, which is just, as the name says, a or ordered by stream. Abstraction.

A

Using webrtc and it comes with multiple streams with with stream multiplexing at the transport layer. So that's pretty nice.

A

How do you establish a webrtc connection in webrtc? There's this thing called the sdp stands for the session description protocol.

A

It's basically just a long description. Saying like these are my addresses. These are my audio codecs. These are my video codecs that I support and the two nodes need to exchange those sdps and once they've done that they will webrtc will establish the connection punching through through firewalls, if necessary and at the end returning you a webrtc connection, the weber. So we we kind of have a checking and act problem here right.

A

We want to establish a connection between those two nodes, but to do that, we need to exchange these sdps and the webrtc spec doesn't tell you how to do that.

A

It's your own problem deal with it. You can use whatsapp, you can use sneakernet anything.

A

So what do what? What will we do in in p2p for our for our hole, punching protocol we've rolled out something called limited relays across the network?

A

A limited relay is, as the name says, it's it's a relay that is willing to transfer a limited amount of data for a limited amount of time, it's very cheap to run a limited relay. So if you start a lip p to p node and that lipitor p node is detects that it's in a public position not behind a firewall, it will start that relay service and other nodes can use it then.

A

So the plan in lib p2p is to just use this. This huge fleet of relays, that's now been already been deployed to to exchange these sdps.

A

In the browser, um how do you? How do you establish the um a webrtc connection? You? You need to generate your own certificate and since webrtc is built as a peer-to-peer protocol made for video conferencing, there's no certificate check like you, don't need you don't need to see a site certificate. Unfortunately, the api is kind of limited. The only thing that you can pass into the generate certificate function is a key key generation algorithm, so we can't encode the peer id into the certificate.

A

So what we'll do is we'll first establish the webrtc connection and then similar to what we do in web in web transport. We open a stream run another noise handshake and learn the the remote peer id.

A

So this is also also getting getting specified and worked on right. Now um we are expecting to to have something to show in the next next couple of months. I'm pretty excited about this. um All of the work is happening in in our specs like to to make any changes in lib p2p. We first need to make a spec change. Then we write the code. So if you want to get involved, the specs repository is the best way and with that I thank you for your attention.

A

D

Thank you for the talk um I'm wondering so with web transport. Do we still have the same problem as web sockets, uh namely double encryption? That is, the web transport encryption and the noise encryption? We.

A

Don't because um we can use that certificate to make sure that there's we can use the certificate hash to make sure that there's no man in the middle in the connection. So, if you think about um what would happen, if there was a man in the middle and con in the connection, then we would have a different certificate. Hash.

B

A

So we run the noise handshake, which gives us first the pr ids, but then on this noise noise handshake. We also send the certificate hash, so the server will see if the certificate hash that the client has got out of this handshake matches the certificate that it actually owns, and it will not accept the connection if, if, if there's a mismatch, so we run this handshake once on the first stream and as soon as this handshake completes, we know there's no man in the middle. In the connection, we know the peer ids.

A

We can just use the raw uh web transport streams after that.

D

Oh so essentially we don't need noise in this.

A

We we we need the first noise handshake, but we don't need to encrypt any any application data with noise after that right.

D

um And if it's okay, another question um you mentioned so with webrtc that you essentially one of the advantages that we have is that we have these leap, p2p hosts and uh they have this kind of like limited relay functionality, which we can now use to exchange these sdps right, yes, is the limited relay functionality. Is that essentially, what is used for uh circuit relay v2?

D

Yes, and does that mean that we can now use all of these lead p2p hosts to do the whole punching for webrtc, um okay running in the browser, essentially so browser to browser? They can just rely on this whole swarm of leap to p hosts, yes to do the hole punching.

A

Well, not to do the hole punching, um so this is a little bit technical. um We use those nodes running the circuit v2 protocol, as you said, to do the hole punching between gold, b2p and rusty p2p nodes for webrtc. We don't need to do the whole punching ourselves. In fact, we can't, because this is all inside the webrtc stack webrtc that comes with hole, punching capabilities, and we can't just go to the browser and say like no, we do our own hole punching disable your whole punching, there's no api for that.

A

So what we'll use the the relays for is just to exchange the stp, and then we hand it to the browser and say like now: do your thing hold punch as much as you need to just give us the connection? Does that make sense.

D

So it would still basically enable browsers to connect to other browsers using these leap. B2B hosts. Yes, it's just that these lipid2p hosts aren't using circuit relay they're just using the they're implementing, essentially whatever the webrtc standard uh defines it.

A

It's using circuit relay to exchange the sdp okay.

D

A

E

It's kind of a quick sanity check, but web transport can't it has to it's designed to go to a server. Is it can you use it to go like laptop to laptop.

A

E

F

Good stuff, martin, a couple quick questions your table earlier had uh web transport is the red x, um but there are some. Can you explain the browser implementation story? Oh sorry,.

B

F

In jsp, I guess for what browsers have implemented web transport.

A

um At the moment, only only chrome, well, you need to distinguish between web transport and web transport with the server certificate. Hashes service certificate hashes has been implemented in chrome since, like april or may this year, the other browsers are still working on their web transport implementation. At the moment, it's not clear if they will implement the server certificate. Hashes function, at least for safari. It's not clear. Firefox has said like we. We view this.

A

um This whole trend uh web transport thing as like one specification, and if we do web transport we'll also do server certificate hashes and for apple. Well, you know it after they ship.

F

Great good stuff, and if I think this is really exciting, if a bunch of people wanted to dog pile and help make this a reality, what are some of the key ways that the community or folks could get involved to bring reality to this.

A

Yes, so, as I said, specification um is the the best way to to to get started. um We also need need help with the implementation um there's all for for webrtc. For web transport, there is a pull request for webrt rtc, there's a pull request since today um for jsli p2p.

A

We also need help with the implementation for um for for web transport and for webrtc. So if you want to get involved, now is a good time.

F

Great thanks yeah hope we can get others involved to make this happen.

B

um I heard that there was this spec in the works for giving raw tcp and udp access. Is that something that is on your radar? Slash actually happening, slash potentially useful for the p2p.

A

I have not heard of that is that for the browser yeah, I would be very interested in that if you could send a link my way, that would be very much appreciated.

B

Cool we'll do.

E

Is there a path forward for like yeah like browser to browser uh peer-to-peer stuff without an internet connection and yeah like yeah, I guess that's the question and or with maybe some hub in the room that doesn't have a global internet connection. How do you see like putting these together to make that work, or is that still down down the line so.

A

So browser to browser requires webrtc, as I've explained, um I'm not sure if the if the webrtc protocol allows you to to use something like mdns like this is what what we're using for.

C

A

The b2b and russell b2b nodes they discover each other via mdns and then just dial each other's connection. I'm not sure if the webrtc specification has something for that use case. It would.

E

Be super cool, that's the one where you said you just have to exchange sdps, somehow yeah, and so as long as like I don't know. If I just scanned a qr, there's a qr code on the wall that we both scanned. Could that then work with webrtc.

A

Yeah, so the the question that you need to need to answer is like: how do you exchange that sdp.

E

Business card with my preferred stp that I don't have to reprint.

F

On I don't know, are you gonna get.

A

One at home and one more.

C

Time maybe.

B

A

Stp, if the question was, if you can have a business card with your with your sdp, like encoded in a qr code or so so so the the sdp contains your ip address. So as long as you have a static ip address, it's possible. But if you are in a home network, you probably don't, but you could configure your router.

C

To give you one, there was an ipfs engineer at aragon, uh aki gorka. He was at last ipfs camp as well, and he did a demo of dual qr codes between two machines on a local subnet as a webrtc connection and passed passing the sdp cool I'll, find the link and drop it in the channel.

C

All right thanks, martin.