From rpsec-bounces@ietf.org Sun Jul 08 18:16:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7f30-0002AA-HQ; Sun, 08 Jul 2007 18:16:06 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I7f2u-0001pW-4U for rpsec-confirm+ok@megatron.ietf.org; Sun, 08 Jul 2007 18:16:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7f2t-0001nZ-5g; Sun, 08 Jul 2007 18:15:59 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7f2S-0001g4-Kx; Sun, 08 Jul 2007 18:15:59 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4ED96328EC; Sun, 8 Jul 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7f1y-00027E-66; Sun, 08 Jul 2007 18:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 08 Jul 2007 18:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rpsec@ietf.org Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-bgpsecrec-08.txt X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF. Title : BGP Security Requirements Author(s) : B. Christian, T. Tauber Filename : draft-ietf-rpsec-bgpsecrec-08.txt Pages : 19 Date : 2007-7-8 The security of BGP, the Border Gateway Protocol, is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routing system, is more complex. This document describes a set of requirements for securing BGP, including communications between BGP speakers, and the routing information carried within BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rpsec-bgpsecrec-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-8171016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-bgpsecrec-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-8171016.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --NextPart-- From rpsec-bounces@ietf.org Mon Jul 09 10:22:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7u7r-00079C-8b; Mon, 09 Jul 2007 10:22:07 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I7u7q-000797-7M for rpsec-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 10:22:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7u7p-00078d-J8 for rpsec@ietf.org; Mon, 09 Jul 2007 10:22:05 -0400 Received: from m106.maoz.com ([205.167.76.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7u7p-0000E1-6Z for rpsec@ietf.org; Mon, 09 Jul 2007 10:22:05 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l69ELWiH018490 for ; Mon, 9 Jul 2007 07:21:32 -0700 Received: (from ttauber@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l69ELWj5018489 for rpsec@ietf.org; Mon, 9 Jul 2007 07:21:32 -0700 Date: Mon, 9 Jul 2007 07:21:32 -0700 From: Tony Tauber To: rpsec@ietf.org Message-ID: <20070709142132.GF7635@1-4-5.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [RPSEC] BGP Security Requirements v08 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Hi Folks, Here's the latest revision of the BGP Security Requirements I-D incorporating comments recieved: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-08.txt Diff from last version: http://tools.ietf.org/wg/rpsec/draft-ietf-rpsec-bgpsecrec/draft-ietf-rpsec-bgpsecrec-08-from-07.wdiff.html Please send your feedback. Thanks, Tony ----- Forwarded message from Internet-Drafts@ietf.org ----- From: Internet-Drafts@ietf.org Date: Sun, 08 Jul 2007 18:15:02 -0400 To: i-d-announce@ietf.org Cc: rpsec@ietf.org Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-bgpsecrec-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF. Title : BGP Security Requirements Author(s) : B. Christian, T. Tauber Filename : draft-ietf-rpsec-bgpsecrec-08.txt Pages : 19 Date : 2007-7-8 The security of BGP, the Border Gateway Protocol, is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routing system, is more complex. This document describes a set of requirements for securing BGP, including communications between BGP speakers, and the routing information carried within BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-08.txt _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 09 10:23:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7u8z-0007Nw-Uq; Mon, 09 Jul 2007 10:23:17 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I7u8y-0007Ni-0k for rpsec-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 10:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7u8x-0007NX-NP for rpsec@ietf.org; Mon, 09 Jul 2007 10:23:15 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7u8t-0000Vd-At for rpsec@ietf.org; Mon, 09 Jul 2007 10:23:15 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l69EN4Ca018504; Mon, 9 Jul 2007 07:23:04 -0700 Received: (from ttauber@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l69EN4Ma018503; Mon, 9 Jul 2007 07:23:04 -0700 Date: Mon, 9 Jul 2007 07:23:04 -0700 From: Tony Tauber To: rpsec@ietf.org Message-ID: <20070709142304.GG7635@1-4-5.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Russ White Subject: [RPSEC] Agenda items for IETF69 (Chicago) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org RPSEC is planning to meet. Please send along any agenda items you may have. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 10 11:39:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HoB-0001gJ-SP; Tue, 10 Jul 2007 11:39:23 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8Ho9-0001g5-MI for rpsec-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 11:39:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Ho9-0001ft-Ay for rpsec@ietf.org; Tue, 10 Jul 2007 11:39:21 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Hnn-0008FQ-Ve for rpsec@ietf.org; Tue, 10 Jul 2007 11:39:21 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I8HnH-0002xs-3g; Tue, 10 Jul 2007 11:38:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070709142132.GF7635@1-4-5.net> References: <20070709142132.GF7635@1-4-5.net> Date: Tue, 10 Jul 2007 11:38:44 -0400 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1222441466==" Errors-To: rpsec-bounces@ietf.org --===============1222441466== Content-Type: multipart/alternative; boundary="============_-1028040568==_ma============" --============_-1028040568==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Tony, Thanks for updating the requirements document. I see that almost all of my suggested edits were incorporated, but a couple of questions I raised in my comments were not addressed, which leaves some ambiguity. Here are the residual questions/comments: In (new) section 4.2 (Incremental Deployment), the second bullet says: o A BGP security mechanism MUST provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non-backward compatible fashion though care must be taken to ensure UPDATES can traverse intermediate routers which don't support the new format. My comment was: One might interpret this to mean that any extended form of UDATE message MUST be transmitted through ASes that are not capable of processing it. This is imposing an unnecessary burden on solutions, since an alternative is to just mot send such messages through ASes than can't make use of them. I'd like to see a clarification of the intent of this bullet, relative to the concern I raised in my comment. The next bullet in the section says: In an environment where both secured and non-secured systems are interoperating a mechanism MUST exist for secured systems to identify whether an originator intended the information to be secured. My questions was: Does this refer to the Origin AS or the neighbor AS? I still think we need to say to which originator this bullet refers. Finally, the last paragraph of (new) section 8 says: An associated delegation criteria is the requirement to allow for non-BGP stub networks. As a result, all secured BGP implementations MUST allow for the contemporaneous origination of a route for a prefix by more than one AS. I had suggested adding the phrase "subject to the authorization criteria above." at the end of the last sentence. I was wondering why you chose to not add this? Steve --============_-1028040568==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] BGP Security Requirements v08
Tony,

Thanks for updating the requirements document. I see that almost all of my suggested edits were incorporated, but a couple of questions I raised in my comments were not addressed, which leaves some ambiguity.  Here are the residual questions/comments:

In (new) section 4.2 (Incremental Deployment), the second bullet says:

o  A BGP security mechanism MUST provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment.  Message  formatting in a fully secured environment MAY be handled in a non-backward compatible fashion though care must be taken to ensure UPDATES can traverse intermediate routers which don't support the new format.

My comment was:  One might interpret this to mean that any extended form of UDATE message MUST be transmitted through ASes that are not capable of processing it. This is imposing an unnecessary burden on solutions, since an
alternative is to just mot send such messages through ASes than can't make use of them.

I'd like to see a clarification of the intent of this bullet, relative to the concern I raised in my comment.

The next bullet in the section says:

In an environment where both secured and non-secured systems are interoperating a mechanism MUST exist for secured systems to identify whether an originator intended the information to be secured.

My questions was: Does this refer to the Origin AS or the neighbor AS?

I still think we need to say to which originator this bullet refers.

Finally, the last paragraph of (new) section 8 says:

An associated delegation criteria is the requirement to allow for non-BGP stub networks.  As a result, all secured BGP implementations MUST allow for the contemporaneous origination of a route for a prefix by more than one AS.

I had suggested adding the phrase "subject to the authorization criteria above." at the end of the last sentence. I was wondering why you chose to not add this?


Steve
--============_-1028040568==_ma============-- --===============1222441466== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1222441466==-- From rpsec-bounces@ietf.org Tue Jul 10 17:36:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8NNI-0001V1-S3; Tue, 10 Jul 2007 17:36:01 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8NNF-0001Uv-UE for rpsec-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 17:35:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8NNF-0001Um-KK for rpsec@ietf.org; Tue, 10 Jul 2007 17:35:57 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8NNB-0004mn-6g for rpsec@ietf.org; Tue, 10 Jul 2007 17:35:57 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l6ALZcOj014580; Tue, 10 Jul 2007 14:35:38 -0700 Received: (from ttauber@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l6ALZcgs014579; Tue, 10 Jul 2007 14:35:38 -0700 Date: Tue, 10 Jul 2007 14:35:38 -0700 From: Tony Tauber To: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Message-ID: <20070710213538.GB27477@1-4-5.net> References: <20070709142132.GF7635@1-4-5.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Hi Steve, As usual your detailed comments were helpful. Comments are inline. On Tue, Jul 10, 2007 at 11:38:44AM -0400, Stephen Kent wrote: > Tony, > > Thanks for updating the requirements document. I see that almost all > of my suggested edits were incorporated, but a couple of questions I > raised in my comments were not addressed, which leaves some > ambiguity. Here are the residual questions/comments: > > In (new) section 4.2 (Incremental Deployment), the second bullet says: > > o A BGP security mechanism MUST provide backward compatibility in > the message formatting, transmission, and processing of routing > information carried through a mixed security environment. Message > formatting in a fully secured environment MAY be handled in a > non-backward compatible fashion though care must be taken to ensure > UPDATES can traverse intermediate routers which don't support the new > format. > > My comment was: One might interpret this to mean that any extended > form of UDATE message MUST be transmitted through ASes that are not > capable of processing it. This is imposing an unnecessary burden on > solutions, since an alternative is to just mot send such messages > through ASes than can't make use of them. I see this requirement as a (possibly unnecessary) corollary to the requirement for supporting non-contiguous deployments. The fact that the interpretation is ambiguous about how specifically one achieves this goal (perhaps properly) reflects the fact that solutions can get creative. I'd like to hear whether others find this item problematic. > I'd like to see a clarification of the intent of this bullet, > relative to the concern I raised in my comment. > > The next bullet in the section says: > > In an environment where both secured and non-secured systems are > interoperating a mechanism MUST exist for secured systems to identify > whether an originator intended the information to be secured. > > My questions was: Does this refer to the Origin AS or the neighbor AS? > > I still think we need to say to which originator this bullet refers. My reading of it would be "originator". I didn't find it ambiguous. Perhaps you or someone else could suggest clearer text if needed. > Finally, the last paragraph of (new) section 8 says: > > An associated delegation criteria is the requirement to allow for > non-BGP stub networks. As a result, all secured BGP implementations > MUST allow for the contemporaneous origination of a route for a > prefix by more than one AS. > > I had suggested adding the phrase "subject to the authorization > criteria above." at the end of the last sentence. I was wondering why > you chose to not add this? It was a simple oversight. I can put it in. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 10 17:51:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Nbi-00044j-CW; Tue, 10 Jul 2007 17:50:54 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8Nbh-00044Y-9L for rpsec-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 17:50:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Nbg-00044Q-VJ for rpsec@ietf.org; Tue, 10 Jul 2007 17:50:52 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Nbg-0007V2-Nb for rpsec@ietf.org; Tue, 10 Jul 2007 17:50:52 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6ALl6dc020521; Tue, 10 Jul 2007 17:47:06 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAtuaW2N; Tue, 10 Jul 07 17:46:25 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 7AF9F3F421; Tue, 10 Jul 2007 17:44:30 -0400 (EDT) To: kent@bbn.com, ttauber@1-4-5.net Subject: Re: [RPSEC] BGP Security Requirements v08 In-Reply-To: <20070710213538.GB27477@1-4-5.net> Message-Id: <20070710214430.7AF9F3F421@pecan.tislabs.com> Date: Tue, 10 Jul 2007 17:44:30 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org > My comment was: One might interpret this to mean that any extended > form of UDATE message MUST be transmitted through ASes that are not > capable of processing it. This is imposing an unnecessary burden on > solutions, since an alternative is to just mot send such messages > through ASes than can't make use of them. This is a question about use of security information during initial deployment. If there are islands of deployment that must communicate through seas of non-deployment, is it useful for the deployer to learn that there is a protected route island out there? When the information came to them over an unprotected sea? I'd say that there is a potential for benefit. Perhaps the unprotected sea in between is known by other out-of-band means to be reliable, even if clueless about the new protection mechanisms. There might be operational procedures that protect the intermediate sea that are adequate from the point of view of the recipient on the island. So I'd say that passing the info along is potentially beneficial, to some, and should be passed. The cost to the clueless routers is storage and bandwidth - processing cost should be minimal. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 10 18:04:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Np5-00004u-Kn; Tue, 10 Jul 2007 18:04:43 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8Np4-0008WT-Sn for rpsec-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 18:04:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Np4-0008WL-HL for rpsec@ietf.org; Tue, 10 Jul 2007 18:04:42 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Nop-0007sQ-6P for rpsec@ietf.org; Tue, 10 Jul 2007 18:04:42 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I8NoI-0008AE-3l; Tue, 10 Jul 2007 18:03:54 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070710213538.GB27477@1-4-5.net> References: <20070709142132.GF7635@1-4-5.net> <20070710213538.GB27477@1-4-5.net> Date: Tue, 10 Jul 2007 18:04:13 -0400 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 2:35 PM -0700 7/10/07, Tony Tauber wrote: >Hi Steve, > >As usual your detailed comments were helpful. >Comments are inline. > >On Tue, Jul 10, 2007 at 11:38:44AM -0400, Stephen Kent wrote: >> Tony, >> >> Thanks for updating the requirements document. I see that almost all >> of my suggested edits were incorporated, but a couple of questions I >> raised in my comments were not addressed, which leaves some >> ambiguity. Here are the residual questions/comments: >> >> In (new) section 4.2 (Incremental Deployment), the second bullet says: >> > > o A BGP security mechanism MUST provide backward compatibility in >> the message formatting, transmission, and processing of routing >> information carried through a mixed security environment. Message >> formatting in a fully secured environment MAY be handled in a >> non-backward compatible fashion though care must be taken to ensure >> UPDATES can traverse intermediate routers which don't support the new > > format. >> >> My comment was: One might interpret this to mean that any extended >> form of UDATE message MUST be transmitted through ASes that are not >> capable of processing it. This is imposing an unnecessary burden on >> solutions, since an alternative is to just mot send such messages >> through ASes than can't make use of them. > >I see this requirement as a (possibly unnecessary) corollary to the >requirement for supporting non-contiguous deployments. The fact that >the interpretation is ambiguous about how specifically one achieves this >goal (perhaps properly) reflects the fact that solutions can get >creative. I worried that one might interpret the requirement as imposing an undue restriction on solutions, by requiring that solutions be able to send UPDATEs with a modified format through ASes that might not be able to process a new format. We seem to be in agreement that one ought not impose such requirements on solutions. If so, then how about rewording this bullet to say: "A BGP security mechanism MUST provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non-backward compatible fashion. Care must be taken to ensure either that UPDATES can traverse intermediate routers which don't support the new format, or that UPDATEs using a new format are not sent to ASes that cannot support such messages." >... > > >> The next bullet in the section says: >> > > In an environment where both secured and non-secured systems are >> interoperating a mechanism MUST exist for secured systems to identify > > whether an originator intended the information to be secured. >> >> My questions was: Does this refer to the Origin AS or the neighbor AS? >> >> I still think we need to say to which originator this bullet refers. > >My reading of it would be "originator". I didn't find it ambiguous. > >Perhaps you or someone else could suggest clearer text if needed. To avoid ambiguity I would suggest: "In an environment where both secured and non-secured systems are interoperating a mechanism MUST exist for secured systems to identify whether the origin AS for a route intended the routing information being transmitted to be secured." Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 10 18:27:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8OBB-0001BJ-Io; Tue, 10 Jul 2007 18:27:33 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8OBA-0001BE-Pj for rpsec-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 18:27:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8OBA-0001B6-GH for rpsec@ietf.org; Tue, 10 Jul 2007 18:27:32 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8OB6-0006Ga-4b for rpsec@ietf.org; Tue, 10 Jul 2007 18:27:32 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I8OB5-00052r-5h; Tue, 10 Jul 2007 18:27:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070710214430.7AF9F3F421@pecan.tislabs.com> References: <20070710214430.7AF9F3F421@pecan.tislabs.com> Date: Tue, 10 Jul 2007 18:27:24 -0400 To: sandy@tislabs.com (Sandy Murphy) From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 X-Spam-Score: 0.5 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: rpsec@ietf.org, ttauber@1-4-5.net X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1125489586==" Errors-To: rpsec-bounces@ietf.org --===============1125489586== Content-Type: multipart/alternative; boundary="============_-1028016028==_ma============" --============_-1028016028==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 5:44 PM -0400 7/10/07, Sandy Murphy wrote: > > My comment was: One might interpret this to mean that any extended >> form of UDATE message MUST be transmitted through ASes that are not >> capable of processing it. This is imposing an unnecessary burden on >> solutions, since an alternative is to just mot send such messages >> through ASes than can't make use of them. > >This is a question about use of security information during initial >deployment. If there are islands of deployment that must communicate >through seas of non-deployment, is it useful for the deployer to >learn that there is a protected route island out there? When the >information came to them over an unprotected sea? > >I'd say that there is a potential for benefit. Perhaps the unprotected >sea in between is known by other out-of-band means to be reliable, >even if clueless about the new protection mechanisms. There might >be operational procedures that protect the intermediate sea that >are adequate from the point of view of the recipient on the island. > >So I'd say that passing the info along is potentially beneficial, >to some, and should be passed. The cost to the clueless routers >is storage and bandwidth - processing cost should be minimal. > >--Sandy Sandy, You make a good point about the potential benefits of being able to pass updated UPDATEs through ASes who are not able to make use of them. However, the benefit is only a potential one, and the flip side is that the intermediate ASes might not be able to store the data from the UPDATEs, which would thus disallow the solution approach. If, as Tony suggested, we want to avoid imposing undue constraints on solutions, then we ought not impose this specific one. Steve --============_-1028016028==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] BGP Security Requirements v08
At 5:44 PM -0400 7/10/07, Sandy Murphy wrote:
> My comment was:  One might interpret this to mean that any extended
> form of UDATE message MUST be transmitted through ASes that are not
> capable of processing it. This is imposing an unnecessary burden on
> solutions, since an alternative is to just mot send such messages
> through ASes than can't make use of them.

This is a question about use of security information during initial
deployment.  If there are islands of deployment that must communicate
through seas of non-deployment, is it useful for the deployer to
learn that there is a protected route island out there?  When the
information came to them over an unprotected sea?

I'd say that there is a potential for benefit.  Perhaps the unprotected
sea in between is known by other out-of-band means to be reliable,
even if clueless about the new protection mechanisms.  There might
be operational procedures that protect the intermediate sea that
are adequate from the point of view of the recipient on the island.

So I'd say that passing the info along is potentially beneficial,
to some, and should be passed.  The cost to the clueless routers
is storage and bandwidth - processing cost should be minimal.

--Sandy

Sandy,

You make a good point about the potential benefits of being able to pass updated UPDATEs through ASes who are not able to make use of them. However, the benefit is only a potential one, and the flip side is that the intermediate ASes might not be able to store the data from the UPDATEs, which would thus disallow the solution approach. If, as Tony suggested, we want to avoid imposing undue constraints on solutions, then we ought not impose this specific one.

Steve
--============_-1028016028==_ma============-- --===============1125489586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1125489586==-- From rpsec-bounces@ietf.org Tue Jul 10 21:09:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8QhY-0005Jh-MA; Tue, 10 Jul 2007 21:09:08 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8QhX-0005CW-LO for rpsec-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 21:09:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8QhX-0005B0-9h; Tue, 10 Jul 2007 21:09:07 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8QhW-0002jg-EH; Tue, 10 Jul 2007 21:09:07 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKZ00L4SPTFB3@szxga03-in.huawei.com>; Wed, 11 Jul 2007 09:08:03 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKZ00GACPTEQV@szxga03-in.huawei.com>; Wed, 11 Jul 2007 09:08:03 +0800 (CST) Received: from l52008 ([10.111.12.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKZ00HS8PT60S@szxml04-in.huawei.com>; Wed, 11 Jul 2007 09:08:02 +0800 (CST) Date: Wed, 11 Jul 2007 09:07:54 +0800 From: Liu Ya To: rpsec@ietf.org, msec@ietf.org, ospf@ietf.org Message-id: <0d2a01c7c357$ec0f1150$3a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_Gaxjm66XcimoVhgdPwnjRw)" Thread-index: AcfDQKb49Ch5PWV1QYe2wsyzopRAEAAFhlUA X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Subject: [RPSEC] FW: I-D ACTION:draft-liu-ospfv3-automated-keying-req-01.txt X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_Gaxjm66XcimoVhgdPwnjRw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, The requirement doc for OSPFv3 IPSec automated group key management has been updated to -01. Compared with the -00 doc, the stuff was reorganized, and some possible solutions and their specific requirements were added. Comments are welcome. Thanks, LIU Ya -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, July 11, 2007 6:15 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-liu-ospfv3-automated-keying-req-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPFv3 Automated Group Keying Requirements Author(s) : Y. Liu, et al. Filename : draft-liu-ospfv3-automated-keying-req-01.txt Pages : 15 Date : 2007-7-10 RFC4552 describes how to provide authentication/confidentiality to OSPFv3 using IPsec. It specifies that same IPsec SA parameters be configured for both inbound and outbound SAs to provide the "one to many" security for multicast OSPFv3 communications over broadcast links (e.g., Ethernet). Manual keying is specified as the mandatory and default group key management solution. However, issues of scalability and security exist with manual keying. It is better to replace manual keying with automated group key management. This document discusses the requirements on OSPFv3 automated group key management, assuming that the centralized group key management architecture introduced in [RFC4046] is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-liu-ospfv3-automated-keying- req-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-liu-ospfv3-automated-keying-req-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-liu-ospfv3-automated-keying-req-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_Gaxjm66XcimoVhgdPwnjRw) Content-type: Message/External-body; name=ATT03353.dat Content-transfer-encoding: 7bit Content-disposition: attachment; filename=ATT03353.dat Content-Type: text/plain Content-ID: <2007-7-10171540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-liu-ospfv3-automated-keying-req-01.txt --Boundary_(ID_Gaxjm66XcimoVhgdPwnjRw) Content-type: Message/External-body; name=draft-liu-ospfv3-automated-keying-req-01.txt Content-transfer-encoding: 7bit Content-disposition: attachment; filename=draft-liu-ospfv3-automated-keying-req-01.txt Content-Type: text/plain Content-ID: <2007-7-10171540.I-D@ietf.org> --Boundary_(ID_Gaxjm66XcimoVhgdPwnjRw) Content-type: text/plain; name=ATT03356.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT03356.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_Gaxjm66XcimoVhgdPwnjRw) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --Boundary_(ID_Gaxjm66XcimoVhgdPwnjRw)-- From rpsec-bounces@ietf.org Wed Jul 11 09:34:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cKT-0003dE-Ek; Wed, 11 Jul 2007 09:34:05 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8cKS-0003cU-5k for rpsec-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 09:34:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cKR-0003cM-SZ for rpsec@ietf.org; Wed, 11 Jul 2007 09:34:03 -0400 Received: from xmail04.myhosting.com ([168.144.250.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8cKN-0000Ex-J2 for rpsec@ietf.org; Wed, 11 Jul 2007 09:34:03 -0400 Received: (qmail 21429 invoked from network); 11 Jul 2007 13:33:59 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Jul 2007 13:33:58 -0000 Message-ID: <4694DC3E.5010007@cisco.com> Date: Wed, 11 Jul 2007 09:33:50 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 References: <20070709142132.GF7635@1-4-5.net> <20070710213538.GB27477@1-4-5.net> In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I see this requirement as a (possibly unnecessary) corollary to the >> requirement for supporting non-contiguous deployments. The fact that >> the interpretation is ambiguous about how specifically one achieves this >> goal (perhaps properly) reflects the fact that solutions can get >> creative. > > "A BGP security mechanism MUST provide backward compatibility in > the message formatting, transmission, and processing of routing > information carried through a mixed security environment. Message > formatting in a fully secured environment MAY be handled in a > non-backward compatible fashion. Care must be taken to ensure either that > UPDATES can traverse intermediate routers which don't support the new > format, or that UPDATEs using a new format are not sent to ASes that cannot > support such messages." This is a pretty traditional and standard argument in routing protocol circles whenever extensions to a routing protocol are proposed--do we make it so older routers can at least forward the new information, or do we make it so it won't work in the presence of older routers? IMHO, it generally comes down to--is the information useful to routers on the other side of the nonsupporting router? Maybe it's useful to break this into two questions? 1. Is information about the authorization of an originator to advertise reachability useful to AS' on the "other side" of a non-supporting AS? 2. Is information about the validity of an AS path useful to AS' on the "other side" of a non-supporting AS? If we could resolve these two questions, I think the wording pretty much falls out (?).... :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlNw+ER27sUhU9OQRAsSqAJsFUPiEP1lbTbGwfODzvnZAlVL14ACfcqxG lRvm1II2jRhvRpUL+gE3/2o= =rtHi -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 11 09:37:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cNs-0005Ov-1m; Wed, 11 Jul 2007 09:37:36 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8cNr-0005Oq-DA for rpsec-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 09:37:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cNq-0005Oi-Ei for rpsec@ietf.org; Wed, 11 Jul 2007 09:37:35 -0400 Received: from xmail02.myhosting.com ([168.144.250.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8cNq-0000ct-6D for rpsec@ietf.org; Wed, 11 Jul 2007 09:37:34 -0400 Received: (qmail 21096 invoked from network); 11 Jul 2007 13:37:26 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Jul 2007 13:37:26 -0000 Message-ID: <4694DD0F.4000104@cisco.com> Date: Wed, 11 Jul 2007 09:37:19 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: rpsec@ietf.org Subject: Re: [RPSEC] BGP Security Requirements v08 References: <20070709142132.GF7635@1-4-5.net> <20070710213538.GB27477@1-4-5.net> <4694DC3E.5010007@cisco.com> In-Reply-To: <4694DC3E.5010007@cisco.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In a separate email, and with my WG chair hat _off_.... > Maybe it's useful to break this into two questions? > > 1. Is information about the authorization of an originator to advertise > reachability useful to AS' on the "other side" of a non-supporting AS? > > 2. Is information about the validity of an AS path useful to AS' on the > "other side" of a non-supporting AS? IMHO, as an individual, I believe both of these pieces of information are useful. I believe the origin authorization information is really useful, along with the first hop (or second hop, depending on your point of view) of the AS Path. The subsequent hops of the AS path are less interesting than these two to the receiver on the "other side" of a non-supporting AS. Why? Because if you can validate the originator and the first (second) hop (the second entry in the AS Path), then you have a good bit more assurance the destination is valid/etc, than if you just drop this information out. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlN0PER27sUhU9OQRAuiZAJ4v/z6YbmRkrZrtOoyCdkmgTAfYWgCgkbFu ViW1S1+MF8ykjh3AhBYjPJk= =/e4u -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 11 09:44:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cUX-0004yc-G7; Wed, 11 Jul 2007 09:44:29 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8cUV-0004up-Hk for rpsec-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 09:44:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cUV-0004uh-6f for rpsec@ietf.org; Wed, 11 Jul 2007 09:44:27 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8cUU-0000mV-Rb for rpsec@ietf.org; Wed, 11 Jul 2007 09:44:27 -0400 Received: from [192.168.1.42] (pool-71-105-86-112.lsanca.dsl-w.verizon.net [71.105.86.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l6BDgEEK014035; Wed, 11 Jul 2007 06:42:15 -0700 (PDT) Message-ID: <4694DE33.2080706@isi.edu> Date: Wed, 11 Jul 2007 06:42:11 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tony Tauber Subject: Re: [RPSEC] BGP Security Requirements v08 References: <20070709142132.GF7635@1-4-5.net> In-Reply-To: <20070709142132.GF7635@1-4-5.net> X-Enigmail-Version: 0.95.2 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1773025698==" Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1773025698== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig782BAE0452A17A5293A173BE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig782BAE0452A17A5293A173BE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tony Tauber wrote: > Hi Folks, >=20 > Here's the latest revision of the BGP Security Requirements I-D > incorporating comments recieved: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-08.txt >=20 > Diff from last version: >=20 > http://tools.ietf.org/wg/rpsec/draft-ietf-rpsec-bgpsecrec/draft-ietf-rp= sec-bgpsecrec-08-from-07.wdiff.html >=20 > Please send your feedback. I didn't see any changes related to the feedback I posted on the transport protocol issues and GTSM. There are a number of current I-Ds in this space that are not discussed, and any description that includes the need for keying (SHOULD) might reconsider whether GTSM qualifies as relevant at all in this space. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig782BAE0452A17A5293A173BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlN4zE5f5cImnZrsRAlOJAKDFoYSnbDrWa3ctD5MAD0OBSRljqgCfUAxO fkNZxGlJdgjdbbxCQzrhNyc= =m7qQ -----END PGP SIGNATURE----- --------------enig782BAE0452A17A5293A173BE-- --===============1773025698== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1773025698==-- From rpsec-bounces@ietf.org Wed Jul 11 10:09:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8csG-0007kM-N5; Wed, 11 Jul 2007 10:09:00 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8csF-0007hg-Rh for rpsec-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:08:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8csF-0007et-4Y for rpsec@ietf.org; Wed, 11 Jul 2007 10:08:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8csB-0001Bt-QI for rpsec@ietf.org; Wed, 11 Jul 2007 10:08:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 11 Jul 2007 07:08:55 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJaBlEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,527,1175497200"; d="scan'208"; a="180196726:sNHT55959750" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6BE8tpR008707; Wed, 11 Jul 2007 07:08:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6BE8smo017936; Wed, 11 Jul 2007 14:08:55 GMT Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 07:08:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] BGP Security Requirements v08 Date: Wed, 11 Jul 2007 07:06:44 -0700 Message-ID: In-Reply-To: <4694DE33.2080706@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RPSEC] BGP Security Requirements v08 Thread-Index: AcfDwaKxDkzO/DKuR7itO1GwO2cQIAAAi37Q References: <20070709142132.GF7635@1-4-5.net> <4694DE33.2080706@isi.edu> From: "Barry Greene \(bgreene\)" To: "Joe Touch" , "Tony Tauber" X-OriginalArrivalTime: 11 Jul 2007 14:08:54.0911 (UTC) FILETIME=[0428E0F0:01C7C3C5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=774; t=1184162935; x=1185026935; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bgreene@cisco.com; z=From:=20=22Barry=20Greene=20\(bgreene\)=22=20 |Subject:=20RE=3A=20[RPSEC]=20BGP=20Security=20Requirements=20v08 |Sender:=20; bh=AQJLt0TnsmkD1UfPHTeWawr+1thuMQC1hwVJ7jcSW08=; b=nFaW13fS+MyGLL1LfGcdn+ZKA0xEeDhQzasSKA2XpY/OZOv9ktTFEgmPCyapPWTdX6479Vvs 3PjmicA1mVBHWUVSNevbvjEtUQqz7RtWJ996IFTSrUr5arNJjjf1ZV9I; Authentication-Results: sj-dkim-4; header.From=bgreene@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =20 > I didn't see any changes related to the feedback I posted on=20 > the transport protocol issues and GTSM. There are a number of=20 > current I-Ds in this space that are not discussed, and any=20 > description that includes the need for keying (SHOULD) might=20 > reconsider whether GTSM qualifies as relevant at all in this space. I see a tool - GTSM - that allows me to policy check the packet in the forwarding ASIC - before I punt to the control plane of the device - as totally relevant. It is a working tool which add resistance to DOS.=20 -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRpTj9L/UEA/xivvmEQIKKACfasX/U135L6QC07Bh0CaecLXYiwgAoMBo RjJoWxRGtiz30k7YJURb5Duk =3DLtiU -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 11 10:20:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8d3i-0002vu-8m; Wed, 11 Jul 2007 10:20:50 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8d3h-0002qZ-54 for rpsec-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:20:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8d3g-0002ne-Pt for rpsec@ietf.org; Wed, 11 Jul 2007 10:20:48 -0400 Received: from m106.maoz.com ([205.167.76.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8d3g-0001e8-EH for rpsec@ietf.org; Wed, 11 Jul 2007 10:20:48 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l6BEKF3Q032549; Wed, 11 Jul 2007 07:20:15 -0700 Received: (from ttauber@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l6BEKFbY032548; Wed, 11 Jul 2007 07:20:15 -0700 Date: Wed, 11 Jul 2007 07:20:15 -0700 From: Tony Tauber To: Joe Touch Subject: Re: [RPSEC] BGP Security Requirements v08 Message-ID: <20070711142015.GC27477@1-4-5.net> References: <20070709142132.GF7635@1-4-5.net> <4694DE33.2080706@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4694DE33.2080706@isi.edu> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org On Wed, Jul 11, 2007 at 06:42:11AM -0700, Joe Touch wrote: > > > > Diff from last version: > > > > http://tools.ietf.org/wg/rpsec/draft-ietf-rpsec-bgpsecrec/draft-ietf-rpsec-bgpsecrec-08-from-07.wdiff.html > > > > I didn't see any changes related to the feedback I posted on the > transport protocol issues and GTSM. There are a number of current I-Ds > in this space that are not discussed, and any description that includes > the need for keying (SHOULD) might reconsider whether GTSM qualifies as > relevant at all in this space. > > Joe Hi Joe, I appreciate your comments and attention. I tried to work these in with by making a couple of modest changes in what's now section 11. GTSM is (and was) only mentioned in the doc by way of saying it's inadequate as a "solution". If you feel strongly that more change is needed, send proposed text. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 11 10:30:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dCw-000867-7F; Wed, 11 Jul 2007 10:30:22 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8dCv-00085q-A8 for rpsec-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:30:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dCu-00085W-Us for rpsec@ietf.org; Wed, 11 Jul 2007 10:30:20 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8dCu-0001tU-Ht for rpsec@ietf.org; Wed, 11 Jul 2007 10:30:20 -0400 Received: from [192.168.1.42] (pool-71-105-86-112.lsanca.dsl-w.verizon.net [71.105.86.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l6BESoCT024700; Wed, 11 Jul 2007 07:28:50 -0700 (PDT) Message-ID: <4694E91E.6040909@isi.edu> Date: Wed, 11 Jul 2007 07:28:46 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tony Tauber Subject: Re: [RPSEC] BGP Security Requirements v08 References: <20070709142132.GF7635@1-4-5.net> <4694DE33.2080706@isi.edu> <20070711142015.GC27477@1-4-5.net> In-Reply-To: <20070711142015.GC27477@1-4-5.net> X-Enigmail-Version: 0.95.2 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0687804019==" Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0687804019== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAD491C5B6523CADF708078CA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAD491C5B6523CADF708078CA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Tony, I'd be glad to send text, since that might be a useful way forward. Thanks! Joe Tony Tauber wrote: > On Wed, Jul 11, 2007 at 06:42:11AM -0700, Joe Touch wrote: >> >>> Diff from last version: >>> >>> http://tools.ietf.org/wg/rpsec/draft-ietf-rpsec-bgpsecrec/draft-ietf-= rpsec-bgpsecrec-08-from-07.wdiff.html >>> >> I didn't see any changes related to the feedback I posted on the >> transport protocol issues and GTSM. There are a number of current I-Ds= >> in this space that are not discussed, and any description that include= s >> the need for keying (SHOULD) might reconsider whether GTSM qualifies a= s >> relevant at all in this space. >> >> Joe >=20 > Hi Joe, >=20 > I appreciate your comments and attention. I tried to work these in wit= h > by making a couple of modest changes in what's now section 11. GTSM is= > (and was) only mentioned in the doc by way of saying it's inadequate as= > a "solution". If you feel strongly that more change is needed, send > proposed text. >=20 > Thanks, >=20 > Tony --------------enigAD491C5B6523CADF708078CA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlOkfE5f5cImnZrsRAg21AJ4nWdJPfZLFwCeDXLLmOhFMonEnvwCfQkdg S5CwTIENC4WxXAWvHb8Sj7c= =evuv -----END PGP SIGNATURE----- --------------enigAD491C5B6523CADF708078CA-- --===============0687804019== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0687804019==-- From rpsec-bounces@ietf.org Wed Jul 11 10:37:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dJh-0005oJ-6a; Wed, 11 Jul 2007 10:37:21 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8dJf-0005oC-DN for rpsec-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:37:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dJf-0005o2-3p for rpsec@ietf.org; Wed, 11 Jul 2007 10:37:19 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8dJb-0001sz-Om for rpsec@ietf.org; Wed, 11 Jul 2007 10:37:19 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6BEYkch029872; Wed, 11 Jul 2007 10:34:46 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3Aaio6; Wed, 11 Jul 07 10:34:13 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 97D2E3F481; Wed, 11 Jul 2007 10:32:19 -0400 (EDT) To: riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] BGP Security Requirements v08 In-Reply-To: <4694DD0F.4000104@cisco.com> Message-Id: <20070711143219.97D2E3F481@pecan.tislabs.com> Date: Wed, 11 Jul 2007 10:32:19 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org >Why? Because if you can validate the originator and the first (second) >hop (the second entry in the AS Path), then you have a good bit more >assurance the destination is valid/etc, than if you just drop this >information out. As many people have said (I recall particularly Danny McPherson at NANOG), a deliberate attack would just take the valid initial info and add invalid info to it. So it is best to be cautious about the good bit more assurance. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 11 10:45:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dRw-0007Sr-SA; Wed, 11 Jul 2007 10:45:52 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8dRw-0007Sl-E0 for rpsec-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:45:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dRw-0007Sd-4Y for rpsec@ietf.org; Wed, 11 Jul 2007 10:45:52 -0400 Received: from xmail09.myhosting.com ([168.144.250.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8dRs-00028l-SG for rpsec@ietf.org; Wed, 11 Jul 2007 10:45:52 -0400 Received: (qmail 15141 invoked from network); 11 Jul 2007 14:45:46 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Jul 2007 14:45:44 -0000 Message-ID: <4694ED10.4030503@cisco.com> Date: Wed, 11 Jul 2007 10:45:36 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [RPSEC] BGP Security Requirements v08 References: <20070711143219.97D2E3F481@pecan.tislabs.com> In-Reply-To: <20070711143219.97D2E3F481@pecan.tislabs.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Why? Because if you can validate the originator and the first (second) >> hop (the second entry in the AS Path), then you have a good bit more >> assurance the destination is valid/etc, than if you just drop this >> information out. > > As many people have said (I recall particularly Danny McPherson at NANOG), > a deliberate attack would just take the valid initial info and add > invalid info to it. So it is best to be cautious about the good bit > more assurance. Right--the more information you have, the more assurance you have. Just the origination authorization is easy to fool. Including the second AS in the AS Path (the first hop) makes it harder to fool but still not impossible. As you add more path information, you add more assurance. So, I would say it's not an "all or nothing" affair, and retaining information through a non-supporting AS is useful. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlO0QER27sUhU9OQRAj2/AJoCXvR21xQSZCpHldM+A1O2smkYRQCgjKnJ Oboutp1yYLSfCP15JIXTW84= =m8hQ -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 11 10:54:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8daG-0000Ye-LU; Wed, 11 Jul 2007 10:54:28 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8daF-0000YU-7b for rpsec-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:54:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8daE-0000YM-Tp for rpsec@ietf.org; Wed, 11 Jul 2007 10:54:26 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8dZz-0002Nf-Kd for rpsec@ietf.org; Wed, 11 Jul 2007 10:54:26 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6BEq329001766; Wed, 11 Jul 2007 10:52:03 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAq1aOld; Wed, 11 Jul 07 10:51:04 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id DCA653F47C; Wed, 11 Jul 2007 10:49:08 -0400 (EDT) To: riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] BGP Security Requirements v08 In-Reply-To: <4694ED10.4030503@cisco.com> Message-Id: <20070711144908.DCA653F47C@pecan.tislabs.com> Date: Wed, 11 Jul 2007 10:49:08 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org >So, I would say it's not an "all or nothing" affair, and retaining >information through a non-supporting AS is useful. I agree. I already said that, but I just wanted to be sure my comment about caution did not indicate I had changed my mind. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 11 11:05:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dkg-000561-9Q; Wed, 11 Jul 2007 11:05:14 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8dkf-00050I-19 for rpsec-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 11:05:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dke-0004wV-Io for rpsec@ietf.org; Wed, 11 Jul 2007 11:05:12 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8dkT-0002eK-BE for rpsec@ietf.org; Wed, 11 Jul 2007 11:05:12 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I8djw-0007PL-4x; Wed, 11 Jul 2007 11:04:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4694DC3E.5010007@cisco.com> References: <20070709142132.GF7635@1-4-5.net> <20070710213538.GB27477@1-4-5.net> <4694DC3E.5010007@cisco.com> Date: Wed, 11 Jul 2007 11:04:17 -0400 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 9:33 AM -0400 7/11/07, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>> I see this requirement as a (possibly unnecessary) corollary to the >>> requirement for supporting non-contiguous deployments. The fact that >>> the interpretation is ambiguous about how specifically one achieves this >>> goal (perhaps properly) reflects the fact that solutions can get >>> creative. >> >> "A BGP security mechanism MUST provide backward compatibility in >> the message formatting, transmission, and processing of routing >> information carried through a mixed security environment. Message >> formatting in a fully secured environment MAY be handled in a >> non-backward compatible fashion. Care must be taken to ensure either that >> UPDATES can traverse intermediate routers which don't support the new >> format, or that UPDATEs using a new format are not sent to ASes that cannot >> support such messages." > >This is a pretty traditional and standard argument in routing protocol >circles whenever extensions to a routing protocol are proposed--do we >make it so older routers can at least forward the new information, or do >we make it so it won't work in the presence of older routers? IMHO, it >generally comes down to--is the information useful to routers on the >other side of the nonsupporting router? I agree that it is generally useful to have a router forward data that it can't use itself, but that a later router might be able to use. However, I am not comfortable with a suggestion that if a solution cannot always guarantee this capability, that it is an unacceptable solution. >Maybe it's useful to break this into two questions? > >1. Is information about the authorization of an originator to advertise >reachability useful to AS' on the "other side" of a non-supporting AS? it could be useful. >2. Is information about the validity of an AS path useful to AS' on the >"other side" of a non-supporting AS? because there may be no way to verify the number, much less the identify of ASes listed in an UPDATE between the end of the secured path and the current AS, the utility of the passing that data beyond the end of the secured part of the path is questionable. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 11 11:13:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dsr-00042r-BW; Wed, 11 Jul 2007 11:13:41 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8dsq-00042m-NM for rpsec-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 11:13:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dsq-00042e-Cd for rpsec@ietf.org; Wed, 11 Jul 2007 11:13:40 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8dsq-0002qK-4q for rpsec@ietf.org; Wed, 11 Jul 2007 11:13:40 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I8dsp-0007Z3-5q; Wed, 11 Jul 2007 11:13:39 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4694ED10.4030503@cisco.com> References: <20070711143219.97D2E3F481@pecan.tislabs.com> <4694ED10.4030503@cisco.com> Date: Wed, 11 Jul 2007 11:13:58 -0400 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 10:45 AM -0400 7/11/07, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>> Why? Because if you can validate the originator and the first (second) >>> hop (the second entry in the AS Path), then you have a good bit more >>> assurance the destination is valid/etc, than if you just drop this >>> information out. >> >> As many people have said (I recall particularly Danny McPherson at NANOG), >> a deliberate attack would just take the valid initial info and add >> invalid info to it. So it is best to be cautious about the good bit >> more assurance. > >Right--the more information you have, the more assurance you have. Just >the origination authorization is easy to fool. Including the second AS >in the AS Path (the first hop) makes it harder to fool but still not >impossible. As you add more path information, you add more assurance. > >So, I would say it's not an "all or nothing" affair, and retaining >information through a non-supporting AS is useful. > >:-) > >Russ I think it's a matter of what you security goals are. - If you want assurance that the traffic you are forwarding will NOT go through a certain AS, then any gap in the secured path undermines this goal, irrespective of the number of "good" hops on the path you receive. - If you assurance that the path you receive is one that will likely cause your traffic to be delivered, again the number of "good" hops on the path you receive is irrelevant, as an attacker could grab a valid long or short path and add themselves onto it. So I'm not sure that one can generalize about the increased assurance afforded by a path with more hops that can be verified as accurate. Also, I worry that it is asking a lot for an operator to try to take a mix of unauthenticated paths, authenticated paths, and partially authenticated paths and decide how to weight them in making a route selection. We have a fair number of examples in other areas where adding this sort of complexity leads to more config errors with adverse security implications. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 00:07:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9CRL-00071d-As; Fri, 13 Jul 2007 00:07:35 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9CRK-00071W-9x for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 00:07:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9CRJ-00071N-Bv for rpsec@ietf.org; Fri, 13 Jul 2007 00:07:33 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9CRF-000833-0s for rpsec@ietf.org; Fri, 13 Jul 2007 00:07:33 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6D45ZQa081057; Fri, 13 Jul 2007 00:05:35 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707130405.l6D45ZQa081057@harbor.brookfield.occnc.com> To: Tony Tauber From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Wed, 11 Jul 2007 07:20:15 PDT." <20070711142015.GC27477@1-4-5.net> Date: Fri, 13 Jul 2007 00:05:35 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rpsec@ietf.org, Joe Touch X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <20070711142015.GC27477@1-4-5.net> Tony Tauber writes: > > On Wed, Jul 11, 2007 at 06:42:11AM -0700, Joe Touch wrote: > > > > > > > Diff from last version: > > > > > > http://tools.ietf.org/wg/rpsec/draft-ietf-rpsec-bgpsecrec/draft-ietf-rpsec-bgpsecrec-08-from-07.wdiff.html > > > > > > > I didn't see any changes related to the feedback I posted on the > > transport protocol issues and GTSM. There are a number of current I-Ds > > in this space that are not discussed, and any description that includes > > the need for keying (SHOULD) might reconsider whether GTSM qualifies as > > relevant at all in this space. > > > > Joe > > Hi Joe, > > I appreciate your comments and attention. I tried to work these in with > by making a couple of modest changes in what's now section 11. GTSM is > (and was) only mentioned in the doc by way of saying it's inadequate as > a "solution". If you feel strongly that more change is needed, send > proposed text. > > Thanks, > > Tony GTSM is very effective in protecting against certain high volume attacks that would cripple infrastructure protected by cryptographic means alone. From a practical standpoint GTSM used alone may be inadequate as a solution (though some ISPs might contest even that) but it is a required part of any solution in an ISP environment. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 02:28:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Edn-000523-70; Fri, 13 Jul 2007 02:28:35 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9Edm-00051y-BJ for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 02:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Edm-00051p-1l for rpsec@ietf.org; Fri, 13 Jul 2007 02:28:34 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Edh-0003dv-8F for rpsec@ietf.org; Fri, 13 Jul 2007 02:28:34 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL30085ETXYW0@szxga04-in.huawei.com> for rpsec@ietf.org; Fri, 13 Jul 2007 14:27:34 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL300B7MTXYYK@szxga04-in.huawei.com> for rpsec@ietf.org; Fri, 13 Jul 2007 14:27:34 +0800 (CST) Received: from l52008 ([10.111.12.58]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL3003M5TXKEE@szxml03-in.huawei.com> for rpsec@ietf.org; Fri, 13 Jul 2007 14:27:34 +0800 (CST) Date: Fri, 13 Jul 2007 14:27:20 +0800 From: Liu Ya Subject: RE: [RPSEC] Agenda items for IETF69 (Chicago) In-reply-to: <20070709142304.GG7635@1-4-5.net> To: 'Tony Tauber' , rpsec@ietf.org Message-id: <001201c7c516$de6657f0$3a0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfCNLQo/d7zq4q1QfmAHqZLcMZbogBI7yIA X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'Russ White' X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Hi Tony, I request a 10 minute slot for draft-liu-ospfv3-automated-keying-req-01.txt. Thanks, Liu Ya > -----Original Message----- > From: Tony Tauber [mailto:ttauber@1-4-5.net] > Sent: Monday, July 09, 2007 10:23 PM > To: rpsec@ietf.org > Cc: Russ White > Subject: [RPSEC] Agenda items for IETF69 (Chicago) > > RPSEC is planning to meet. > Please send along any agenda items you may have. > > Thanks, > > Tony > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 02:58:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9F73-0003vb-OW; Fri, 13 Jul 2007 02:58:49 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9F72-0003vU-PL for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 02:58:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9F6w-00030U-AD for rpsec@ietf.org; Fri, 13 Jul 2007 02:58:42 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9F6i-0006fa-Vl for rpsec@ietf.org; Fri, 13 Jul 2007 02:58:42 -0400 Received: from [192.168.1.42] (pool-71-105-86-112.lsanca.dsl-w.verizon.net [71.105.86.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l6D6vHtM026798; Thu, 12 Jul 2007 23:57:17 -0700 (PDT) Message-ID: <4697224A.5050901@isi.edu> Date: Thu, 12 Jul 2007 23:57:14 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: curtis@occnc.com Subject: Re: [RPSEC] BGP Security Requirements v08 References: <200707130405.l6D45ZQa081057@harbor.brookfield.occnc.com> In-Reply-To: <200707130405.l6D45ZQa081057@harbor.brookfield.occnc.com> X-Enigmail-Version: 0.95.2 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0305160756==" Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0305160756== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig83C121E94D993BF64E62C2FD" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig83C121E94D993BF64E62C2FD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Curtis Villamizar wrote: =2E.. > GTSM is very effective in protecting against certain high volume > attacks that would cripple infrastructure protected by cryptographic > means alone. From a practical standpoint GTSM used alone may be > inadequate as a solution (though some ISPs might contest even that) > but it is a required part of any solution in an ISP environment. >=20 > Curtis I agree that DOS attacks benefit from protections that help reduce the impact of attack traffic; GTSM falls into that category - it's clearly a useful part of a DOS solution, but DOS protection isn't cryptographic protection. The bulk of the BGP security requirements document focuses on cryptographic issues - not DOS protection. It's worth noting the difference, but not lumping the solutions together. Joe --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig83C121E94D993BF64E62C2FD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGlyJKE5f5cImnZrsRAo6UAJ9vr2y5FnkKOMO0PmtOmUqe4o7RTwCeO5HD 9Q/b0Fz9shAGzUfog6Xis00= =Ysv4 -----END PGP SIGNATURE----- --------------enig83C121E94D993BF64E62C2FD-- --===============0305160756== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0305160756==-- From rpsec-bounces@ietf.org Fri Jul 13 10:41:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MKJ-0006hA-Am; Fri, 13 Jul 2007 10:40:59 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9MKH-0006gz-DE for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 10:40:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MKH-0006gr-1B for rpsec@ietf.org; Fri, 13 Jul 2007 10:40:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9MKG-0004CB-Mz for rpsec@ietf.org; Fri, 13 Jul 2007 10:40:56 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2007 07:40:47 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGMrl0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="8414650:sNHT91231530" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6DEel0s023530; Fri, 13 Jul 2007 07:40:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6DEXul6025852; Fri, 13 Jul 2007 14:40:43 GMT Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 07:40:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] BGP Security Requirements v08 Date: Fri, 13 Jul 2007 07:40:07 -0700 Message-ID: In-Reply-To: <4697224A.5050901@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RPSEC] BGP Security Requirements v08 Thread-Index: AcfFG04vIBmkI8ciRqKHa4JTbLeX0AAPcLnA References: <200707130405.l6D45ZQa081057@harbor.brookfield.occnc.com> <4697224A.5050901@isi.edu> From: "Barry Greene \(bgreene\)" To: "Joe Touch" , X-OriginalArrivalTime: 13 Jul 2007 14:40:08.0337 (UTC) FILETIME=[B5A28010:01C7C55B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1527; t=1184337647; x=1185201647; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bgreene@cisco.com; z=From:=20=22Barry=20Greene=20\(bgreene\)=22=20 |Subject:=20RE=3A=20[RPSEC]=20BGP=20Security=20Requirements=20v08 |Sender:=20; bh=EJG2UGeF1kGj9W7Bc+xyHaWgRiqdF9WNVCsUNP6C5ho=; b=xir5uOSAyvmULeVtGb9UTMDvvODt71CdbrP/mleXTzp0YVKtxfAnYfPpK5bkQBG4VzkIe0Go v9FNhfqkFVqSoZAes0NsA131KHSeMCG7pa7xf5GWNrs3xIfGF675Fu6h; Authentication-Results: sj-dkim-2; header.From=bgreene@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the last draft it was pretty clear. =20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Thursday, July 12, 2007 11:57 PM > To: curtis@occnc.com > Cc: rpsec@ietf.org; Tony Tauber > Subject: Re: [RPSEC] BGP Security Requirements v08 >=20 >=20 >=20 > Curtis Villamizar wrote: > ... > > GTSM is very effective in protecting against certain high volume=20 > > attacks that would cripple infrastructure protected by=20 > cryptographic=20 > > means alone. From a practical standpoint GTSM used alone may be=20 > > inadequate as a solution (though some ISPs might contest even > > that) but it is a required part of any solution in an ISP > > environment. =20 > >=20 > > Curtis >=20 > I agree that DOS attacks benefit from protections that help=20 > reduce the impact of attack traffic; GTSM falls into that=20 > category - it's clearly a useful part of a DOS solution, but=20 > DOS protection isn't cryptographic protection. The bulk of=20 > the BGP security requirements document focuses on=20 > cryptographic issues - not DOS protection. It's worth noting=20 > the difference, but not lumping the solutions together. >=20 > Joe >=20 > -- > ---------------------------------------- > Joe Touch > Sr. Network Engineer, USAF TSAT Space Segment >=20 -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRpeKdb/UEA/xivvmEQIL1ACfbKLE8p52y8WgllMN5PWSbQejFRAAniRu 8F1H0PBJEgFTMnAGx2cch1tg =3DXqpD -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 10:43:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MML-00032G-Au; Fri, 13 Jul 2007 10:43:05 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9MMJ-0002kd-Bb for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 10:43:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9MMI-0002hd-Vt for rpsec@ietf.org; Fri, 13 Jul 2007 10:43:02 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9MME-0001Vb-IV for rpsec@ietf.org; Fri, 13 Jul 2007 10:43:02 -0400 Received: from [192.168.1.42] (pool-71-105-86-112.lsanca.dsl-w.verizon.net [71.105.86.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l6DEg6AI007744; Fri, 13 Jul 2007 07:42:06 -0700 (PDT) Message-ID: <46978F3A.5040306@isi.edu> Date: Fri, 13 Jul 2007 07:42:02 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Barry Greene (bgreene)" Subject: Re: [RPSEC] BGP Security Requirements v08 References: <200707130405.l6D45ZQa081057@harbor.brookfield.occnc.com> <4697224A.5050901@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.2 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0538540183==" Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0538540183== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C1367AF38EB9928E2F3B38D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C1367AF38EB9928E2F3B38D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I disagree, and have offered to contribute text already. Joe Barry Greene (bgreene) wrote: > =20 > In the last draft it was pretty clear. =20 >=20 >> -----Original Message----- >> From: Joe Touch [mailto:touch@ISI.EDU]=20 >> Sent: Thursday, July 12, 2007 11:57 PM >> To: curtis@occnc.com >> Cc: rpsec@ietf.org; Tony Tauber >> Subject: Re: [RPSEC] BGP Security Requirements v08 >=20 >=20 >=20 >> Curtis Villamizar wrote: >> ... >>> GTSM is very effective in protecting against certain high volume=20 >>> attacks that would cripple infrastructure protected by=20 >> cryptographic=20 >>> means alone. From a practical standpoint GTSM used alone may be=20 >>> inadequate as a solution (though some ISPs might contest even >>> that) but it is a required part of any solution in an ISP >>> environment. =20 >>> >>> Curtis >> I agree that DOS attacks benefit from protections that help=20 >> reduce the impact of attack traffic; GTSM falls into that=20 >> category - it's clearly a useful part of a DOS solution, but=20 >> DOS protection isn't cryptographic protection. The bulk of=20 >> the BGP security requirements document focuses on=20 >> cryptographic issues - not DOS protection. It's worth noting=20 >> the difference, but not lumping the solutions together. >=20 >> Joe >=20 >> -- >> ---------------------------------------- >> Joe Touch >> Sr. Network Engineer, USAF TSAT Space Segment >=20 >=20 --=20 ---------------------------------------- Joe Touch Sr. Network Engineer, USAF TSAT Space Segment --------------enig1C1367AF38EB9928E2F3B38D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl486E5f5cImnZrsRAjaGAJ4gD+0DzhNoRirCAUOCSSKrGMrVuACg5ywf R1YnTxrGhZg4rVCz21l7B3I= =Rrr2 -----END PGP SIGNATURE----- --------------enig1C1367AF38EB9928E2F3B38D-- --===============0538540183== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0538540183==-- From rpsec-bounces@ietf.org Fri Jul 13 12:33:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9O5A-00030L-MR; Fri, 13 Jul 2007 12:33:28 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9O59-000301-Fj for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 12:33:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9O59-0002zr-3f for rpsec@ietf.org; Fri, 13 Jul 2007 12:33:27 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9O55-0005tG-MJ for rpsec@ietf.org; Fri, 13 Jul 2007 12:33:27 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6DGW1b3021820; Fri, 13 Jul 2007 12:32:01 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707131632.l6DGW1b3021820@harbor.brookfield.occnc.com> To: Joe Touch From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Thu, 12 Jul 2007 23:57:14 PDT." <4697224A.5050901@isi.edu> Date: Fri, 13 Jul 2007 12:32:01 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <4697224A.5050901@isi.edu> Joe Touch writes: > > Curtis Villamizar wrote: > =2E.. > > GTSM is very effective in protecting against certain high volume > > attacks that would cripple infrastructure protected by cryptographic > > means alone. From a practical standpoint GTSM used alone may be > > inadequate as a solution (though some ISPs might contest even that) > > but it is a required part of any solution in an ISP environment. > >=20 > > Curtis > > I agree that DOS attacks benefit from protections that help reduce the > impact of attack traffic; GTSM falls into that category - it's clearly a > useful part of a DOS solution, but DOS protection isn't cryptographic > protection. The bulk of the BGP security requirements document focuses > on cryptographic issues - not DOS protection. It's worth noting the > difference, but not lumping the solutions together. > > Joe Joe, It would be most accurate most helpful to acknowledge the strengths and weaknesses of both and then define the limit of scope of your work. Cryptographic solutions can provide for protection over an insecure channel but cannot provide protection against very high traffic volume DOS attacks. GTSM protects against very high traffic volume DOS attacks over a secure channel to a peer but provides no protection over an insecure channel. Which approach is appropriate, or both, depends on the situation. The scope of your work is cryptographic solutions. (Some ISPs have noted that this does not fit *their* problem space, but it does fit other problem spaces). So we seem to be in violent agreement about the difference between crypto solutions and DOS solutions. Its just a matter of the wording in the draft not adequately acknowledging the part of the problem space that is not addressed. draft-behringer-bgp-session-sec-req-01.txt cites rfc4593 which defines part of the real world problem. ISPs might argue that rfc4593 is silly in the context of a fiber strung across 20 feet of collocation space that is regularly taken down by DOS attacks and they'd be right. Its time these security requirements documents acknowledged that. For the ISP, GTSM protects the BGP peerings. Packet filtering protects the IGP if its OSPF (not applicable for ISIS). Crypto protection of the session can protect against low traffic volume internal attacks. Other applications such as routing in a wireless battlefield would have different requirements. We don't need to go into specifics but both types of attack need to be acknowledged. Drafts/RFCs describing requirements need to be clear about this and specify which problem space they are addressing without implicitly denying that the other problem space exists. The way the draft reads now is GTSM, TCP/MD5, etc are all "prior work" and the reader might interpret this to mean that work meeting these BGP requirements supercede that prior work. It doesn't state otherwise and it should. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 12:41:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9OCR-0004mj-H4; Fri, 13 Jul 2007 12:40:59 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9OCP-0004mY-TV for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 12:40:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9OCP-0004mL-IY for rpsec@ietf.org; Fri, 13 Jul 2007 12:40:57 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9OCA-0008RK-At for rpsec@ietf.org; Fri, 13 Jul 2007 12:40:57 -0400 Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l6DGdbmd006190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Jul 2007 09:39:38 -0700 (PDT) Message-ID: <4697AAC9.1060604@isi.edu> Date: Fri, 13 Jul 2007 09:39:37 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: curtis@occnc.com Subject: Re: [RPSEC] BGP Security Requirements v08 References: <200707131632.l6DGW1b3021820@harbor.brookfield.occnc.com> In-Reply-To: <200707131632.l6DGW1b3021820@harbor.brookfield.occnc.com> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Curtis Villamizar wrote: > In message <4697224A.5050901@isi.edu> > Joe Touch writes: >> >> Curtis Villamizar wrote: >> =2E.. >>> GTSM is very effective in protecting against certain high volume >>> attacks that would cripple infrastructure protected by cryptographic >>> means alone. From a practical standpoint GTSM used alone may be >>> inadequate as a solution (though some ISPs might contest even that) >>> but it is a required part of any solution in an ISP environment. >>> =20 >>> Curtis >> >> I agree that DOS attacks benefit from protections that help reduce the >> impact of attack traffic; GTSM falls into that category - it's clearly a >> useful part of a DOS solution, but DOS protection isn't cryptographic >> protection. The bulk of the BGP security requirements document focuses >> on cryptographic issues - not DOS protection. It's worth noting the >> difference, but not lumping the solutions together. >> >> Joe > > > Joe, > > It would be most accurate most helpful to acknowledge the strengths > and weaknesses of both and then define the limit of scope of your > work. Agreed... > So we seem to be in violent agreement about the difference between > crypto solutions and DOS solutions. Its just a matter of the wording > in the draft not adequately acknowledging the part of the problem > space that is not addressed. Agreed! ... > The way the draft reads now is GTSM, TCP/MD5, etc are all "prior work" > and the reader might interpret this to mean that work meeting these > BGP requirements supercede that prior work. It doesn't state > otherwise and it should. Yes - that's the sort of thing I'm hoping to address in a brief paragraph. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl6rJE5f5cImnZrsRAnOpAJ998nCytW9y2YMhdb7bZaCgwOS6pwCeKQqh JfW0JgqK0flx+06hGhgjiyU= =chEy -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 12:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9OJh-0000QG-OX; Fri, 13 Jul 2007 12:48:29 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9OJg-0000NN-Ng for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 12:48:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9OJg-0000N6-E9 for rpsec@ietf.org; Fri, 13 Jul 2007 12:48:28 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9OJb-0006Vu-WB for rpsec@ietf.org; Fri, 13 Jul 2007 12:48:28 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6DGl2fH022003; Fri, 13 Jul 2007 12:47:02 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707131647.l6DGl2fH022003@harbor.brookfield.occnc.com> To: "Barry Greene \(bgreene\)" From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Fri, 13 Jul 2007 07:40:07 PDT." Date: Fri, 13 Jul 2007 12:47:02 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: rpsec@ietf.org, Tony Tauber , Joe Touch X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message "Barry Greene \(bgreene\)" writes: > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In the last draft it was pretty clear. Are we reading the same draft? It would be nice to have the draft name in the subject line. In draft-ietf-rpsec-bgpsecrec-08 the only mention of GTSM is the following and there is no mention of the issue of high volume DOS. Current approaches to improving resilience of BGP transport (e.g., TCP-MD5 [5] and GTSM [7]) are inadequate and require significant operator interaction to maintain a respectable level of security. The draft is in denial regarding the existance of DOS issues, the existing means to address DOS, and the fact that DOS is not addressed by crypto methods. I keep bringing this up and nothing changes. Curtis > > -----Original Message----- > > From: Joe Touch [mailto:touch@ISI.EDU] > > Sent: Thursday, July 12, 2007 11:57 PM > > To: curtis@occnc.com > > Cc: rpsec@ietf.org; Tony Tauber > > Subject: Re: [RPSEC] BGP Security Requirements v08 > > > > > > > > Curtis Villamizar wrote: > > ... > > > GTSM is very effective in protecting against certain high volume > > > attacks that would cripple infrastructure protected by > > cryptographic > > > means alone. From a practical standpoint GTSM used alone may be > > > inadequate as a solution (though some ISPs might contest even > > > that) but it is a required part of any solution in an ISP > > > environment. > > > > > > Curtis > > > > I agree that DOS attacks benefit from protections that help > > reduce the impact of attack traffic; GTSM falls into that > > category - it's clearly a useful part of a DOS solution, but > > DOS protection isn't cryptographic protection. The bulk of > > the BGP security requirements document focuses on > > cryptographic issues - not DOS protection. It's worth noting > > the difference, but not lumping the solutions together. > > > > Joe > > > > -- > > ---------------------------------------- > > Joe Touch > > Sr. Network Engineer, USAF TSAT Space Segment _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 13:26:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9OuF-0001TU-CE; Fri, 13 Jul 2007 13:26:15 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9OuD-0001SU-BS for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 13:26:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9OuD-0001S4-0L for rpsec@ietf.org; Fri, 13 Jul 2007 13:26:13 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9Ou8-0001di-PO for rpsec@ietf.org; Fri, 13 Jul 2007 13:26:12 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6DHMYRm004733; Fri, 13 Jul 2007 13:22:34 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAceaakj; Fri, 13 Jul 07 13:22:10 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id C10153F420; Fri, 13 Jul 2007 13:20:14 -0400 (EDT) To: curtis@occnc.com, touch@ISI.EDU Subject: Re: [RPSEC] BGP Security Requirements v08 In-Reply-To: <4697AAC9.1060604@isi.edu> Message-Id: <20070713172014.C10153F420@pecan.tislabs.com> Date: Fri, 13 Jul 2007 13:20:14 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: rpsec@ietf.org, ttauber@1-4-5.net X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org >> The way the draft reads now is GTSM, TCP/MD5, etc are all "prior work" >Yes - that's the sort of thing I'm hoping to address in a brief paragraph. I *think* Curtis meant the behring draft, not the bgpsecrec draft. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 15:21:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9QhM-0006Ut-4K; Fri, 13 Jul 2007 15:21:04 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9QhK-0006Un-FG for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 15:21:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9QhK-0006Ue-5m for rpsec@ietf.org; Fri, 13 Jul 2007 15:21:02 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9QhF-0004BG-Uf for rpsec@ietf.org; Fri, 13 Jul 2007 15:21:02 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6DJIRrV015976; Fri, 13 Jul 2007 15:18:27 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAABZaymF; Fri, 13 Jul 07 15:18:19 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 0CCCB3F47A; Fri, 13 Jul 2007 15:16:25 -0400 (EDT) To: rpsec@ietf.org Subject: Re: [RPSEC] BGP Security Requirements v08 In-Reply-To: <200707131632.l6DGW1b3021820@harbor.brookfield.occnc.com> Message-Id: <20070713191625.0CCCB3F47A@pecan.tislabs.com> Date: Fri, 13 Jul 2007 15:16:25 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: rcallon@juniper.net, dward@cisco.com, psavola@funet.fi X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org >So we seem to be in violent agreement about the difference between >crypto solutions and DOS solutions. >... >draft-behringer-bgp-session-sec-req-01.txt cites rfc4593 There is also Pekka Savola's draft, draft-savola-rtgwg-backbone-attacks-03.txt which talks about the various attacks on routing infrastructure in ISP backbones, the various countermeasures, and speaks briefly about where each type of countermeasure would be appropriate. He talked about this work at several working groups in Jul 06, including rpsec. The presentations seemed to be generally well received, and there was some discussion of where the work would best be done. But no wg seems to have picked it up as a wg item. Should there be discussion of picking up both the behringer and the savola drafts as wg items? (Actually, the routing ADs may know more about the status of the savola draft, so I've put them on the recipient list.) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 16:48:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9S44-0007Vf-4J; Fri, 13 Jul 2007 16:48:36 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9S42-0007Sq-R7 for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 16:48:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9S41-0007R3-6x for rpsec@ietf.org; Fri, 13 Jul 2007 16:48:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9S3w-0007AI-Ss for rpsec@ietf.org; Fri, 13 Jul 2007 16:48:33 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 13 Jul 2007 13:48:25 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FABqCl0arR7PE/2dsb2JhbACQZg X-IronPort-AV: i="4.16,537,1175497200"; d="scan'208"; a="503118979:sNHT3523541850" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6DKmOto024218; Fri, 13 Jul 2007 13:48:24 -0700 Received: from [192.168.100.205] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l6DKmK6C029451; Fri, 13 Jul 2007 20:48:21 GMT Message-ID: <4697E505.2090809@cisco.com> Date: Fri, 13 Jul 2007 16:48:05 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [RPSEC] BGP Security Requirements v08 References: <20070713191625.0CCCB3F47A@pecan.tislabs.com> In-Reply-To: <20070713191625.0CCCB3F47A@pecan.tislabs.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=585; t=1184359704; x=1185223704; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RPSEC]=20BGP=20Security=20Requirements=20v08 |Sender:=20; bh=Zh6/sbAK33qVCQCuTTj6xOXQC8soqjh4jIreXwWmodM=; b=Qaq0ZGmlB1ssWliH/Ar7noRVmanp1AsAzSYHI4OPje0swUCFVba9uO6mJJSvq6aaMjTbsdXn DDxKCeDWyiqAiCxffU+sOm8YEQBwd5jgNArDAikD/a0xcpwORD5orl/F; Authentication-Results: sj-dkim-4; header.From=riw@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: rcallon@juniper.net, rpsec@ietf.org, dward@cisco.com, psavola@funet.fi X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Should there be discussion of picking up both the behringer and > the savola drafts as wg items? I think so.... I wonder how this overlaps with the p-2-p bgp draft also being considered? Or wasn't there one? What happened to that one? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl+UFER27sUhU9OQRAtCaAJ48I/VJJX651Tx8oXg9TGhYTdr7QQCfUK6l PtteOD3wdRFeINbr3sa46uk= =WrsO -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 16:54:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9S9T-0008FH-P4; Fri, 13 Jul 2007 16:54:11 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9S9S-0008Ey-EC for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 16:54:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9S9S-0008Eq-3M for rpsec@ietf.org; Fri, 13 Jul 2007 16:54:10 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9S9O-0007Nj-Qm for rpsec@ietf.org; Fri, 13 Jul 2007 16:54:10 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6DKpVAb022615; Fri, 13 Jul 2007 16:51:31 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAn4aikS; Fri, 13 Jul 07 16:51:26 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 3D6A63F420; Fri, 13 Jul 2007 16:49:32 -0400 (EDT) To: riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] BGP Security Requirements v08 In-Reply-To: <4697E505.2090809@cisco.com> Message-Id: <20070713204932.3D6A63F420@pecan.tislabs.com> Date: Fri, 13 Jul 2007 16:49:32 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: rcallon@juniper.net, rpsec@ietf.org, dward@cisco.com, psavola@funet.fi X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org >I think so.... I wonder how this overlaps with the p-2-p bgp draft also >being considered? I don't quite know what you mean by a p-2-p bgp draft. The behringer draft concerns the security requirements of protecting the bgp peer to bgp peer connection (e.g., TCP MD5). Perhaps that is what you are talking about? http://www.ietf.org/internet-drafts/draft-behringer-bgp-session-sec-req-01.txt Abstract The document "BGP security requirements" (draft-ietf-rpsec-bgpsecrec-07) specifies general security requirements for BGP. However, specific security requirements for single BGP sessions, i.e., the connection between two BGP peers, are only touched on briefly in the section "transport layer protection". This document expands on this particular aspect of BGP security, defining the security requirements between two BGP peers. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 17:57:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9T8j-0003AQ-UC; Fri, 13 Jul 2007 17:57:29 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9T8j-0003AK-01 for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 17:57:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9T8i-0003AC-LM for rpsec@ietf.org; Fri, 13 Jul 2007 17:57:28 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9T8i-0002Ru-B7 for rpsec@ietf.org; Fri, 13 Jul 2007 17:57:28 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2007 14:57:27 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEaSl0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,538,1175497200"; d="scan'208"; a="181850410:sNHT26287308" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6DLvRcO027671; Fri, 13 Jul 2007 14:57:27 -0700 Received: from [192.168.100.205] (rtp-ruwhite-vpn13.cisco.com [10.82.175.126]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l6DLvKSb009192; Fri, 13 Jul 2007 21:57:21 GMT Message-ID: <4697F531.3000105@cisco.com> Date: Fri, 13 Jul 2007 17:57:05 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [RPSEC] BGP Security Requirements v08 References: <20070713204932.3D6A63F420@pecan.tislabs.com> In-Reply-To: <20070713204932.3D6A63F420@pecan.tislabs.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1617; t=1184363847; x=1185227847; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RPSEC]=20BGP=20Security=20Requirements=20v08 |Sender:=20; bh=0RkFUfVOYS+y+D7z0z+lom0SZW90qFIWhA7dmEgU3TU=; b=OmQnSRmJNnkgR5xFq9beJoB70O8hwD6eEF0I1Gb0kSmugaJR18pVLi8ZkyZoo8AyjuYI+qMK YJNBocJvE4DXxWmt2FpuZ54Nw7N4oE1Q7e0XDjsugY14b0vz0peQBaPaGtNHpnn1ccv7WznVCy b1bJM78oWwag97w7pqIl/6WBE=; Authentication-Results: sj-dkim-1; header.From=riw@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: rcallon@juniper.net, rpsec@ietf.org, dward@cisco.com, psavola@funet.fi X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I think so.... I wonder how this overlaps with the p-2-p bgp draft also >> being considered? > > I don't quite know what you mean by a p-2-p bgp draft. The behringer > draft concerns the security requirements of protecting the bgp peer to > bgp peer connection (e.g., TCP MD5). Perhaps that is what you are > talking about? > > http://www.ietf.org/internet-drafts/draft-behringer-bgp-session-sec-req-01.txt > > Abstract > > The document "BGP security requirements" > (draft-ietf-rpsec-bgpsecrec-07) specifies general security > requirements for BGP. However, specific security requirements for > single BGP sessions, i.e., the connection between two BGP peers, are > only touched on briefly in the section "transport layer protection". > This document expands on this particular aspect of BGP security, > defining the security requirements between two BGP peers. Yes... We should pick this work up as a WG item, I think, because it really relates directly to the charter. But, I'll leave it to Tony to bring it up at the Chicago meeting (it overlaps with Networkers this time, and I really can't skip Networkers, *sigh*. We should try and see what folks think on list before then, if possible, though, I think (?). :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGl/UxER27sUhU9OQRAhb4AKDJRU5Emu0HvOTK4IZ1qxQoAk62DgCeKP1P vlNLckQ+M00dNx/MrSsDboo= =/PTq -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 13 21:28:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9WQM-0004zv-4y; Fri, 13 Jul 2007 21:27:54 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I9WQL-0004vg-FZ for rpsec-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 21:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9WQK-0004tp-VT for rpsec@ietf.org; Fri, 13 Jul 2007 21:27:52 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9WQG-000818-H3 for rpsec@ietf.org; Fri, 13 Jul 2007 21:27:52 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6E1QwYZ061559; Fri, 13 Jul 2007 21:26:58 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707140126.l6E1QwYZ061559@harbor.brookfield.occnc.com> To: Stephen Kent From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Wed, 11 Jul 2007 11:04:17 EDT." Date: Fri, 13 Jul 2007 21:26:58 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Stephen Kent writes: > > At 9:33 AM -0400 7/11/07, Russ White wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > > > >>> I see this requirement as a (possibly unnecessary) corollary to the > >>> requirement for supporting non-contiguous deployments. The fact that > >>> the interpretation is ambiguous about how specifically one achieves this > >>> goal (perhaps properly) reflects the fact that solutions can get > >>> creative. > >> > >> "A BGP security mechanism MUST provide backward compatibility in > >> the message formatting, transmission, and processing of routing > >> information carried through a mixed security environment. Message > >> formatting in a fully secured environment MAY be handled in a > >> non-backward compatible fashion. Care must be taken to ensure either that > >> UPDATES can traverse intermediate routers which don't support the new > >> format, or that UPDATEs using a new format are not sent to ASes that cannot > >> support such messages." > > > >This is a pretty traditional and standard argument in routing protocol > >circles whenever extensions to a routing protocol are proposed--do we > >make it so older routers can at least forward the new information, or do > >we make it so it won't work in the presence of older routers? IMHO, it > >generally comes down to--is the information useful to routers on the > >other side of the nonsupporting router? > > I agree that it is generally useful to have a router forward data > that it can't use itself, but that a later router might be able to > use. However, I am not comfortable with a suggestion that if a > solution cannot always guarantee this capability, that it is an > unacceptable solution. I think most of the WG is comfortable with this and is insisting on it. How many times do we need to go in circles on this? Once every IETF meeting? > >Maybe it's useful to break this into two questions? > > > >1. Is information about the authorization of an originator to advertise > >reachability useful to AS' on the "other side" of a non-supporting AS? > > it could be useful. Yes. So don't create a protocol that prevents it. > >2. Is information about the validity of an AS path useful to AS' on the > >"other side" of a non-supporting AS? > > because there may be no way to verify the number, much less the > identify of ASes listed in an UPDATE between the end of the secured > path and the current AS, the utility of the passing that data beyond > the end of the secured part of the path is questionable. The real world problem is that this is the best you are going to get for attempts to use any such mechanism on most of the Internet at least during early deployment which might be many years or longer. There is no sense defining a protocol which won't get deployed. If you do there is a good chance it won't be widely implemented - or implemented at all without someone throwing big money at it. So even if the application you have in mind would never trust information from another island, you need this capability to have some chance that the protocol you define will get widely implemented and eventually deployed in enough places to start to gather critical mass. A bit of optimism maybe. > Steve Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 16 12:34:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATWT-0003fg-Ux; Mon, 16 Jul 2007 12:34:09 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IATWT-0003fZ-1q for rpsec-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 12:34:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATWS-0003fM-O9 for rpsec@ietf.org; Mon, 16 Jul 2007 12:34:08 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IATWO-00026b-9U for rpsec@ietf.org; Mon, 16 Jul 2007 12:34:08 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jul 2007 18:34:04 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKs5m0aQ/uCLh2dsb2JhbACPPAEBCQon X-IronPort-AV: i="4.16,542,1175464800"; d="scan'208"; a="148177542:sNHT28538844" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6GGY3OF013300; Mon, 16 Jul 2007 18:34:03 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6GGXYlN008825; Mon, 16 Jul 2007 16:34:01 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 18:33:33 +0200 Received: from mbehring-wxp.cisco.com ([10.55.2.211]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 18:33:33 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 16 Jul 2007 18:33:30 +0200 To: Russ White , Sandy Murphy From: "Michael H. Behringer" Subject: Re: [RPSEC] BGP Security Requirements v08 In-Reply-To: <4697F531.3000105@cisco.com> References: <20070713204932.3D6A63F420@pecan.tislabs.com> <4697F531.3000105@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-OriginalArrivalTime: 16 Jul 2007 16:33:33.0442 (UTC) FILETIME=[0D085E20:01C7C7C7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3305; t=1184603643; x=1185467643; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbehring@cisco.com; z=From:=20=22Michael=20H.=20Behringer=22=20 |Subject:=20Re=3A=20[RPSEC]=20BGP=20Security=20Requirements=20v08 |Sender:=20; bh=hNfvCE7Ya5UcXgo2vMOzky08EG8RvnQMEMLfecHaSq0=; b=GcEjevFMzaLb7TwszI0f8wAUYyj/I5fMZ4xjaM0Ww75z9p+4Hh/bM3oWVnaMGkZCz8ROztrX 1sE1JymCTPq+6MeaznOduO7b/X77N7SCsrszQThY8dbSb+dNJouBkdZy; Authentication-Results: ams-dkim-2; header.From=mbehring@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: rcallon@juniper.net, rpsec@ietf.org, dward@cisco.com, psavola@funet.fi X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org [Just back from vacation today, so I missed the earlier discussion.] Just as a reminder where I was coming from with my draft http://www.ietf.org/internet-drafts/draft-behringer-bgp-session-sec-req-01.txt: This was directly taken from a to-do-list from Russ, specifying that the WG needs to work on the point-to-point security requirements of BGP speakers: At 15:37 06/01/2007, Russ White wrote: [...] >o P-2-P security requirements for BGP: This was to provide some cover >and thinking on the various TCP auth mechanisms to replace MD5 that are >currently being considered. We need, I believe, a volunteer to >author/edit this, and get it moving. [...] I request (again) that my draft be accepted as a WG item, after all it's taken from the WG's to-do list ;-) The problem space of draft-behringer-bgp-session-sec-req-01 is significantly smaller than that of draft-ietf-rpsec-bgpsecrec-08; I can see this work remaining independent, but I can also see it merged with draft-ietf-rpsec-bgpsecrec-08. My current preference is to keep it standalone, since it's problem space is nicely small and well-defined. But I have no strong views either way. I guess we should discuss this in Chicago. BTW, I have received a number of emails with feedback which I have not yet incorporated into the draft, due to time constraints. Apologies for that. Will happen after the IETF. See you all next week, Michael At 23:57 13/07/2007, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>> I think so.... I wonder how this overlaps with the p-2-p bgp draft also >>> being considered? >> >> I don't quite know what you mean by a p-2-p bgp draft. The behringer >> draft concerns the security requirements of protecting the bgp peer to >> bgp peer connection (e.g., TCP MD5). Perhaps that is what you are >> talking about? >> >> http://www.ietf.org/internet-drafts/draft-behringer-bgp-session-sec-req-01.txt >> >> Abstract >> >> The document "BGP security requirements" >> (draft-ietf-rpsec-bgpsecrec-07) specifies general security >> requirements for BGP. However, specific security requirements for >> single BGP sessions, i.e., the connection between two BGP peers, are >> only touched on briefly in the section "transport layer protection". >> This document expands on this particular aspect of BGP security, >> defining the security requirements between two BGP peers. > >Yes... We should pick this work up as a WG item, I think, because it >really relates directly to the charter. But, I'll leave it to Tony to >bring it up at the Chicago meeting (it overlaps with Networkers this >time, and I really can't skip Networkers, *sigh*. > >We should try and see what folks think on list before then, if possible, >though, I think (?). > >:-) > >Russ > >- -- >riw@cisco.com CCIE <>< Grace Alone > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.6 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iD8DBQFGl/UxER27sUhU9OQRAhb4AKDJRU5Emu0HvOTK4IZ1qxQoAk62DgCeKP1P >vlNLckQ+M00dNx/MrSsDboo= >=/PTq >-----END PGP SIGNATURE----- > > >_______________________________________________ >RPSEC mailing list >RPSEC@ietf.org >https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 16 14:28:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVJJ-0003hA-8l; Mon, 16 Jul 2007 14:28:41 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IAVJH-0003h5-Qx for rpsec-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 14:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVJH-0003gx-HU for rpsec@ietf.org; Mon, 16 Jul 2007 14:28:39 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAVJD-0006UY-8j for rpsec@ietf.org; Mon, 16 Jul 2007 14:28:39 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IAVJC-0005RZ-5b; Mon, 16 Jul 2007 14:28:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707140126.l6E1QwYZ061559@harbor.brookfield.occnc.com> References: <200707140126.l6E1QwYZ061559@harbor.brookfield.occnc.com> Date: Mon, 16 Jul 2007 14:28:54 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 9:26 PM -0400 7/13/07, Curtis Villamizar wrote: >... > > >I think most of the WG is comfortable with this and is insisting on >it. How many times do we need to go in circles on this? Once every >IETF meeting? You may be right. Hoqwever, I appear to be the primary (only?) person who reads each draft and provides comments and edits to Tony, so I'm don't think that the WG consensus has been established, at least not through the editing process. >... >> >2. Is information about the validity of an AS path useful to AS' on the >> >"other side" of a non-supporting AS? >> >> because there may be no way to verify the number, much less the >> identify of ASes listed in an UPDATE between the end of the secured >> path and the current AS, the utility of the passing that data beyond >> the end of the secured part of the path is questionable. > > >The real world problem is that this is the best you are going to get >for attempts to use any such mechanism on most of the Internet at >least during early deployment which might be many years or longer. >There is no sense defining a protocol which won't get deployed. If >you do there is a good chance it won't be widely implemented - or >implemented at all without someone throwing big money at it. So even >if the application you have in mind would never trust information from >another island, you need this capability to have some chance that the >protocol you define will get widely implemented and eventually >deployed in enough places to start to gather critical mass. > >A bit of optimism maybe. Sorry, Curtis, but I don't understand your reasoning above. I think we all want to establish requirements for a protocol that will be widely deployed, and agree that deployment will be a long time coming. I think the question is why, if the path info received by an "island AS" has a number of unverified hops, is this path info useful, in a security sense, to the AS that receives? How does the requirement to send such info promote adoption of the protocol? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 16 22:19:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAceV-0001JT-2F; Mon, 16 Jul 2007 22:19:03 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IAceU-0001JO-MP for rpsec-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 22:19:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAceU-0001JB-AV for rpsec@ietf.org; Mon, 16 Jul 2007 22:19:02 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAceP-0002JM-Q7 for rpsec@ietf.org; Mon, 16 Jul 2007 22:19:02 -0400 Received: from [202.12.29.135] (dhcp135.apnic.net [202.12.29.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 70C18D5F2D for ; Tue, 17 Jul 2007 12:18:56 +1000 (EST) Message-ID: <469C270F.6030102@apnic.net> Date: Tue, 17 Jul 2007 12:18:55 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: rpsec@ietf.org Subject: Re: [RPSEC] BGP Security Requirements v08 References: <200707140126.l6E1QwYZ061559@harbor.brookfield.occnc.com> In-Reply-To: <200707140126.l6E1QwYZ061559@harbor.brookfield.occnc.com> X-Enigmail-Version: 0.95.2 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Curtis Villamizar wrote: > In message > Stephen Kent writes: > >>> This is a pretty traditional and standard argument in routing protocol >>> circles whenever extensions to a routing protocol are proposed--do we >>> make it so older routers can at least forward the new information, or do >>> we make it so it won't work in the presence of older routers? IMHO, it >>> generally comes down to--is the information useful to routers on the >>> other side of the nonsupporting router? >> >> I agree that it is generally useful to have a router forward data >> that it can't use itself, but that a later router might be able to >> use. However, I am not comfortable with a suggestion that if a >> solution cannot always guarantee this capability, that it is an >> unacceptable solution. > > I think most of the WG is comfortable with this and is insisting on > it. How many times do we need to go in circles on this? Once every > IETF meeting? Curtis, Stephen, please correct me if I'm mis-characterising your opinions... Curtis, you seem to be saying that passing on the information via non-supporting routers is better than nothing, and so should definitely be done. Stephen, you appear to be saying that it might be found to be pointless or, in fact, worse than useless (ie, actively harmful), and don't want to be committed to doing so this early in the game. Is that correct? Rob -- Robert Loomans Email: robertl@apnic.net Senior Programmer/Analyst, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 17 10:03:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAndb-0002fw-Lw; Tue, 17 Jul 2007 10:02:51 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IAndX-0002X6-PU for rpsec-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 10:02:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAndX-0002Wt-FS for rpsec@ietf.org; Tue, 17 Jul 2007 10:02:47 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAndU-0000PM-8Z for rpsec@ietf.org; Tue, 17 Jul 2007 10:02:47 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IAndT-0001Mb-54; Tue, 17 Jul 2007 10:02:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <469C270F.6030102@apnic.net> References: <200707140126.l6E1QwYZ061559@harbor.brookfield.occnc.com> <469C270F.6030102@apnic.net> Date: Tue, 17 Jul 2007 09:57:14 -0400 To: Robert Loomans From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 12:18 PM +1000 7/17/07, Robert Loomans wrote: >... > >Curtis, Stephen, please correct me if I'm mis-characterising your >opinions... > >Curtis, you seem to be saying that passing on the information via >non-supporting routers is better than nothing, and so should definitely >be done. > >Stephen, you appear to be saying that it might be found to be pointless >or, in fact, worse than useless (ie, actively harmful), and don't want >to be committed to doing so this early in the game. > >Is that correct? > >Rob > Rob, yes, that's a good, concise characterization of my position. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 17 10:27:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAo0y-00058r-3z; Tue, 17 Jul 2007 10:27:00 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IAo0q-00053m-C7 for rpsec-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 10:26:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAo0o-00052u-FX for rpsec@ietf.org; Tue, 17 Jul 2007 10:26:51 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAo0n-0001IC-5v for rpsec@ietf.org; Tue, 17 Jul 2007 10:26:50 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6HEQJiK090507; Tue, 17 Jul 2007 10:26:19 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707171426.l6HEQJiK090507@harbor.brookfield.occnc.com> To: Stephen Kent From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Mon, 16 Jul 2007 14:28:54 EDT." Date: Tue, 17 Jul 2007 10:26:19 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Stephen Kent writes: > > I think the question is why, if the path info received by an "island > AS" has a number of unverified hops, is this path info useful, in a > security sense, to the AS that receives? How does the requirement to > send such info promote adoption of the protocol? > > Steve Because it is likely to be more reliable than information with no authentication at all. The major ISPs are fairly reliable at getting their internal routing right so if the non-authenticating routers in the middle are entirely in a set of ISPs that are known to generally not have breakins into their own infrastructure. For the purposes of commercial traffic among other ISPs that want to distinguish their services as having somewhat more reliable routing due to the use of authentication, there is a great deal of value. It may be optimistic to think that this value would be enough to give any routing authentication sufficient value to gain critical mass in the commercial world. If there is no value for islands of deployment except to authenticate within the island this is a non-starter from day one in the commercial world. If so it may be a non-starter at router vendors without a very large influx of money from elsewhere, such as government funding specifically for something that is not being implemented because it will never get commercially deployed. If you are sure that the money is out there waiting for this spec to publish, then fine. Otherwise you may be wasting your time and ours if the requirement to add value to disconnected islands is ignored. That's just an opinion and I don't know how widely held it is today. This might be a good question to ask at the WG meeting. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 17 11:01:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoXn-0002hy-Vf; Tue, 17 Jul 2007 11:00:55 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IAoXm-0002bE-I1 for rpsec-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 11:00:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoXm-0002Zq-76 for rpsec@ietf.org; Tue, 17 Jul 2007 11:00:54 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAoXj-0002ko-QA for rpsec@ietf.org; Tue, 17 Jul 2007 11:00:54 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6HF0iEx090863; Tue, 17 Jul 2007 11:00:44 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707171500.l6HF0iEx090863@harbor.brookfield.occnc.com> To: "Michael H. Behringer" From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Mon, 16 Jul 2007 18:33:30 +0200." Date: Tue, 17 Jul 2007 11:00:43 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: rpsec@ietf.org, dward@cisco.com, Sandy Murphy , rcallon@juniper.net, psavola@funet.fi, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message "Michael H. Behringer" writes: > > [Just back from vacation today, so I missed the earlier discussion.] > > Just as a reminder where I was coming from with my draft > http://www.ietf.org/internet-drafts/draft-behringer-bgp-session-sec-req-01.txt: > This was directly taken from a to-do-list from Russ, specifying that > the WG needs to work on the point-to-point security requirements of > BGP speakers: > > At 15:37 06/01/2007, Russ White wrote: > [...] > >o P-2-P security requirements for BGP: This was to provide some cover > >and thinking on the various TCP auth mechanisms to replace MD5 that are > >currently being considered. We need, I believe, a volunteer to > >author/edit this, and get it moving. > [...] > > I request (again) that my draft be accepted as a WG item, after all > it's taken from the WG's to-do list ;-) IMO this should be a WG item. > The problem space of draft-behringer-bgp-session-sec-req-01 is > significantly smaller than that of draft-ietf-rpsec-bgpsecrec-08; I > can see this work remaining independent, but I can also see it merged > with draft-ietf-rpsec-bgpsecrec-08. My current preference is to keep > it standalone, since it's problem space is nicely small and > well-defined. But I have no strong views either way. I guess we should > discuss this in Chicago. Since the requirements are those that the ISPs have been working from for over a decade, it is likely that we will arrive at agreement on what those requirements are within a reasonable amount of time. Then draft-ietf-rpsec-bgpsecrec can reference bgp-session-sec-req and we can put to end any discussion on rpsec-bgpsecrec being incomplete due to failure to acknowledge these requirements. > BTW, I have received a number of emails with feedback which I have not > yet incorporated into the draft, due to time constraints. Apologies > for that. Will happen after the IETF. > > See you all next week, > Michael Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 17 11:17:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAolv-0008Kj-4f; Tue, 17 Jul 2007 11:15:31 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IAolu-0008KV-CQ for rpsec-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 11:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAolu-0008KN-2u for rpsec@ietf.org; Tue, 17 Jul 2007 11:15:30 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAolt-0003Aj-QS for rpsec@ietf.org; Tue, 17 Jul 2007 11:15:30 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IAols-0002aN-3t; Tue, 17 Jul 2007 11:15:29 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707171426.l6HEQJiK090507@harbor.brookfield.occnc.com> References: <200707171426.l6HEQJiK090507@harbor.brookfield.occnc.com> Date: Tue, 17 Jul 2007 11:09:48 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 10:26 AM -0400 7/17/07, Curtis Villamizar wrote: >In message >Stephen Kent writes: >> >> I think the question is why, if the path info received by an "island >> AS" has a number of unverified hops, is this path info useful, in a >> security sense, to the AS that receives? How does the requirement to >> send such info promote adoption of the protocol? >> >> Steve > > >Because it is likely to be more reliable than information with no >authentication at all. > >The major ISPs are fairly reliable at getting their internal routing >right so if the non-authenticating routers in the middle are entirely >in a set of ISPs that are known to generally not have breakins into >their own infrastructure. For the purposes of commercial traffic >among other ISPs that want to distinguish their services as having >somewhat more reliable routing due to the use of authentication, there >is a great deal of value. > >It may be optimistic to think that this value would be enough to give >any routing authentication sufficient value to gain critical mass in >the commercial world. If there is no value for islands of deployment >except to authenticate within the island this is a non-starter from >day one in the commercial world. If so it may be a non-starter at >router vendors without a very large influx of money from elsewhere, >such as government funding specifically for something that is not >being implemented because it will never get commercially deployed. If >you are sure that the money is out there waiting for this spec to >publish, then fine. Otherwise you may be wasting your time and ours >if the requirement to add value to disconnected islands is ignored. > >That's just an opinion and I don't know how widely held it is today. >This might be a good question to ask at the WG meeting. > >Curtis Curtis, I think our difference of opinion arises from the different perspectives we bring to the problem. As a "security guy" I would not agree with your opening statement. We usually worry that mixing unverified info with verified info, in any context, is a recipe for trouble, as it encourages folks to accept the mixed info and treat it as verified. You give an example of ISPs wanting to " ... distinguish their services as having somewhat more reliable routing due to the use of authentication ..." That is precisely the sort of claim most security folks would worry about :-). As for what will make incremental valuable enough to ISPs to warrant their buy-in, I think that's a hard call for anyone to make right now. One possible deployment scenario is that the biggest ISPs will deploy first. If so, then the fact that most of these folks have direct peering arrangements with one another would allow them to benefit, irrespective of the issue of intermediaries who are not yet playing. If the next set of adopters are ISPs directly connected to the big ISPs, and often to one another (e.g., via IXPs), then they too can derive benefits in many instances, even without passing verified path info through unverified ASes. So, given possible deployment scenarios like these, the uncertainty about which deployment scenarios may happen, and the security principle of avoiding situations that may encourage folks to accept mixed data as all authentic, I feel it's inappropriate to mandate support for passing such data along. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 17 11:35:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAp5J-0005rF-9r; Tue, 17 Jul 2007 11:35:33 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IAp5I-0005mC-2J for rpsec-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 11:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAp5H-0005jM-IE for rpsec@ietf.org; Tue, 17 Jul 2007 11:35:31 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAp5H-00042r-75 for rpsec@ietf.org; Tue, 17 Jul 2007 11:35:31 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6HFZSE05171; Tue, 17 Jul 2007 15:35:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] BGP Security Requirements v08 Date: Tue, 17 Jul 2007 11:35:24 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RPSEC] BGP Security Requirements v08 Thread-Index: AcfIhVYXrLhQ65QmRECddUUD8psafgAAPbhw References: <200707171426.l6HEQJiK090507@harbor.brookfield.occnc.com> From: "James Ko" To: "Stephen Kent" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Indeed, ideally incoming data should be "authentic" and "verifiable", otherwise we are back to square one and this work is no different but to give bad guys a window of opportunity to run man-in-the-middle attacks, or inject bogus routes. James Ko, CISA CISM CISSP-ISSAP GCFW GCIH OAM & Security=20 Nortel jamesko@nortel.com phone 1 613 763 6920 (ESN 393 6920) -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Tuesday, July 17, 2007 11:10 AM To: curtis@occnc.com Cc: rpsec@ietf.org; Russ White Subject: Re: [RPSEC] BGP Security Requirements v08 At 10:26 AM -0400 7/17/07, Curtis Villamizar wrote: >In message >Stephen Kent writes: >>=20 >> I think the question is why, if the path info received by an "island >> AS" has a number of unverified hops, is this path info useful, in a =20 >> security sense, to the AS that receives? How does the requirement to >> send such info promote adoption of the protocol? >>=20 >> Steve > > >Because it is likely to be more reliable than information with no=20 >authentication at all. > >The major ISPs are fairly reliable at getting their internal routing=20 >right so if the non-authenticating routers in the middle are entirely=20 >in a set of ISPs that are known to generally not have breakins into=20 >their own infrastructure. For the purposes of commercial traffic among >other ISPs that want to distinguish their services as having somewhat=20 >more reliable routing due to the use of authentication, there is a=20 >great deal of value. > >It may be optimistic to think that this value would be enough to give=20 >any routing authentication sufficient value to gain critical mass in=20 >the commercial world. If there is no value for islands of deployment=20 >except to authenticate within the island this is a non-starter from day >one in the commercial world. If so it may be a non-starter at router=20 >vendors without a very large influx of money from elsewhere, such as=20 >government funding specifically for something that is not being=20 >implemented because it will never get commercially deployed. If you=20 >are sure that the money is out there waiting for this spec to publish,=20 >then fine. Otherwise you may be wasting your time and ours if the=20 >requirement to add value to disconnected islands is ignored. > >That's just an opinion and I don't know how widely held it is today. >This might be a good question to ask at the WG meeting. > >Curtis Curtis, I think our difference of opinion arises from the different perspectives we bring to the problem. As a "security guy" I would not agree with your opening statement.=20 We usually worry that mixing unverified info with verified info, in any context, is a recipe for trouble, as it encourages folks to accept the mixed info and treat it as verified. You give an example of ISPs wanting to " ... distinguish their services as having somewhat more reliable routing due to the use of authentication ..."=20 That is precisely the sort of claim most security folks would worry about :-). As for what will make incremental valuable enough to ISPs to warrant their buy-in, I think that's a hard call for anyone to make right now. One possible deployment scenario is that the biggest ISPs will deploy first. If so, then the fact that most of these folks have direct peering arrangements with one another would allow them to benefit, irrespective of the issue of intermediaries who are not yet playing. If the next set of adopters are ISPs directly connected to the big ISPs, and often to one another (e.g., via IXPs), then they too can derive benefits in many instances, even without passing verified path info through unverified ASes. So, given possible deployment scenarios like these, the uncertainty about which deployment scenarios may happen, and the security principle of avoiding situations that may encourage folks to accept mixed data as all authentic, I feel it's inappropriate to mandate support for passing such data along. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 17 12:00:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApTQ-0001di-AD; Tue, 17 Jul 2007 12:00:28 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IApT8-0001Bn-Pp for rpsec-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 12:00:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApT8-0001Bd-6n for rpsec@ietf.org; Tue, 17 Jul 2007 12:00:10 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IApT6-0005Rz-Gm for rpsec@ietf.org; Tue, 17 Jul 2007 12:00:10 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6HFvwBP000958 for ; Tue, 17 Jul 2007 11:57:58 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVdaaOb; Tue, 17 Jul 07 11:57:21 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id EBC053F47D; Tue, 17 Jul 2007 11:55:19 -0400 (EDT) To: rpsec@ietf.org Subject: Re: [RPSEC] BGP Security Requirements v08 In-Reply-To: <200707171426.l6HEQJiK090507@harbor.brookfield.occnc.com> Message-Id: <20070717155519.EBC053F47D@pecan.tislabs.com> Date: Tue, 17 Jul 2007 11:55:19 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Curtis writes: >In message >Stephen Kent writes: >> >> I think the question is why, if the path info received by an "island >> AS" has a number of unverified hops, is this path info useful, in a >> security sense, to the AS that receives? How does the requirement to >> send such info promote adoption of the protocol? >> >> Steve > > >Because it is likely to be more reliable than information with no >authentication at all. > >The major ISPs are fairly reliable at getting their internal routing >right so if the non-authenticating routers in the middle are entirely >in a set of ISPs that are known to generally not have breakins into >their own infrastructure. Curtis, I'm not sure exactly what you mean here, but Steve was talking about AS hops, not router hops. I *think* that's what you mean, also, but I'm not sure. Steve, I strongly believe that incremental deployment scenarios WILL include cases where non-upgradable ASs will be provided with other, operational or algorithmic, protections, so that ISPs in the know will trust paths that come to them from those ASs. I am less strongly convinced that incremental deployment scenarios MUST include such cases. But I see no way to provide benefit in incremental deployment otherwise. I do not think that you are saying that solutions COULD NOT provide benefit when island hopping. The work being done in the sidr wg (to provide an infrastructure that would provide authorization for prefix origination) would be an example of protections that would still provide benefit when island hopping, as the origin authorization check is of value no matter how many clueless ASs touch the UPDATE. I believe that you are arguing whether solutions should be REQUIRED to provide benefit when island hopping. And Curtis is arguing that they should, because otherwise incremental deployment will be very very unattractive. The choices seem to boil down to MUST or SHOULD. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 17 12:18:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAplG-0004XW-6a; Tue, 17 Jul 2007 12:18:54 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IAplE-0004XM-R6 for rpsec-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 12:18:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAplE-0004XE-Gx for rpsec@ietf.org; Tue, 17 Jul 2007 12:18:52 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAplD-0006LV-7y for rpsec@ietf.org; Tue, 17 Jul 2007 12:18:52 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IAplC-0003uW-5H; Tue, 17 Jul 2007 12:18:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20070717155519.EBC053F47D@pecan.tislabs.com> References: <20070717155519.EBC053F47D@pecan.tislabs.com> Date: Tue, 17 Jul 2007 12:19:00 -0400 To: sandy@tislabs.com (Sandy Murphy) From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rpsec@ietf.org, sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 11:55 AM -0400 7/17/07, Sandy Murphy wrote: >... >Steve, I strongly believe that incremental deployment scenarios WILL >include cases where non-upgradable ASs will be provided with other, >operational or algorithmic, protections, so that ISPs in the know will >trust paths that come to them from those ASs. I am less strongly >convinced that incremental deployment scenarios MUST include such cases. >But I see no way to provide benefit in incremental deployment otherwise. Incremental deployment in ASes that are adjacent to one another offers advantages, and I think one cannot rule out scenarios in which adjacent ASes deploy an enhanced version of BGP. >I do not think that you are saying that solutions COULD NOT provide >benefit when island hopping. The work being done in the sidr wg >(to provide an infrastructure that would provide authorization for >prefix origination) would be an example of protections that would >still provide benefit when island hopping, as the origin authorization >check is of value no matter how many clueless ASs touch the UPDATE. True, the SIDR work will make origin AS authorization data available to every ISP by virtue of publishing ROAs. However, it does so without passing ROA data via BGP, so the non-adjacency issue does not apply in this case. >I believe that you are arguing whether solutions should be REQUIRED >to provide benefit when island hopping. And Curtis is arguing that >they should, because otherwise incremental deployment will be very >very unattractive. > >The choices seem to boil down to MUST or SHOULD. Or a MUST/SHOULD vs. MAY. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 17 12:33:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApyx-00019c-Ss; Tue, 17 Jul 2007 12:33:03 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IApyt-0000pD-3r for rpsec-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 12:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApys-0000mb-AY for rpsec@ietf.org; Tue, 17 Jul 2007 12:32:58 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IApyo-0006Jk-V1 for rpsec@ietf.org; Tue, 17 Jul 2007 12:32:58 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l6HGWhSm024790; Tue, 17 Jul 2007 09:32:43 -0700 Received: (from ttauber@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l6HGWhng024789; Tue, 17 Jul 2007 09:32:43 -0700 Date: Tue, 17 Jul 2007 09:32:43 -0700 From: Tony Tauber To: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Message-ID: <20070717163243.GB1426@1-4-5.net> References: <20070717155519.EBC053F47D@pecan.tislabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org What meaning a receiving AS might assign to a partially authenticated piece of data is left up to that AS (keeping in the spirit of autonomy). Certainly one can envision an attack which exposes the authenticated origin info but which nefariously removes intervening hops to draw in traffic improperly (e.g., to inspect, alter, or drop). > >I believe that you are arguing whether solutions should be REQUIRED > >to provide benefit when island hopping. And Curtis is arguing that > >they should, because otherwise incremental deployment will be very > >very unattractive. > > > >The choices seem to boil down to MUST or SHOULD. > > Or a MUST/SHOULD vs. MAY. Right, based on the discussion thus far, I was leaning toward keeping the idea in as a MAY. One might argue that doing so is effectively the same as leaving it out altogether, but the intention and information is retained. Beyond that, asserting it as a "MAY" explicitly blocks any interpretation which ends in "... NOT". Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 17 16:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAtr1-0005ib-H0; Tue, 17 Jul 2007 16:41:07 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IAtr0-0005Xk-4e for rpsec-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 16:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAtqz-0005V9-Ko for rpsec@ietf.org; Tue, 17 Jul 2007 16:41:05 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAtqy-0006tZ-CE for rpsec@ietf.org; Tue, 17 Jul 2007 16:41:05 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6HKcrbd000349 for ; Tue, 17 Jul 2007 16:38:53 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAu7aiGa; Tue, 17 Jul 07 16:37:54 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 72FA73F484; Tue, 17 Jul 2007 16:35:54 -0400 (EDT) To: rpsec@ietf.org Subject: Re: [RPSEC] BGP Security Requirements v08 In-Reply-To: <20070717163243.GB1426@1-4-5.net> Message-Id: <20070717203554.72FA73F484@pecan.tislabs.com> Date: Tue, 17 Jul 2007 16:35:54 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: -0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Tony Tauber said: >Right, based on the discussion thus far, I was leaning toward keeping >the idea in as a MAY. I am OK with that, especially the "keeping the idea in" part. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 09:39:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB9ka-0003RE-1F; Wed, 18 Jul 2007 09:39:32 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IB9kY-0003R9-Kq for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 09:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB9kY-0003R1-B9 for rpsec@ietf.org; Wed, 18 Jul 2007 09:39:30 -0400 Received: from xmail02.myhosting.com ([168.144.250.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB9kX-0001EH-35 for rpsec@ietf.org; Wed, 18 Jul 2007 09:39:30 -0400 Received: (qmail 19755 invoked from network); 18 Jul 2007 13:39:26 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Jul 2007 13:39:26 -0000 Message-ID: <469E1801.3040101@cisco.com> Date: Wed, 18 Jul 2007 09:39:13 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Tony Tauber Subject: Re: [RPSEC] BGP Security Requirements v08 References: <20070717155519.EBC053F47D@pecan.tislabs.com> <20070717163243.GB1426@1-4-5.net> In-Reply-To: <20070717163243.GB1426@1-4-5.net> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: rpsec@ietf.org, Stephen Kent , Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> The choices seem to boil down to MUST or SHOULD. >> Or a MUST/SHOULD vs. MAY. > > Right, based on the discussion thus far, I was leaning toward keeping > the idea in as a MAY. One might argue that doing so is effectively the > same as leaving it out altogether, but the intention and information is > retained. Beyond that, asserting it as a "MAY" explicitly blocks any > interpretation which ends in "... NOT". I would prefer SHOULD over MAY, because I believe there is value in partially validated data. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnhgBER27sUhU9OQRAlW8AKD3fEAg+/R9P2JuMH6zjmd7doNgBgCfZQfx 3xlwMnB/cJsjys6t0Rb9FbE= =8WLb -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 11:44:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBhO-0007nV-M9; Wed, 18 Jul 2007 11:44:22 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBBhN-0007nM-7w for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 11:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBhM-0007nE-Tv for rpsec@ietf.org; Wed, 18 Jul 2007 11:44:20 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBBhL-0004ks-Hs for rpsec@ietf.org; Wed, 18 Jul 2007 11:44:20 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6IFiMLG025817; Wed, 18 Jul 2007 11:44:22 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707181544.l6IFiMLG025817@harbor.brookfield.occnc.com> To: Stephen Kent From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Tue, 17 Jul 2007 11:09:48 EDT." Date: Wed, 18 Jul 2007 11:44:22 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Stephen Kent writes: > > As a "security guy" I would not agree with your opening statement. > We usually worry that mixing unverified info with verified info, in > any context, is a recipe for trouble, as it encourages folks to > accept the mixed info and treat it as verified. You give an example > of ISPs wanting to " ... distinguish their services as having > somewhat more reliable routing due to the use of authentication ..." > That is precisely the sort of claim most security folks would worry > about :-). As a security guy, you could think of it as a different kind of (not very good) security across a known reliable ISP or a small set of known reliable ISPs. A provider may peer with one or more ISPs who they know have excellent security practices and whose routing is known to be fairly robust. An set of AS with those AS numbers only plus a set of authenticated AS would be more likely to deliver packets than an AS Path through unauthenticated AS of unknown reliability. What we are talking about here is prevention of DOS, not protection of secrets. Choosing a path that is extremely likely to be reliable but not guarenteed to be reliable in practice is clearly an improvement over choosing any available path. It is the sole basis of most policy routing decisions today. My view on this is we can strive for perfection and get nothing at all or try to improve the current situation and get the work implemented with limited deployment in ISPs and due to being implemented the security community has it and can use it as they please. My concern is that with no interest from ISPs it will be hard to get vendors to implement and it will never get PS status for lack of implementation. It would be nice to hear from ISPs since I'm not at one. If memory serves me, we had two opinions voiced. One was that some sort of transitive property across non-authenticated AS was a necessary feature. The other was that the storage overhead needed to be reasonable or ISPs who did not use the authentication would simply drop the attributes at their peerings. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 12:14:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCAH-0004iS-Nf; Wed, 18 Jul 2007 12:14:13 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBCAG-0004iE-TT for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 12:14:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCAG-0004i2-Ju for rpsec@ietf.org; Wed, 18 Jul 2007 12:14:12 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBCAG-0005Y3-94 for rpsec@ietf.org; Wed, 18 Jul 2007 12:14:12 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6IGEGrr026084; Wed, 18 Jul 2007 12:14:16 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707181614.l6IGEGrr026084@harbor.brookfield.occnc.com> To: "James Ko" From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Tue, 17 Jul 2007 11:35:24 EDT." Date: Wed, 18 Jul 2007 12:14:16 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: rpsec@ietf.org, Russ White , Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message "James Ko" writes: > > > Indeed, ideally incoming data should be "authentic" and "verifiable", > otherwise we are back to square one and this work is no different but to > give bad guys a window of opportunity to run man-in-the-middle attacks, > or inject bogus routes. So why does Internet routing work at all today? Rhetorical question. It does work by the way. Not always perfectly. Curtis ps - The answer is because the DOS would be short lived and very traceable (ie: not much damage and they'd get caught). The reason for this is the bogus information would have to be injected from within an ISP and ISP security of their own infrastructure is reasonably good. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 12:33:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCSy-0007Ly-0E; Wed, 18 Jul 2007 12:33:32 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBCSw-0007Jd-II for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 12:33:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCSw-0007JV-7T for rpsec@ietf.org; Wed, 18 Jul 2007 12:33:30 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBCSu-0007I1-Od for rpsec@ietf.org; Wed, 18 Jul 2007 12:33:30 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6IGY7h1026467; Wed, 18 Jul 2007 12:34:07 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707181634.l6IGY7h1026467@harbor.brookfield.occnc.com> To: sandy@tislabs.com (Sandy Murphy) From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Tue, 17 Jul 2007 11:55:19 EDT." <20070717155519.EBC053F47D@pecan.tislabs.com> Date: Wed, 18 Jul 2007 12:34:07 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <20070717155519.EBC053F47D@pecan.tislabs.com> Sandy Murphy writes: > > Curtis writes: > >In message > >Stephen Kent writes: > >> > >> I think the question is why, if the path info received by an "island > >> AS" has a number of unverified hops, is this path info useful, in a > >> security sense, to the AS that receives? How does the requirement to > >> send such info promote adoption of the protocol? > >> > >> Steve > > > > > >Because it is likely to be more reliable than information with no > >authentication at all. > > > >The major ISPs are fairly reliable at getting their internal routing > >right so if the non-authenticating routers in the middle are entirely > >in a set of ISPs that are known to generally not have breakins into > >their own infrastructure. > > Curtis, I'm not sure exactly what you mean here, but Steve was talking > about AS hops, not router hops. I *think* that's what you mean, also, > but I'm not sure. What I meant is that 1) major ISPs do a very good job of filtering customer routes and not originating bogus information into the global BGP routing and 2) major ISP security is good enough that it is very hard for an attacker to inject BGP information into an ISP from within the ISP's own infrastructure. That Internet routing for the most part works is partially due to the above and that places where this is not true are enough AS hops away from the major ISPs that bogus information is localized to those far reaches that may be a little behind on the operations learning curve. > Steve, I strongly believe that incremental deployment scenarios WILL > include cases where non-upgradable ASs will be provided with other, > operational or algorithmic, protections, so that ISPs in the know will > trust paths that come to them from those ASs. I am less strongly > convinced that incremental deployment scenarios MUST include such cases. > But I see no way to provide benefit in incremental deployment otherwise. > > I do not think that you are saying that solutions COULD NOT provide > benefit when island hopping. The work being done in the sidr wg > (to provide an infrastructure that would provide authorization for > prefix origination) would be an example of protections that would > still provide benefit when island hopping, as the origin authorization > check is of value no matter how many clueless ASs touch the UPDATE. > > I believe that you are arguing whether solutions should be REQUIRED > to provide benefit when island hopping. And Curtis is arguing that > they should, because otherwise incremental deployment will be very > very unattractive. > > The choices seem to boil down to MUST or SHOULD. > > --Sandy IMO if we are down to SHOULD and MUST: The protocol MUST support a mechanism ... [to connect islands, sic] The protocol MUST keep authentication information reasonable small. If that information needs to be large in order to be robust, then the protocol SHOULD provide an alternate smaller digest that is less likely to get tossed. ISPs SHOULD try to pass information to non-authenticating peers. ISPs SHOULD prefer information from a subset or trustworthy non-authenticating peer AS with partial authentication covering all less known AS over information where untrusted non-authenticating AS are in the path. Non-authenticating AS should pass the authentication information unchanged unless doing so is infeasible due to router memory constraints. This needs rewording but I hope its clear enough for discussion. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 12:57:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCpU-0002OF-4E; Wed, 18 Jul 2007 12:56:48 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBCpS-0002O6-G1 for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 12:56:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBCpS-0002Ny-6Y for rpsec@ietf.org; Wed, 18 Jul 2007 12:56:46 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBCpQ-0006jj-T5 for rpsec@ietf.org; Wed, 18 Jul 2007 12:56:46 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6IGtc1o026662; Wed, 18 Jul 2007 12:55:39 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707181655.l6IGtc1o026662@harbor.brookfield.occnc.com> To: Tony Tauber From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Tue, 17 Jul 2007 09:32:43 PDT." <20070717163243.GB1426@1-4-5.net> Date: Wed, 18 Jul 2007 12:55:38 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: rpsec@ietf.org, Stephen Kent , Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <20070717163243.GB1426@1-4-5.net> Tony Tauber writes: > > > What meaning a receiving AS might assign to a partially authenticated > piece of data is left up to that AS (keeping in the spirit of autonomy). > > Certainly one can envision an attack which exposes the authenticated > origin info but which nefariously removes intervening hops to draw in > traffic improperly (e.g., to inspect, alter, or drop). You could imagine that but ... The major ISPs have important major customers and peer. For example they would not want their routing corrupted by a bad route to a major content provider. Therefore many major providers will only accept these major customer and peer routes from a very limited set of ISPs. In order to get a short enough AS Path to have an effect on those routes, you'd need to first break into the ISP infrastructure. Then there are routes farther away. For example, a few AS hops might be required to reach a destination in Europe from the US. If the AS in between have both secure infrastructure and reasonable route policy for any major European customer or peer the same situation exists. This is why in theory a man-in-th-middle could inject bad information but in practice it can't happen for most "important" routes (ones that the ISPs consider most important because they are big paying customers or having bad routes to them would be a significant disruption and embarasement). Add some authentication and you may have further improviment in the reliability of routing information. Don't allow that to cross the major ISPs and the authenticaion is of very little use for ISPs. A small ISP in the far reaches (less developed world, for example) may get better connectivity and immunity from injection of bad routing information for their own routes if they provide authenticaion on routes they originate, register their routes for policy verification by other ISPs, and check authentication and registration of routes they receive. The standard routing and security hygene also applies. > > >I believe that you are arguing whether solutions should be REQUIRED > > >to provide benefit when island hopping. And Curtis is arguing that > > >they should, because otherwise incremental deployment will be very > > >very unattractive. > > > > > >The choices seem to boil down to MUST or SHOULD. > > > > Or a MUST/SHOULD vs. MAY. > > Right, based on the discussion thus far, I was leaning toward keeping > the idea in as a MAY. One might argue that doing so is effectively the > same as leaving it out altogether, but the intention and information is > retained. Beyond that, asserting it as a "MAY" explicitly blocks any > interpretation which ends in "... NOT". > > Tony The MAY or SHOULD words MUST apply only to decisions regarding deployment (MAY use some featured, SHOULD use some feature, MAY or SHOULD pass some information ...). In the requirements the word MUST has to be applied to protocol definitions and protocol implementations or at the very least a SHOULD with very strong emphasis. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 13:38:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDTU-0002IX-6s; Wed, 18 Jul 2007 13:38:08 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBDTT-0002CT-1j for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 13:38:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDTS-00026R-GY for rpsec@ietf.org; Wed, 18 Jul 2007 13:38:06 -0400 Received: from xmail08.myhosting.com ([168.144.250.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBDTP-0000qr-5L for rpsec@ietf.org; Wed, 18 Jul 2007 13:38:06 -0400 Received: (qmail 6158 invoked from network); 18 Jul 2007 17:38:00 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Jul 2007 17:38:00 -0000 Message-ID: <469E4FEB.4080307@cisco.com> Date: Wed, 18 Jul 2007 13:37:47 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: curtis@occnc.com Subject: Re: [RPSEC] BGP Security Requirements v08 References: <200707181634.l6IGY7h1026467@harbor.brookfield.occnc.com> In-Reply-To: <200707181634.l6IGY7h1026467@harbor.brookfield.occnc.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The protocol MUST support a mechanism ... [to connect islands, sic] > > The protocol MUST keep authentication information reasonable small. > If that information needs to be large in order to be robust, then > the protocol SHOULD provide an alternate smaller digest that is less > likely to get tossed. > > ISPs SHOULD try to pass information to non-authenticating peers. > > ISPs SHOULD prefer information from a subset or trustworthy > non-authenticating peer AS with partial authentication covering all > less known AS over information where untrusted non-authenticating AS > are in the path. > > Non-authenticating AS should pass the authentication information > unchanged unless doing so is infeasible due to router memory > constraints. Maybe this would work? The protocol SHOULD either either be designed so: o Non-authenticating implementations will pass the authentication information without modification. o The authentication information may be passed between authenticating implementations outside the BGP protocol. Would that cover what you're trying to get to? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnk/rER27sUhU9OQRAhb+AJ0WPdWfJghpG0l/0pBxJ5E2UcOyXACeNV+G sobdBs31dQmkGSMWEuQOLso= =crZa -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 14:10:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDyb-0005OS-0B; Wed, 18 Jul 2007 14:10:17 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBDyV-0005KT-Fe for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:10:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDyV-0005KJ-65 for rpsec@ietf.org; Wed, 18 Jul 2007 14:10:11 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBDyT-0000Tn-Sn for rpsec@ietf.org; Wed, 18 Jul 2007 14:10:11 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6IIAUcc028332; Wed, 18 Jul 2007 14:10:30 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707181810.l6IIAUcc028332@harbor.brookfield.occnc.com> To: Russ White From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Wed, 18 Jul 2007 13:37:47 EDT." <469E4FEB.4080307@cisco.com> Date: Wed, 18 Jul 2007 14:10:30 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <469E4FEB.4080307@cisco.com> Russ White writes: > > o The authentication information may be passed between authenticating > implementations outside the BGP protocol. Is this practical? Pass information out of band to every far distant BGP speaker rather than just to peers. This seems to break the "must be scalable" requirement for everything related to routing. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 14:30:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEHq-0005u3-7y; Wed, 18 Jul 2007 14:30:10 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBEHo-0005jS-BL for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:30:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEHn-0005j9-Vl for rpsec@ietf.org; Wed, 18 Jul 2007 14:30:08 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBEHn-0002OE-Ke for rpsec@ietf.org; Wed, 18 Jul 2007 14:30:07 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBEHm-0005PI-5b; Wed, 18 Jul 2007 14:30:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707181614.l6IGEGrr026084@harbor.brookfield.occnc.com> References: <200707181614.l6IGEGrr026084@harbor.brookfield.occnc.com> Date: Wed, 18 Jul 2007 14:10:18 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 12:14 PM -0400 7/18/07, Curtis Villamizar wrote: >In message >"James Ko" writes: >> >> >> Indeed, ideally incoming data should be "authentic" and "verifiable", >> otherwise we are back to square one and this work is no different but to >> give bad guys a window of opportunity to run man-in-the-middle attacks, >> or inject bogus routes. > > >So why does Internet routing work at all today? Rhetorical question. > >It does work by the way. Not always perfectly. > >Curtis > > >ps - The answer is because the DOS would be short lived and very >traceable (ie: not much damage and they'd get caught). The reason for >this is the bogus information would have to be injected from within an >ISP and ISP security of their own infrastructure is reasonably good. Curtis, a few observations: - as I just noted in a prior response, DoS is not the only issue here. - the fact that routing does generally work today is not a good basis for deciding on security requirements. If we turn back the clock a few years we could say that DDoS attacks never happen and thus one need not make provisions to deter such attacks. As they say in the financial sector "performance data shown represents past performance and is no guarantee of future results" :-). - active attacks against BGP sessions are possible. not all BGP sessions make use of extant protection mechanisms like the TCP MD5 checksum, and among those that do there are reports of key management that leave s a lot ot be desired Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 14:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEHs-00061p-AN; Wed, 18 Jul 2007 14:30:12 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBEHp-0005p0-BT for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEHo-0005lt-TQ for rpsec@ietf.org; Wed, 18 Jul 2007 14:30:08 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBEHn-00018k-OT for rpsec@ietf.org; Wed, 18 Jul 2007 14:30:08 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBEHn-0005PI-4F; Wed, 18 Jul 2007 14:30:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707181634.l6IGY7h1026467@harbor.brookfield.occnc.com> References: <200707181634.l6IGY7h1026467@harbor.brookfield.occnc.com> Date: Wed, 18 Jul 2007 14:30:07 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org >... > > >> I do not think that you are saying that solutions COULD NOT provide >> benefit when island hopping. The work being done in the sidr wg >> (to provide an infrastructure that would provide authorization for >> prefix origination) would be an example of protections that would >> still provide benefit when island hopping, as the origin authorization > > check is of value no matter how many clueless ASs touch the UPDATE. The ROA defined by the SIDR work is a good example of a first step that acknowledges that some verified info is better than none, a point you have been making. It also is an example of a mechanism that addresses what some folks say is the most common form of accidental "attack" by ISPs, i.e., erroneous origin announcements due to config errors. That makes is an appropriate partial solution, since it addresses, in a comprehensive fashion, one specific form of problem. Also, the ROA model is especially simple, as there is no notion of a serial mix of verified and unverified path data, since a ROA attests only to origin AS data. Finally, based on the current SIDR architecture model, ROAs are distributed via a repository system, essentially out-of-band, and so the argument re transitive propagation does not apply here. > > I believe that you are arguing whether solutions should be REQUIRED > > to provide benefit when island hopping. And Curtis is arguing that >> they should, because otherwise incremental deployment will be very > > very unattractive. >> > > The choices seem to boil down to MUST or SHOULD. Sandy changed her position to MAY yesterday, based on further discussion and on Tony's suggestion. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 14:30:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEHm-0005iF-Uz; Wed, 18 Jul 2007 14:30:06 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBEHl-0005ey-Q2 for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:30:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEHl-0005ed-EC for rpsec@ietf.org; Wed, 18 Jul 2007 14:30:05 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBEHk-00018b-SV for rpsec@ietf.org; Wed, 18 Jul 2007 14:30:05 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBEHk-0005PI-4v; Wed, 18 Jul 2007 14:30:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707181544.l6IFiMLG025817@harbor.brookfield.occnc.com> References: <200707181544.l6IFiMLG025817@harbor.brookfield.occnc.com> Date: Wed, 18 Jul 2007 14:00:48 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 11:44 AM -0400 7/18/07, Curtis Villamizar wrote: >In message >Stephen Kent writes: >> >> As a "security guy" I would not agree with your opening statement. >> We usually worry that mixing unverified info with verified info, in >> any context, is a recipe for trouble, as it encourages folks to >> accept the mixed info and treat it as verified. You give an example >> of ISPs wanting to " ... distinguish their services as having >> somewhat more reliable routing due to the use of authentication ..." >> That is precisely the sort of claim most security folks would worry >> about :-). > > >As a security guy, you could think of it as a different kind of (not >very good) security across a known reliable ISP or a small set of >known reliable ISPs. A provider may peer with one or more ISPs who >they know have excellent security practices and whose routing is known >to be fairly robust. An set of AS with those AS numbers only plus >a set of authenticated AS would be more likely to deliver packets than >an AS Path through unauthenticated AS of unknown reliability. I think we are in agreement that, under some circumstances, one could make good use of path info that is a mix of verified data from unknown ASes, plus unverified data from known, trusted ASes. However, I also think it is fair to say that there are examples of incremental deployment where this is not a requirement. Moreover there are be cases where relying on trusted ASes will cause problems, not because the ASes are not trusted, but because people make mistakes and these mistakes are equivalent to some forms of attacks. Given this mix of possible scenarios, it seems appropriate to allow for solutions that accommodate propagation of mixed (verified and unverified) path data, but not to mandate them. Hence a MUST here seems too stringent, as that is a mandate. SHOULD expresses a strong preference for solutions to accommodate this capability, and MAY is neutral. That's why I believe MAY is appropriate. >What we are talking about here is prevention of DOS, not protection of >secrets. DoS is the primary concern, but not the only one. Misrouting to effect active or passive wiretapping also was cited as a concern in RFC 4272 (BGP Security Vulnerabilities Analysis). >Choosing a path that is extremely likely to be reliable but >not guarenteed to be reliable in practice is clearly an improvement >over choosing any available path. It is the sole basis of most policy >routing decisions today. Choosing a path that is extremely likely to be reliable is obviously a goal, but having some verified info for a path does not, per se, make it "extremely reliable." >My view on this is we can strive for perfection and get nothing at all >or try to improve the current situation and get the work implemented >with limited deployment in ISPs and due to being implemented the >security community has it and can use it as they please. My concern >is that with no interest from ISPs it will be hard to get vendors to >implement and it will never get PS status for lack of implementation. I have to admit that whenever I hear someone argue that a proposed security approach is striving for perfection at the expense of practicality, I wince. Thus is a reasonable argument in principle, but very often folks disagree about what constitutes a practical (or impractical) solution, or a what constitutes reasonable threat model, etc. So, let;s try to not go down this path as a basis for deciding about these requirements, as it is unlikely to be a fruitful wa to resolve our disagreements. >It would be nice to hear from ISPs since I'm not at one. If memory >serves me, we had two opinions voiced. One was that some sort of >transitive property across non-authenticated AS was a necessary >feature. The other was that the storage overhead needed to be >reasonable or ISPs who did not use the authentication would simply >drop the attributes at their peerings. The second argument you cited was not the principle one, but rather an example of why mandating this as a requirement might be problematic. I think the argument I have made in this and previous messages is that there are a number of incremental deployment scenarios where the need for the sort of transitive property you cite is not needed, and there are scenarios where it could lead to bad decisions. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 15:04:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEpF-0008PK-1I; Wed, 18 Jul 2007 15:04:41 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBEpE-0008PE-02 for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:04:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEpD-0008P6-LM for rpsec@ietf.org; Wed, 18 Jul 2007 15:04:39 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBEpD-0003IF-3P for rpsec@ietf.org; Wed, 18 Jul 2007 15:04:39 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6IJ5MdD029754; Wed, 18 Jul 2007 15:05:22 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707181905.l6IJ5MdD029754@harbor.brookfield.occnc.com> To: Stephen Kent From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Wed, 18 Jul 2007 14:00:48 EDT." Date: Wed, 18 Jul 2007 15:05:22 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Stephen Kent writes: > > >What we are talking about here is prevention of DOS, not protection of > >secrets. > > DoS is the primary concern, but not the only one. Misrouting to > effect active or passive wiretapping also was cited as a concern in > RFC 4272 (BGP Security Vulnerabilities Analysis). Steve, As a security guy wouldn't you consider relying on routing to protect secrets to be more than just a slightly bad idea? For secure applications you must always assume an insecure channel even if its in the same building. With enough snooped data breaking some forms of encryption is possible so I know what you are getting at. In terms of real world, it might be possible to divert information that is supposed to go to some major bank from some far away place and have a go at the SSL encryption but I suspect its orders of magnitudes easier to take over the client's Windows box and record keystrokes. > I have to admit that whenever I hear someone argue that a proposed > security approach is striving for perfection at the expense of > practicality, I wince. Thus is a reasonable argument in principle, > but very often folks disagree about what constitutes a practical (or > impractical) solution, or a what constitutes reasonable threat model, > etc. So, let;s try to not go down this path as a basis for deciding > about these requirements, as it is unlikely to be a fruitful wa to > resolve our disagreements. At what point do we set theory aside and look at whether we are addressing any sort of real world problem? Is your answer "never"? > The second argument you cited was not the principle one, but rather > an example of why mandating this as a requirement might be > problematic. I think the argument I have made in this and previous > messages is that there are a number of incremental deployment > scenarios where the need for the sort of transitive property you cite > is not needed, and there are scenarios where it could lead to bad > decisions. OK. Lets have some specifics. What deployment scenarios? Where could transitive behaviour that only applies to selecting among incompletely authenticated results (and can be administratively disabled) lead to bad decisions? This would not be the first routing activity of the IETF that was great in theory but went nowhere because it had no practical deployment scenario. If it goes nowhere it is a waste of our time. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 15:12:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEwS-0006Tm-AY; Wed, 18 Jul 2007 15:12:08 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBEwR-0006Tg-QS for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:12:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBEwR-0006TY-Gf for rpsec@ietf.org; Wed, 18 Jul 2007 15:12:07 -0400 Received: from xmail08.myhosting.com ([168.144.250.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBEwQ-0002Fs-8O for rpsec@ietf.org; Wed, 18 Jul 2007 15:12:07 -0400 Received: (qmail 10850 invoked from network); 18 Jul 2007 19:12:05 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Jul 2007 19:12:05 -0000 Message-ID: <469E65F7.8010509@cisco.com> Date: Wed, 18 Jul 2007 15:11:51 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: curtis@occnc.com Subject: Re: [RPSEC] BGP Security Requirements v08 References: <200707181810.l6IIAUcc028332@harbor.brookfield.occnc.com> In-Reply-To: <200707181810.l6IIAUcc028332@harbor.brookfield.occnc.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> o The authentication information may be passed between authenticating >> implementations outside the BGP protocol. > > Is this practical? Pass information out of band to every far distant > BGP speaker rather than just to peers. > > This seems to break the "must be scalable" requirement for everything > related to routing. Aren't the ROAs already being transmitted that way? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnmX3ER27sUhU9OQRAkx0AKD9ygT8P3jGLvcOp/iunrI+BDXdDgCgwepW kYUFeS0aYgF7uFkvgLewr5U= =GwF6 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 15:18:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBF2I-0003ds-KL; Wed, 18 Jul 2007 15:18:10 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBF2H-0003dl-74 for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:18:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBF2G-0003dd-Si for rpsec@ietf.org; Wed, 18 Jul 2007 15:18:08 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBF2G-0003kL-9d for rpsec@ietf.org; Wed, 18 Jul 2007 15:18:08 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6IJIr3X029859; Wed, 18 Jul 2007 15:18:53 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707181918.l6IJIr3X029859@harbor.brookfield.occnc.com> To: Stephen Kent From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Wed, 18 Jul 2007 14:10:18 EDT." Date: Wed, 18 Jul 2007 15:18:53 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Stephen Kent writes: > > At 12:14 PM -0400 7/18/07, Curtis Villamizar wrote: > >In message > >"James Ko" writes: > >> > >> > >> Indeed, ideally incoming data should be "authentic" and "verifiable", > >> otherwise we are back to square one and this work is no different but to > >> give bad guys a window of opportunity to run man-in-the-middle attacks, > >> or inject bogus routes. > > > > > >So why does Internet routing work at all today? Rhetorical question. > > > >It does work by the way. Not always perfectly. > > > >Curtis > > > > > >ps - The answer is because the DOS would be short lived and very > >traceable (ie: not much damage and they'd get caught). The reason for > >this is the bogus information would have to be injected from within an > >ISP and ISP security of their own infrastructure is reasonably good. > > Curtis, > > a few observations: > - as I just noted in a prior response, DoS is not the only issue here. > > - the fact that routing does generally work today is not a > good basis for deciding on security requirements. If we turn back > the clock a few years we could say that DDoS attacks never happen and > thus one need not make provisions to deter such attacks. As they say > in the financial sector "performance data shown represents past > performance and is no guarantee of future results" :-). I think you mean turn back the clock a decade. DDOS attacks are more than a decade old. DDOS is exactly the sort of practical problem that the security theorists ignored while the Internet practitioners advocated hardenning. The hardenning had nothing to do with cryptography and in fact cryptography was impractical. The security theorists had a very hard time accepting this and still do, hence our recent discussion on GTSM. I can dig up plenty of back email dating from the mid-1990s on DOS hardenning and DDOS hardenning and *practial* and *deployable* protection against injection of false routing information. > - active attacks against BGP sessions are possible. not all > BGP sessions make use of extant protection mechanisms like the TCP > MD5 checksum, and among those that do there are reports of key > management that leave s a lot ot be desired > > Steve TCP MD5 is of limited value with GTSM and packet filtering being the preferred methods of providing such protection. GTSM for EBGP peerings. Filtering for IBGP peerings. I would also point out that GTSM had very strong ISP support particularly from AOL (Vijay Gill) because it did solve a practical problem and vendors had no choice but to implement it promptly, even before the IETF had acted. In contranst this work may drag on for (many more) years and (continue to) yield nothing if practical problems are not addressed. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 15:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFY7-0002Jk-PW; Wed, 18 Jul 2007 15:51:03 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBFY3-0002IC-LQ for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:50:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFY3-0002HW-7n for rpsec@ietf.org; Wed, 18 Jul 2007 15:50:59 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBFY1-0004q3-8b for rpsec@ietf.org; Wed, 18 Jul 2007 15:50:59 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6IJme53025398; Wed, 18 Jul 2007 15:48:40 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAEFaqEX; Wed, 18 Jul 07 15:47:59 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id D2FBB3F43C; Wed, 18 Jul 2007 15:45:58 -0400 (EDT) To: curtis@occnc.com Subject: Re: [RPSEC] BGP Security Requirements v08 In-Reply-To: <200707181655.l6IGtc1o026662@harbor.brookfield.occnc.com> Message-Id: <20070718194558.D2FBB3F43C@pecan.tislabs.com> Date: Wed, 18 Jul 2007 15:45:58 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org >The major ISPs have important major customers and peer. For example >they would not want their routing corrupted by a bad route to a major >content provider. Therefore many major providers will only accept >these major customer and peer routes from a very limited set of ISPs. I hear you about the Internet mostly just works. But we seem to have p-l-e-n-t-y of publically discussed examples of cases where the trust structure did not not serve us well. Furthermore, from what major ISP have said, what is said by others about major ISPs and from the analyses of public data of some incidents, it seems the case that some major ISPs (Spring comes to mind?) do not filter well enough to prevent some noticable traffic redirection. These have been accidents so far, but provide worked examples of how bad the problem can get. Relying on the ISP trust and policies is mostly good enough for mostly just works. >Add some authentication and you may have further improviment in the >reliability of routing information. Don't allow that to cross the >major ISPs and the authenticaion is of very little use for ISPs. I agree with you here! But I don't think anyone is talking about not allowing auth info to cross major ISPs. We're mostly arguing how strong a requirement to make the ability to transit un-upgraded ISPs: MUST, SHOULD, or MAY. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 15:59:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFg5-0003md-JT; Wed, 18 Jul 2007 15:59:17 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBFg2-0003jq-Ci for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 15:59:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFg2-0003j1-0m for rpsec@ietf.org; Wed, 18 Jul 2007 15:59:14 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBFg1-00055K-Ji for rpsec@ietf.org; Wed, 18 Jul 2007 15:59:13 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6IK0570030774; Wed, 18 Jul 2007 16:00:05 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707182000.l6IK0570030774@harbor.brookfield.occnc.com> To: Russ White From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Wed, 18 Jul 2007 15:11:51 EDT." <469E65F7.8010509@cisco.com> Date: Wed, 18 Jul 2007 16:00:05 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <469E65F7.8010509@cisco.com> Russ White writes: > > > >> o The authentication information may be passed between authenticating > >> implementations outside the BGP protocol. > > > > Is this practical? Pass information out of band to every far distant > > BGP speaker rather than just to peers. > > > > This seems to break the "must be scalable" requirement for everything > > related to routing. > > Aren't the ROAs already being transmitted that way? > > :-) > > Russ The ROAs do not provide authentication information to accompany a packet or that pert of an AS path might be legitimate. It just serves to verify that a route could be originated at all by a given AS. If you want to authenticate a routing packet you need a signature over the packet or a digest. Its fine to then provide the public keys OOB. For example, if the AS Path is A X Y Z and I trust my peer A but not X and Y, the ROA only tells me that its OK for Z to have originated this route and nothing about whether this could have legitimately passed through Y and Z. An authentication would be Z signature, Y signing that, X signing that, and A passing along the signatures. If 128 bytes are used per signature that is 384 bytes. OTOH if some OOB mechanism also addressed whether a peering might be legitimate, then requirements would be met. So maybe its just that the current ROA scheme (or schema) is inadequate. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 17:00:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGdC-0007Rd-DM; Wed, 18 Jul 2007 17:00:22 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBGdA-0007PU-3T for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 17:00:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGd8-0007MK-24 for rpsec@ietf.org; Wed, 18 Jul 2007 17:00:19 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBGd6-0005vN-Le for rpsec@ietf.org; Wed, 18 Jul 2007 17:00:18 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6IL172W031766; Wed, 18 Jul 2007 17:01:08 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707182101.l6IL172W031766@harbor.brookfield.occnc.com> To: sandy@tislabs.com (Sandy Murphy) From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Wed, 18 Jul 2007 15:45:58 EDT." <20070718194558.D2FBB3F43C@pecan.tislabs.com> Date: Wed, 18 Jul 2007 17:01:07 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <20070718194558.D2FBB3F43C@pecan.tislabs.com> Sandy Murphy writes: > > >The major ISPs have important major customers and peer. For example > >they would not want their routing corrupted by a bad route to a major > >content provider. Therefore many major providers will only accept > >these major customer and peer routes from a very limited set of ISPs. > > I hear you about the Internet mostly just works. > > But we seem to have p-l-e-n-t-y of publically discussed examples of > cases where the trust structure did not not serve us well. > > Furthermore, from what major ISP have said, what is said by others > about major ISPs and from the analyses of public data of some incidents, > it seems the case that some major ISPs (Spring comes to mind?) do not > filter well enough to prevent some noticable traffic redirection. > These have been accidents so far, but provide worked examples of > how bad the problem can get. > > Relying on the ISP trust and policies is mostly good enough for > mostly just works. This has been true for over a decade. Back in the mid-1990s ANS days two very major incidents occurred. One was the intentional advertisement of very specific routes into PSI for every DNS TLD servier. This took out DNS for anyone who beleived those routes. It did not affect ANS due to IRR policy. Another was announding critical subnets of AOL. Again that did not affect ANS since they had specific filters to protect their direct customers and any peer that wished to register in the IRR. Even earlier, Sprint, UUNET, and PSI default routed to the NSFNET. Someone got a 56K circuit to ANS at a university in the middle east and announced the NSFNET address. Sprint, UUNET and PSI were a mess for 10 hours. NSFNET customers were fine (then it was the PRDB). There are ways to protect routing today. Not everyone makes use of them. That's been the case for a very long time. And they are far from perfect. > >Add some authentication and you may have further improviment in the > >reliability of routing information. Don't allow that to cross the > >major ISPs and the authenticaion is of very little use for ISPs. > > I agree with you here! But I don't think anyone is talking about > not allowing auth info to cross major ISPs. We're mostly arguing > how strong a requirement to make the ability to transit un-upgraded > ISPs: MUST, SHOULD, or MAY. > > --Sandy Some providers may never upgrade. Some mechanism to still pass routes through them is needed, albiet placing less trust in those routes. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 18 18:42:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIDr-0005p7-VG; Wed, 18 Jul 2007 18:42:20 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBIDn-0005ol-2A for rpsec-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 18:42:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBIDm-0005od-NT for rpsec@ietf.org; Wed, 18 Jul 2007 18:42:14 -0400 Received: from xmail06.myhosting.com ([168.144.250.220]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBIDm-0001vO-8N for rpsec@ietf.org; Wed, 18 Jul 2007 18:42:14 -0400 Received: (qmail 28555 invoked from network); 18 Jul 2007 22:42:11 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Jul 2007 22:42:11 -0000 Message-ID: <469E9735.4080703@cisco.com> Date: Wed, 18 Jul 2007 18:41:57 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: curtis@occnc.com Subject: Re: [RPSEC] BGP Security Requirements v08 References: <200707182000.l6IK0570030774@harbor.brookfield.occnc.com> In-Reply-To: <200707182000.l6IK0570030774@harbor.brookfield.occnc.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> o The authentication information may be passed between authenticating >>>> implementations outside the BGP protocol. >>> Is this practical? Pass information out of band to every far distant >>> BGP speaker rather than just to peers. >>> >>> This seems to break the "must be scalable" requirement for everything >>> related to routing. >> >> Aren't the ROAs already being transmitted that way? > > The ROAs do not provide authentication information to accompany a > packet or that pert of an AS path might be legitimate. It just serves > to verify that a route could be originated at all by a given AS. Whether a BGP packet is "authentic" is only a question hop by hop, and hence, anything transitive you carry within the packet doesn't help you much. Whether an AS Path is valid is a long discussion, and we've had it many times before. Suffice it to say I believe it's possible in many ways without carrying anything in the BGP packet. > If you want to authenticate a routing packet you need a signature over > the packet or a digest. Its fine to then provide the public keys OOB. You're treating this like IPsec, where a packet originates at one end of a connection, and ends up on the other side of the Internet at the other end of that connection. Wrong. There's no way to know if a BGP "packet" is "valid," beyond a single hop. You can validate the information contained within the packet, but "validating" the packet across "multiple hops," is only one possible way to do it. :-) Russ > > For example, if the AS Path is A X Y Z and I trust my peer A but not X > and Y, the ROA only tells me that its OK for Z to have originated this > route and nothing about whether this could have legitimately passed > through Y and Z. An authentication would be Z signature, Y signing > that, X signing that, and A passing along the signatures. If 128 > bytes are used per signature that is 384 bytes. > > OTOH if some OOB mechanism also addressed whether a peering might be > legitimate, then requirements would be met. So maybe its just that > the current ROA scheme (or schema) is inadequate. > > Curtis - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnpc1ER27sUhU9OQRAtgLAJwO7/Q/n6jjdFLDs/tA93HI74ZFywCgzJXU 12xxdMHHt2SAQRX2bAgCSLk= =7vX4 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 08:35:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVDV-00047K-Mw; Thu, 19 Jul 2007 08:34:49 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBVDU-00047B-52 for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 08:34:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVDT-00046y-QK for rpsec@ietf.org; Thu, 19 Jul 2007 08:34:47 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBVDT-0006zU-4d for rpsec@ietf.org; Thu, 19 Jul 2007 08:34:47 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6JCZZWv043998; Thu, 19 Jul 2007 08:35:35 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707191235.l6JCZZWv043998@harbor.brookfield.occnc.com> To: Russ White From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Wed, 18 Jul 2007 18:41:57 EDT." <469E9735.4080703@cisco.com> Date: Thu, 19 Jul 2007 08:35:35 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <469E9735.4080703@cisco.com> Russ White writes: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >>>> o The authentication information may be passed between authenticating > >>>> implementations outside the BGP protocol. > >>> Is this practical? Pass information out of band to every far distant > >>> BGP speaker rather than just to peers. > >>> > >>> This seems to break the "must be scalable" requirement for everything > >>> related to routing. > >> > >> Aren't the ROAs already being transmitted that way? > > > > The ROAs do not provide authentication information to accompany a > > packet or that pert of an AS path might be legitimate. It just serves > > to verify that a route could be originated at all by a given AS. > > Whether a BGP packet is "authentic" is only a question hop by hop, and > hence, anything transitive you carry within the packet doesn't help you > much. > > Whether an AS Path is valid is a long discussion, and we've had it many > times before. Suffice it to say I believe it's possible in many ways > without carrying anything in the BGP packet. I do too but if it involves information using a slow, almost static, OOB mechanism such as IRR or X.509 based ROA, then it needs some means of expressing the possible AS adjacencies and the policies applied over those adjacencies. If so, we're right back to RPSL. We might as well just pick up that work and use a different underlying delivery if the RPS work was considered unacceptable. > > If you want to authenticate a routing packet you need a signature over > > the packet or a digest. Its fine to then provide the public keys OOB. > > You're treating this like IPsec, where a packet originates at one end of > a connection, and ends up on the other side of the Internet at the other > end of that connection. Wrong. There's no way to know if a BGP "packet" > is "valid," beyond a single hop. You can validate the information > contained within the packet, but "validating" the packet across > "multiple hops," is only one possible way to do it. > > :-) > > Russ Sorry. Should have said advertisement. Curtis > > For example, if the AS Path is A X Y Z and I trust my peer A but not X > > and Y, the ROA only tells me that its OK for Z to have originated this > > route and nothing about whether this could have legitimately passed > > through Y and Z. An authentication would be Z signature, Y signing > > that, X signing that, and A passing along the signatures. If 128 > > bytes are used per signature that is 384 bytes. > > > > OTOH if some OOB mechanism also addressed whether a peering might be > > legitimate, then requirements would be met. So maybe its just that > > the current ROA scheme (or schema) is inadequate. > > > > Curtis > > - -- > riw@cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGnpc1ER27sUhU9OQRAtgLAJwO7/Q/n6jjdFLDs/tA93HI74ZFywCgzJXU > 12xxdMHHt2SAQRX2bAgCSLk= > =7vX4 > -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 09:41:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWFU-0006lo-UW; Thu, 19 Jul 2007 09:40:56 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBWFT-0006li-Sx for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 09:40:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBWFT-0006la-Hv for rpsec@ietf.org; Thu, 19 Jul 2007 09:40:55 -0400 Received: from xmail05.myhosting.com ([168.144.250.219]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBWFT-0000Yv-2F for rpsec@ietf.org; Thu, 19 Jul 2007 09:40:55 -0400 Received: (qmail 12064 invoked from network); 19 Jul 2007 13:40:52 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Jul 2007 13:40:51 -0000 Message-ID: <469F69D4.2060002@cisco.com> Date: Thu, 19 Jul 2007 09:40:36 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: curtis@occnc.com Subject: Re: [RPSEC] BGP Security Requirements v08 References: <200707191235.l6JCZZWv043998@harbor.brookfield.occnc.com> In-Reply-To: <200707191235.l6JCZZWv043998@harbor.brookfield.occnc.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I do too but if it involves information using a slow, almost static, >> OOB mechanism such as IRR or X.509 based ROA, then it needs some means >> of expressing the possible AS adjacencies and the policies applied >> over those adjacencies. If so, we're right back to RPSL. We might as >> well just pick up that work and use a different underlying delivery if >> the RPS work was considered unacceptable. Perhaps we should leave out the actual mechanisms, and just leave the option for out of band delivery open. :-) >> Sorry. Should have said advertisement. Really, advertisements aren't end-to-end in BGP, either. Any time you're designing something, and have to start making exceptions to the rule for each situation brought up, you should probably go back and rethink the paradigm your using. The AS Path is our favorite "whipping boy," but, in reality, the AS Path is just one attribute among many in BGP, and, like other attributes, the AS Path is mutable. So far, we've discovered: o AS Path Prepend o AS Path Stripping o Aggregation o Local AS At least that change the processing rules for the AS Path, or change the AS Path itself. If we think of the AS Path as being constant end to end, and plan security based on that thinking, then we must think in exceptions to the rule set for each possible modification to the AS Path, and as people think of new ways to modify the AS Path, we have to think of new exceptions to the rules. It seems, to me, that it's easier just not to think of the AS Path as anything more, or less, than an attribute among attributes, all mutable for various reasons. This allows us to stop thinking in terms of an "end-to-end" advertisement, and see BGP for what it really is: A distributed database system in which each device along the way might change the data in subtle or not-so-subtle ways, and for valid reasons. The question then changes from: "Who has touched this," to: "Is the data valid?" Of course, then you have to decide what "valid" means, but, there we digress into a lot of other conversations we've already had, and I don't want to repeat. :-) Going back to the original question: The basic point, to me, is that the validity of the data is not a "true/false" situation. Hence, it's possible that passing information through or around a non-implementing AS, whichever way you want to put it, has potential benefit. There's no way to know that until you actually look at the way the proposed mechanism works, though. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGn2nUER27sUhU9OQRAiXHAJ9l0McWqdsxU3i31TAYp7dornbHCwCgkUfM jYsrkP9U8AStueMDhXT9GrQ= =XNRJ -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 14:27:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaiU-0000uR-L1; Thu, 19 Jul 2007 14:27:10 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBaiT-0000t4-Um for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:27:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaiT-0000sv-5e for rpsec@ietf.org; Thu, 19 Jul 2007 14:27:09 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBaiS-0000vQ-Gn for rpsec@ietf.org; Thu, 19 Jul 2007 14:27:09 -0400 Received: from pc6 (1Cust124.tnt28.lnd4.gbr.da.uu.net [62.188.156.124]) by galaxy.systems.pipex.net (Postfix) with SMTP id 65ED1E000278; Thu, 19 Jul 2007 19:27:04 +0100 (BST) Message-ID: <051901c7ca29$521f4780$0601a8c0@pc6> From: "tom.petch" To: , "Sandy Murphy" References: <200707182101.l6IL172W031766@harbor.brookfield.occnc.com> Subject: Re: [RPSEC] BGP Security Requirements v08 Date: Thu, 19 Jul 2007 16:42:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.4 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org I am very much with Curtis on this one. What he says seems pragmatic engineering, allowing the Internet to evolve to a better place. I would go for a MUST in the protocol at this stage. Tom Petch ----- Original Message ----- From: "Curtis Villamizar" To: "Sandy Murphy" Cc: Sent: Wednesday, July 18, 2007 11:01 PM Subject: Re: [RPSEC] BGP Security Requirements v08 > > In message <20070718194558.D2FBB3F43C@pecan.tislabs.com> > Sandy Murphy writes: > > > > >The major ISPs have important major customers and peer. For example > > >they would not want their routing corrupted by a bad route to a major > > >content provider. Therefore many major providers will only accept > > >these major customer and peer routes from a very limited set of ISPs. > > > > I hear you about the Internet mostly just works. > > > > But we seem to have p-l-e-n-t-y of publically discussed examples of > > cases where the trust structure did not not serve us well. > > > > Furthermore, from what major ISP have said, what is said by others > > about major ISPs and from the analyses of public data of some incidents, > > it seems the case that some major ISPs (Spring comes to mind?) do not > > filter well enough to prevent some noticable traffic redirection. > > These have been accidents so far, but provide worked examples of > > how bad the problem can get. > > > > Relying on the ISP trust and policies is mostly good enough for > > mostly just works. > > > This has been true for over a decade. > > Back in the mid-1990s ANS days two very major incidents occurred. One > was the intentional advertisement of very specific routes into PSI for > every DNS TLD servier. This took out DNS for anyone who beleived > those routes. It did not affect ANS due to IRR policy. Another was > announding critical subnets of AOL. Again that did not affect ANS > since they had specific filters to protect their direct customers and > any peer that wished to register in the IRR. > > Even earlier, Sprint, UUNET, and PSI default routed to the NSFNET. > Someone got a 56K circuit to ANS at a university in the middle east > and announced the NSFNET address. Sprint, UUNET and PSI were a mess > for 10 hours. NSFNET customers were fine (then it was the PRDB). > > There are ways to protect routing today. Not everyone makes use of > them. That's been the case for a very long time. And they are far > from perfect. > > > > >Add some authentication and you may have further improviment in the > > >reliability of routing information. Don't allow that to cross the > > >major ISPs and the authenticaion is of very little use for ISPs. > > > > I agree with you here! But I don't think anyone is talking about > > not allowing auth info to cross major ISPs. We're mostly arguing > > how strong a requirement to make the ability to transit un-upgraded > > ISPs: MUST, SHOULD, or MAY. > > > > --Sandy > > > Some providers may never upgrade. Some mechanism to still pass routes > through them is needed, albiet placing less trust in those routes. > > Curtis > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 15:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRS-0004Fo-0d; Thu, 19 Jul 2007 15:13:38 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBbRQ-0004Cj-Hr for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRQ-0004CS-7h for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbRP-0007r8-UO for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBbRP-0006za-4l; Thu, 19 Jul 2007 15:13:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707182000.l6IK0570030774@harbor.brookfield.occnc.com> References: <200707182000.l6IK0570030774@harbor.brookfield.occnc.com> Date: Thu, 19 Jul 2007 15:06:32 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: rpsec@ietf.org, Sandy Murphy , Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 4:00 PM -0400 7/18/07, Curtis Villamizar wrote: >... >For example, if the AS Path is A X Y Z and I trust my peer A but not X >and Y, the ROA only tells me that its OK for Z to have originated this >route and nothing about whether this could have legitimately passed >through Y and Z. An authentication would be Z signature, Y signing >that, X signing that, and A passing along the signatures. If 128 >bytes are used per signature that is 384 bytes. We really ought not get into details on specific techniques, as Russ noted. For example, if one uses a fancy EEC signature scheme that allow signature aggregation, the total for the three signatures is about 128 bytes. (See the PhD work by Meiyuan Zhao at Dartmouth 2 years ago.) >OTOH if some OOB mechanism also addressed whether a peering might be >legitimate, then requirements would be met. So maybe its just that >the current ROA scheme (or schema) is inadequate. The ROA scheme has a specific purpose, i.e., allowing a resource holder to express an globally-verifiable authorization to originate a route to the holder's prefix(es). ROAs ought not be criticized for not doing something that they are not intended to do. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 15:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRS-0004Fu-81; Thu, 19 Jul 2007 15:13:38 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBbRQ-0004Co-LB for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRQ-0004CY-Ac for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBbRP-000252-VA for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBbRN-0006za-3w; Thu, 19 Jul 2007 15:13:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707181918.l6IJIr3X029859@harbor.brookfield.occnc.com> References: <200707181918.l6IJIr3X029859@harbor.brookfield.occnc.com> Date: Thu, 19 Jul 2007 14:44:50 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org >... > >DDOS attacks are more than a decade old. DDOS is exactly the sort of >practical problem that the security theorists ignored while the >Internet practitioners advocated hardenning. The hardenning had >nothing to do with cryptography and in fact cryptography was >impractical. The security theorists had a very hard time accepting >this and still do, hence our recent discussion on GTSM. It seems that you took my reference to DDoS to mean attacks against BGP session on routers. I was referring to the broader problem of such attacks against subscriber end point or links. In that broad context, almost all of what you say above is not accurate: - security folks noted this potential for such attacks before they occurred - ISPs ignored the warnings because they had not seen the attacks - the security community generated a lot of papers on the topic, some good some bad - a few start up companies were created to deliver technology to address the problem - ... As for GTSM, yes, it is a simple fix for a class of off-link attacks, and there's nothing wrong with that. If ISPs decide to stop there, and not also employ crypto-based mechanisms that addresses on-link (or, more properly on the same L2 net) attacks, that's a local decision based on a perceived threat. However, it still makes sense for the IETF to develop such mechanisms, for those ISPs who do choose to employ them. > I can dig up >plenty of back email dating from the mid-1990s on DOS hardenning and >DDOS hardenning and *practial* and *deployable* protection against >injection of false routing information. A common theme in your comments is "practial [sic] and deployable." There's nothing wrong with those goals, although I would add "secure" as well :-). The problem, of course, is getting agreement on what constitutes practical, deployable, and secure. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 15:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRV-0004JP-Ou; Thu, 19 Jul 2007 15:13:41 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBbRS-0004Ft-5z for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRR-0004Fe-Rg for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbRQ-0007rE-LZ for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBbRQ-0006za-4O; Thu, 19 Jul 2007 15:13:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <469F69D4.2060002@cisco.com> References: <200707191235.l6JCZZWv043998@harbor.brookfield.occnc.com> <469F69D4.2060002@cisco.com> Date: Thu, 19 Jul 2007 15:13:52 -0400 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 9:40 AM -0400 7/19/07, Russ White wrote: >... > >At least that change the processing rules for the AS Path, or change the >AS Path itself. If we think of the AS Path as being constant end to end, >and plan security based on that thinking, then we must think in >exceptions to the rule set for each possible modification to the AS >Path, and as people think of new ways to modify the AS Path, we have to >think of new exceptions to the rules. Of course the path is not an e-2-e constant, since it is legitimate for it to change, in certain ways, as the path info passes through each AS. However, I don't think we believe that all possible changes to the path are legitimate at each hop. That suggests that it may be possible to express what the allowed transformations are and develop mechanisms that allow the recipient of the path info to verify whether the received path is legitimate relative to the transformations that have been applied. >It seems, to me, that it's easier just not to think of the AS Path as >anything more, or less, than an attribute among attributes, all mutable >for various reasons. This allows us to stop thinking in terms of an >"end-to-end" advertisement, and see BGP for what it really is: A >distributed database system in which each device along the way might >change the data in subtle or not-so-subtle ways, and for valid reasons. see comments above that apply here too. >The question then changes from: "Who has touched this," to: "Is the data >valid?" Of course, then you have to decide what "valid" means, but, >there we digress into a lot of other conversations we've already had, >and I don't want to repeat. :-) and yet you are repeating them :-( >Going back to the original question: > >The basic point, to me, is that the validity of the data is not a >"true/false" situation. I don't think we have a string basis to believe that this is undecidable. The examples you cite merely show that it's not trivial, but then routing is not trivial even absent security considerations. >Hence, it's possible that passing information >through or around a non-implementing AS, whichever way you want to put >it, has potential benefit. There's no way to know that until you >actually look at the way the proposed mechanism works, though. I agree that it MAY have benefit (i.e., potential benefit) but since it also might be harmful, or might not be necessary, it seems inappropriate to mandate support for it in our requirements. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 15:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRV-0004Hc-GG; Thu, 19 Jul 2007 15:13:41 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBbRR-0004FK-PA for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRR-0004FB-FM for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbRP-0007r7-T1 for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBbRO-0006za-4w; Thu, 19 Jul 2007 15:13:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707181905.l6IJ5MdD029754@harbor.brookfield.occnc.com> References: <200707181905.l6IJ5MdD029754@harbor.brookfield.occnc.com> Date: Thu, 19 Jul 2007 15:03:12 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 3:05 PM -0400 7/18/07, Curtis Villamizar wrote: >In message >Stephen Kent writes: >> >> >What we are talking about here is prevention of DOS, not protection of >> >secrets. >> >> DoS is the primary concern, but not the only one. Misrouting to >> effect active or passive wiretapping also was cited as a concern in >> RFC 4272 (BGP Security Vulnerabilities Analysis). > > >Steve, > >As a security guy wouldn't you consider relying on routing to protect >secrets to be more than just a slightly bad idea? WRT content disclosure one certainly ought not rely on the path for confidentiality. Hiwever, very little Internet traffic is encrypted today, so it still makes sense to consider this as a valid concern. Moreover, traffic analysis is a confidentiality concern for some folks, e.g., in the DoD. Avoding routes that would cause traffic to pass through an AS where TA might be effected is a reasonable goal as well. >For secure applications you must always assume an insecure channel >even if its in the same building. I have no idea what you're saying above. >With enough snooped data breaking some forms of encryption is >possible so I know what you are getting at. No, you don't :-). >In terms of real world, it might be possible to divert information >that is supposed to go to some major bank from some far away place and >have a go at the SSL encryption but I suspect its orders of magnitudes >easier to take over the client's Windows box and record keystrokes. That's not what I am alluding to, so let's not waste time arguing over what you think I might have said, but didn't really say :-). > > I have to admit that whenever I hear someone argue that a proposed >> security approach is striving for perfection at the expense of >> practicality, I wince. Thus is a reasonable argument in principle, >> but very often folks disagree about what constitutes a practical (or >> impractical) solution, or a what constitutes reasonable threat model, >> etc. So, let;s try to not go down this path as a basis for deciding >> about these requirements, as it is unlikely to be a fruitful wa to >> resolve our disagreements. > >At what point do we set theory aside and look at whether we are >addressing any sort of real world problem? Is your answer "never"? Sounds like you're asking if I have stopped beating my wife yet? :-) SSL/TLS is very widely used, yet it's primary protection is against wiretapping attacks that rarely occur. (It also is supposed to provide authentication that we are connected the the site we think, but the PKI model used with browsers limits the ability to achieve that goal.) In reality, your credit card data is at much greater risk when it arrives at a web server vs. while it is in transit. I believe that the concerns we're addressing here are at least as valid as those addressed by TLS. > > The second argument you cited was not the principle one, but rather >> an example of why mandating this as a requirement might be >> problematic. I think the argument I have made in this and previous >> messages is that there are a number of incremental deployment >> scenarios where the need for the sort of transitive property you cite >> is not needed, and there are scenarios where it could lead to bad >> decisions. > >OK. Lets have some specifics. What deployment scenarios? Where >could transitive behaviour that only applies to selecting among >incompletely authenticated results (and can be administratively >disabled) lead to bad decisions? In a message earlier this week I suggested that a likely deployment scenario might be that big ISPs are the early adopters, followed by their customers. In such instances there are no intermediary ASes to worry about. Your second question seems to be a mix of two things. Let try to re-phrase.: What bad thing might happen if an ISP uses partially verified data to select a path when the only paths he has for the NLRI in question are all unverified? You also add in a parenthetical allusion to the ability to administratively disable something, presumably you mean the ability to turn off checking the verified path data when it is only part of an overall path. A bad thing that might happen is that the ISP might configure the router to automatically prefer any route that has at least SOME verified path components, an easy policy to express, but one that also is naive. Trying to express a more reasonable policy, e.g., one that take into account known "trusted" ASes and a mix of verified and unverified path elements is very complex. We developed a set of policy controls that tried to do this a fee years ago, and decided that the result was so complex as to create more problems than it was worth. We decided that only a simple policy setting, i.e., my peer has security enabled or not, was easy enough to be practical. It seems that many ISPs have trouble predicting the impact of route configuration choices today (c.f. RFC 4264 "BGP Wedgies"). I think it is not unreasonable to extrapolate this sort of experience with complexity to the routing security context and come the the conclusion that we ought not create an environment that makes it likely that folks will have the same problems. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 15:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRS-0004Fu-81; Thu, 19 Jul 2007 15:13:38 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBbRQ-0004Co-LB for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRQ-0004CY-Ac for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBbRP-000252-VA for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBbRN-0006za-3w; Thu, 19 Jul 2007 15:13:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707181918.l6IJIr3X029859@harbor.brookfield.occnc.com> References: <200707181918.l6IJIr3X029859@harbor.brookfield.occnc.com> Date: Thu, 19 Jul 2007 14:44:50 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org >... > >DDOS attacks are more than a decade old. DDOS is exactly the sort of >practical problem that the security theorists ignored while the >Internet practitioners advocated hardenning. The hardenning had >nothing to do with cryptography and in fact cryptography was >impractical. The security theorists had a very hard time accepting >this and still do, hence our recent discussion on GTSM. It seems that you took my reference to DDoS to mean attacks against BGP session on routers. I was referring to the broader problem of such attacks against subscriber end point or links. In that broad context, almost all of what you say above is not accurate: - security folks noted this potential for such attacks before they occurred - ISPs ignored the warnings because they had not seen the attacks - the security community generated a lot of papers on the topic, some good some bad - a few start up companies were created to deliver technology to address the problem - ... As for GTSM, yes, it is a simple fix for a class of off-link attacks, and there's nothing wrong with that. If ISPs decide to stop there, and not also employ crypto-based mechanisms that addresses on-link (or, more properly on the same L2 net) attacks, that's a local decision based on a perceived threat. However, it still makes sense for the IETF to develop such mechanisms, for those ISPs who do choose to employ them. > I can dig up >plenty of back email dating from the mid-1990s on DOS hardenning and >DDOS hardenning and *practial* and *deployable* protection against >injection of false routing information. A common theme in your comments is "practial [sic] and deployable." There's nothing wrong with those goals, although I would add "secure" as well :-). The problem, of course, is getting agreement on what constitutes practical, deployable, and secure. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 15:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRV-0004JP-Ou; Thu, 19 Jul 2007 15:13:41 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBbRS-0004Ft-5z for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRR-0004Fe-Rg for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbRQ-0007rE-LZ for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBbRQ-0006za-4O; Thu, 19 Jul 2007 15:13:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <469F69D4.2060002@cisco.com> References: <200707191235.l6JCZZWv043998@harbor.brookfield.occnc.com> <469F69D4.2060002@cisco.com> Date: Thu, 19 Jul 2007 15:13:52 -0400 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 9:40 AM -0400 7/19/07, Russ White wrote: >... > >At least that change the processing rules for the AS Path, or change the >AS Path itself. If we think of the AS Path as being constant end to end, >and plan security based on that thinking, then we must think in >exceptions to the rule set for each possible modification to the AS >Path, and as people think of new ways to modify the AS Path, we have to >think of new exceptions to the rules. Of course the path is not an e-2-e constant, since it is legitimate for it to change, in certain ways, as the path info passes through each AS. However, I don't think we believe that all possible changes to the path are legitimate at each hop. That suggests that it may be possible to express what the allowed transformations are and develop mechanisms that allow the recipient of the path info to verify whether the received path is legitimate relative to the transformations that have been applied. >It seems, to me, that it's easier just not to think of the AS Path as >anything more, or less, than an attribute among attributes, all mutable >for various reasons. This allows us to stop thinking in terms of an >"end-to-end" advertisement, and see BGP for what it really is: A >distributed database system in which each device along the way might >change the data in subtle or not-so-subtle ways, and for valid reasons. see comments above that apply here too. >The question then changes from: "Who has touched this," to: "Is the data >valid?" Of course, then you have to decide what "valid" means, but, >there we digress into a lot of other conversations we've already had, >and I don't want to repeat. :-) and yet you are repeating them :-( >Going back to the original question: > >The basic point, to me, is that the validity of the data is not a >"true/false" situation. I don't think we have a string basis to believe that this is undecidable. The examples you cite merely show that it's not trivial, but then routing is not trivial even absent security considerations. >Hence, it's possible that passing information >through or around a non-implementing AS, whichever way you want to put >it, has potential benefit. There's no way to know that until you >actually look at the way the proposed mechanism works, though. I agree that it MAY have benefit (i.e., potential benefit) but since it also might be harmful, or might not be necessary, it seems inappropriate to mandate support for it in our requirements. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 15:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRV-0004Hc-GG; Thu, 19 Jul 2007 15:13:41 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBbRR-0004FK-PA for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRR-0004FB-FM for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbRP-0007r7-T1 for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBbRO-0006za-4w; Thu, 19 Jul 2007 15:13:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707181905.l6IJ5MdD029754@harbor.brookfield.occnc.com> References: <200707181905.l6IJ5MdD029754@harbor.brookfield.occnc.com> Date: Thu, 19 Jul 2007 15:03:12 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 3:05 PM -0400 7/18/07, Curtis Villamizar wrote: >In message >Stephen Kent writes: >> >> >What we are talking about here is prevention of DOS, not protection of >> >secrets. >> >> DoS is the primary concern, but not the only one. Misrouting to >> effect active or passive wiretapping also was cited as a concern in >> RFC 4272 (BGP Security Vulnerabilities Analysis). > > >Steve, > >As a security guy wouldn't you consider relying on routing to protect >secrets to be more than just a slightly bad idea? WRT content disclosure one certainly ought not rely on the path for confidentiality. Hiwever, very little Internet traffic is encrypted today, so it still makes sense to consider this as a valid concern. Moreover, traffic analysis is a confidentiality concern for some folks, e.g., in the DoD. Avoding routes that would cause traffic to pass through an AS where TA might be effected is a reasonable goal as well. >For secure applications you must always assume an insecure channel >even if its in the same building. I have no idea what you're saying above. >With enough snooped data breaking some forms of encryption is >possible so I know what you are getting at. No, you don't :-). >In terms of real world, it might be possible to divert information >that is supposed to go to some major bank from some far away place and >have a go at the SSL encryption but I suspect its orders of magnitudes >easier to take over the client's Windows box and record keystrokes. That's not what I am alluding to, so let's not waste time arguing over what you think I might have said, but didn't really say :-). > > I have to admit that whenever I hear someone argue that a proposed >> security approach is striving for perfection at the expense of >> practicality, I wince. Thus is a reasonable argument in principle, >> but very often folks disagree about what constitutes a practical (or >> impractical) solution, or a what constitutes reasonable threat model, >> etc. So, let;s try to not go down this path as a basis for deciding >> about these requirements, as it is unlikely to be a fruitful wa to >> resolve our disagreements. > >At what point do we set theory aside and look at whether we are >addressing any sort of real world problem? Is your answer "never"? Sounds like you're asking if I have stopped beating my wife yet? :-) SSL/TLS is very widely used, yet it's primary protection is against wiretapping attacks that rarely occur. (It also is supposed to provide authentication that we are connected the the site we think, but the PKI model used with browsers limits the ability to achieve that goal.) In reality, your credit card data is at much greater risk when it arrives at a web server vs. while it is in transit. I believe that the concerns we're addressing here are at least as valid as those addressed by TLS. > > The second argument you cited was not the principle one, but rather >> an example of why mandating this as a requirement might be >> problematic. I think the argument I have made in this and previous >> messages is that there are a number of incremental deployment >> scenarios where the need for the sort of transitive property you cite >> is not needed, and there are scenarios where it could lead to bad >> decisions. > >OK. Lets have some specifics. What deployment scenarios? Where >could transitive behaviour that only applies to selecting among >incompletely authenticated results (and can be administratively >disabled) lead to bad decisions? In a message earlier this week I suggested that a likely deployment scenario might be that big ISPs are the early adopters, followed by their customers. In such instances there are no intermediary ASes to worry about. Your second question seems to be a mix of two things. Let try to re-phrase.: What bad thing might happen if an ISP uses partially verified data to select a path when the only paths he has for the NLRI in question are all unverified? You also add in a parenthetical allusion to the ability to administratively disable something, presumably you mean the ability to turn off checking the verified path data when it is only part of an overall path. A bad thing that might happen is that the ISP might configure the router to automatically prefer any route that has at least SOME verified path components, an easy policy to express, but one that also is naive. Trying to express a more reasonable policy, e.g., one that take into account known "trusted" ASes and a mix of verified and unverified path elements is very complex. We developed a set of policy controls that tried to do this a fee years ago, and decided that the result was so complex as to create more problems than it was worth. We decided that only a simple policy setting, i.e., my peer has security enabled or not, was easy enough to be practical. It seems that many ISPs have trouble predicting the impact of route configuration choices today (c.f. RFC 4264 "BGP Wedgies"). I think it is not unreasonable to extrapolate this sort of experience with complexity to the routing security context and come the the conclusion that we ought not create an environment that makes it likely that folks will have the same problems. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 15:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRS-0004Fu-81; Thu, 19 Jul 2007 15:13:38 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBbRQ-0004Co-LB for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRQ-0004CY-Ac for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBbRP-000252-VA for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:36 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBbRN-0006za-3w; Thu, 19 Jul 2007 15:13:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707181918.l6IJIr3X029859@harbor.brookfield.occnc.com> References: <200707181918.l6IJIr3X029859@harbor.brookfield.occnc.com> Date: Thu, 19 Jul 2007 14:44:50 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org >... > >DDOS attacks are more than a decade old. DDOS is exactly the sort of >practical problem that the security theorists ignored while the >Internet practitioners advocated hardenning. The hardenning had >nothing to do with cryptography and in fact cryptography was >impractical. The security theorists had a very hard time accepting >this and still do, hence our recent discussion on GTSM. It seems that you took my reference to DDoS to mean attacks against BGP session on routers. I was referring to the broader problem of such attacks against subscriber end point or links. In that broad context, almost all of what you say above is not accurate: - security folks noted this potential for such attacks before they occurred - ISPs ignored the warnings because they had not seen the attacks - the security community generated a lot of papers on the topic, some good some bad - a few start up companies were created to deliver technology to address the problem - ... As for GTSM, yes, it is a simple fix for a class of off-link attacks, and there's nothing wrong with that. If ISPs decide to stop there, and not also employ crypto-based mechanisms that addresses on-link (or, more properly on the same L2 net) attacks, that's a local decision based on a perceived threat. However, it still makes sense for the IETF to develop such mechanisms, for those ISPs who do choose to employ them. > I can dig up >plenty of back email dating from the mid-1990s on DOS hardenning and >DDOS hardenning and *practial* and *deployable* protection against >injection of false routing information. A common theme in your comments is "practial [sic] and deployable." There's nothing wrong with those goals, although I would add "secure" as well :-). The problem, of course, is getting agreement on what constitutes practical, deployable, and secure. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 15:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRV-0004JP-Ou; Thu, 19 Jul 2007 15:13:41 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBbRS-0004Ft-5z for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRR-0004Fe-Rg for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbRQ-0007rE-LZ for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBbRQ-0006za-4O; Thu, 19 Jul 2007 15:13:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <469F69D4.2060002@cisco.com> References: <200707191235.l6JCZZWv043998@harbor.brookfield.occnc.com> <469F69D4.2060002@cisco.com> Date: Thu, 19 Jul 2007 15:13:52 -0400 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 9:40 AM -0400 7/19/07, Russ White wrote: >... > >At least that change the processing rules for the AS Path, or change the >AS Path itself. If we think of the AS Path as being constant end to end, >and plan security based on that thinking, then we must think in >exceptions to the rule set for each possible modification to the AS >Path, and as people think of new ways to modify the AS Path, we have to >think of new exceptions to the rules. Of course the path is not an e-2-e constant, since it is legitimate for it to change, in certain ways, as the path info passes through each AS. However, I don't think we believe that all possible changes to the path are legitimate at each hop. That suggests that it may be possible to express what the allowed transformations are and develop mechanisms that allow the recipient of the path info to verify whether the received path is legitimate relative to the transformations that have been applied. >It seems, to me, that it's easier just not to think of the AS Path as >anything more, or less, than an attribute among attributes, all mutable >for various reasons. This allows us to stop thinking in terms of an >"end-to-end" advertisement, and see BGP for what it really is: A >distributed database system in which each device along the way might >change the data in subtle or not-so-subtle ways, and for valid reasons. see comments above that apply here too. >The question then changes from: "Who has touched this," to: "Is the data >valid?" Of course, then you have to decide what "valid" means, but, >there we digress into a lot of other conversations we've already had, >and I don't want to repeat. :-) and yet you are repeating them :-( >Going back to the original question: > >The basic point, to me, is that the validity of the data is not a >"true/false" situation. I don't think we have a string basis to believe that this is undecidable. The examples you cite merely show that it's not trivial, but then routing is not trivial even absent security considerations. >Hence, it's possible that passing information >through or around a non-implementing AS, whichever way you want to put >it, has potential benefit. There's no way to know that until you >actually look at the way the proposed mechanism works, though. I agree that it MAY have benefit (i.e., potential benefit) but since it also might be harmful, or might not be necessary, it seems inappropriate to mandate support for it in our requirements. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 15:13:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRV-0004Hc-GG; Thu, 19 Jul 2007 15:13:41 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBbRR-0004FK-PA for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbRR-0004FB-FM for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbRP-0007r7-T1 for rpsec@ietf.org; Thu, 19 Jul 2007 15:13:37 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBbRO-0006za-4w; Thu, 19 Jul 2007 15:13:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707181905.l6IJ5MdD029754@harbor.brookfield.occnc.com> References: <200707181905.l6IJ5MdD029754@harbor.brookfield.occnc.com> Date: Thu, 19 Jul 2007 15:03:12 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 3:05 PM -0400 7/18/07, Curtis Villamizar wrote: >In message >Stephen Kent writes: >> >> >What we are talking about here is prevention of DOS, not protection of >> >secrets. >> >> DoS is the primary concern, but not the only one. Misrouting to >> effect active or passive wiretapping also was cited as a concern in >> RFC 4272 (BGP Security Vulnerabilities Analysis). > > >Steve, > >As a security guy wouldn't you consider relying on routing to protect >secrets to be more than just a slightly bad idea? WRT content disclosure one certainly ought not rely on the path for confidentiality. Hiwever, very little Internet traffic is encrypted today, so it still makes sense to consider this as a valid concern. Moreover, traffic analysis is a confidentiality concern for some folks, e.g., in the DoD. Avoding routes that would cause traffic to pass through an AS where TA might be effected is a reasonable goal as well. >For secure applications you must always assume an insecure channel >even if its in the same building. I have no idea what you're saying above. >With enough snooped data breaking some forms of encryption is >possible so I know what you are getting at. No, you don't :-). >In terms of real world, it might be possible to divert information >that is supposed to go to some major bank from some far away place and >have a go at the SSL encryption but I suspect its orders of magnitudes >easier to take over the client's Windows box and record keystrokes. That's not what I am alluding to, so let's not waste time arguing over what you think I might have said, but didn't really say :-). > > I have to admit that whenever I hear someone argue that a proposed >> security approach is striving for perfection at the expense of >> practicality, I wince. Thus is a reasonable argument in principle, >> but very often folks disagree about what constitutes a practical (or >> impractical) solution, or a what constitutes reasonable threat model, >> etc. So, let;s try to not go down this path as a basis for deciding >> about these requirements, as it is unlikely to be a fruitful wa to >> resolve our disagreements. > >At what point do we set theory aside and look at whether we are >addressing any sort of real world problem? Is your answer "never"? Sounds like you're asking if I have stopped beating my wife yet? :-) SSL/TLS is very widely used, yet it's primary protection is against wiretapping attacks that rarely occur. (It also is supposed to provide authentication that we are connected the the site we think, but the PKI model used with browsers limits the ability to achieve that goal.) In reality, your credit card data is at much greater risk when it arrives at a web server vs. while it is in transit. I believe that the concerns we're addressing here are at least as valid as those addressed by TLS. > > The second argument you cited was not the principle one, but rather >> an example of why mandating this as a requirement might be >> problematic. I think the argument I have made in this and previous >> messages is that there are a number of incremental deployment >> scenarios where the need for the sort of transitive property you cite >> is not needed, and there are scenarios where it could lead to bad >> decisions. > >OK. Lets have some specifics. What deployment scenarios? Where >could transitive behaviour that only applies to selecting among >incompletely authenticated results (and can be administratively >disabled) lead to bad decisions? In a message earlier this week I suggested that a likely deployment scenario might be that big ISPs are the early adopters, followed by their customers. In such instances there are no intermediary ASes to worry about. Your second question seems to be a mix of two things. Let try to re-phrase.: What bad thing might happen if an ISP uses partially verified data to select a path when the only paths he has for the NLRI in question are all unverified? You also add in a parenthetical allusion to the ability to administratively disable something, presumably you mean the ability to turn off checking the verified path data when it is only part of an overall path. A bad thing that might happen is that the ISP might configure the router to automatically prefer any route that has at least SOME verified path components, an easy policy to express, but one that also is naive. Trying to express a more reasonable policy, e.g., one that take into account known "trusted" ASes and a mix of verified and unverified path elements is very complex. We developed a set of policy controls that tried to do this a fee years ago, and decided that the result was so complex as to create more problems than it was worth. We decided that only a simple policy setting, i.e., my peer has security enabled or not, was easy enough to be practical. It seems that many ISPs have trouble predicting the impact of route configuration choices today (c.f. RFC 4264 "BGP Wedgies"). I think it is not unreasonable to extrapolate this sort of experience with complexity to the routing security context and come the the conclusion that we ought not create an environment that makes it likely that folks will have the same problems. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 22:40:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBiPx-0007vi-OC; Thu, 19 Jul 2007 22:40:33 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBiPw-0007uE-Bb for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 22:40:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBiPv-0007tb-W0 for rpsec@ietf.org; Thu, 19 Jul 2007 22:40:31 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBiPu-0002Jv-HS for rpsec@ietf.org; Thu, 19 Jul 2007 22:40:31 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6K2f7w6055015; Thu, 19 Jul 2007 22:41:07 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707200241.l6K2f7w6055015@harbor.brookfield.occnc.com> To: Stephen Kent From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Thu, 19 Jul 2007 14:44:50 EDT." Date: Thu, 19 Jul 2007 22:41:07 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Stephen Kent writes: > > A common theme in your comments is "practial [sic] and deployable." > There's nothing wrong with those goals, although I would add "secure" > as well :-). The problem, of course, is getting agreement on what > constitutes practical, deployable, and secure. > > Steve Practical and deployable should be goals if we want to see something deployed. Secure where there is no portion of the path containing non-participant AS should be a goal. Providing indication of better confidence with certain semi-trusted non-participant AS in the path should be a goal. Regarding Russ' comments: OOB is not excluded but any OOB solution must meet requirements regarding AS Path, not just origin AS. Do we have agreement? Curtis ps - If you are talking about general DDoS attacks, providers knew this was possible. They would rather see Bill Gates hung for providing the insecure OS that made DDoS bots so easy to implement. The point was that not much can be done from the provider's standpoint for DDoS to end sites. Now if the Feds confiscated PCs involved in attacks, spam, etc, sent the PCs back to the supplier to apply patches, returned the PCs, and sent the bill for the investigation to the OS vendor, we'd have the problems all solved. :-) Users of free or homegrown OS would have to apply patches themselved before bringing computers online again. [No chance of this happenning - just a dream.] _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 19 22:45:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBiUt-0002Cq-OA; Thu, 19 Jul 2007 22:45:39 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBiUs-0002Cc-KZ for rpsec-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 22:45:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBiUs-0002C0-7W for rpsec@ietf.org; Thu, 19 Jul 2007 22:45:38 -0400 Received: from 69.37.59.172.adsl.snet.net ([69.37.59.172] helo=harbor.brookfield.occnc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBiUr-0005VQ-SA for rpsec@ietf.org; Thu, 19 Jul 2007 22:45:38 -0400 Received: from harbor.brookfield.occnc.com (harbor.brookfield.occnc.com [69.37.59.172]) by harbor.brookfield.occnc.com (8.13.6/8.13.6) with ESMTP id l6K2kOPa055104; Thu, 19 Jul 2007 22:46:25 -0400 (EDT) (envelope-from curtis@harbor.brookfield.occnc.com) Message-Id: <200707200246.l6K2kOPa055104@harbor.brookfield.occnc.com> To: Stephen Kent From: Curtis Villamizar Subject: Re: [RPSEC] BGP Security Requirements v08 In-reply-to: Your message of "Thu, 19 Jul 2007 15:06:32 EDT." Date: Thu, 19 Jul 2007 22:46:24 -0400 X-Spam-Score: 1.7 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Sandy Murphy , rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Stephen Kent writes: > > The ROA scheme has a specific purpose, i.e., allowing a resource > holder to express an globally-verifiable authorization to originate a > route to the holder's prefix(es). ROAs ought not be criticized for > not doing something that they are not intended to do. > > Steve ROA should be criticized for a major ommission relative to an existing scheme it is expecting to replace. But we're off topic. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 20 10:36:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtZV-0000Uc-5K; Fri, 20 Jul 2007 10:35:09 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IBtZT-0000Oh-D0 for rpsec-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 10:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtZT-0000OS-3W for rpsec@ietf.org; Fri, 20 Jul 2007 10:35:07 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBtZS-0000CS-S8 for rpsec@ietf.org; Fri, 20 Jul 2007 10:35:07 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IBtZS-0003aW-4Q; Fri, 20 Jul 2007 10:35:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707200246.l6K2kOPa055104@harbor.brookfield.occnc.com> References: <200707200246.l6K2kOPa055104@harbor.brookfield.occnc.com> Date: Fri, 20 Jul 2007 09:59:02 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Sandy Murphy , rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 10:46 PM -0400 7/19/07, Curtis Villamizar wrote: >In message >Stephen Kent writes: >> >> The ROA scheme has a specific purpose, i.e., allowing a resource >> holder to express an globally-verifiable authorization to originate a >> route to the holder's prefix(es). ROAs ought not be criticized for >> not doing something that they are not intended to do. >> >> Steve > > >ROA should be criticized for a major ommission relative to an existing >scheme it is expecting to replace. But we're off topic. > >Curtis Perhaps more accurately, we're talking about this in the wrong WG. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 20 17:46:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0JF-0006sD-8C; Fri, 20 Jul 2007 17:46:49 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IC0JD-0006s8-UE for rpsec-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 17:46:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC0JD-0006s0-Jb for rpsec@ietf.org; Fri, 20 Jul 2007 17:46:47 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IC0JD-0002rv-4q for rpsec@ietf.org; Fri, 20 Jul 2007 17:46:47 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IC0JC-00026o-4r; Fri, 20 Jul 2007 17:46:46 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200707200241.l6K2f7w6055015@harbor.brookfield.occnc.com> References: <200707200241.l6K2f7w6055015@harbor.brookfield.occnc.com> Date: Fri, 20 Jul 2007 17:47:08 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements v08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 10:41 PM -0400 7/19/07, Curtis Villamizar wrote: >In message >Stephen Kent writes: >> >> A common theme in your comments is "practial [sic] and deployable." >> There's nothing wrong with those goals, although I would add "secure" >> as well :-). The problem, of course, is getting agreement on what >> constitutes practical, deployable, and secure. >> >> Steve > > >Practical and deployable should be goals if we want to see something >deployed. I'd list security at the same level as practical and deployable, i.e., without further qualification, since the whole purpose of this requirements document is security. >Secure where there is no portion of the path containing >non-participant AS should be a goal. I think we can agree on something of this sort, perhaps with revised wording. >Providing indication of better confidence with certain semi-trusted >non-participant AS in the path should be a goal. We don't agree on this point, if the goal translates into a MUST, for the reasons we've discussed in previous exchanges. >Regarding Russ' comments: OOB is not excluded but any OOB solution >must meet requirements regarding AS Path, not just origin AS. The problem with OOB is one of timeliness. For origin AS there seems to be agreement that the binding between a prefix holder and the origin AS is fairly stable, so OOB distribution of this data is OK< at least most of the time. There has been less agreement about whether the bindings between successive hops in a path are sufficiently static, and limited in fanout, to make OOB distribution acceptable. For example, OOB distribution can provide a set of routes that might be "legitimate" based on transitive closure, but that set may be bigger that the set of routes that are ever advertised. At best, the set of routes generally will be bigger that what is currently being advertised. In some contexts that may be adequate. In other contexts the set may be so big as to not provide acceptable security. That's why the question of OOB distribution is not an easy one to answer. >Do we have agreement? not exactly. >Curtis > > >ps - If you are talking about general DDoS attacks, providers knew >this was possible. They would rather see Bill Gates hung for >providing the insecure OS that made DDoS bots so easy to implement. Maybe fair wish (said the Mac user :-)), but from a security standpoint that's not a great strategy anyway. The fact that there are lots of vulnerable machines that can be turned into zombies makes this problem especially bad, but one would never want to rely on good security practices by every user as a defense anyway. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Jul 21 01:25:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC7So-0007zT-QV; Sat, 21 Jul 2007 01:25:10 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IC7Sm-0007zN-Vn for rpsec-confirm+ok@megatron.ietf.org; Sat, 21 Jul 2007 01:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IC7Sm-0007zB-6Q for rpsec@ietf.org; Sat, 21 Jul 2007 01:25:08 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IC7Sk-0000N5-Mb for rpsec@ietf.org; Sat, 21 Jul 2007 01:25:08 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l6L5P6D1005041 for ; Fri, 20 Jul 2007 22:25:06 -0700 Received: (from ttauber@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l6L5P5V0005040 for rpsec@ietf.org; Fri, 20 Jul 2007 22:25:05 -0700 Date: Fri, 20 Jul 2007 22:25:05 -0700 From: Tony Tauber To: rpsec@ietf.org Message-ID: <20070721052505.GD12344@1-4-5.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [RPSEC] Agenda for IETF-69 (Chicago) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Routing Protocol Security Requirements WG (rpsec) Tuesday, July 24 at 1850-1950 State Ballroom ============================================ CHAIRS: Russ White Tony Tauber AGENDA: Agenda Bashing and Administrivia BGP Security Requirements draft-ietf-rpsec-bgpsecrec-08 T. Tauber BGP Session Security draft-behringer-bgp-session-sec-req-01 M. Behringer OSPFv3 Automated Group Keying Requirements draft-liu-ospfv3-automated-keying-req-01.txt Y. Liu _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 24 11:14:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM5g-0005Ml-Il; Tue, 24 Jul 2007 11:14:24 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IDM5f-0005MS-Am for rpsec-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:14:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM5e-0005MJ-W9 for rpsec@ietf.org; Tue, 24 Jul 2007 11:14:23 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDM5e-0004St-8c for rpsec@ietf.org; Tue, 24 Jul 2007 11:14:22 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.28.170.76]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IDM5c-0000e9-65 for rpsec@ietf.org; Tue, 24 Jul 2007 11:14:21 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 24 Jul 2007 11:14:42 -0400 To: rpsec@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [RPSEC] one more comment on MUST/SHOULD/MAY X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Folks, Michael Behringer and I spoke this morning at breakfast, and he suggested that I clarify my arguments re the choice of requirements wording in the BGP security requirements draft. I will not be at this evening's RPSEC meeting, otherwise I would present the arguments in person. I have two arguments against the use of MUST in Section 4.2: "A BGP security mechanism MUST provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non-backward compatible fashion though care must be taken to ensure UPDATES can traverse intermediate routers which don't support the new format." The first argument is that we have discussed plausible deployment scenarios in which participating ASes are all contiguous. For example, larger ISPs deploy might deploy a solution first, then their ISP clients, etc. In such contexts there is no need for the requirement imposed above, and imposing this requirement on solutions might added needless complexity in such deployment scenarios. The second argument is that even if non-contiguous deployment does take place, it is not clear that security is improved by providing ASes with the ability to make decisions about the relative security of paths for which there is a mix of verified and unverified path elements. An example ma help here. Assume that A, B, C, and D are ASes that have deployed a BGP security technology, and X, Y, and Z have not. AS A might receive two paths for a prefix originated by AS C: C->X->Y->A and C->B->Z->A. Both paths are the same length, but the second contains an AS that has verified path info, where the former has none. Does that make the second path more trustworthy than the first? Not necessarily. If AS A tries to create policy that takes into account parameters such as the number of verified ASes in a path, rather than just making individual value judgments about the ASes in question, it may be in for a rude awakening. Experience in the security arena has show that individuals do a bad job of making such judgments. Experience on the routing arena would seem to confirm the applicability of this notion in this context, as indicated by the BG Wedgies RFC. Thus my preference would be for us to reword this text in 4.2 to be a MAY. Such wording would say that a proposed solution can include provisions for passing security info through ASes that are not aware of new message formats, or it may not. The presence or absence of such a capability would not affect the evaluation of the solution relative to this criteria. If we stick with a MUST here, then we are saying that we anticipate deployment scenarios that will involve a non-trivial number of non-contiguous ASes that adopt a solution, AND we are convinced that the operators of these ASes are better off having an ability to use some (locally defined?) algorithm to select between two or more paths when all of the paths contain some amount of unverified data. Based on our discussions, I don't see these two premises being satisfied with high probability. Using SHOULD as a compromise is an odd choice here. SHOULD is intended to be used in standards when they talk about implementations of the standard; we are talking not about criteria for judging a standard, not an implementation. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 24 20:53:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDV7b-00021M-Nh; Tue, 24 Jul 2007 20:52:59 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IDV7Z-00021F-NG for rpsec-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 20:52:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDV7Z-000216-4M for rpsec@ietf.org; Tue, 24 Jul 2007 20:52:57 -0400 Received: from mint.apnic.net ([202.12.29.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDV7X-0002WU-Ix for rpsec@ietf.org; Tue, 24 Jul 2007 20:52:56 -0400 Received: from [130.129.23.125] (dhcp-177d.ietf69.org [130.129.23.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id BA93FD5F35; Wed, 25 Jul 2007 10:52:52 +1000 (EST) Message-ID: <46A69F57.4030808@apnic.net> Date: Wed, 25 Jul 2007 10:54:47 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: rpsec@ietf.org, Geoff Huston , ttauber@1-4-5.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: Subject: [RPSEC] Notes from IETF69 WG session X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Routing Protocol Security Requirements WG (rpsec) Tuesday, July 24 at 1850-1950 State Ballroom ============================================ CHAIRS: Russ White Tony Tauber AGENDA: Agenda Bashing and Administrivia BGP Security Requirements draft-ietf-rpsec-bgpsecrec-08 T. Tauber BGP Session Security draft-behringer-bgp-session-sec-req-01 M. Behringer OSPFv3 Automated Group Keying Requirements draft-liu-ospfv3-automated-keying-req-01.txt Y. Liu Notes 0. No changes to the Agenda 1. BGP Security Requirements [slides] Tony noted that the SIDR WG is posed to work on consensus items as provided by RPSEC. Originating AS Authorization appears to have WG consensus. Transport Layer Protection is also ok Noted that section 4.2 (Incremental Deployment) of the draft there is a "MUST" regarding useful non-contiguous deployment. Should it be a MAY that information be propagated opaquely. Or SHOULD? Or a MUST? Is this burdensome to legacy ASs? RFC4271, sec9, para 2 describes treatment here. Do users want unclear validity data, or is it open to misinterpretation? Section 7 refers to the "special Note" in the text about the lack of consensus on a number of items. It was proposed to change this text to note a requirement to revisit this in the future. comments on section 7: Geoff Huston commented that the original version was unhelpful Sandy Murphy noted that she was happy to have this as a revision. Noted that there is still a MUST and a SHOULD is still confusing, and proposes to leave the text without the MUST and SHOULD Dave Ward commented that the document cannot progress without consensus, and if the document states that there is no consensus than this is contradictory. Suggest to change the normative text to a wording of "may in the future" Comments on section 4.2: Dave Ward commented on traversing legacy systems noted we have existing technology that uses optional transitive information in 4 byte AS support, so the question of whether it could work is demonstrated to work in the 4 Byte context. Sandy Murphy pointed out that the the MAY SHOULD or MUST does not refer to any specific mechanism. Dave Ward noted that RFC4271 noted that there was normative language there about this, and this could be used in the context of this document by reference. John Scudder agreed with the end statement that BGP RFC is fine here. The propagation can allow the side that understands the propagation can filter it. John noted that the alternative text with respect to the special note was a way to go forward. With respect to propagation question: Geoff Huston noted that there are two types of propagated information: incrementally altered and unaltered. In the case of unaltered information partial propagation is fine, but the incremental information is less clear. John - just ignore is fine Michael Behringer - ignore ie basically fine, but its more complex Sandy - one case is more complex it it passes and the other is more complex if it does not - it is really up to the nature of the information itself and yes or no a priori is hard so MUST is too strong and MUST NOT is too strong. MAY or SHOULD is probably reaonsable as a general position. Geoff Huston - with these document revisions, does this get us to the point of a WSGLC? Tony: Yes, I think so, but I'll consult with my co-chair. 2. BGP Session Security Requirements [slides] Jo Touch refered to a Bellovin document that was relevant to session security and questioned whether there was a need for two documents on this topic. Michael Behringer noted that he referenced the Bellovin document in this RPSEC draft, but would recheck this. Jo Touch noted requirements to limit TCP header space, and processing overhead of packets on the outbound and inbound path in the other draft. Jo Touch: BGP currently is inherently dependent on TCP for notification of peer 'liveness' and its important to note that the RFC that describes the reset attack is coming out as RFC 4953 notes that there is a need for protection of incoming spoofed segments at the TCP connection level as well as the BGP level. i.e. this Transport Area document does cover this in some detail Micheal noted that the various protection mechanisms exist at various levels in the protocol stack, and that this document will be referenced. Jo Touch: What did we miss in the Transport area? Maybe you should check that we have referenced all these documents, and the Bellovin document (draft-bellovin-tcpsec) Michael will check that this work approrpiate references the transport area work. Sandy Murphy noted that the section on avaibility and restricting IP appeared to be solutions rather than requirements, and the requirement is about something other than solutions (Jo Touch volunteered to offer text) Micheal noted that the document should also state that these sort of things (such as fragements) "must be handled" Jo notes that the requirement is "an efficient way of dropping non-session packets". This is actually general advice about sessions and operational issues to avoid session attacks Michael noted that the whole point of the draft was to head away from a single defence mechanism to look at a broader spectrum of requirements Jo Touch noted that the work in Transport for transport protections was intended to be generic in the sense that this was intended to protect applications that include BGP. Michael noted that the point of the draft was to capture the difference facets of BGP. Jo suggest that as a requirement for a protocol the Transport activity is in this space already and a BCP on when and why to use different mechanisms as advice to BGP deployers Michael: Then the To DO list item was bogus in the first place? The value of the document was to go beyond single mechanisms and look at this at a broad set of requirements, but if the transport area is already working here...? Itojun: why is IPSEC not specifically mentioned in other areas? Michael: requirements rather than solutions is the point here Michael will review the Bellovin draft and judge the extent of overlap Sandy Murphy noted that there was not much overlap as the emphasis of requirements was quite distinct here - TCP and BGP centric approaches are distinct here. Jo: whats the issue here? If you want to protect the data then there are choices in one dimension, but if you want to protect TCP as well as data then this is different. There is overlap in the areas of protection of the data layer, but there are issues of identity in BGP here that are not part of the TCP document. I'm not referring to the entire document, but more the specific areas of the data layer. Illijtsch van Beijnum: wondering about key management issues for MD5 for BGP - whatever happened to this work? The issue is important in terms of keys, identity, storage, and similar. Michael: this document is about solutions and cases, not requirements and mechanisms. Illijtsch van Beijnum: physical security is a relevant consideration here. Sandy Murphy: operational concerns about security for BGP also refers to Pekka Savola's draft about protecting network backbones was well received in the various working groups where it was presented, but current status of this document is unknown. This is nothing to do with this draft Followup Actions: - check this draft for extent of overlap with Bellovin document - then poll the WG regarding adoption of this draft as a WG document 3. OSPFv3 Automated Group Keying Requirements [slides] [note taker had to leave at this point...... Baton passed back to chair] _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 25 17:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo4H-0001vk-A0; Wed, 25 Jul 2007 17:06:49 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IDo4G-0001ve-MT for rpsec-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 17:06:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo4G-0001vR-Bc for rpsec@ietf.org; Wed, 25 Jul 2007 17:06:48 -0400 Received: from m106.maoz.com ([205.167.76.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDo4F-0001B6-Sh for rpsec@ietf.org; Wed, 25 Jul 2007 17:06:48 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l6PL6fLH015286; Wed, 25 Jul 2007 14:06:41 -0700 Received: (from ttauber@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l6PL6fxn015285; Wed, 25 Jul 2007 14:06:41 -0700 Date: Wed, 25 Jul 2007 14:06:41 -0700 From: Tony Tauber To: Geoff Huston Message-ID: <20070725210641.GN12344@1-4-5.net> References: <46A69F57.4030808@apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A69F57.4030808@apnic.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: rpsec@ietf.org Subject: [RPSEC] Re: Notes from IETF69 WG session X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Thanks, Geoff for taking notes. I merged in some others and posted them at http://www3.ietf.org/proceedings/07jul/minutes/rpsec.txt. Send any comments or corrections soon, please. Cheers, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 25 17:15:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDoCs-0007rW-8i; Wed, 25 Jul 2007 17:15:42 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IDoCr-0007rR-Eu for rpsec-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 17:15:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDoCr-0007rG-3R for rpsec@ietf.org; Wed, 25 Jul 2007 17:15:41 -0400 Received: from m106.maoz.com ([205.167.76.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDoCq-0001Mu-Jl for rpsec@ietf.org; Wed, 25 Jul 2007 17:15:41 -0400 Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l6PLFepL015399 for ; Wed, 25 Jul 2007 14:15:40 -0700 Received: (from ttauber@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l6PLFehp015398 for rpsec@ietf.org; Wed, 25 Jul 2007 14:15:40 -0700 Date: Wed, 25 Jul 2007 14:15:40 -0700 From: Tony Tauber To: rpsec@ietf.org Message-ID: <20070725211539.GO12344@1-4-5.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [RPSEC] Change to Consensus statement in BGP Sec Reqs -08 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org As was noted during yesterday's meeting, I'm proposing changing part of Sec 7 from: "The AS_PATH for specific prefixes may be protected in any proposed security system in four ways, outlined below. Special Note: On the first two categories below, the community has reached consensus; on the latter two (AS_PATH Feasibility Check and Update Transit Check), the community has not reached consensus." to "The AS_PATH for specific prefixes may be protected in any proposed security system in four ways, outlined below. Special Note: On the latter two categories below (AS_PATH Feasibility Check and Update Transit Check), the requirement will be revisited in the future once more experience has been garnered." There was support in the room including from Dave Ward who is our shepherding AD who indicated publishing a consensus document which states a lack of consensus is contradictory. The SIDR Co-Chairs also applauded this move as it allows them to progress their work. Please send your comments and statements of support for or opposition to this change to the text. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 25 17:30:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDoR3-0004Tq-B6; Wed, 25 Jul 2007 17:30:21 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IDoR2-0004Tl-FR for rpsec-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 17:30:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDoR1-0004Td-Sh for rpsec@ietf.org; Wed, 25 Jul 2007 17:30:19 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDoR1-00056G-0Y for rpsec@ietf.org; Wed, 25 Jul 2007 17:30:19 -0400 Received: from [130.129.23.125] (dhcp-177d.ietf69.org [130.129.23.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 18BEFD5F36; Thu, 26 Jul 2007 07:30:16 +1000 (EST) Message-ID: <46A7C160.2010207@apnic.net> Date: Thu, 26 Jul 2007 07:32:16 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Tony Tauber Subject: Re: [RPSEC] Change to Consensus statement in BGP Sec Reqs -08 References: <20070725211539.GO12344@1-4-5.net> In-Reply-To: <20070725211539.GO12344@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org I support this change and would also advise you to change the normative MUST and SHOULD in the latter two sections to non-normative text so that there is no confusion here. Here is an example of such a change to the text o AS_PATH Feasibility Check: The AS_PATH list may correspond to a valid list of autonomous systems according to the first verification category listed in the "Areas to Secure" Section above. Further study will determine the extent to which this is a security requirement. o Update Transit Check: Routing information carried through BGP may include information that can be used to verify the re- advertisement or modification by each autonomous system through which the UPDATE has passed. This check is more rigorous than the "valid list of autonomous systems" above. Further study will determine the extent to which this is a security requirement. Geoff Tony Tauber wrote: > As was noted during yesterday's meeting, I'm proposing changing part of > Sec 7 from: > > "The AS_PATH for specific prefixes may be protected in any proposed > security system in four ways, outlined below. Special Note: On the first > two categories below, the community has reached consensus; on the latter > two (AS_PATH Feasibility Check and Update Transit Check), the community > has not reached consensus." > > to > > "The AS_PATH for specific prefixes may be protected in any proposed > security system in four ways, outlined below. Special Note: On the > latter two categories below (AS_PATH Feasibility Check and Update > Transit Check), the requirement will be revisited in the future once > more experience has been garnered." > > There was support in the room including from Dave Ward who is our > shepherding AD who indicated publishing a consensus document which > states a lack of consensus is contradictory. > > The SIDR Co-Chairs also applauded this move as it allows them to > progress their work. > > Please send your comments and statements of support for or opposition to > this change to the text. > > Thanks, > > Tony > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 25 17:32:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDoTO-00053X-4R; Wed, 25 Jul 2007 17:32:46 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IDoTM-00053S-If for rpsec-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 17:32:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDoTM-00053J-8D for rpsec@ietf.org; Wed, 25 Jul 2007 17:32:44 -0400 Received: from mint.apnic.net ([202.12.29.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDoTL-0001tJ-Li for rpsec@ietf.org; Wed, 25 Jul 2007 17:32:44 -0400 Received: from [130.129.23.125] (dhcp-177d.ietf69.org [130.129.23.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id AC870D5F36; Thu, 26 Jul 2007 07:32:41 +1000 (EST) Message-ID: <46A7C1F4.9040508@apnic.net> Date: Thu, 26 Jul 2007 07:34:44 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Tony Tauber Subject: Re: [RPSEC] Change to Consensus statement in BGP Sec Reqs -08 References: <20070725211539.GO12344@1-4-5.net> In-Reply-To: <20070725211539.GO12344@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org whoops - also a change to the next para The results of the first two checks SHOULD be made available to network operators. Each network operator will decide, on a local basis, which of these checks to enable Geoff Tony Tauber wrote: > As was noted during yesterday's meeting, I'm proposing changing part of > Sec 7 from: > > "The AS_PATH for specific prefixes may be protected in any proposed > security system in four ways, outlined below. Special Note: On the first > two categories below, the community has reached consensus; on the latter > two (AS_PATH Feasibility Check and Update Transit Check), the community > has not reached consensus." > > to > > "The AS_PATH for specific prefixes may be protected in any proposed > security system in four ways, outlined below. Special Note: On the > latter two categories below (AS_PATH Feasibility Check and Update > Transit Check), the requirement will be revisited in the future once > more experience has been garnered." > > There was support in the room including from Dave Ward who is our > shepherding AD who indicated publishing a consensus document which > states a lack of consensus is contradictory. > > The SIDR Co-Chairs also applauded this move as it allows them to > progress their work. > > Please send your comments and statements of support for or opposition to > this change to the text. > > Thanks, > > Tony > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 25 19:26:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDqFB-0003kY-JT; Wed, 25 Jul 2007 19:26:13 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IDqFA-0003kN-3r for rpsec-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 19:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDqF9-0003kE-QR for rpsec@ietf.org; Wed, 25 Jul 2007 19:26:11 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDqF8-0006zf-JP for rpsec@ietf.org; Wed, 25 Jul 2007 19:26:11 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6PNMui3016087; Wed, 25 Jul 2007 19:22:56 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAThaqrF; Wed, 25 Jul 07 19:22:12 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 8B4463F423; Wed, 25 Jul 2007 18:48:40 -0400 (EDT) To: rpsec@ietf.org, ttauber@1-4-5.net Subject: Re: [RPSEC] Change to Consensus statement in BGP Sec Reqs -08 In-Reply-To: <20070725211539.GO12344@1-4-5.net> Message-Id: <20070725224840.8B4463F423@pecan.tislabs.com> Date: Wed, 25 Jul 2007 18:48:40 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org >As was noted during yesterday's meeting, I'm proposing changing part of >Sec 7 from: > >"The AS_PATH for specific prefixes >... >to > >"The AS_PATH for specific prefixes There was also a suggestion that the MUST/SHOULD language of "the latter two categories below" be changed so they don't look like RFC2119 statements. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 25 21:44:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDsOt-0006lA-Qc; Wed, 25 Jul 2007 21:44:23 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IDsOr-0006kx-Uu for rpsec-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 21:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDsOr-0006km-Kj for rpsec@ietf.org; Wed, 25 Jul 2007 21:44:21 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDsOq-0000hN-EV for rpsec@ietf.org; Wed, 25 Jul 2007 21:44:21 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2007 21:44:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMaYp0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,582,1175486400"; d="scan'208"; a="127042871:sNHT28239966" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6Q1iKMb022379; Wed, 25 Jul 2007 21:44:20 -0400 Received: from [172.27.172.113] (rtp-vpn3-1054.cisco.com [10.82.220.35]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6Q1iIEZ005809; Thu, 26 Jul 2007 01:44:19 GMT Message-ID: <46A7FC71.1030407@cisco.com> Date: Wed, 25 Jul 2007 21:44:17 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Geoff Huston Subject: Re: [RPSEC] Change to Consensus statement in BGP Sec Reqs -08 References: <20070725211539.GO12344@1-4-5.net> <46A7C160.2010207@apnic.net> In-Reply-To: <46A7C160.2010207@apnic.net> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2908; t=1185414260; x=1186278260; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RPSEC]=20Change=20to=20Consensus=20statement=20in=20 BGP=20Sec=20Reqs=20-08 |Sender:=20 |To:=20Geoff=20Huston=20; bh=WokHYFUb9B/R4rpGuvR8isXFFVfaL5nWbvlpJpabTf4=; b=rn0NKtSMRxKSQEcZxW1t0zpaiLiCXVV1Nl8YC6ElY3XP03KZWmbHhVCxaS5mirgR9JVQI0Ea X/c4IrfZYrSlnAvs02Ok6RmngdguJo0wqN1+bhnhX08wi/D2RLUNraAi; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -3.8 (---) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This wording looks fine to me.... :-) Russ Geoff Huston wrote: > I support this change and would also advise you to change the normative > MUST and SHOULD in the latter two sections to non-normative text so that > there is no confusion here. > > Here is an example of such a change to the text > > > o AS_PATH Feasibility Check: The AS_PATH list may correspond to a > valid list of autonomous systems according to the first > verification category listed in the "Areas to Secure" Section > above. Further study will determine the extent to which this > is a security requirement. > > o Update Transit Check: Routing information carried through BGP > may include information that can be used to verify the re- > advertisement or modification by each autonomous system through > which the UPDATE has passed. This check is more rigorous than the > "valid list of autonomous systems" above. Further study will > determine the extent to which this is a security requirement. > > > > Geoff > > > > > > Tony Tauber wrote: >> As was noted during yesterday's meeting, I'm proposing changing part of >> Sec 7 from: >> >> "The AS_PATH for specific prefixes may be protected in any proposed >> security system in four ways, outlined below. Special Note: On the first >> two categories below, the community has reached consensus; on the latter >> two (AS_PATH Feasibility Check and Update Transit Check), the community >> has not reached consensus." >> >> to >> >> "The AS_PATH for specific prefixes may be protected in any proposed >> security system in four ways, outlined below. Special Note: On the >> latter two categories below (AS_PATH Feasibility Check and Update >> Transit Check), the requirement will be revisited in the future once >> more experience has been garnered." >> >> There was support in the room including from Dave Ward who is our >> shepherding AD who indicated publishing a consensus document which >> states a lack of consensus is contradictory. >> >> The SIDR Co-Chairs also applauded this move as it allows them to >> progress their work. >> >> Please send your comments and statements of support for or opposition to >> this change to the text. >> >> Thanks, >> >> Tony >> >> >> _______________________________________________ >> RPSEC mailing list >> RPSEC@ietf.org >> https://www1.ietf.org/mailman/listinfo/rpsec > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGp/xxER27sUhU9OQRAt9mAJ9iaC9rgUzrhyeFiqzVqr7cE9x5VQCgwelE yR10KaSwpHaI85RfjWNm2Qk= =NOUk -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 27 09:46:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQ8w-0001SE-5W; Fri, 27 Jul 2007 09:46:10 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IEQ8u-0001S1-Ud for rpsec-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 09:46:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQ8u-0001Rr-L0 for rpsec@ietf.org; Fri, 27 Jul 2007 09:46:08 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEQ8t-0004Wp-NW for rpsec@ietf.org; Fri, 27 Jul 2007 09:46:08 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Jul 2007 15:46:05 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALeTqUaQ/uCKh2dsb2JhbACCLTiNAwEBAQgKJw X-IronPort-AV: i="4.16,589,1175464800"; d="scan'208,217"; a="149180327:sNHT72838416" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6RDk4mD021189 for ; Fri, 27 Jul 2007 15:46:04 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6RDk0kt012065 for ; Fri, 27 Jul 2007 13:46:04 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 15:46:00 +0200 Received: from mbehring-wxp.cisco.com ([10.55.2.210]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 15:45:59 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Jul 2007 18:28:31 -0500 To: rpsec@ietf.org From: "Michael H. Behringer" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 27 Jul 2007 13:45:59.0881 (UTC) FILETIME=[772FF390:01C7D054] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4819; t=1185543964; x=1186407964; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbehring@cisco.com; z=From:=20=22Michael=20H.=20Behringer=22=20 |Subject:=20Follow-up=20on=20discussion=20on=20BGP=20session=20security=2 0draft |Sender:=20; bh=UO/f4PPccCau9nusAhAShL5lzuGsEjTeHLA7kMhl+Oc=; b=H+eVniCROtFg9kl6ij7HshBlnZSFZ41OD8iws3wQ2/iwUjZgDJjS1nKKfFUiwgKR4OUAcHm+ v28RBFcBxgIzmHZuKbLxce7T5eu8OSWMDFgKK+5BHhfkeQxg4U/sAfEQ; Authentication-Results: ams-dkim-1; header.From=mbehring@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -2.2 (--) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [RPSEC] Follow-up on discussion on BGP session security draft X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1778934524==" Errors-To: rpsec-bounces@ietf.org --===============1778934524== Content-Type: multipart/alternative; boundary="=====================_13885296==.ALT" --=====================_13885296==.ALT Content-Type: text/plain; charset="us-ascii" Following up on the discussion we had in the WG meeting, on draft-behringer-bgp-session-sec-req-01.txt. [Thanks for the excellent minutes, Geoff!] The key issue as I see it is the scope of the document and the potential overlap with draft-bellovin-tcpsec-01.txt. (The other issues are comparatively minor, and will be addressed after we clarified the scope of the doc.) Let me try to address those here. - Scope of the document. Strictly speaking the WG is focusing on *protocol* security requirements, ie, the BGP protocol specific security stuff. Right now my doc addresses a wider scope, namely all the security mechanisms that a BGP speaker should implement to secure a BGP peering. This includes mechanisms on several layers. So strictly speaking the doc is out of scope. However, if we are that strict, *nothing* is going to be in scope for BGP, not even the bellovin draft, since tcpsec is not part of the BGP protocol either. ;-) It was also pointed out that the document is a mix between operational requirements, and implementation requirements. That needs to be clarified as well. (At least what the intention is.) My goal was to address real, practical requirements (leave out detailed discussion here, there is still a lot of work to be done). I agree the scope needs refining, along what I wrote above, and I'll give it a try. I am open for suggestions. But having discussed with various people, I think, assuming the fixes above, we are in agreement that this scope is correct, and fits into the WG charter. Is this correct? - Overlap with draft-bellovin-tcpsec-01.txt I *had* actually read the -00 draft, but forgot to add the reference. I think that the two documents address a different problem space. The Bellovin draft is TCP specific, not focused on BGP. However, it is an excellent analysis of the security requirements for this space. It is clear that my document must reference the Bellovin draft, and must also explain how the two documents fit together. This will also be addressed. Can we have a vote: With those clarifications, does the document fit into the WG charter? [If there is consensus, I will address the other points raised in version -02] Thanks for your feedback! Michael --=====================_13885296==.ALT Content-Type: text/html; charset="us-ascii" Following up on the discussion we had in the WG meeting, on draft-behringer-bgp-session-sec-req-01.txt. [Thanks for the excellent minutes, Geoff!]

The key issue as I see it is the scope of the document and the potential overlap with 
draft-bellovin-tcpsec-01.txt. (The other issues are
comparatively minor, and will be addressed after we clarified the scope
of the doc.) Let me try to address those here.
- Scope of the document.

Strictly speaking the WG is focusing on *protocol* security requirements, ie, the BGP protocol specific security stuff. Right now my doc addresses a wider scope, namely all the security mechanisms that a BGP speaker should implement to secure a BGP peering. This includes mechanisms on several layers. So strictly speaking the doc is out of scope. However, if we are that strict, *nothing* is going to be in scope for BGP, not even the bellovin draft, since tcpsec is not part of the BGP protocol either. ;-) 

It was also pointed out that the document is a mix between operational requirements, and implementation requirements. That needs to be clarified as well. (At least what the intention is.)

My goal was to address real, practical requirements (leave out detailed discussion here, there is still a lot of work to be done). I agree the scope needs refining, along what I wrote above, and I'll give it a try. I am open for suggestions.

But having discussed with various people, I think, assuming the fixes above, we are in agreement that this scope is correct, and fits into the WG charter. Is this correct?

- Overlap with 
draft-bellovin-tcpsec-01.txt
I *had* actually read the -00 draft, but forgot to add the reference. I think that the two documents address a different problem space. The Bellovin draft is TCP specific, not focused on BGP. However, it is an excellent analysis of the security requirements for this space. It is clear that my document must reference the Bellovin draft, and must also explain how the two documents fit together. This will also be addressed.
Can we have a vote: With those clarifications, does the document fit into the WG charter?

[If there is consensus, I will address the other points raised in version -02]

Thanks for your feedback!
Michael

--=====================_13885296==.ALT-- --===============1778934524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1778934524==-- From rpsec-bounces@ietf.org Fri Jul 27 10:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQQt-0000lt-FG; Fri, 27 Jul 2007 10:04:43 -0400 Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1IEQQr-0000lg-4w for rpsec-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 10:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQQq-0000lW-0K for rpsec@ietf.org; Fri, 27 Jul 2007 10:04:40 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEQQo-0004rz-Ic for rpsec@ietf.org; Fri, 27 Jul 2007 10:04:39 -0400 Received: from [130.129.23.125] (dhcp-177d.ietf69.org [130.129.23.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 508C3D5F37; Sat, 28 Jul 2007 00:04:35 +1000 (EST) Message-ID: <46A9FBEF.1060406@apnic.net> Date: Sat, 28 Jul 2007 00:06:39 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Michael H. Behringer" Subject: Re: [RPSEC] Follow-up on discussion on BGP session security draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org I agree with the proposition that this work fits within the WG charter, provides requirement information above and beyond TCP transport, and I support the adoption of this draft as a WG document. Geoff Michael H. Behringer wrote: [...] > But having discussed with various people, I think, assuming the fixes > above, we are in agreement that this scope is correct, and fits into the > WG charter. Is this correct? _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec