Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt

Gert Doering <gert@space.net> Fri, 05 July 2013 14:43 UTC

Return-Path: <gert@space.net>
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 8362411E812B for <v6ops@ietfa.amsl.com>; Fri, 5 Jul 2013 07:43:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 U3k4JFDd3Tc7 for <v6ops@ietfa.amsl.com>; Fri, 5 Jul 2013 07:43:31 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id D990211E8104 for <v6ops@ietf.org>; Fri, 5 Jul 2013 07:43:30 -0700 (PDT)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 533C660A12 for <v6ops@ietf.org>; Fri, 5 Jul 2013 16:43:28 +0200 (CEST)
X-SpaceNet-Relay: true
Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 3FE05609FB for <v6ops@ietf.org>; Fri, 5 Jul 2013 16:43:28 +0200 (CEST)
Received: (qmail 86476 invoked by uid 1007); 5 Jul 2013 16:43:28 +0200
Date: Fri, 05 Jul 2013 16:43:28 +0200
From: Gert Doering <gert@space.net>
To: Ray Hunter <v6ops@globis.net>
Message-ID: <20130705144328.GU2706@Space.Net>
References: <1372897534.35448.YahooMailNeo@web2802.biz.mail.ne1.yahoo.com> <CAD6AjGSGeNHPUs9+F6OOAeDOy_FZpTOGkH6viX_fENca4H8X0g@mail.gmail.com> <1372899240.80312.YahooMailNeo@web2803.biz.mail.ne1.yahoo.com> <51D614F6.4030000@isi.edu> <20130705124651.GP2706@Space.Net> <51D6C601.70003@globis.net> <51D6CC01.4070600@isi.edu> <51D6D4D4.5000704@globis.net> <20130705141735.GT2706@Space.Net> <51D6D6FB.2090401@globis.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="V04wbe4pUYOisw7u"
Content-Disposition: inline
In-Reply-To: <51D6D6FB.2090401@globis.net>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-wkumari-long-headers-01.txt
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: Fri, 05 Jul 2013 14:43:31 -0000

Hi,

On Fri, Jul 05, 2013 at 04:23:55PM +0200, Ray Hunter wrote:
> > ... "drop this UDP/53 flood at the most external borders we can to stop
> > it from overloading internal links".
> No disrespect, but by the time you've detected the attack and put in the
> appropriate L4 filtering config, haven't the attackers long gone?
> 
> Doesn't this sort of DoS defence need to be auto-detecting, and
> auto-responding, like fair queueing?

Well, these days people observe UDP/53 flooding that goes on for days.

Who will know what's there tomorrow?


> Or in the old days, simply reducing the link speed to untrusted peers?

All peers are untrusted - and we're not interested in reducing speed for
useful traffic.  

Assume that our external links can handle the traffic, the "bad" traffic 
is easily identified (like: UDP/53 reflective DoS to a web server who 
doesn't need any external UDP in the first place), and that some internal 
link towards the web server would become overloaded.

Being able to filter at the most external borders is a must.

(But I'm not sure this discussion is going anywhere - I'd welcome if all
people that argue that this is not a problem run an ISP network for a 
few weeks, and then come back)

Gert Doering
        -- Operator
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279