Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)

Randy Bush <randy@psg.com> Wed, 27 February 2019 23:48 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407071311E1 for <sidrops@ietfa.amsl.com>; Wed, 27 Feb 2019 15:48:34 -0800 (PST)
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 F73WEJTqzxpD for <sidrops@ietfa.amsl.com>; Wed, 27 Feb 2019 15:48:32 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A111311D7 for <sidrops@ietf.org>; Wed, 27 Feb 2019 15:48:32 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1gz8w7-0004SJ-O7; Wed, 27 Feb 2019 23:48:27 +0000
Date: Wed, 27 Feb 2019 15:48:26 -0800
Message-ID: <m2ef7s4wtx.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: "Montgomery, Douglas (Fed)" <dougm@nist.gov>
Cc: Russ Housley <housley@vigilsec.com>, Jeffrey Haas <jhaas@pfrc.org>, "sidrops@ietf.org" <sidrops@ietf.org>
In-Reply-To: <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>
References: <m2fts968ei.wl-randy@psg.com> <BD686FC4-58B7-48FC-85EC-EEC5C2F30B53@vigilsec.com> <20190227215142.GB21642@pfrc.org> <3EF81391-A613-4F10-B636-E29ABB5643DA@vigilsec.com> <7735E727-E19E-493B-ACAE-38F6A1A4BA75@nist.gov>
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/sidrops/nBdcYspNYDjg_vJsYts5pq1H1pw>
Subject: Re: [Sidrops] WG-ADOPTION: draft-borchert-sidrops-rpki-state-unverified-01 - ENDS: 2019-03-12 (mar 12)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 23:48:34 -0000

> Examine the iBGP peer that you thought you configured to do origin
> validation and determine why it is unable to.

the path of debugging hooks runs far deeper into the mud.  to repeat;
you are stepping off a cliff here.

there are a number of reasons the match might not have been made: peer
not configured for validation, prefix in execption list, AS in exception
list, ...  will we next enumerate them all?  e.g. for debugging, i might
like to know which of my policies, or combination thereof, caused the
prefix not to be evaluated.  i am NOT suggesting we go down this rabbit
hole.

> We envisioned this being useful in scenarios such as: you have enabled
> BGP Origin Validation on a router that has lost all connections to its
> validating caches.

% show bgp rpki servers

> At the moment we can't tell administratively disabled from enabled,
> but failed in some manner.  We see some value in being able to
> diagnose that.

that is why we have cli-based (and yang etc) debugging tools.  you want
to know where in all your complex policy some decision was made, you
need to go through the policy, don't try to encode the cross-product of
all the posibilities in a result.

> Keep in mind, most of the FUD in this space comes from the fear that
> operators will not be able to diagnose why routes are/are not being
> filtered.  This theme came up a lot in the meeting before NANOG.

the game is over.  at&t has deployed and the multitude are hurrying to
join him.  and the flag-wavers are rushing to get in front and curry
publicity.

> Not the subject of this draft, but the concept of being able to tell
> if your iBGP peer actually performed validation will be even more
> useful in BGPSec, but that is for another draft.

and another century

randy