Re: [GROW] Genart LC review: draft-ietf-grow-filtering-threats-06

Job Snijders <job@instituut.net> Wed, 24 June 2015 23:45 UTC

Return-Path: <job@instituut.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4BB1ACD22 for <grow@ietfa.amsl.com>; Wed, 24 Jun 2015 16:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 g7OxRzSQ0LSv for <grow@ietfa.amsl.com>; Wed, 24 Jun 2015 16:45:17 -0700 (PDT)
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48F01A6F32 for <grow@ietf.org>; Wed, 24 Jun 2015 16:45:16 -0700 (PDT)
Received: by wicnd19 with SMTP id nd19so2658361wic.1 for <grow@ietf.org>; Wed, 24 Jun 2015 16:45:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ox2FIR+7WVDrx4sJ5P+ik2PWf1xfHHLl7Sx7B10D4O8=; b=Ypao6s8A2+0+MAJxIQbVrStUZXTAOzgL0GgdRhswJAApsLQVGNrhYEQ24GMxxdcEK0 ocNDkM6f0wxSpd1hBn+3yUP1CrlJVmfctDzBIHo6//01NXRThPWpHgKS2wmOQwMuiI/P 2ZX1XPa5ZbmDyze6gFl8PUo3u6k795eJFfA3mQnGrQTnw6Ly0EcIbH8L09ntwLvFZv1i 6u5xJFpu55eGl2baVVvtbNbNeTP4NuEVAy7sGmzv0WBuR4hFfJ5mu/Ae0cBXT0O0XS0b +4mikJcHqpivvKm2MqzL3yIIUu4n44A0eFqwxxvARXDwONa+l3Esrsmvai0aDAytz9Pm /xLQ==
X-Gm-Message-State: ALoCoQl/EHWmyKbhRzSth68T36LhxrTKRgW5iG+2STzxdRXRKcg6McLC0hK6/CIBK73IdrC94i6b
X-Received: by 10.180.83.40 with SMTP id n8mr455039wiy.57.1435189515594; Wed, 24 Jun 2015 16:45:15 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:f97f:8a4a:c2e:214b]) by mx.google.com with ESMTPSA id c3sm42849379wja.3.2015.06.24.16.45.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2015 16:45:14 -0700 (PDT)
Date: Thu, 25 Jun 2015 01:45:12 +0200
From: Job Snijders <job@instituut.net>
To: Randy Bush <randy@psg.com>
Message-ID: <20150624234512.GG49729@Vurt.local>
References: <558B3AEE.2010009@nostrum.com> <m2pp4k7k8o.wl%randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m2pp4k7k8o.wl%randy@psg.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/grow/C-DdacVuxfgjsMEP4-MfepCBPME>
Cc: GROW List <grow@ietf.org>, IETF Disgust <ietf@ietf.org>, Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [GROW] Genart LC review: draft-ietf-grow-filtering-threats-06
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2015 23:45:18 -0000

On Thu, Jun 25, 2015 at 08:35:35AM +0900, Randy Bush wrote:
> > Is the last paragraph of 4.1 an IETF consensus position on how operators 
> > might charge one another? It would be good to find a way to word this 
> > that look more like statements of fact and less like charging advice.
> 
> darn hard as there are no facts there and it is first class lawyer
> bait.

Indeed.

It might be better to remove this part:

"It is possible that the behavior of the neighboring AS causing the
unexpected traffic flows opposes the peering agreement.  In this case,
an operator could account the amount of traffic that has been subject to
the unexpected flows, using traffic measurement protocols such as IPFIX,
and charge the peer for that traffic.  That is, the operator can claim
that it has been a provider of that peer for the traffic that transited
between the two ASes."

Instead something like:

"It is possible that the behavior of the neighboring AS causing the
unexpected traffic flows violates a contractual agreement between the
two networks."

And just leave it at that. It is worth noting that, although from a
technical perspective it is not always trivial to proactively prevent
these types of traffic flows, you could try and capture your intentions
in a contract and deal with fallout as said contract prescribed.

Kind regards,

Job