From rpsec-bounces@ietf.org Sat Jan 06 09:39:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Cg1-0006Nk-0X; Sat, 06 Jan 2007 09:37:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Cfz-0006NF-3n for rpsec@ietf.org; Sat, 06 Jan 2007 09:37:39 -0500 Received: from xmail06.myhosting.com ([168.144.250.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Cfx-0007ak-Px for rpsec@ietf.org; Sat, 06 Jan 2007 09:37:39 -0500 Received: (qmail 20147 invoked from network); 6 Jan 2007 14:37:31 -0000 Received: from unknown (HELO [127.0.0.1]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with SMTP for ; 6 Jan 2007 14:37:31 -0000 Message-ID: <459FB41F.80409@cisco.com> Date: Sat, 06 Jan 2007 09:37:19 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: rpsec@ietf.org X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Subject: [RPSEC] Charter and Meeting Agenda 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 Y'all: The list has been pretty much down for a while, but we need to bring it back up again. :-) For the next IETF, we should probably meet, and go over: o A new charter. Ours is woefully out of date, and while I've sent several out, I've not received any response to base sending one to the IESG on. o Outstanding drafts. Towards that end, please take a look at the proposed charter, below. Anyone who has drafts they would like to present before the Prague meeting, please let Tony or I know. Also, anyone who has an outstanding draft, please let me know the current status, so we can get things updated, and rolling again. Thanks! :-) Russ == Proposed Charter: The lack of a common set of security requirements and methods for routing protocols has resulted in a wide variety of security mechanisms for individual routing protocols. Ongoing work on requirements for the next generation routing system and future work on the actual mechanisms for it will require well documented routing security requirements. The products of this working group will be used by routing protocol designers to ensure adequate coverage of security in the future, including well known and possible threats. The scope of work is limited to router-to-router protocols for unicast and multicast systems, and does NOT include host-to-router protocol such as IGMP, ICMP, ARP, or ND. It is also a non-goal at this point to produce new or change the current security mechanisms in the existing routing protocols. The RPSEC working group is charged with the following tasks: - - Document threat models for routing systems - - Document security requirements for routing systems - - Document security analysis and requirements for specific routing protocols (e.g., OSPF, BGP) - - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Goals and Milestones: July 07 Submit BGP Attack-Tree analysis for publication as Informational RFC. July 07 Submit OSPF vulnerability analysis for publication as Informational RFC. July 07 Submit BGP security requirements for publication as Informational RFC. July 07 Initial draft of requirements for point-to-point security of BGP peering sessions. December 07 Evaluate progress, recharter with new goals or shutdown. == Current Drafts: o BGP Attack Tree: I believe, at least check, no-one was working on this one. The original authors have, I think, all moved on, and I don't know if anyone has the original text. We probably need a volunteer to edit this draft through the final stages, which would mostly mean getting it into a publishable format from the last known copy. It has, AFAIK, already been accepted as a WG doc. o OSPF Vulnerability Analysis: I think this was also accepted as a WG doc, but I'm not certain of the current state. o BGP Security Requirements: I thought we had a rough consensus on the current text, so we should move this forward. 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. - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFFn7QfER27sUhU9OQRAt/UAKCPrlMitMU55fs3CDIM7EITn8zMIQCYiSRN hgCWSqzz68GmCnBvQJgTFg== =Cwsj -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 29 12:20:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBa8f-0004iI-TZ; Mon, 29 Jan 2007 12:17:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBa8f-0004iA-1v for rpsec@ietf.org; Mon, 29 Jan 2007 12:17:53 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBa8d-0001O3-M9 for rpsec@ietf.org; Mon, 29 Jan 2007 12:17:53 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l0THHmJa017592; Mon, 29 Jan 2007 09:17:48 -0800 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) with ESMTP id l0THHmpH017589; Mon, 29 Jan 2007 09:17:48 -0800 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Mon, 29 Jan 2007 09:17:48 -0800 (PST) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: Russ White Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... In-Reply-To: <44CA8803.1010807@cisco.com> Message-ID: References: <44CA8803.1010807@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 All, Sorry for the long snooze. See the new third sentence below and fourth bullet-point after that. I feel these are only marginal clarifications on what was contextual received wisdom within the group. If there are no grave concerns by week's end, I'll submit the changes. Thanks, Tony ---- 3.2. Incremental deployment It will not be feasible to deploy a newly secured BGP protocol throughout the public Internet instantaneously. It also may not be possible to deploy a such a protocol to all routers in a large AS at + one time. Any proposed solution MUST support an incremental + deployment which will provide some benefit for those who participate. Because of this, there are several requirements that any proposed mechanism to secure BGP must consider. o A BGP security mechanism MUST enable each BGP speaker to configure use of the security mechanism on a per-peer basis. 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. o 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. + o Proposed solutions MUST provide comment and analysis of what the + security services the solution will provide in the case of + incremental deployment scenarios (e.g, contiguous islands, + discontiguous islands, universal deployment). > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I would call for a hum, but we can't hear it, of course, on email, > so.... Please state your answer to the following: > > o Discontiguous deployment should be included as a capability any > proposed mechanism SHOULD have. > > o Discontiguous deployment should be included as a capability any > proposed mechanism MUST have. > > o We should say something about discontiguous deployment, but we > shouldn't attach any requirements to that statement. > > o Discontiguous deployment should not be included in the requirements at > all. > > I'd just like to settle where we are, so we can actually work on wording > with a common understanding of what it is we are trying to actually word. > > :-) > > Russ > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jan 30 11:02:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvP7-0002Zg-29; Tue, 30 Jan 2007 11:00:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvP5-0002Za-Aw for rpsec@ietf.org; Tue, 30 Jan 2007 11:00:15 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvP3-0005PO-Vg for rpsec@ietf.org; Tue, 30 Jan 2007 11:00:15 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l0UG0AGH003580; Tue, 30 Jan 2007 08:00:10 -0800 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) with ESMTP id l0UG02Lt003577; Tue, 30 Jan 2007 08:00:06 -0800 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Tue, 30 Jan 2007 08:00:02 -0800 (PST) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: Curtis Villamizar Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... In-Reply-To: <200701292226.l0TMQL4G029593@workhorse.brookfield.occnc.com> Message-ID: References: <200701292226.l0TMQL4G029593@workhorse.brookfield.occnc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 [ Adding the list back on. ] On Mon, 29 Jan 2007, Curtis Villamizar wrote: > > Tony, Russ, > > Tony Tauber writes: > >> possible to deploy a such a protocol to all routers in a large AS at >> ^^^^^^^^ > > > Looks better with the additions. Note the minor typo above. Fixed. Thanks. > Another practical consideration is deployment rollout. Makes sense. > This might be a good replacement for your third bullet. > > - o 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. > > > 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. > For some providers resetting the BGP sessions during a service > rollout would be at least highly undesireable and might be > completely unacceptable. With providers trying to acheive higher > service availability than their competitors, this becomes very > important. > > Curtis At first, I was inclined to put this kind of thing in as a SHOULD, but after thinking for a bit, am leaning toward MUST. Re-setting an eBGP session here or there is an event any deployment should be able to deal with fairly gracefully for an upgrade of such magnitude. Taking down major parts of one's iBGP infrastructure, however, is not acceptable, IMO. I'll add this text unless the list disapproves. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jan 30 20:02:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3ok-0002E7-Hl; Tue, 30 Jan 2007 19:59:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3oj-0002Dy-GP for rpsec@ietf.org; Tue, 30 Jan 2007 19:59:17 -0500 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC3oi-0005Vd-56 for rpsec@ietf.org; Tue, 30 Jan 2007 19:59:17 -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 l0V0vuDU036201; Tue, 30 Jan 2007 19:57:57 -0500 (EST) (envelope-from curtis@occnc.com) X-DKIM: Sendmail DKIM Filter v0.5.2 workhorse.brookfield.occnc.com l0V0vuDU036201 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=occnc.com; s=workhorse; t=1170205077; bh=u+YXyPLTsMJQICnYe8rj7sp6//Q=; h=To:cc:Reply-To: From:Subject:In-reply-to:Date; b=pdeD7mpT290qdDkJQwJTm1uKmEkUmab7Fe DF8t3l0ArsYAIiBXOq0IY4mvClPG/UZ8Wi6vAD6z9t5Y2LFbJPZg== Message-Id: <200701310057.l0V0vuDU036201@workhorse.brookfield.occnc.com> To: Tony Tauber From: Curtis Villamizar Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... In-reply-to: Your message of "Tue, 30 Jan 2007 08:00:02 PST." Date: Tue, 30 Jan 2007 19:57:56 -0500 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Tony Tauber writes: > > > This might be a good replacement for your third bullet. > > > > - o 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. > > > > > > 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. Briefly - Yes I agree. [Aside: This was an email edit problem on my part. I reread your third bullet and realized that this was a different point so I didn't add the + on the addition but forgot to go back and edit the part above that. Brain temporarily disconnected from fingers. Seems to be reconnected at this point.] Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec