Re: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route Server

Roque Gagliano <rogaglia@cisco.com> Sat, 09 July 2011 15:00 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 C76F721F87BA for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2011 08:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 OQO6uro4+jeu for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2011 08:00:57 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8329521F87B6 for <sidr@ietf.org>; Sat, 9 Jul 2011 08:00:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=7616; q=dns/txt; s=iport; t=1310223656; x=1311433256; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=l2VhydFU/GxPYi7UchaYOW+UPXkQCn5y/lD6IG3pFQM=; b=PqVl1VJ1uxhN+8+YTwb9o1IAZJMgAo6/LJoCFrgXebyd3nq/tN9RztoC M5EIyAg/eWPQl7nep+wqpqrE3HroQISAbAIHL0G1sRgRQNF1bnmxCd0xV uYD4/P/mpUY2t3LHKyppg0yX5GUT37c6BJowa5U4WAjx2U4PebGLCxN8/ U=;
X-Files: smime.p7s : 4389
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAF1sGE6Q/khL/2dsb2JhbABFDqdRd4h6pXCdIYMigjlfBJJUkEk
X-IronPort-AV: E=Sophos; i="4.65,504,1304294400"; d="p7s'?scan'208"; a="41345994"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 09 Jul 2011 15:00:54 +0000
Received: from ams3-vpn-dhcp5022.cisco.com (ams3-vpn-dhcp5022.cisco.com [10.61.83.157]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p69F0scn017775; Sat, 9 Jul 2011 15:00:54 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary="Apple-Mail-235--943512811"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Roque Gagliano <rogaglia@cisco.com>
In-Reply-To: <m2oc14ljh7.wl%randy@psg.com>
Date: Sat, 09 Jul 2011 17:00:49 +0200
Message-Id: <0D4139F7-B4DC-497E-9079-C95EA1D3662D@cisco.com>
References: <012601cc3d54$8f07c4e0$ad174ea0$@highwayman.com> <m2y609kptw.wl%randy@psg.com> <014001cc3d74$319571c0$94c05540$@highwayman.com> <m2pqlklw3v.wl%randy@psg.com> <014a01cc3d7f$6312f730$2938e590$@highwayman.com> <m2oc14ljh7.wl%randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.1084)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route Server
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: Sat, 09 Jul 2011 15:00:57 -0000

Randy,

>> I'm suggesting that A delegates a unique signing key to the RS.
> 
> the expression we use is, now RS can sign gifs of naked furries in A's
> name.  i.e. A has given away the store.  you do NOT let anyone else have
> your private keys.
> 
> for example. in this context, RS can now give that key to Perp who can
> originate A's prefixes.  #fail

I do not follow this reasoning. The certificate for BGPSEC are EE certificates with only A's ASN in its RFC3779 extension. So, you cannot use the same key to sign a ROA with another ASN nor issue any certificate using that same key.

IMHO, A good idea could be to clearly identify BGPSEC EE certs in the RPKI repository by assign them a distinct Extended Key Usage (EKU). The use of EKU is permitted by the RPKI CP. The EKU should be checked by the RP during the validation process.

Roque  


> 
>> This is what "6.6 Proxy Signing" in
>> draft-sriram-bgpsec-design-choices suggests, is it not ?  Or does that
>> blow the trust model to hell, also ?
> 
> it does indeed.  that is why 6.6 was rejected.
> 
> randy
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr