Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?

Mark Andrews <marka@isc.org> Thu, 12 November 2015 20:28 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5411B3506 for <dnsop@ietfa.amsl.com>; Thu, 12 Nov 2015 12:28:18 -0800 (PST)
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 TVmA3lR-BtAH for <dnsop@ietfa.amsl.com>; Thu, 12 Nov 2015 12:28:17 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C570E1B3503 for <dnsop@ietf.org>; Thu, 12 Nov 2015 12:28:16 -0800 (PST)
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.ams1.isc.org (Postfix) with ESMTPS id 1A4B41FCADC; Thu, 12 Nov 2015 20:28:14 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C46F8160067; Thu, 12 Nov 2015 20:28:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AD79A160084; Thu, 12 Nov 2015 20:28:45 +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 6w38mOicaGMU; Thu, 12 Nov 2015 20:28:45 +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 68451160067; Thu, 12 Nov 2015 20:28:45 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id CCFDA3C97F2B; Fri, 13 Nov 2015 07:28:02 +1100 (EST)
To: Robert Edmonds <edmonds@mycre.ws>
From: Mark Andrews <marka@isc.org>
References: <D26A217F.1E6DC%gwiley@verisign.com> <B66E268E-866C-4C47-BB93-7D2D41FDC8D1@icsi.berkeley.edu> <20151112104340.4ebb742a@localhost> <20151112173519.GA21365@mycre.ws>
In-reply-to: Your message of "Thu, 12 Nov 2015 12:35:19 -0500." <20151112173519.GA21365@mycre.ws>
Date: Fri, 13 Nov 2015 07:28:02 +1100
Message-Id: <20151112202802.CCFDA3C97F2B@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/uyiytkGAgQPJhAtyH4g4GX13ljA>
Cc: "Wiley, Glen" <gwiley@verisign.com>, "dnsop@ietf.org" <dnsop@ietf.org>, John Kristoff <jtk@cymru.com>, Nicholas Weaver <nweaver@icsi.berkeley.edu>
Subject: Re: [DNSOP] are there recent studies of client side/ISP firewalls interfering with EDNS?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2015 20:28:18 -0000

The real issue with fragmentation is that firewalls don't add
appropriate slit rules to let through the response fragments when
they open the pinhole for the reply packet.

It isn't that hard to add "permit from dest, to src, type udp, frag
offset != 0" when you add "permit from dest port 53, to src port
xxx, type udp" except the firewall vendors haven't written code to
do it.  You don't have to let through all fragments.  You can filter
to potentially matching fragment.  The effort to be a perfect filter
breaks legitimate traffic.

NATs need to reassemble packets / hold fragments until the initial
fragment arrives but even they can use slit rules to reduce the
attack surface.  You don't have to drop fragments that you haven't
seen the initial fragment of the packet yet (ipfw does/did this).

The fragment with offset 0 also needs to be sent first.  This greatly
improves to possibility of fragments getting through.

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