860047 - NAT-PMP Implementation for WebRTC NAT Traversal

Status: NEW

(Core :: WebRTC: Networking, enhancement, P4)

Description

[Adam Roach [:abr]]

+++ This bug was initially created as a clone of Bug #860045 +++

Implement NAT-PMP (RFC 6886) as a way to program network devices from within WebRTC.

Note that the publication of RFC 6886 is pending. Until its publication, it is available in draft form as https://tools.ietf.org/html/draft-cheshire-nat-pmp-07

Comment 1

[Adam Roach [:abr]]

As a potential candidate library, this looks license compatible: https://github.com/miniupnp/miniupnp

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

I'll note that the security considerations for nat-pmp gloss over the case of "compromised program on device A can open ports in the NAT leading to all other devices behind the NAT"; they just say generally the ability to spoof other devices can be resolved with IPSEC "in cases where this is a concern".

At minimum, they should have reprized their argument that the rogue program could act as a relay for any external attempts to connect to an internal address; however this ignores that a device can make holes in the NAT for *any* address behind it, not just addresses the spoofer can access.  Perhaps an edge case in most uses, but if a large firewall protecting multiple subnets/VPNs/etc were to implement NAT-PMP, this could be used as part of an escalation attack on the network.

However, that's not an issue for us; it's there or it isn't, and JS clients won't be able to generate spoofing attacks.  They at most will be able to create fully-open nat holes to WebRTC RTP/RTCP ports, while automatic NAT behavior might only produce a destination-specific mapping (symmetric/5-tuple mapping).  

As an edge case, this could be used by a malicious app to expose the media-processing code in WebRTC to packet-injection attacks by off-path attackers.  These attacks would always be possible for on-path attackers and if you have a more open NAT, but most attackers won't be on-path.

Comment 3

[kameoduda]

The attack is certainly valid. Some of the issues with NAT-PMP were fixed in PCP where there is authentication under the advance threat model and third party mappings are not permitted. 

From an implementation point of view PCP (under basic use) and NAT-PMP are mostly compatible. Wireshark decodes PCP packets as NAT-PMP.

Comment 4

[Maire Reavy [:mreavy]]

Adam - should we target this, or PCP, or both?  Any changes to the security status in the last 2 years?

Comment 5

[Adam Roach [:abr]]

(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #4)
> Adam - should we target this, or PCP, or both?  Any changes to the security
> status in the last 2 years?

Keeping in mind that the NAT-PMP document is documentation of existing, deployed products rather than a spec for new products to implement towards, I don't expect that the security properties are likely to ever change. That said, I think this point is the most important one (quoting Jesup from comment 2): "[T]hat's not an issue for us; [NAT-PMP is] there or it isn't, and JS clients won't be able to generate spoofing attacks."

So the existence of NAT-PMP firewalls is a security concern. Our use of them makes the problem neither better nor worse, and it improves the rate at which we make connections without TURN servers (which is a net quality gain for users).

I don't have any numbers on NAT-PMP versus PCP, but my gut feel is that NAT-PMP probably still has a greater market share. Market research would be nice, but lacking that, my suggestion would be to do this bug first.

Comment 6

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.