Re: [OPSAWG] I-D Action: draft-gont-opsawg-firewalls-analysis-01.txt

Mark Andrews <marka@isc.org> Tue, 20 October 2015 00:38 UTC

Return-Path: <marka@isc.org>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF291B2F74 for <opsawg@ietfa.amsl.com>; Mon, 19 Oct 2015 17:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgZnKtjeDTls for <opsawg@ietfa.amsl.com>; Mon, 19 Oct 2015 17:38:58 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9641B2B71 for <opsawg@ietf.org>; Mon, 19 Oct 2015 17:38:58 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 140DE349315; Tue, 20 Oct 2015 00:38:57 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 92D6116003F; Tue, 20 Oct 2015 00:39:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 81DFE16008B; Tue, 20 Oct 2015 00:39:02 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 99IJ9ct2i1gx; Tue, 20 Oct 2015 00:39:02 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 2BFD816003F; Tue, 20 Oct 2015 00:39:02 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8E74D3AC85D6; Tue, 20 Oct 2015 11:38:24 +1100 (EST)
To: Melinda Shore <melinda.shore@gmail.com>
From: Mark Andrews <marka@isc.org>
References: <20151013134530.1812.97650.idtracker@ietfa.amsl.com> <56245AE1.405@gmail.com> <D24A9604.20C16%uri@ll.mit.edu> <20151019231628.CB57D3AC7EDB@rock.dv.isc.org> <562582EA.4030301@gmail.com>
In-reply-to: Your message of "Mon, 19 Oct 2015 15:55:22 -0800." <562582EA.4030301@gmail.com>
Date: Tue, 20 Oct 2015 11:38:24 +1100
Message-Id: <20151020003824.8E74D3AC85D6@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsawg/bWkmNQ0z3fyDoDxFKDJHVwHbnYo>
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] I-D Action: draft-gont-opsawg-firewalls-analysis-01.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2015 00:39:00 -0000

In message <562582EA.4030301@gmail.com>, Melinda Shore writes:
Input error
> On 10/19/15 3:16 PM, Mark Andrews wrote:
> > When one actually wants to use the capabilities we built into the
> > protocol one then has to fight the firewalls even to get the packet
> > delivered.  Cleaning out old/broken firewalls takes decades.
>
> Right, but vendors do love their firewalls.  It can take an
> inordinately long time to get IETF documents out (longer than
> it takes to design and implement a product feature) and vendors
> are likely to release products that break DNS before a firewalls
> draft is done.

We will be, DNS COOKIES support will be released early next year
and yes we will hit firewalls that block EDNS queries with unknown
options along with all the other breakage out there.  Somewhere
around 90% of servers will return good answers to those queries.
A couple of percent will be blocked by firewalls.  If the servers
behind those firewalls are serving signed zones then DNS lookups
for those zones *will* fail if the recursive server is validating.
Similarly if they return FORMERR.  Some of the errors are benign
to DNS COOKIES.

Despite the fact that we will be doing this I still think that a
document on firewalls should go ahead.

I also have draft-andrews-dns-no-response-issue which looks at DNS
server misbehaviour and it covers all of these areas.  I've had
feedback that the IETF shouldn't be asking TLD operators to be good
network citizens by running checks on the delegated servers and
informing their operators that they are broken.  I've also had
feedback saying "when are you publishing, this is good stuff".

Mark

> I've been watching this discussion and getting a strong sense

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org