Re: Genart last call review of draft-ietf-grow-large-communities-usage-06

Job Snijders <job@instituut.net> Wed, 19 April 2017 14:18 UTC

Return-Path: <job@instituut.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776C4129649 for <ietf@ietfa.amsl.com>; Wed, 19 Apr 2017 07:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
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 SU1Y82Lhv-pn for <ietf@ietfa.amsl.com>; Wed, 19 Apr 2017 07:18:47 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 48262129AAD for <ietf@ietf.org>; Wed, 19 Apr 2017 07:18:45 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id l28so16625883wre.0 for <ietf@ietf.org>; Wed, 19 Apr 2017 07:18:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=6f/MLbmZcIGt0635Dmfko5kO55hiUY0E1UeOldlQ1Gc=; b=VIhUD1GBPSI1iKiZ2vM0X2jhTeS3O3vKWSVhTQXGZUB8XTh9G8p/FUOyIMlagSN/3P PCbJxePkEzigdXhFn70Z/m2pL4ZCtibfNXK6Iar3DMedwFDOMCYzBS9gYa/bPNSF1vTw jBe+ryP/ujtppIGcuwOBjUuQDp+QfJgc/9iu7CrlqZ2UCPc7Gj1oWwVTn4SqN3IVE82x IP8NtOubJ6S7DB9wBXLyz5W1XkQs7n92eVJiJq8DWp32vfvVO7WrIaRTTNEiWLxO+q3J NlI98im97rAYrlzk6UhSgceOE1ECSVoPBEIY2YmFJBYhapGp87VDLv3EJJurgUUjuMSL +WPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=6f/MLbmZcIGt0635Dmfko5kO55hiUY0E1UeOldlQ1Gc=; b=VAwKIyxEFGbFaIJ2v46cbXM5YmHDYUZ4rjLVpu9eulNZKY800D2sONfe+9OclPoh9h v5Iz3eRPHyn8awMqQHye+oXedvU0C7n/RCcR/6tCbQCUslcAWka9I712C5CIPsRRnutA eVzzB1tOT3Ia7ZLWPvarQ9Ck3t7szjQZX2TWZ6Z6df7OzNJDc8KYWE/axShPJifwAaEV RQExH67AUFVFklfVkO6WHxsubxsw/CJHyLR/cC3vK/nR7xjxfyVx/MJrFMdBZlHhuxar KRRGc0cssO2YCg/wdcTWrVqTeLzs+yS4EtKEGfHZF8JthWWlpX3hHJen+P9kAfjJQSdR P1wA==
X-Gm-Message-State: AN3rC/55tLaMW4jItpQf5mZL8u3EJx8Hpkz46LsAzLT0SqG0uwIIFhiY Wnug2e6ZxXAKbQ==
X-Received: by 10.223.130.212 with SMTP id 78mr2970192wrc.106.1492611523758; Wed, 19 Apr 2017 07:18:43 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:1558:83a0:4ae5:75f7]) by smtp.gmail.com with ESMTPSA id d10sm3498962wrd.54.2017.04.19.07.18.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 07:18:42 -0700 (PDT)
Date: Wed, 19 Apr 2017 16:18:41 +0200
From: Job Snijders <job@instituut.net>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: gen-art@ietf.org, grow@ietf.org, draft-ietf-grow-large-communities-usage.all@ietf.org, ietf@ietf.org
Subject: Re: Genart last call review of draft-ietf-grow-large-communities-usage-06
Message-ID: <20170419141841.5agsblcuiqvyxek4@Vurt.local>
References: <149252287543.16134.18005737444773296286@ietfa.amsl.com> <20170418235858.sgsa64r7b5th7zam@Vurt.local> <21c205d9-eac4-9403-8450-6bce56b3bfe6@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <21c205d9-eac4-9403-8450-6bce56b3bfe6@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Z6dmgVe_FkOawrtgK0irNO8J8H4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2017 14:18:48 -0000

On Wed, Apr 19, 2017 at 09:46:53AM +0100, Stewart Bryant wrote:
> > >     Operations and Security [RFC7454].
> > > 
> > > SB> You do not address the question of whether there are new
> > > SB> considerations, or considerations that are of increased importance?
> > 
> > It is my understanding that RFC 8092 "BGP Large Communities" are
> > just like RFC 1997 "BGP Communities", but ...  larger (for lack of
> > better words). Referencing RFC 7454 seems plenteous.
> > 
> > So, what if there are not any additional considerations, If there
> > were, they would've been (or are) covered in RFC 8092's security
> > section, right?
> > 
> > This is an Internet-Draft targetted for Informational status, I'm
> > not sure what you expect here.
>
> I was wondering if there was more scope to make mischief at a distance
> in a less less obvious way than before.
> 
> If everyone is happy that there is no additional risk then I am fine,
> but seems to me the more knobs you give the mischeif maker to turn the
> more security risks you have.

Ah, I see now. This document does not create new knobs. RFC 8092
definded the BGP Large Community attribute, and this internet-draft
reflects on possible use cases, much like RFC 1998 was a companion for
RFC 1997.

> > > SB> Is there is text somewhere that discusses the integrity and
> > > SB> synchronization of the parameters and any consequences that arise?
> >
> > the what now? Can you elaborate on the above?
>
> So you rely on the nodes that receive these community strings to
> interpret them in a common way. Maybe this is an already solved
> problem, or an known risk, but what if the dictionaries get out of
> sync?

Yes, there is not anything novel here. How to keep a list of integers
like UN M.49 up to date (or how to write bug-free software) is out of
scope for this internet draft. ;-)

Deploy coherent routing policy configurations on an autonomous
system-wide level is not for this document to cover.

Kind regards,

Job