From rpsec-bounces@ietf.org Wed Feb 14 15:54:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR7P-0000By-Mi; Wed, 14 Feb 2007 15:52:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHR5k-00077a-0n; Wed, 14 Feb 2007 15:51:04 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHR5j-0008PM-H9; Wed, 14 Feb 2007 15:51:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DEF761761C; Wed, 14 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HHR4k-0004K5-6W; Wed, 14 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rpsec@ietf.org Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-bgpsecrec-07.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-07.txt Pages : 18 Date : 2007-2-14 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-07.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-07.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-07.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-2-14130229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-bgpsecrec-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-14130229.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 Feb 26 13:17:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkMG-00028h-5u; Mon, 26 Feb 2007 13:13:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkMF-00028M-G8 for rpsec@ietf.org; Mon, 26 Feb 2007 13:13:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLkMB-00043P-Tc for rpsec@ietf.org; Mon, 26 Feb 2007 13:13:55 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2007 19:13:51 +0100 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 l1QIDoM7016188; Mon, 26 Feb 2007 19:13:50 +0100 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 l1QIDcCE003790; Mon, 26 Feb 2007 19:13:46 +0100 (MET) 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, 26 Feb 2007 19:13:42 +0100 Received: from mbehring-wxp.cisco.com ([144.254.202.57]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 19:13:41 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Feb 2007 19:13:41 +0100 To: Russ White , rpsec@ietf.org From: "Michael H. Behringer" Subject: Re: [RPSEC] Charter and Meeting Agenda In-Reply-To: <459FB41F.80409@cisco.com> References: <459FB41F.80409@cisco.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 26 Feb 2007 18:13:42.0024 (UTC) FILETIME=[D8983880:01C759D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1954; t=1172513630; x=1173377630; 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]=20Charter=20and=20Meeting=20Agenda |Sender:=20; bh=8qqPKymfCT7vunOFI2SJePxhYkedFs/NQXoWO+klte4=; b=jiJ5K8/Jlr6E6Zj7GnSLCqzyYRALWUR6TIYzWErjL7qs6NMtxdrzxpl1Z6lssBuav/ct4+ko tJ7mIprJMKqa6SCawLAyzDR89s+YDNP3n11DUVgAxZasYrwO27JbsZSS; Authentication-Results: ams-dkim-2; header.From=mbehring@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 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="===============1593871075==" Errors-To: rpsec-bounces@ietf.org --===============1593871075== Content-Type: multipart/alternative; boundary="=====================_77214562==.ALT" --=====================_77214562==.ALT Content-Type: text/plain; charset="us-ascii" Russ, all, 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 had a go at that topic, please see below. This still needs quite some content and editing; for now, I would like to ask for feedback on the abstract / intro (to make sure the problem is described correctly), and the outline of the draft. Is this the way we want to go down here? Please let me know your opinion. http://www.ietf.org/internet-drafts/draft-behringer-bgp-session-sec-req-00.txt Cheers, Michael --=====================_77214562==.ALT Content-Type: text/html; charset="us-ascii" Russ, all,

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 had a go at that topic, please see below. This still needs quite some content and editing; for now, I would like to ask for feedback on the abstract / intro (to make sure the problem is described correctly), and the outline of the draft. Is this the way we want to go down here? Please let me know your opinion. 


http://www.ietf.org/internet-drafts/draft-behringer-bgp-session-sec-req-00.txt
Cheers,
Michael --=====================_77214562==.ALT-- --===============1593871075== 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 --===============1593871075==-- From rpsec-bounces@ietf.org Wed Feb 28 12:47:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSrc-0000Uz-Ka; Wed, 28 Feb 2007 12:45:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSra-0000B4-Kl for rpsec@ietf.org; Wed, 28 Feb 2007 12:45:14 -0500 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMSrY-0006Rv-T5 for rpsec@ietf.org; Wed, 28 Feb 2007 12:45:14 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l1SHh5Ew024621; Wed, 28 Feb 2007 12:43:05 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2UaO4V; Wed, 28 Feb 07 12:42:06 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id E53EC3F443; Wed, 28 Feb 2007 12:41:25 -0500 (EST) To: curtis@occnc.com, ttauber@1-4-5.net Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... In-Reply-To: Message-Id: <20070228174125.E53EC3F443@pecan.tislabs.com> Date: Wed, 28 Feb 2007 12:41:25 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rpsec@ietf.org, riw@cisco.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 I got to thinking about: Tony Tauber said: >> o In an environment where secured service is in the process of >> being deplyed a mechanism MUST exist to support a transition >> free of service interruption. > >I think the original bullet is about something else and still has >merit, but I like your addition. If a secured service requires a change in the router software, would it not then require a service interrruption to upgrade the software? Is this stipulation intended to outlaw any and all in-band secured service? Would a replacement for the TCP MD5 method, for example, be outlawed? Just how broad a "free of service interruption" requirement is this? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 28 12:54:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSz3-0006Ej-6i; Wed, 28 Feb 2007 12:52:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSz1-0006Bq-Lp for rpsec@ietf.org; Wed, 28 Feb 2007 12:52:55 -0500 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 1HMSz0-0007Ic-Fg for rpsec@ietf.org; Wed, 28 Feb 2007 12:52:55 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l1SHonkN025258; Wed, 28 Feb 2007 12:50:58 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAARBaimX; Wed, 28 Feb 07 12:49:59 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id DC9BA3F422; Wed, 28 Feb 2007 12:48:56 -0500 (EST) To: mbehring@cisco.com, riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Charter and Meeting Agenda In-Reply-To: Message-Id: <20070228174856.DC9BA3F422@pecan.tislabs.com> Date: Wed, 28 Feb 2007 12:48:56 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 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. It should be noted that the tcpm working group has adopted the action of working on a replacement to TCP MD5. A design team, I'm told, is being assembled and should be announced RSN, like maybe this week. The intent is to meld the two most promising existing suggestions. So if we are setting requirements, and they are starting work on the protocol, we'd better get going pretty fast. Some coordination with the tcpm chairs seems like it might be in order. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 28 13:01:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMT6G-0000KI-PD; Wed, 28 Feb 2007 13:00:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMT6F-0000DN-7b for rpsec@ietf.org; Wed, 28 Feb 2007 13:00:23 -0500 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMT6D-00087s-Pe for rpsec@ietf.org; Wed, 28 Feb 2007 13:00:23 -0500 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.6/8.13.4) with ESMTP id l1SHtYEQ081106; Wed, 28 Feb 2007 12:55:34 -0500 (EST) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l1SHtYEQ081106 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1172685334; bh=qqp5M1EyM8RdUCD42t2g3mPOtyc=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=O6+Prp5ttopyRykqxW3fLdRAIAU/Zy6dli ljYum11dPoB5QGnfc8L6DTRVPErqq0oTUgBx0Y/nInPtUxoCBmzQ== Message-Id: <200702281755.l1SHtYEQ081106@workhorse.brookfield.occnc.com> To: sandy@tislabs.com (Sandy Murphy) From: Curtis Villamizar Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... In-reply-to: Your message of "Wed, 28 Feb 2007 12:41:25 EST." <20070228174125.E53EC3F443@pecan.tislabs.com> Date: Wed, 28 Feb 2007 12:55:34 -0500 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: riw@cisco.com, ttauber@1-4-5.net, 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 <20070228174125.E53EC3F443@pecan.tislabs.com> Sandy Murphy writes: > > I got to thinking about: > > Tony Tauber said: > > >> o In an environment where secured service is in the process of > >> being deplyed a mechanism MUST exist to support a transition > >> free of service interruption. > > > >I think the original bullet is about something else and still has > >merit, but I like your addition. > > If a secured service requires a change in the router software, > would it not then require a service interrruption to upgrade the software? Some routers can do a change in software without disruption. For routers that don't that shouldn't disqualify the protocol change. Obviously no progress can be made without software changes. > Is this stipulation intended to outlaw any and all in-band secured service? No. IMHO. > Would a replacement for the TCP MD5 method, for example, be outlawed? In that case BGP gracefull restart might be suggested as a means of easing the transition. Again, the absense of gracefull restart in an implementation or failure to use it shouldn't disqualify the protocol extension. > Just how broad a "free of service interruption" requirement is this? > > --Sandy Do it right and it could be completely free of service interruption. I think the intent is to completely disallow "flag day" changes that require simultaneious change to multiple routers that can't be accomplished in a reasonable amount of time and to discourage changes that require taking one thing down before bringing another up in a way that can't be done at all without disruption. For BGP session restarts gracefull restart should be assumed. But then again, I'm just lurking so I could be clueless (again? :). Does the above statement need this level of clarification in the document in your opinion? [Assuming I've got it mostly right here.] Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec