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

Stewart Bryant <stewart.bryant@gmail.com> Wed, 19 April 2017 14:54 UTC

Return-Path: <stewart.bryant@gmail.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 58A3F129AC9; Wed, 19 Apr 2017 07:54:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JyL6cKcLQggt; Wed, 19 Apr 2017 07:54:11 -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 A07FE129AC4; Wed, 19 Apr 2017 07:54:10 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id z109so17367484wrb.1; Wed, 19 Apr 2017 07:54:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=g5s24NlMTYgrKxKepXovDtryOUxF0WN0Cpl3Vv+C0Sk=; b=r9QUxQk52Eqp05KuZRWFW21MNJtK4PEpzAvg/ArI1OTEbC0aUYKFeLGOsF0PFcoYfB MPcIsqcm/v56uCUJTrMyxo7wg6FN4ocBMxndhqaJZaZRwogEB8KH/39ZQwBy1OmFKYSK sg972JWRhfC4pA/sAYduXa8OUjNGZpRxp4lDn4Wjq7FtVWTeFUBB0Bz6T8XLmpFfkg3L E4HdZPfvCx0mJgpCj55s67jFSAYDd2jZ5os9nigY9H+e09fvoRCj6y22JQMEPAdIrp0r cs1XVbxIRo2uV19oL3Q8MRKTH3WgFYdqqOfxgezBehcLcbh2iuvl+ySspTzQaiidzanz sCsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=g5s24NlMTYgrKxKepXovDtryOUxF0WN0Cpl3Vv+C0Sk=; b=HqnWalPjklSm2N64pttEmnOqj41GnpNBTZKY+yBo3D6EqfgjTQg8lvrhhNKWNVLSlk G+vdI2KfoJKmgPfJu9iyMXFKbbSGb16kb9dfmq0SaafQI58S4P7PVXEfFZee+FGZOKnq JF/JImIhTnsl/ponNpC2fduGPlnXj0FjijxMYtJob9U6Rb9Wx+QQT+xWqkdfaOOaXN4v dQwupIkXg9DqKMdTOcxWByWAdyf9Q0NltEvM1R6C58YnPuthEktFKkO3XyKx1zWbt38K ymUdvlnvzcxbqMVN88pP7WJxXjeVmAsuc2eL/acsREABJkA//xRyMU0JbCjdT/jXOBNE 0WfQ==
X-Gm-Message-State: AN3rC/5iva/42V8/2qKWusQcmHpqjq0ZyDqAQvt8tnOp6Klp9hEhRTcs YmVByHaHU7zMLA==
X-Received: by 10.223.150.121 with SMTP id c54mr3130046wra.202.1492613649035; Wed, 19 Apr 2017 07:54:09 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id h199sm13062217wme.4.2017.04.19.07.54.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 07:54:08 -0700 (PDT)
Subject: Re: Genart last call review of draft-ietf-grow-large-communities-usage-06
To: Job Snijders <job@instituut.net>
References: <149252287543.16134.18005737444773296286@ietfa.amsl.com> <20170418235858.sgsa64r7b5th7zam@Vurt.local> <21c205d9-eac4-9403-8450-6bce56b3bfe6@gmail.com> <20170419141841.5agsblcuiqvyxek4@Vurt.local>
Cc: gen-art@ietf.org, grow@ietf.org, draft-ietf-grow-large-communities-usage.all@ietf.org, ietf@ietf.org
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <63963b8c-6e76-b59f-1af2-45dcc68c5422@gmail.com>
Date: Wed, 19 Apr 2017 15:54:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170419141841.5agsblcuiqvyxek4@Vurt.local>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/S7FSrNR8PX7dI68Fz81-AQdXjtY>
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:54:12 -0000

Thanks

I think I have done the required Genart level of due diligence on Security.

Stewart

On 19/04/2017 15:18, Job Snijders wrote:
> 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