Re: [sidr] draft-ietf-sidr-pfx-validate-04.txt

Jay Borkenhagen <jayb@braeburn.org> Mon, 26 March 2012 18:16 UTC

Return-Path: <jayb@braeburn.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E3E21E810F for <sidr@ietfa.amsl.com>; Mon, 26 Mar 2012 11:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.932
X-Spam-Level:
X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0LP8DT64IyR for <sidr@ietfa.amsl.com>; Mon, 26 Mar 2012 11:16:11 -0700 (PDT)
Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id EE36721E80CE for <sidr@ietf.org>; Mon, 26 Mar 2012 11:16:10 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id a62b07f4.0.362912.00-474.1005127.nbfkord-smmo04.seg.att.com (envelope-from <jayb@braeburn.org>); Mon, 26 Mar 2012 18:16:10 +0000 (UTC)
X-MXL-Hash: 4f70b26a65e18265-ea645b966501f1644802ae04ca83e60a91a60d90
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2QIGA7x002961 for <sidr@ietf.org>; Mon, 26 Mar 2012 14:16:10 -0400
Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2QIG0Kn002878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <sidr@ietf.org>; Mon, 26 Mar 2012 14:16:03 -0400
Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for <sidr@ietf.org>; Mon, 26 Mar 2012 14:15:32 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2QIFWuj013125 for <sidr@ietf.org>; Mon, 26 Mar 2012 14:15:32 -0400
Received: from oz.mt.att.com (oz.mt.att.com [135.16.165.23]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2QIFRPM012935 for <sidr@ietf.org>; Mon, 26 Mar 2012 14:15:28 -0400
Received: by oz.mt.att.com (Postfix, from userid 500) id 8F99B2BF2C; Mon, 26 Mar 2012 14:15:27 -0400 (EDT)
X-Mailer: emacs 21.2.1 (via feedmail 8 I); VM 7.18 under Emacs 21.2.1
Message-ID: <20336.45627.147578.984228@oz.mt.att.com>
Date: Mon, 26 Mar 2012 14:15:23 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown
Content-Transfer-Encoding: 7bit
From: Jay Borkenhagen <jayb@braeburn.org>
To: sidr wg list <sidr@ietf.org>
In-Reply-To: <m2k427h2oa.wl%randy@psg.com>
References: <m2k427h2oa.wl%randy@psg.com>
X-GPG-Fingerprint: DDDB 542E D988 94D0 82D3 D198 7DED 6648 2308 D3C0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-RSA-Action: allow
Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-04.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Jay Borkenhagen <jayb@braeburn.org>
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: Mon, 26 Mar 2012 18:16:12 -0000

Randy Bush writes:
 > at this afternoon's sidr ssion, i presented two open issue with
 > draft-ietf-sidr-pfx-validate-04.txt
 > 
 > 1 - Should updates learned via iBGP be marked?
 > 
 > 2 - Should updates injected into BGP on this router be marked?
 > 
 > i think yes because:
 >   o i want support of incremental deployment
 >   o i do not want to find out I am announcing garbage when my neighbor$,1ry(Bs
 >     NOC calls, mis-originations should be stopped at the source
 > 
 > there was fear that, if used at other than edge routers, this allowed
 > creation of loops, as setting local pref etc, do.
 > 
 > i think there was general agreement that this was ok on edge routers
 > and the point of injection, as that is logically an edge router.
 > 
 > would like to see convergence on this


I could not hear the discussion in the room today because the utter
webex fail prevented my remote participation.  So let me ask about
today's discussion.

Pre-RPKI, an ibgp policy can manipulate attributes elsewhere than just
at ingress edge routers, and if the policy is broken it can result in
loops.  It's something to watch out for when designing a policy, but I
am thankful that this kind of flexibility exists, because not all
policies that manipulate attributes other than at ingress edges are
broken.

Regarding pfx-validate: 

I hope the agreement in the room was that a sane network design would
probably involve setting a local 'origin has been checked' community
on the first router inside the AS where that check occurred.

I hope the agreement was _not_ that pfx-validate implementations
should be hard-coded to assess validation state only at the ingress
edge router.