Re: [sidr] pCNT & prepending

Roque Gagliano <rogaglia@cisco.com> Thu, 28 July 2011 22:21 UTC

Return-Path: <rogaglia@cisco.com>
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 0AD745E8017 for <sidr@ietfa.amsl.com>; Thu, 28 Jul 2011 15:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAPU1BKrM4u6 for <sidr@ietfa.amsl.com>; Thu, 28 Jul 2011 15:21:07 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 125215E800E for <sidr@ietf.org>; Thu, 28 Jul 2011 15:21:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=10729; q=dns/txt; s=iport; t=1311891667; x=1313101267; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=gAxijWliR+W82kZnvwT1+mPP44h4gm3+srQrpaxqEko=; b=U0KjAyZR8GY30FXrw5i33oaABnKvDhkhs1i/rErKAJr0K//F+VCT2jsM q8aX+yih0gwzBemH83ctn/mnjJ3QDFkzK7Iww/2p8CbqpyM0EPBDkHdOT 1xy+mAVLApE3VBDbL8G7xkKLL7jNBFNjo4dsnyBd0ZT5aDWPNTQGPda2L o=;
X-Files: smime.p7s : 4389
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAJnfMU6rRDoI/2dsb2JhbAA1AQEBAQIBAQEBEQFlCwUMDAROAhIYOQcXJ6c1d4h8BKRGnjuFYl8EknmRAA
X-IronPort-AV: E=Sophos; i="4.67,284,1309737600"; d="p7s'?scan'208,217"; a="7564248"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jul 2011 22:21:06 +0000
Received: from sjc-vpn7-1108.cisco.com (sjc-vpn7-1108.cisco.com [10.21.148.84]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6SML5uc030815; Thu, 28 Jul 2011 22:21:05 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary="Apple-Mail-268-724499598"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Roque Gagliano <rogaglia@cisco.com>
In-Reply-To: <p0624080fca572d4618ba@[130.129.71.153]>
Date: Thu, 28 Jul 2011 18:21:01 -0400
Message-Id: <7BF9E3EF-B784-43AB-95FC-137AB9C627A0@cisco.com>
References: <3E7A5153-26C1-4974-9A1B-33AB92FCD657@tcb.net> <p0624080fca572d4618ba@[130.129.71.153]>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] pCNT & prepending
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: Thu, 28 Jul 2011 22:21:08 -0000

> I think Roque's suggestion of an EKU to mark an EE cert as being associated with a route server is helpful here.  Yes, this is a self-assertion, and thus not authoritative.
> But, it could be a convenient mechanism to assist in configuration for checking when it's OK to receive an update with a 0 pCNT value. Specifically, if we agree that an ISP knows when a configured peer is an RS, then we can mandate that an ISP check to make sure that an update received from a peer with a 0 pCNT is, in fact, coming from what it believes is an RS. Having a marker in a cert that says "HI, I'm an RS" at least makes this intent clear.  (One also could imagine that, since IXPs are well known and the route servers at IXPs are known, a third party could scan the RPKI looking for certs that claim to be associated with RSes, and checking to see if they appear to be legit.)

About this last statement, the RIRs keep a list of IP Addresses for the IXPs, we could ask them to sign that list and include their ASN to increase the "confidence" that they really are RS. This could be checked by the validator.

Roque


> BGPSEC also could mandate some configuration capabilities that enable ASes further along a path to filter routes based on 0 pCNT values in a path. For example, one might say that any AS can be configured to drop a route with 2 or more 0 pCNT hops in a row, or more than 2 total, or whatever.  If we can reach agreement on any general rules with regard to 0 pCNT values, these rules can become part of the validation standard.
> 
> Steve
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr