A listener is a piece of software that advertises itself as available to inbound connections. You can do this on a variety of protocols.
Multipath TCP is a neat trick that allows a single TCP connection (TCP = Transport Control Protocol, a stateless protocol for long running connections) to use multiple physical interfaces. You could do something similar before MTCP using bonding, but this was annoying to set up and usually required application level code to efficiently use the bonded connection. MTCP makes this much simpler from an application level point of view and it can use widely diverse underlying transport layers at the same time (for instance, WiFi, Cellular and wired connections).
TCP is in the transport layer! The layers which you name are lower, such as Layer 2 (Data Link)!
MTCP, being in the transport layer, is working at a higher level of abstraction than bonding or link aggregation. There is no need for application-layer support, but it is possible, and easier, with MTCP than with the Layer 2 solutions, because MTCP is in the transport layer. That is why Go was able to activate it, and the POC uses it, because MTCP controls can be exposed at that level.
It's an extension to TCP that, similar to QUIC, allows you to use multiple address/port pairs to transmit data over a single logical stream. Both client/initiator and server/listener have to opt into the extension. This might need to be enabled explicitly by the application[1], which Go apparently does for you, or judging from other posts may be enabled by default systemwide, depending on your platform.
AFAIU, a major user of MPTCP is Apple and the iPhone, and the ubiquity of iPhone clients motivated implementation in and deployment on Linux servers.
I had to look it up too since I hadn't heard of it. It's an extension to TCP that allows responses across different NICs. Sort of like Link Aggregation on to a switch, except it can go out dissimilar interfaces, like your wifi connection and your hardwired connection. Looks like you have to opt into it when you set up your socket: https://docs.kernel.org/networking/mptcp.html
In addition to aggregating, it can also be useful in cases where one link is much slower or higher latency. For example, if you're sitting in your driveway trying to get directions in maps while your phone is still on your very weak wifi network, it's a better user experience to have it to attempt the request using both radios concurrently so that it can fallback to cellular without waiting for a timeout/connection error if you're too far for wifi to actually work well.
MPTCP is an extension that requires cooperation. So it is only supported if the network stacks of both peers and all middleboxes can support it. The Linux kernel docs describe it as "opt-in", so it is not enabled by default for every socket opened on the system.
Again, the description of this CVE indicates that the vulnerability does not depend on MPTCP. But it is a factor in the proof-of-concept and its likelihood of success.
So if there was any widespread mutual support of MPTCP, it may shrink significantly as network admins deploy mitigations.
A listener is a piece of software that advertises itself as available to inbound connections. You can do this on a variety of protocols.
Multipath TCP is a neat trick that allows a single TCP connection (TCP = Transport Control Protocol, a stateless protocol for long running connections) to use multiple physical interfaces. You could do something similar before MTCP using bonding, but this was annoying to set up and usually required application level code to efficiently use the bonded connection. MTCP makes this much simpler from an application level point of view and it can use widely diverse underlying transport layers at the same time (for instance, WiFi, Cellular and wired connections).
> Transport Control Protocol, a stateless protocol
TCP is stateful by definition, and that is why it supports robust error correction and reliable streams of data. UDP is its stateless counterpart.
> bonding, ... usually required application level code
No, it doesn't. https://en.wikipedia.org/wiki/Link_aggregation
> underlying transport layers
TCP is in the transport layer! The layers which you name are lower, such as Layer 2 (Data Link)!
MTCP, being in the transport layer, is working at a higher level of abstraction than bonding or link aggregation. There is no need for application-layer support, but it is possible, and easier, with MTCP than with the Layer 2 solutions, because MTCP is in the transport layer. That is why Go was able to activate it, and the POC uses it, because MTCP controls can be exposed at that level.
Sorry, total failure on my part I meant to write 'stateful'.
See https://en.wikipedia.org/wiki/Multipath_TCP
It's an extension to TCP that, similar to QUIC, allows you to use multiple address/port pairs to transmit data over a single logical stream. Both client/initiator and server/listener have to opt into the extension. This might need to be enabled explicitly by the application[1], which Go apparently does for you, or judging from other posts may be enabled by default systemwide, depending on your platform.
AFAIU, a major user of MPTCP is Apple and the iPhone, and the ubiquity of iPhone clients motivated implementation in and deployment on Linux servers.
[1] https://docs.kernel.org/networking/mptcp.html#sockets-api
I had to look it up too since I hadn't heard of it. It's an extension to TCP that allows responses across different NICs. Sort of like Link Aggregation on to a switch, except it can go out dissimilar interfaces, like your wifi connection and your hardwired connection. Looks like you have to opt into it when you set up your socket: https://docs.kernel.org/networking/mptcp.html
You have a Wifi network interface and a wired Ethernet one, multipath is somehow combining the two together.
In addition to aggregating, it can also be useful in cases where one link is much slower or higher latency. For example, if you're sitting in your driveway trying to get directions in maps while your phone is still on your very weak wifi network, it's a better user experience to have it to attempt the request using both radios concurrently so that it can fallback to cellular without waiting for a timeout/connection error if you're too far for wifi to actually work well.
Do apps actually use this possibility though?
MPTCP is an extension that requires cooperation. So it is only supported if the network stacks of both peers and all middleboxes can support it. The Linux kernel docs describe it as "opt-in", so it is not enabled by default for every socket opened on the system.
Again, the description of this CVE indicates that the vulnerability does not depend on MPTCP. But it is a factor in the proof-of-concept and its likelihood of success.
So if there was any widespread mutual support of MPTCP, it may shrink significantly as network admins deploy mitigations.