Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt

Danny McPherson <danny@tcb.net> Mon, 02 April 2012 01:22 UTC

Return-Path: <danny@tcb.net>
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 B9E9411E80AE for <sidr@ietfa.amsl.com>; Sun, 1 Apr 2012 18:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.74
X-Spam-Level:
X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100]
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 77Pvvjlcc2Hq for <sidr@ietfa.amsl.com>; Sun, 1 Apr 2012 18:22:18 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4953A11E80AD for <sidr@ietf.org>; Sun, 1 Apr 2012 18:22:18 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id E536526806D; Sun, 1 Apr 2012 19:22:17 -0600 (MDT)
Received: from new-host-4.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Sun, 01 Apr 2012 19:22:17 -0600 (MDT) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=49864; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1257)
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625@Hermes.columbia.ads.sparta.com>
Date: Sun, 1 Apr 2012 21:22:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4315F042-CB35-4A42-9571-D1D51F5EEC09@tcb.net>
References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <D7A0423E5E193F40BE6E94126930C49308E9E3552F@MBCLUSTER.xchange.nist.gov> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> <D7A0423E5E193F40BE6E94126930C49308EE1E84C3@MBCLUSTER.xchange.nist.gov> <CAL9jLaYRi1Uj1g1OXVt9O10ZCWWtoCm646fyqGsYrJkJG99HxQ@mail.gmail.com> <CAH1iCipDYJpWmMpmvdX+Z4AW7cg0QarJbaAmf1JeEBq0rGHiAw@mail.gmail.com> <CAL9jLaaZ2z+WfXJCgaa2ob71t4Qk_khC12UZrr8XT9OzCEs8FA@mail.gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.com>, <CAH1iCiqk4cgPwQGi4751mZCNes2J4B6z7BeRJ0AD0+An8M_DNg@mail.gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625@Hermes.columbia.ads.sparta.com>
To: "sidr@ietf.org list" <sidr@ietf.org>
X-Mailer: Apple Mail (2.1257)
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 02 Apr 2012 01:22:18 -0000

On Mar 31, 2012, at 12:12 AM, Murphy, Sandra wrote:

> 
> Origin validation is strictly and only judging whether the origin has the authority to originate announcements of the prefix.  Origin validation does not ensure that the authorized AS is actually making the announcement.

Indeed!  It's not actually "validation" at all, it's more "policy enforcement".  I.e., is the origin AS in the AS_PATH of the received update an origin AS that the resource holder said was "authorized" to originate the prefix in question.

I suppose it's really no different than static AS filter lists except that rtr-rpki is router-wide and storage is soft-state (akin to ORF, though it's in-band per-peer, or flow spec, for that matter) v. persistent static configuration most folks employ today for policy.

> It is bgpsec path validation that ensures that the announcement is currently and authentically being announced by the AS.  That's the "signed injection" you mention.

This reminds me -- we don't have a signing certificate and validation certificate router on-boarding protocol defined yet for BGPSEC (I assume rtr-rpki is the basis, though it currently does not support this), I think we need to begin working that out sooner rather than later as I suspect the operational implications are far more complex and they will markedly impact RPKI system design as well.

Finally, to R.'s point in a different thread:

"If that would not be enough BGP is soon to become completely "hard state" if one would implement http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-01"

I suspect we're going to end up with draft-foo-rtr-rpki--proto-persistence-* at some point as well (or we could use BGP itself for on-boarding RPKI data :-)

-danny