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

Randy Bush <> Sat, 17 December 2016 23:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBDB912949A; Sat, 17 Dec 2016 15:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.001
X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3WfS4T7CaHvI; Sat, 17 Dec 2016 15:31:50 -0800 (PST)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2EFF12948D; Sat, 17 Dec 2016 15:31:49 -0800 (PST)
Received: from localhost ([] by with esmtp (Exim 4.86_2) (envelope-from <>) id 1cIOSB-0005gV-1c; Sat, 17 Dec 2016 23:31:47 +0000
Date: Sun, 18 Dec 2016 08:31:44 +0900
Message-ID: <>
From: Randy Bush <>
To: Job Snijders <>
Subject: Re: Last Call: <draft-ietf-sidr-bgpsec-ops-12.txt> (BGPsec Operational Considerations) to Best Current Practice
In-Reply-To: <20161217182610.GE1554@Vurt.local>
References: <> <20161217182610.GE1554@Vurt.local>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
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 23:31:51 -0000

hi job,

>     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?

that is why it is SHOULD.  and note it does say "and trusts its
upstream(s)."  going down the rat-hole of trusting upstreams differently
seems an exercise in adding words but not adding value.

note that doing path validation would pretty much mean the end site buys
new hardware.  pointing out that one could avoid that was the purpose of
the paragraph.

if i made any change, it would be a rant about out-sourcing security.
e.g. "Note that this is out-sourcing security, which is generally
unwise.  But the trade-off is likely out-sourcing security or buying
bigger hardware."