Re: [sidr] BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)

Matthew Lepinski <mlepinski@ncf.edu> Tue, 04 April 2017 19:15 UTC

Return-Path: <mlepinski@ncf.edu>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A79129498 for <sidr@ietfa.amsl.com>; Tue, 4 Apr 2017 12:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ncf.edu
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 Okgf9s3cJ_d3 for <sidr@ietfa.amsl.com>; Tue, 4 Apr 2017 12:15:51 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 D80161294C4 for <sidr@ietf.org>; Tue, 4 Apr 2017 12:15:44 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id o81so33465052wmb.1 for <sidr@ietf.org>; Tue, 04 Apr 2017 12:15:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncf.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tcSBmI1r0k/WN1ATuI8C1RkP3v+DAVq/sxrxdcSFVcg=; b=Kevno6kMOpBDRd03P3h1yZkxF/Uu0lrn1E2+HBnUyBMpts3du6gC04rTa/rqnnN0ND 55xriUi2PUcrzZYIUc/HGKsCcqpWJCyPrOYPe6E8w8yZF4EGtcU67f3i2nTnQXPGw8+X Ak4qB6TNkFHf7w3o4tf/PdfPjF874F6Zqd4EbcYL0X24ZapNKZdYiknqWjiGdlW5AKdN 5ExrqnECqaw9UD1OUdFTEHI4hKxnNQGd1VXDLfh7/7zvhXCz8SK9+D+BR+6aQf8/13v4 VNnV3eAQ5Ku9IiXUR19PAS/qvwIRkA30h0maqmvKm/p9Ok/DZHBTrIIYcBv3/T/MimAa zMcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tcSBmI1r0k/WN1ATuI8C1RkP3v+DAVq/sxrxdcSFVcg=; b=gYyDNRv+qxRX5ZDlCSK3ztQjR+q6fZL+9Tb9Q4OLzPOtEl2lhpQN7VFAbiICA2kgDn LbEB9QRYz1oW3LJwSbcG1TQyNI2UcYEPK3c0yB5yA30fKKVwlpFqvaOVLmWRRWgD/dJg dLtwCwe/jKhazx+VPP+3QHQ/jtCtlBCIRktK+QEAo8gDLw2zrHwL2kg2Zxc2BiZ/roZW wKCHcWzX9oMFrWvhLbrIbAmbgJ0l/4HB9IyEuHn7hiJiHhZvGcUpcao8YZ1LheHkXJoj Yt61Hpr7dJAUak5BeakpICZ0hB8nw+/3nqKfav7+AER2IK8ddR9VLHGwOxhokelSjvd6 VsFg==
X-Gm-Message-State: AFeK/H1RKO1iZbF1f08gaQxWkmCAcK/WNg69x1fN2w4yQvTrBsuAUKYH isQSSeKAbzZCvT7u1Q2JRx1Ah1MWTViT
X-Received: by 10.28.66.77 with SMTP id p74mr16286641wma.107.1491333343299; Tue, 04 Apr 2017 12:15:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.173.232 with HTTP; Tue, 4 Apr 2017 12:15:42 -0700 (PDT)
Received: by 10.80.173.232 with HTTP; Tue, 4 Apr 2017 12:15:42 -0700 (PDT)
In-Reply-To: <36894BDC-01FC-41A5-B7B8-BC91204AE1D2@cisco.com>
References: <65677770-43DB-4CE0-8E81-B35B9A82DF6F@cisco.com> <CA++NScEB1=TswjnszJm8_kghE2n8MX9gyDPePRsqqNALKyA6=g@mail.gmail.com> <36894BDC-01FC-41A5-B7B8-BC91204AE1D2@cisco.com>
From: Matthew Lepinski <mlepinski@ncf.edu>
Date: Tue, 4 Apr 2017 15:15:42 -0400
Message-ID: <CA++NScGi8J0=9QKs1m3MNqJXCo3XReirAy7i64aKUrE24VULqQ@mail.gmail.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
Cc: "sidr@ietf.org" <sidr@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-sidr-bgpsec-protocol@ietf.org" <draft-ietf-sidr-bgpsec-protocol@ietf.org>, "idr@ietf.org" <idr@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c0742ec2b7675054c5c1a5e
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/ygOMsW-kZqkw1-b2woFUjqeELgg>
Subject: Re: [sidr] BGPsec without Extended Messages (draft-ietf-sidr-bgpsec-protocol)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 19:15:53 -0000

Alvaro,

Thanks a lot. That makes perfect sense.

I support this change.

- Matt Lepinski

On Apr 4, 2017 1:18 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

> On 4/4/17, 12:44 PM, "Matthew Lepinski" <mlepinski@ncf.edu> wrote:
>
> Matt:
>
> Hi!
>
> > The proposed changes seem reasonable, but I want to make sure that I
> > understand the path forward clearly.
> >
> > My understanding is that if we were to reach a future where
> > draft-ietf-idr-bgp-extended-messages is widely deployed, then the BGP
> > speaker's maximum message size will just be larger (than it is today)
> > and as a result we avoid reaching the point where Section 9.2 (of
> > 4271) guidance is needed.
> >
> > Is my understanding correct?
>
> Not exactly.
>
> The text in 9.2/rfc4271 is generic, it doesn’t apply to a specific message
> size; the maximum size is defined elsewhere.  The current text of
> draft-ietf-idr-bgp-extended-messages changes the size of the messages in
> Section 4 (of rfc4271), which is the same place where 9.2 points to.  IOW,
> the text in 9.2 would not change and still be applicable, the limit would
> just be reached later.
>
> > (I want to make sure that future
> > implementers will find our text clear and we won't need to revise this
> > spec to add clarity if extended messages ends up in widespread use.)
>
> To me, the main purpose of changing the BGPsec spec is to depend on
> whatever BGP does, and not on a future extension that may or may not be in
> the form it is today.  However, if we keep the reference to the known
> standard (rfc4271), then we should not have to update this document because
> we would just inherit whatever BGP does.
>
> Thanks!
>
> Alvaro.
>
>