IETF Logo Mail Archive

Re: [Idr] I-D Action: draft-ietf-idr-next-hop-capability-03.txt

Randy Bush <randy@psg.com> Thu, 28 June 2018 16:01 UTC

Return-Path: <randy@psg.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21B7130DEA for <idr@ietfa.amsl.com>; Thu, 28 Jun 2018 09:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 M-aQ-j72ip30 for <idr@ietfa.amsl.com>; Thu, 28 Jun 2018 09:01:36 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 79F98130DE8 for <idr@ietf.org>; Thu, 28 Jun 2018 09:01:36 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1fYZMV-0004wC-2j; Thu, 28 Jun 2018 16:01:35 +0000
Date: Thu, 28 Jun 2018 09:01:34 -0700
Message-ID: <m2h8lmq4rl.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: bruno.decraene@orange.com
Cc: Interminable Discussion Room <idr@ietf.org>
In-Reply-To: <19553_1530173556_5B349874_19553_6_1_53C29892C857584299CBF5D05346208A47AB766D@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <153008684965.15406.536825824891886594@ietfa.amsl.com> <m2o9fvptr9.wl-randy@psg.com> <19553_1530173556_5B349874_19553_6_1_53C29892C857584299CBF5D05346208A47AB766D@OPEXCLILM21.corporate.adroot.infra.ftgroup>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 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: <https://mailarchive.ietf.org/arch/msg/idr/jdAuLxbgGhDOtG98z4kdrtpuvL8>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-next-hop-capability-03.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2018 16:01:39 -0000

hi bruno,

> [Trimming the list to IDR]

sorry about that.  yesterday was almost as rushed as today.

>> from the sec cons
>> 
>>     an operator who is relying on the information carried in BGP must have a
>>     transitive trust relationship back to the source of the information.
>>     Specifying the mechanism(s) to provide such a relationship is beyond the
>>     scope of this document.
>> 
>> call the security police!
>  
> This is intended to be just stating a fact.

a fact which is lethal

> Would you mind elaborating on your comment?

trust is not transitive.  the document could be assuming it is within
some kind of an assured trust boundary, but makes no assurance of that.
for an example of how one might deal with this, see section 3 and the
first sec cons of draft-ymbk-sidrops-ov-signal-01.txt

randy

v2.23.0 | Report a Bug | By Email