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

Dan Wing <dwing@cisco.com> Tue, 24 September 2013 15:38 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FFC11E813A for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 08:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.647
X-Spam-Level:
X-Spam-Status: No, score=-110.647 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgbXgr+DmWjd for <pntaw@ietfa.amsl.com>; Tue, 24 Sep 2013 08:38:03 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7EA11E8138 for <pntaw@ietf.org>; Tue, 24 Sep 2013 08:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4389; q=dns/txt; s=iport; t=1380037081; x=1381246681; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Pmg/uRy7NpZFqodbBAZqLjKzr2oKCLF/FMQmPpWVOOM=; b=hbSRWYT0WekHORstVTbWeG+RIfuhBHoYLtNFDJaGJZwygM5iJNMSoZM5 g0WkN3k6Wz47R9pIKMKdyy40N5ibeaownSJrjhHpBCHdZRt89ttYBdcH+ NEJukDuCAuE87Ke9qTv/Nqm85W7bE4Ynk2CeY7u8dkGesITTe4G1AdH1Y s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAH+wQVKrRDoI/2dsb2JhbABagwc4wSCBHhZ0giUBAQEDAQEBATc0CwULCxI0IQYiDgYTh3MDCQUNsy8NiWYEjGaBIoEWMweDHYEAA4k4jFuBaYxEhTODRByBNQ
X-IronPort-AV: E=Sophos;i="4.90,971,1371081600"; d="scan'208";a="92965039"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 24 Sep 2013 15:38:01 +0000
Received: from sjc-vpn3-476.cisco.com (sjc-vpn3-476.cisco.com [10.21.65.220]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8OFc0xI028529; Tue, 24 Sep 2013 15:38:00 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <52411CD5.1050909@gmail.com>
Date: Tue, 24 Sep 2013 08:38:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D9195556-BA71-4A58-9D48-80E27413986A@cisco.com>
References: <52411CD5.1050909@gmail.com>
To: Melinda Shore <melinda.shore@gmail.com>
X-Mailer: Apple Mail (2.1508)
Cc: "pntaw@ietf.org" <pntaw@ietf.org>
Subject: Re: [pntaw] More on draft-hutton-rtcweb-nat-firewall-considerations
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2013 15:38:08 -0000

On Sep 23, 2013, at 10:02 PM, Melinda Shore <melinda.shore@gmail.com> 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.  

* The bogus response has to match STUN's 96-bit transaction ID (which is generated by the client and supposed to be random), or else the bogus response is ignored.
* All WebRTC media traffic is encrypted (SRTP) and all WebRTC non-media traffic ("data traffic") is DTLS-protected (SCTPoDTLSoUDP).

-d

> 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
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw