[pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations

[Melinda Shore <[e-mail]>]

I think you really need to be clearer about the distinction
between NAT and firewall, and that firewalls are policy
enforcement devices.  NATs arguably are (address policy)
but to the extent they're deployed as access control
mechanisms that function is incidental to their design.
This matters a lot when you're talking about ICE, since
it was designed as a *NAT* traversal mechanism, not a
firewall traversal mechanism.  There's been a long history
of highly contentious middlebox work in the IETF and
it's probably better to address those questions sooner
rather than later, as I think they're bound to come up.

So, you're extending ICE to firewall traversal, because
... ?

In particular I'd put some text in section 1 addressing
the difference between NATs and firewalls, the policy
enforcement role of firewalls, that it is explicitly
not the intention of this draft to propose a mechanism
for violating local firewall policy, and that you recognize
a need to give the network administrator control over
what does and does not enter their network.  That said,
if they do wish to allow WebRTC traffic, this is how to
do it.  I think that will help fend off irritating questions
from people like, say, me.

I think there's probably a lot more that can be said about
addressing and policy, particularly around authenticity, but
I'm going to save that for after having re-read the WebRTC
documents.  But I'd like to skip ahead to the security
considerations section, because that's really critically
important and can't be left empty (to be honest I'm considering
proposing to my own working group and others that we not
adopt any working group draft that has an empty security
considerations section - it's a big problem).

I think there are two broad classes of security issues here:
1) the security of the mechanism itself, and
2) security in the context of the environment

In this case the two are not cleanly separable, to the
extent that presumably the reason for subverting the
security of a WebRTC traversal mechanism would be to
compromise the firewall (with one prominent exception, which
I'll get to below).

As I mentioned in previous email, you cannot allow the
WebRTC firewall traversal technology to be subverted
to allow "unauthorized" pinholing.  This is kind of a
messy problem, since it can involve port numbers (which
doesn't apply in the creation of real-time media
streams), stateful traffic inspection (which doesn't
work in the presence of encrypted signaling traffic),
and so on.  It *may* be the case that there's an authoritative,
trusted entity somewhere in the application architecture
that can make authoritative statements about what's
allowed, and you could leverage a third-party mechanism
like OAuth if you can live with the added latency.

I can give you a long, long list of reasons I don't like
STUN (and, to a lesser extent, TURN), but prominent among
them is that without some sort of application-layer
authentication it is trivially easy to use it to hijack media
streams.  All you have to do is send a bogus STUN or
TURN response with an address of your choosing, since the
answer is unauthenticated.  Using TCP as the TURN
transport makes an attack more challenging but it doesn't
eliminate it entirely.  In VoIP scenarios, what they typically
do is accept the response but then authenticate the
application traffic, so if they get a bogus response
the media streams can't be established, anyway.
So, either think about how to protect against an insertion
attack, or make it clear that you've got protection
available at the application layer.

Melinda