IETF Logo Mail Archive

Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Mon, 23 September 2013 13:10 UTC

Return-Path: <tireddy@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 EDDBB21F9F97 for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 06:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.421
X-Spam-Level:
X-Spam-Status: No, score=-10.421 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
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 MC1RySgn1cZi for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 06:09:59 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 92CCD21F9EB0 for <pntaw@ietf.org>; Mon, 23 Sep 2013 06:09:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2225; q=dns/txt; s=iport; t=1379941799; x=1381151399; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WZcJi/cOkqs6+GEa6uaWhgBQYGw53Pn+p1NTdx4i/6k=; b=Yo10INrFIOSg8/uRFRDeVXzOsNqGykEjXdnA+KrT7PhfWJEKACzxBVd6 XmUfw5LKvZhRxiW0+wjrYKhTU5C2JlH5I17ov4gG+N/OmI4XNM5mcOqmH SW4GtZZvG/t2GXjuaVPn1azTEpDaCKDEyQNcYpISG5DYkUj4v8bEt0Sg6 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAEg9QFKtJV2b/2dsb2JhbABZgwc4UsExgR8WdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQchBgsUCQgCBAENBQgTh1gDCQYMsWINiWYEjHeCPTEHBoMYgQADlhOOLYUzgySCKg
X-IronPort-AV: E=Sophos;i="4.90,962,1371081600"; d="scan'208";a="263233890"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 23 Sep 2013 13:09:58 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8ND9wi9008152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Sep 2013 13:09:58 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 08:09:57 -0500
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>, "melinda.shore@gmail.com" <melinda.shore@gmail.com>, "mom040267@gmail.com" <mom040267@gmail.com>
Thread-Topic: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations
Thread-Index: AQHOuECUFMKlZO8qJEi5r5cdKK9UapnTSkFg
Date: Mon, 23 Sep 2013 13:09:56 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A1907D1B8@xmb-rcd-x10.cisco.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17BCF3A5@MCHP04MSX.global-ad.net> <523CCD06.3030902@gmail.com> <BLU169-W136A55AC013DA147313576D93220@phx.gbl> <523CD42E.8070102@gmail.com> <BLU169-W82036280852F26ED26283C93230@phx.gbl> <523D4F17.2040202@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17BD01A8@MCHP04MSX.global-ad.net> <CALDtMrL5pT3MfbQufCphEKq0-pXj+JcfwW__wzG3T6wZ=TuWhg@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17BD08EA@MCHP04MSX.global-ad.net> <CALDtMrLcUrxseyiaPc_0AWJw3HPdaBuAS+xpviT2q=y4zmdNgw@mail.gmail.com> <523FD5FD.8030601@gmail.com> <CALDtMrK=9D3qXXK6EeWF4RDk26GHPDgkYfQzdJpD33JNK_MeRw@mail.gmail.com> <523FE3E7.3060101@gmail.com> <E44893DD4E290745BB608EB23FDDB7620A0C0969@008-AM1MPN1-043.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A0C0969@008-AM1MPN1-043.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.39.64.227]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pntaw@ietf.org" <pntaw@ietf.org>
Subject: Re: [pntaw] New version of 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: Mon, 23 Sep 2013 13:10:06 -0000

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf Of
> Markus.Isomaki@nokia.com
> Sent: Monday, September 23, 2013 3:05 PM
> To: melinda.shore@gmail.com; mom040267@gmail.com
> Cc: pntaw@ietf.org
> Subject: Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-
> considerations
> 
> Hi,
> 
> Melinda Shore wrote:
> >
> > On 9/22/13 10:41 PM, Oleg Moskalenko wrote:
> > > Melinda, you are assuming that the policies are a precise accurate
> > > instrument that can be used to set the exact network access rules.
> > >
> 
> I agree it is hard to determine what the policy is based on the actual
> firewall etc. rules. For instance if all UDP is blocked may not necessarily
> mean that the high level policy is that VoIP is not allowed. 

Good point. The current technique Firewalls in Enterprise use are "block UDP by default" and also perform SIP inspection (ALG). Firewall pin-holes are opened/closed for UDP media streams based on SIP ALG.

-Tiru.

> Or, on the other
> hand, if outbound HTTPS to port 443 is open, it does not necessarily mean that
> the policy is to allow whatever apps to tunnel whatever traffic that way.
> 
> > > They are not. The reality is that the modern state of network policies
> > > is rather behind the real-world requirements.
> >
> > My comfort level with telling people who run networks that their network
> > access management policies and technologies are behind the times and
> > because we know better then they do about these things it's fine if we
> > punch holes in their firewalls without asking is not very high, to be
> honest.
> >
> 
> While I'm in general supportive to the proposals in draft-hutton-, I also
> agree we need to consider the network admin's perspective as well.
> 
> There will be networks and administrators that explicitly want to restrict
> WebRTC. I think one part of the WebRTC firewall traversal "solution" needs to
> be an explanation HOW they can do it.
> 
> Markus
> 
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw

v2.23.0 | Report a Bug | By Email