IETF Logo Mail Archive

Re: [sidr] comment on draft-ietf-sidr-bgpsec-protocol and draft-ietf-sidr-bgpsec-ops

Matthew Lepinski <mlepinski.ietf@gmail.com> Thu, 24 July 2014 19:17 UTC

Return-Path: <mlepinski.ietf@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6CA1B280E for <sidr@ietfa.amsl.com>; Thu, 24 Jul 2014 12:17:15 -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, SPF_PASS=-0.001] 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 281FYLaJrjns for <sidr@ietfa.amsl.com>; Thu, 24 Jul 2014 12:17:13 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0111B2803 for <sidr@ietf.org>; Thu, 24 Jul 2014 12:17:11 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id u56so3177386wes.14 for <sidr@ietf.org>; Thu, 24 Jul 2014 12:17:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Wdq5kwllw+xpgSkN8B7uf5A0hRF1xsUt2f6GinP3el4=; b=KYCWiUwmew0F1HZVf53Qwvqv4QSIxFa26bBq/GnvpFNYwQcf0DVtO/JVwTmUoCllWs L85Q3R4HxGzEWI6+esybL2D6qjuPuYItFDl0DwncgSNox6ySG0sGm6nkfK++TXEEVLtv g80ukCliZZNiQUmEmnoBPwviOqMUuEh3VblHvqofF++D3wohc7n/BhC7V6mfYyGek637 82Erh8adLE+GZqoDgLRIAkxmM30TWXPKpq5mex/QC5RA3SEIGQYfqWsvyD19qvKOoKM1 NOWIjEeouhUglnTYCJdLyYWttVXn/Zrih/2Jgf1VwlCjv8/bn+q3pEqnTjuWYEZXvuzL Ka1w==
MIME-Version: 1.0
X-Received: by 10.195.18.8 with SMTP id gi8mr14643216wjd.75.1406229428564; Thu, 24 Jul 2014 12:17:08 -0700 (PDT)
Received: by 10.216.148.138 with HTTP; Thu, 24 Jul 2014 12:17:08 -0700 (PDT)
In-Reply-To: <4C2B730F-3BED-40CF-BBD6-90F97B69E22D@tislabs.com>
References: <4C2B730F-3BED-40CF-BBD6-90F97B69E22D@tislabs.com>
Date: Thu, 24 Jul 2014 15:17:08 -0400
Message-ID: <CANTg3aBZUKZx29RtVQ-oYwp-WyaU=3TxLom_4WVgdEoY=XPuWA@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: Sandra Murphy <sandy@tislabs.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/jp-Ef2Sg0IgRM507AqWgMZi_KPE
Cc: IETF SIDR <sidr@ietf.org>
Subject: Re: [sidr] comment on draft-ietf-sidr-bgpsec-protocol and draft-ietf-sidr-bgpsec-ops
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 24 Jul 2014 19:17:15 -0000

With regards to the bgpsec-protocol document, I agree with Sandy that
the protocol document should reference RFC 6811/6483. I will reference
the origin validation algorithm in next version of bpgsec-protocol.

With regards to the bpgsec-ops document, it isn't at all clear to me
what the "right" answer is for how an implementation handles
configuration of origin validation and path validation (when both are
implemented). Unless there is something that we fear implementations
might do that is clearly bad, I don't see value in adding text to
bgpsec-ops.

On Thu, Jul 24, 2014 at 2:54 PM, Sandra Murphy <sandy@tislabs.com> wrote:
> Speaking as regular ol' member
>
> The bgpsec-protocol draft has the following text:
>
>    Next, the BGPSEC speaker verifies that the origin AS is authorized to
>    advertise the prefix in question.  To do this, consult the valid ROA
>    data to obtain a list of AS numbers that are associated with the
>    given IP address prefix in the update message.  Then locate the last
>    (least recently added) AS number in the Secure_Path portion of the
>    BGPSEC_Path attribute.  If the origin AS in the Secure_Path is not in
>    the set of AS numbers associated with the given prefix, then the
>    BGPSEC update message is 'Not Valid' and the validation algorithm
>    terminates.
>
> This text reprises the origin validation algorithm, without some of the more detailed pieces.
>
> I believe it would be better instead to refer to RFC6483 or RFC6811, rather than try to reprise the algorithm.  Something like:  "To do this, the speaker performs the algorithm of RFC6483/RFC6811.  If the result is not Valid, then the BGP Update is 'Not Valid'."
>
> (This seems particularly prudent as we might be reconsidering the validation algorithm.)
>
> This also brought to mind a point I'm curious about.
>
> Does a bgpsec speaking router have one configuration about the results of the bgpsec validation, or does it have two configurations, one for the results of the origin validation and a second for the results of the bgpsec validation?  Are the two validation states separated?
>
> Should this be a point to be explained in the bgpsec-ops document?
>
> --Sandy, speaking as regular ol' member
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>

v2.23.0 | Report a Bug | By Email