IETF Logo Mail Archive

Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

Mark Andrews <marka@isc.org> Thu, 18 October 2012 22:31 UTC

Return-Path: <marka@isc.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEC021F853C for <v6ops@ietfa.amsl.com>; Thu, 18 Oct 2012 15:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.319
X-Spam-Level:
X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUKsxRJrz+M7 for <v6ops@ietfa.amsl.com>; Thu, 18 Oct 2012 15:31:31 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3C121F8500 for <v6ops@ietf.org>; Thu, 18 Oct 2012 15:31:31 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 3D3A7C947E; Thu, 18 Oct 2012 22:31:24 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 067B1216C80; Thu, 18 Oct 2012 22:31:24 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 28B2C2A0041D; Fri, 19 Oct 2012 09:31:21 +1100 (EST)
To: Warren Kumari <warren@kumari.net>
From: Mark Andrews <marka@isc.org>
References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3A2@XCH-NW-01V.nw.nos.boeing.com> <507DA6A3.20807@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3C3@XCH-NW-01V.nw.nos.boeing.com> <507DAB13.2010704@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3CE@XCH-NW-01V.nw.nos.boeing.com> <507DDF8A.9010607@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF5AB@XCH-NW-01V.nw.nos.boeing.com> <BB219517-B488-4777-AE9C-35C57BE91263@kumari.net> <Pine.LNX.4.64.1210171337470.7337@shell4.bayarea.net> <AC530E99-4054-4B0A-9B5C-30F9EF4A530C@kumari.net>
In-reply-to: Your message of "Thu, 18 Oct 2012 13:37:19 EDT." <AC530E99-4054-4B0A-9B5C-30F9EF4A530C@kumari.net>
Date: Fri, 19 Oct 2012 09:31:21 +1100
Message-Id: <20121018223121.28B2C2A0041D@drugs.dv.isc.org>
Cc: V6 Ops <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Oct 2012 22:31:32 -0000

repl: bad addresses:
	C. M. Heard <heard@pobox.com> -- no at-sign after local-part (<)

In message <AC530E99-4054-4B0A-9B5C-30F9EF4A530C@kumari.net>, Warren Kumari writes:
> 
> Yes, and part of the reason that packets are not reaching the core infrastr=
> ucture at line rate is because operators have the ability to examine traffi=
> c destined for the core infrastructure and filter / rate-limit it to someth=
> ing reasonable. I may want to allow e.g traceroute to "core" stuff and toss=
>  that in one rate-limit bucket, but never allow SSH towards my core.  If I =
> have fragments I have no way of knowing what they are supposed to be part o=
> f, and so, er=85 =

So you want allow fragmented ICMP directed at core routers through and are worried
that some non initial TCP fragments might make it through.  As far as I can tell
letting through non initial TCP fragments doesn't increase your risk or attack
surface at all.

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

v2.23.0 | Report a Bug | By Email