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

joel jaeggli <joelja@bogus.com> Mon, 01 May 2017 17:05 UTC

Return-Path: <joelja@bogus.com>
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 39CD612EAB6; Mon, 1 May 2017 10:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 6E0PHDMQJ3eq; Mon, 1 May 2017 10:05:33 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C0612EA24; Mon, 1 May 2017 10:02:24 -0700 (PDT)
Received: from mb.local ([IPv6:2620:11a:c081:20:a48c:7fae:30c1:868]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v41H2Njv093174 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 1 May 2017 17:02:23 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:a48c:7fae:30c1:868] claimed to be mb.local
Subject: Re: [GROW] Genart last call review of draft-ietf-grow-large-communities-usage-06
To: Stewart Bryant <stewart.bryant@gmail.com>, Randy Bush <randy@psg.com>, Job Snijders <job@instituut.net>
Cc: gen-art@ietf.org, draft-ietf-grow-large-communities-usage.all@ietf.org, grow@ietf.org, ietf@ietf.org
References: <149252287543.16134.18005737444773296286@ietfa.amsl.com> <20170418235858.sgsa64r7b5th7zam@Vurt.local> <m2vaq1p5oi.wl-randy@psg.com> <1c121aaf-fae7-94ec-71ae-7ac618d86f31@gmail.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <a49c9368-4e49-6699-451e-0af2c1550b73@bogus.com>
Date: Mon, 01 May 2017 10:02:17 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Thunderbird/53.0
MIME-Version: 1.0
In-Reply-To: <1c121aaf-fae7-94ec-71ae-7ac618d86f31@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="6cbvW9DhjU6InIb8PImk84hLP5Cnq5ute"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/peASL0c3NWs2D4BHsiYfg1rlEmQ>
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: Mon, 01 May 2017 17:05:35 -0000

On 4/19/17 1:52 AM, Stewart Bryant wrote:
> 
> 
> On 19/04/2017 02:06, Randy Bush wrote:
>>>> 5.  Security Considerations
>>>>
>>>>     Operators should note the recommendations in Section 11 of BGP
>>>>     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.
>>>
>>>> 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?
>> you're supposed to guess
>>
>> the normal hack here is
>>
>>    this document introduces no new security issues beyond those discussed
>>    in 1997
> 
> Guessing is horrible, but if that is what you do, that is what you do,
> and if the risks are the accepted norm in the BGP
> community I am fine.
> 
> Is corruption (deliberate or otherwise) of the community strings
> something that BGPsec will address?

That seems like a dubious premise given that they are optional. One can
simply remove them and substitute / add additional ones if you so
inclined and that occcurs in the normal course of events.

> - Stewart
>