Re: Last Call: <draft-ietf-sidr-bgpsec-ops-12.txt> (BGPsec Operational Considerations) to Best Current Practice

Job Snijders <> Sat, 17 December 2016 18:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49328129A5B for <>; Sat, 17 Dec 2016 10:26:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z4l114VRLrQd for <>; Sat, 17 Dec 2016 10:26:17 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 632C0129A5F for <>; Sat, 17 Dec 2016 10:26:14 -0800 (PST)
Received: by with SMTP id v7so117487926wjy.2 for <>; Sat, 17 Dec 2016 10:26:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=bX6zBfD8iEqJ5BTfXYkKnl8L81443CaQcrUnHgzKrAY=; b=XuoriYQinS2g97v+Sa+JDi2kP2firFLukFU1Q/r/cOqqY9zCCjJ8dKCEZviaFv2S5S kaqMnLynrcqSx3zN5LJQy4hEl6UJ1l+aK7rATpevFBgt5+XqOtfGs2hzKqnhtzDjGfQw gAy7qPIeHapuuIf3x+wQIOvOfxvGNLFrMli3RV2GN3DX8OS9QXJL8hvpHr6eM8noQRDC Z5H+/HWTA6rMW6ilvbb56kQly0wSbap63xpTm3hxS24s/uf8zezLHFMrdaViNG7+otH+ f7Ezg/IG/osjbOJ3Aqyo2YDXou3fFJBXf5NlJbA2EnQVZcU9pLhfELUw0yczQJHGW04e 27Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=bX6zBfD8iEqJ5BTfXYkKnl8L81443CaQcrUnHgzKrAY=; b=FKcJxbDRxCPjpXf2GY3+zVy+M9sb+ZQB4i+jFZ2qwrshu7Q+HkcerD3Ko/rzM/yCP+ glaVxK+ugMc1fhlFLh3s2ax2eeIGM4ipnR7znu2ZOCOlwzYOmppGFEXFyNeFnlqPV4Dl jH7U/ZN+VWGS+xWJx4mXB8/pYLHzjTxwOzci6K3jWIUH878mAbGEw2Zsl/bZVlVWfY5n GJZCo9olUL2u38r+OlOfZrw3BjS/YkPFhPb8WwBeZ+Gxg7rHWg2V+B+tCdeqTbWygTd2 GwKrhSfJmT7/GACqUEAL/S7exCpLK6mODzjPsOjLBDIBHToJhIB5VwWeKDQ4OigaBbrI wq3g==
X-Gm-Message-State: AKaTC020Hc5ouulDFi08Qztw3pX2pJ02AnmPOzHqun6SDXSa4bnXvp6Urr2Asx4zfyYYgg==
X-Received: by with SMTP id tc3mr7781372wjb.129.1481999172649; Sat, 17 Dec 2016 10:26:12 -0800 (PST)
Received: from localhost ([2001:67c:208c:10:b591:3f29:3ca8:f0b9]) by with ESMTPSA id jm6sm12471778wjb.27.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Dec 2016 10:26:12 -0800 (PST)
Date: Sat, 17 Dec 2016 19:26:10 +0100
From: Job Snijders <>
Subject: Re: Last Call: <draft-ietf-sidr-bgpsec-ops-12.txt> (BGPsec Operational Considerations) to Best Current Practice
Message-ID: <20161217182610.GE1554@Vurt.local>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <>
Cc: Chris Morrow <>,,, IETF-Announce <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Dec 2016 18:26:18 -0000

Hi all,

This following paragraph looks somewhat awkward to me.

    An edge site which does not provide transit and trusts its
    upstream(s) SHOULD only originate a signed prefix announcement and
    need not validate received announcements.

    If you are multihomed and receive full (or partial) tables, there is
    benefit in validating the received routes, if not: why not? One
    upstream might be poisoned while the other isn't? Mabye the text
    should be amended to make it clear that this might apply if the stub
    ASN only takes default-originates?

Kind regards,


On Wed, Dec 07, 2016 at 07:27:28AM -0800, The IESG wrote:
> The IESG has received a request from the Secure Inter-Domain Routing WG
> (sidr) to consider the following document:
> - 'BGPsec Operational Considerations'
>   <draft-ietf-sidr-bgpsec-ops-12.txt> as Best Current Practice
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> mailing lists by 2016-12-21. Exceptionally, comments may be
> sent to instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> Abstract
>    Deployment of the BGPsec architecture and protocols has many
>    operational considerations.  This document attempts to collect and
>    present the most critical and universal.  It is expected to evolve as
>    BGPsec is formalized and initially deployed.
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.
> The document contains these normative downward references.
> See RFC 3967 for additional information: 
>     rfc6811: BGP Prefix Origin Validation (Proposed Standard - IETF stream)
>     draft-ietf-sidr-bgpsec-protocol: BGPsec Protocol Specification (None - IETF stream)
>     rfc6493: The Resource Public Key Infrastructure (RPKI) Ghostbusters Record (Proposed Standard - IETF stream)
> Note that some of these references may already be listed in the acceptable Downref Registry.