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

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Sat, 09 July 2011 13:31 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 C532E21F8640 for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2011 06:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 uMljyr1sKhX8 for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2011 06:31:15 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 371CB21F85F9 for <sidr@ietf.org>; Sat, 9 Jul 2011 06:31:15 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.323.0; Sat, 9 Jul 2011 09:30:59 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Sat, 9 Jul 2011 09:31:14 -0400
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: Chris Hall <chris.hall@highwayman.com>
Date: Sat, 09 Jul 2011 09:30:24 -0400
Thread-Topic: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route Server
Thread-Index: AQLnVxnGjNWVOyUsj5rn4Yr0eH1c1gL48hq9AYUdEa8CIAtBeALePpAvAmnYtsEBdZrX2AJHVOEeAiwqzkKSHwlsgIAAOq9B
Message-ID: <D7A0423E5E193F40BE6E94126930C4930877FE8A5C@MBCLUSTER.xchange.nist.gov>
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> <017d01cc3da0$9f8cd390$dea67ab0$@highwayman.com> <Pine.WNT.4.64.1107081506110.1536@SMURPHY-LT.columbia.ads.sparta.com> <D7A0423E5E193F40BE6E94126930C4930879E9BDD3@MBCLUSTER.xchange.nist.gov>, <01ab01cc3e1b$db54d230$91fe7690$@highwayman.com>
In-Reply-To: <01ab01cc3e1b$db54d230$91fe7690$@highwayman.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: 'Sandra Murphy' <Sandra.Murphy@sparta.com>, '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 13:31:15 -0000

>Strictly entre nous, I don't get a strong sense from the text that
>entering into such an arrangement is an obvious and foolish mistake
>:-}  Unlike, for example, an ISP using its own key to proxy sign for a
>customer, which is "considered a bad idea".
>
>Chris

If an ISP (or IXP/RS) and its customer feel strongly that they have a long trusted relationship,
and they are comfortable with this type of arrangement (outside of BGPSEC
but still only to allow them to perform BGPSEC more efficiently or with lower cost), 
what good does it do to tell them that they are making "an obvious and foolish mistake"?
They also know that the customer can revoke the EE cert and annul the 
router (or RS)-specific private key if the relationship ends or trust
is compromised (Section 6.6.2).   

Having said that, I respect Randy's viewpoint (and yours -- seems you are in agreement).
There is no conflict here since it is not about BGPSEC protocol specification.
This is about operational best practices.
We can revise Section 6.6 to put greater emphasis on the "cons" part of it.

Sriram
________________________________________