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

Oleg Moskalenko <> Tue, 24 September 2013 07:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19C7C21F9CC6 for <>; Tue, 24 Sep 2013 00:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.407
X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xLMniwpWxjHu for <>; Tue, 24 Sep 2013 00:20:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::231]) by (Postfix) with ESMTP id 34DBE21F9CC2 for <>; Tue, 24 Sep 2013 00:20:18 -0700 (PDT)
Received: by with SMTP id xb4so4206586pbc.22 for <>; Tue, 24 Sep 2013 00:20:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NVWfVKHipyPZiqC4i6nJitNDWWcsxsIpLpwQKMEApaA=; b=YwWNWXpkIJi/gzLq1BLOAyiqgOFI5gm91P4m//9DNcO71DnPmvOOUtziR6W3mceEh4 okUlotYXcr//hk3qWf/UyK518yIUV8OEZqdgWs+SC71KjyUvTcCqfwZ3uR12iElbR1cW kEooJQp8CwaMO3oKCb7/w8Tj8xju2T68dU5Frzxa1BOQc12TU/XiqXC3lmMeDYfi86Oy 7f4clAlxBU6F5lvVsAvZysOnJQrafrDTARdkcswI7dmAqchP9dAVIDAgJzl2iEyB1LTT THvxusCsl1GxedWHtYIAtKhgv/kdxcqk3mXhT9zCQezxNR8B5cT1xSdJq+Kc0pE9o9Xo XCOQ==
MIME-Version: 1.0
X-Received: by with SMTP id pg6mr26148422pbb.67.1380007217914; Tue, 24 Sep 2013 00:20:17 -0700 (PDT)
Received: by with HTTP; Tue, 24 Sep 2013 00:20:17 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 24 Sep 2013 00:20:17 -0700
Message-ID: <>
From: Oleg Moskalenko <>
To: Melinda Shore <>
Content-Type: multipart/alternative; boundary=047d7b10cebf02eb3304e71bf8d0
Cc: "" <>
Subject: Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Sep 2013 07:20:20 -0000

Melinda raised some valid TURN security concerns. I'd suggest to add two
optional recommendations for the secure TURN environments:

1) Enforce authentication of STUN Binding request/response;
2) Short-term authentication mechanism.

The problems with those recommendations are:

1) The existing STUN, TURN, WebRTC and ICE implementations do not support
authenticated STUN Binding request/responses; this is an implementation
problem, this is not a standard problem. I personally can say that adding
an option of authenticated STUN request/response to our TURN server
(rfc5766-turn-server) is an easy 1-hour work, but this is rather a
convention problem. My experience is that once this option is enabled, the
WebRTC stops working - it is not expecting a challenge response from the
STUN server. It can be considered as a bug of the existing WebRTC libraries.

2) As of now, WebRTC does not support short-term authentication mechanism.

3) The new TURN REST API standard (under development) is revolving around
the long-term authentication mechanism.

On Mon, Sep 23, 2013 at 10:02 PM, Melinda Shore <>wrote;wrote:

> 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
> _______________________________________________
> pntaw mailing list