In most cases ARP spoofing [0] is probably a lot easier, and gives you all the traffic, instead of just one connection. And if we're talking something like a CGN where ARP spoofing isn't possible, how would you know when to try to hijack a connection if you can't already see the signaling traffic. And if you can already see the signaling traffic, you probably have easier means to MITM.

And even if you managed to get past all that. Don't they layer encryption and authentication on top anyways? I know WebRTC uses DTLS and the certificates are exchanged through the signaling channel. So unless you can MITM the signaling channel already (which probably itself uses TLS), it won't get you anything.

In short, I don't think it's particularly interesting.

[0]: https://en.wikipedia.org/wiki/ARP_spoofing

Of course, but ARP spoofing doesn't have the same requirements (being on the same L2 domain), and it can be easily defended against at the switch level.

But indeed, this attack requires us to know when (and where) to start sending probes.

> And even if you managed to get past all that. Don't they layer encryption and authentication on top anyways?

That's true of most network-level MITM attacks, it doesn't mean they are useless, as the layered encryption and authentication is not always properly implemented.

The remark about cryptographic authentication in probe packets is the key. The attacker mustn't know what your packets say, or be able to fabricate or (important!) save and re-use what it has seen before.

It involves lots of public-key encrypted random numbers carried in the probe packets. You discard packets that don't match your expectations, and you are safe(ish). If you have to avoid too much public-key encryption and decryption because your cores are slow, it gets more complicated, like establishing beach-heads and using symmetric encryption and, still, random numbers between those while establishing the next level up. But cores are usually fast enough nowadays, even on cheap routers and IOT SOCs.

I'm not sure I understand how can cryptographic authentication completely solve that problem, as it is only validated on the endpoints themselves, not on the router.

As long as you have a signal that probing has started, you can just start sending probes : even if their contents are not validated, the NAT device will still define mappings accordingly. The probability distribution for the birthday attack in this configuration is a bit different, but not that much : for 3 devices to get to the same port number, at 4096 probes you get a ~93% probability.

The only way I see would be blocking probes that match an already-received invalid probe, but that creates other problems as it allows an attacker (or even just corrupted packets) to block this communication.

With care, a hostile router can interfere with you getting a connection, but cannot trick you into connecting to it instead.

You may also be interested in this: https://samy.pl/slipstream/

It's an attack leveraging NAT workarounds (like SIP ALG) to potentially access any device behind a NAT by letting a single device load some content sent with the right package sizes and fragmentation properties (say, by publishing a malicious ad).