From mailman-owner@ietf.org Mon Apr 1 06:51:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20365 for ; Mon, 1 Apr 2002 06:51:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17202 for ; Mon, 1 Apr 2002 06:51:06 -0500 (EST) Date: Mon, 1 Apr 2002 06:51:06 -0500 (EST) Message-Id: <200204011151.GAA17202@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: rpsec-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rpsec-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rpsec-web-archive@ietf.org: List Password // URL ---- -------- rpsec@ietf.org lLFY https://www1.ietf.org/mailman/options/rpsec/rpsec-web-archive@ietf.org From rpsec-admin@ietf.org Tue Apr 2 20:06:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10350 for ; Tue, 2 Apr 2002 20:06:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00993; Tue, 2 Apr 2002 20:06:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00961 for ; Tue, 2 Apr 2002 20:06:06 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10341 for ; Tue, 2 Apr 2002 20:06:05 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA28728 for ; Tue, 2 Apr 2002 20:05:36 -0500 (EST) Date: Tue, 2 Apr 2002 20:05:36 -0500 (EST) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Minutes (draft) from Minneapolis Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Below the sig are the draft minutes. If anyone has anything to add/etc, I would appreciate the comments. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone ---- Routing Protocol Security BOF Minutes from March 2002 IETF Minneapolis, Minnesota ----- Open the Meeting Presentation: Demensions of Routing Security Radia Perlman http://www.riw.to/rpsec/perlman-rpsec-mar02.pdf Presentation: Routing Protocol Security Requirements Sandy Murphy http://www.riw.to/rpsec/murphy-rpsec-mar02.ppt Comments from the microphone on the presenations (I probably didn't catch all of these) Other things that could be detected Anomolous route distribution Router which has been broken in to It's very hard to detect a subverting router (Radia) BGP can detect anomolies in data Registry of data isn't necessarily fast enough Things sometimes change too fast for the database to keep up 9/11, for instance Wireless topology and network mobility are important considerations Charter http://www.riw.to/rpsec/charter-rpsec-mar02.ppt http://www.riw.to/rpsec/charter-rpsec-draft-06.txt Comments from the micropohne on the charter What is it we're after? Attacks, mistakes, or....? (Sandy) Everything which affects routing protocols security at a protocol level Comments from Alex Z on the BOF Should we include attacking routing platforms? No, this is outside the protocols themselves Routing protocol authors need security direction Instead of focusing on requirements, focus on assets and risks Multicast routing security The MSEC group focuses on secure distribution in multicast Multicast routing protocol security should be included here Where should specific mechanisms be provided? Specific protocol changes should be done in the protocol working groups Frameworks should be here Routing protocols security related drafts can be presented here to focus on the security aspects, but they won't be WG items Should look beyond requirements, into architectures This relates specifically to building security into the architecture of the protocols themselves It's good to have a specific place to focus interaction between routing protocols and security folks Make certain we have a direction (Sue H) Survivability should be addressed If we document threats without documenting solutions, are we helping or not? Should this be a working group? Concensus through hum Should we work on charter before presenting to IESG? Concensus through hum _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue Apr 2 20:09:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10497 for ; Tue, 2 Apr 2002 20:09:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01178; Tue, 2 Apr 2002 20:09:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01150 for ; Tue, 2 Apr 2002 20:09:34 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10489 for ; Tue, 2 Apr 2002 20:09:33 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA28813 for ; Tue, 2 Apr 2002 20:09:04 -0500 (EST) Date: Tue, 2 Apr 2002 20:09:04 -0500 (EST) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Charter Bashing... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org We left Minneapolis with the understanding that this should be a working group, but that we need to bash the charter some before going to the IESG with the proposal. A copy of the latest charter draft is below.... I know we had a good number of things to add from the comments we got there, so bash away.... :-) Russ __________________________________ Routing Protocol Security Requirements (rpsec) CHAIRS: Russ White (riw@cisco.com) Danny McPherson (danny@tcb.net) Description ----------- 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 protcool designers to ensure adequate coverage of security in the future, including well known and possible threats. It is not the goal of this working group to revisit current routing protocol security mechanisms. The goal of this BOF is to discuss creation and charter of a WG in the routing area that would be charged with the following tasks: - Document threat models for routing protocols - Document security requirements for routing protocols Proposed WG milestones: 1. Jul 2002: Submit initial I-D (or set of I-Ds) which details the threats to routing protocols. 2. Oct 2002: Submit initial I-D (or set of I-Ds) which outlines security requirements for routing protocols. 3. Dec 2002: Submit I-Ds documenting threats to routing protocols for publication as Informational RFC. 4. Mar 2003: Submit the I-D documenting security requirements to routing protocols for publication as Informational RFC. 5. Mar 2003: Evaluate progress, recharter with new goals (see possible future work below) or shutdown. BOF Agenda ---------- 1. Agenda bashing 2. Overview of security issues in routing protocols 3. Overview of the current status of routing protocol security work 4. Presentation on proposed WG charter and milestones 5. Open mike (discussion, Q&As) References ---------- 1. Flaws in packet's authentication of OSPFv2, Jerome Etienne http://www.ietf.org/internet-drafts/draft-etienne-ospfv2-auth-flaws-00.txt 2. Flaws in RIPv2 packet's authentication, Jerome Etienne http://www.ietf.org/internet-drafts/draft-etienne-ripv2-auth-flaws-00.txt 3. BGP Security Vulnerabilities Analysis, S. Murphy http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-00.txt 4. BGP Security Protections, S. Murphy http://www.ietf.org/internet-drafts/draft-murphy-bgp-protect-00.txt 5. OSPF with digital signature against an insider, Jerome Etienne http://www.ietf.org/internet-drafts/draft-etienne-rfc2154-flaws-00.txt 6. Secure BGP (S-BGP) http://www.net-tech.bbn.com/sbgp/draft-clynn-s-bgp-protocol-00.txt 7. OSPF Version 2 (RFC2328) http://www.ietf.org/rfc/rfc2328.txt 8. RIP-2 MD5 Authentication (RFC2082) http://www.ietf.org/rfc/rfc2082.txt 9. IS-IS Cryptographic Authentication http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-03.txt 10. Protection of BGP Sessions via the TCP MD5 Signature Option http://www.ietf.org/rfc/rfc2385.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2385bis-00.txt Possible Future Work -------------------- - Document the feasibility of various types of security mechinisms within routing protocols - Document requirements for new security mechanisms - Document security requirements for the next generation routing system _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Wed Apr 3 19:51:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20247 for ; Wed, 3 Apr 2002 19:51:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10063; Wed, 3 Apr 2002 19:51:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10027 for ; Wed, 3 Apr 2002 19:51:17 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20232 for ; Wed, 3 Apr 2002 19:51:15 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA13541 for ; Wed, 3 Apr 2002 19:50:48 -0500 (EST) Date: Wed, 3 Apr 2002 19:50:48 -0500 (EST) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Subject: Re: [RPSEC] Charter Bashing... (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Sorry--having mailer problems.... So I'm forwarding this to the list manually. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone ---------- Forwarded message ---------- Date: Wed, 3 Apr 2002 18:16:40 -0500 (EST) From: Radia Perlman - Boston Center for Networking To: rpsec@ietf.org, riw@cisco.com Subject: Re: [RPSEC] Charter Bashing... I don't see why evaluating the security of current routing protocol security mechanisms should be out of charter. I think we should come up with threats and countermeasures generically, and then look at existing mechanisms in existing protocols and evaluate them. What threats do they answer? Are there weaknesses that can be fixed? Otherwise, I find the charter mystifying. If the assumption is that existing mechanisms are perfect and should not be thought about or improved upon, then we don't need this group. But obviously, we do need this group. I think we need to approach the problem from both sides: we need to understand what routing security means (I tried to do some of that in my talk at the BOF). Then, how draconian are we willing to be? What kinds of solutions answer what kinds of threats and what are the costs of these solutions (e.g., CPU, configuration, bandwidth)? (and studying them generically, not worrying about shoehorning things into packet formats of existing protocols). Then also approaching it from another angle: looking at what we have in existing protocols and evaluating them for minor tweaking (perhaps a mechanism doesn't avoid replay, but could with minor enhancements), as well as noting that an existing mechanism only solves some problems that might be called "routing security", and deciding whether the mechanism should be enhanced with mechanisms that solve more, or perhaps replacing that mechanism with more powerful mechanisms. Radia _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Wed Apr 3 20:01:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20397 for ; Wed, 3 Apr 2002 20:01:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10645; Wed, 3 Apr 2002 20:01:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA10619 for ; Wed, 3 Apr 2002 20:01:11 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20394 for ; Wed, 3 Apr 2002 20:01:04 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA13792; Wed, 3 Apr 2002 20:00:36 -0500 (EST) Date: Wed, 3 Apr 2002 20:00:36 -0500 (EST) From: Russ White Reply-To: Russ White To: Radia Perlman - Boston Center for Networking cc: rpsec@ietf.org Subject: Re: [RPSEC] Charter Bashing... In-Reply-To: <200204032316.SAA04968@bcn.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > I don't see why evaluating the security of current routing > protocol security mechanisms should be out of charter. I > think we should come up with threats and countermeasures > generically, and then look at existing mechanisms in existing > protocols and evaluate them. What threats do they answer? Are > there weaknesses that can be fixed? I think the main concern here is that we could easily rathole on this, with the group spending a lot of time worrying about what the current security options are, what they really mean, and what their weaknesses are. > But obviously, we do need this group. I think we need to > approach the problem from both sides: we need to understand > what routing security means (I tried to do some of that in my > talk at the BOF). Then, how draconian are we willing to be? > What kinds of solutions answer what kinds of threats and what > are the costs of these solutions (e.g., CPU, configuration, > bandwidth)? (and studying them generically, not worrying > about shoehorning things into packet formats of existing > protocols). Okay--so the first part seems to be working on what security really means. Do we want to address bona-fide attacks from inside and outside the network? Do we want to include things which aren't attacks, but rather things which are 'mistakes,' or 'configuration errors,' or 'implementation errors?' I think we probably do, but if anyone has a different opinion.... By the way--I think there are at least two reasons to include these things. The first is that if you are thinking about a new mechanism, it makes more sense to make it cover more things rather than fewer. The second is that I'm not even certain the two problems--attacks vs other issues--are really seperable in a way that is clean enough to try and address them seperately. Solutions for the two are going to overlap, whether we intend it or not. > Then also approaching it from another angle: looking at what > we have in existing protocols and evaluating them for minor > tweaking (perhaps a mechanism doesn't avoid replay, but could > with minor enhancements), as well as noting that an existing > mechanism only solves some problems that might be called > "routing security", and deciding whether the mechanism should > be enhanced with mechanisms that solve more, or perhaps > replacing that mechanism with more powerful mechanisms. I think once we have frameworks and requirements, it might be worth thinking about how the existing work fits in those frameworks and requirements. My primary concern would be (as above) going into long detailed discussions about current methods, and (possibly even) having mud flung all over the place, with no real product as the outcome. If that makes sense. So, I suppose the real question is: Can we look at the existing mechanisms, and compare them to the requirements and frameworks, and see what we can learn from this excercise, without causing a diminishing amount of work to actually be done? It's hard to say, so I'll leave it for others to comment on. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu Apr 4 09:54:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17210 for ; Thu, 4 Apr 2002 09:54:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05953; Thu, 4 Apr 2002 09:54:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04477 for ; Wed, 3 Apr 2002 18:16:43 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18450 for ; Wed, 3 Apr 2002 18:16:39 -0500 (EST) Received: from bcn.East.Sun.COM ([129.148.75.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02440; Wed, 3 Apr 2002 16:16:41 -0700 (MST) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with SMTP id SAA04968; Wed, 3 Apr 2002 18:16:41 -0500 (EST) Message-Id: <200204032316.SAA04968@bcn.East.Sun.COM> Date: Wed, 3 Apr 2002 18:16:40 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [RPSEC] Charter Bashing... To: rpsec@ietf.org, riw@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q4WUD40Vl/wm57VOex1teg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org I don't see why evaluating the security of current routing protocol security mechanisms should be out of charter. I think we should come up with threats and countermeasures generically, and then look at existing mechanisms in existing protocols and evaluate them. What threats do they answer? Are there weaknesses that can be fixed? Otherwise, I find the charter mystifying. If the assumption is that existing mechanisms are perfect and should not be thought about or improved upon, then we don't need this group. But obviously, we do need this group. I think we need to approach the problem from both sides: we need to understand what routing security means (I tried to do some of that in my talk at the BOF). Then, how draconian are we willing to be? What kinds of solutions answer what kinds of threats and what are the costs of these solutions (e.g., CPU, configuration, bandwidth)? (and studying them generically, not worrying about shoehorning things into packet formats of existing protocols). Then also approaching it from another angle: looking at what we have in existing protocols and evaluating them for minor tweaking (perhaps a mechanism doesn't avoid replay, but could with minor enhancements), as well as noting that an existing mechanism only solves some problems that might be called "routing security", and deciding whether the mechanism should be enhanced with mechanisms that solve more, or perhaps replacing that mechanism with more powerful mechanisms. Radia _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu Apr 4 12:06:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23226 for ; Thu, 4 Apr 2002 12:06:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16757; Thu, 4 Apr 2002 12:06:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16722 for ; Thu, 4 Apr 2002 12:06:08 -0500 (EST) Received: from mesa.bbnplanet.com (mesa.bbnplanet.com [199.94.208.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23218 for ; Thu, 4 Apr 2002 12:06:05 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id g34H5V616962; Thu, 4 Apr 2002 12:05:31 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Thu, 4 Apr 2002 12:05:29 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Russ White cc: rpsec@ietf.org Subject: Re: [RPSEC] Charter Bashing... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > Description > ----------- > > 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 > protcool designers to ensure adequate coverage of security in the > future, including well known and possible threats. It is not the > goal of this working group to revisit current routing protocol > security mechanisms. > > The goal of this BOF is to discuss creation and charter of a WG > in the routing area that would be charged with the following > tasks: > > - Document threat models for routing protocols > - Document security requirements for routing protocols What about generalizing to other network control signalling protocols like LDP and RSVP? I know I mentioned this idea to you prior to the BOF and someone beat me to mentioning it on the mic, but that comment didn't make it into the published minutes. People may argue about which signalling protocols may be in scope or out, but think about the desire (which I think has alot of currency) to preserve the security and resiliency of public networks. Thoughts? Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri Apr 5 06:02:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01605 for ; Fri, 5 Apr 2002 06:02:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23203; Fri, 5 Apr 2002 06:01:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23165 for ; Fri, 5 Apr 2002 06:01:48 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01592 for ; Fri, 5 Apr 2002 06:01:43 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA14872; Fri, 5 Apr 2002 06:01:14 -0500 (EST) Date: Fri, 5 Apr 2002 06:01:14 -0500 (EST) From: Russ White Reply-To: Russ White To: Tony Tauber cc: rpsec@ietf.org Subject: Re: [RPSEC] Charter Bashing... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > > 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 > > protcool designers to ensure adequate coverage of security in the > > future, including well known and possible threats. It is not the > > goal of this working group to revisit current routing protocol > > security mechanisms. > > > > The goal of this BOF is to discuss creation and charter of a WG > > in the routing area that would be charged with the following > > tasks: > > > > - Document threat models for routing protocols > > - Document security requirements for routing protocols > > What about generalizing to other network control signalling > protocols like LDP and RSVP? As long as they are within the routing area, then I don't see any problem with extending to these.... > I know I mentioned this idea to you prior to the BOF and > someone beat me to mentioning it on the mic, but that comment > didn't make it into the published minutes. First, you'll have to sit closer to the mic next time. Second, I'll have to try and write faster, or learn to bring a second notebook to type on (since I type faster than I write, at least legibally). :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri Apr 5 09:31:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05742 for ; Fri, 5 Apr 2002 09:31:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03111; Fri, 5 Apr 2002 09:31:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03077 for ; Fri, 5 Apr 2002 09:31:10 -0500 (EST) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05728 for ; Fri, 5 Apr 2002 09:31:04 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <2B9B27BN>; Fri, 5 Apr 2002 09:30:37 -0500 Message-ID: From: "Manral, Vishwas" To: "'Russ White'" , Tony Tauber Cc: rpsec@ietf.org Subject: RE: [RPSEC] Charter Bashing... Date: Fri, 5 Apr 2002 09:30:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Russ, I had an query. The charter seems to say: - The products of this working group will be used by routing protcool designers to ensure adequate coverage of security in the future, including well known and possible threats. It is not the goal of this working group to revisit current routing protocol security mechanisms. I wanted to know what we should consider security threats? In the sense, the set of threats when we use security mechanisms such as MD5 etc are used are different from when they are not. Because as for many existing protocols now, the simple answer to a lot of security issues seems to be "use MD5". Also as most of the threats and solutions will be based on experience we have from existing protocols, I guess we can always have suggestions for existing protocols too and not preclude it from the charter. At the least least we can remove the sentence "It is not the goal of this working group to revisit current routing protocol security mechanisms." even if we do not add anything more to the charter regarding this. Agree??? Thanks, Vishwas -----Original Message----- From: Russ White [mailto:ruwhite@cisco.com] Sent: Friday, April 05, 2002 4:31 PM To: Tony Tauber Cc: rpsec@ietf.org Subject: Re: [RPSEC] Charter Bashing... > > 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 > > protcool designers to ensure adequate coverage of security in the > > future, including well known and possible threats. It is not the > > goal of this working group to revisit current routing protocol > > security mechanisms. > > > > The goal of this BOF is to discuss creation and charter of a WG > > in the routing area that would be charged with the following > > tasks: > > > > - Document threat models for routing protocols > > - Document security requirements for routing protocols > > What about generalizing to other network control signalling > protocols like LDP and RSVP? As long as they are within the routing area, then I don't see any problem with extending to these.... > I know I mentioned this idea to you prior to the BOF and > someone beat me to mentioning it on the mic, but that comment > didn't make it into the published minutes. First, you'll have to sit closer to the mic next time. Second, I'll have to try and write faster, or learn to bring a second notebook to type on (since I type faster than I write, at least legibally). :-) Russ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri Apr 5 10:34:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07592 for ; Fri, 5 Apr 2002 10:34:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07868; Fri, 5 Apr 2002 10:34:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07834 for ; Fri, 5 Apr 2002 10:34:05 -0500 (EST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07565 for ; Fri, 5 Apr 2002 10:33:59 -0500 (EST) Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g35FUEO27283; Fri, 5 Apr 2002 07:30:14 -0800 (PST) Received: from THARDJONO-LAP.verisign.com (THARDJONO-LAP [10.35.42.239]) by vhqpostal-gw1.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G4SCPXQN; Fri, 5 Apr 2002 07:35:14 -0800 Message-Id: <5.0.0.25.2.20020405102129.0196e098@10.25.1.45> X-Sender: thardjono@10.25.1.45 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 05 Apr 2002 10:35:12 -0500 To: rpsec@ietf.org, Radia.Perlman@Sun.COM From: Thomas Hardjono Subject: Re: [RPSEC] Charter Bashing... Cc: thardjono@verisign.com In-Reply-To: <200204032316.SAA04968@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org I think one of the most important tasks of this group is to get a buy-in from the router vendors (as many as possible). For many vendors, security-related functions are low-priority (and in my experience, trying to convince a product manager of the need of security-related features is a thankless/fruitless task :). People in different routing-related WGs (both unicast and multicast) have been aware of the need of "security". However, between the routing community and the security community there seems to be some differing understandings of what "security" means. It would be good if this group could be the forum where the two communities could meet. I do agree with Radia that we should consider current routing protocol security mechanisms. This ranges from the simple manually-keyed MD5/HMAC approaches to more comprehensive solutions like S-BGP. Afterall, the reason why some security people have devised solutions (like S-BGP) is because they have studied the problem (for a number of years now). Having their experiences and knowledge would be beneficial for everybody. thomas ------ At 4/3/2002||06:16 PM, you wrote: >I don't see why evaluating the security of current routing protocol >security mechanisms should be out of charter. I think we should >come up with threats and countermeasures generically, and then >look at existing mechanisms in existing >protocols and evaluate them. What threats do they >answer? Are there weaknesses that can be fixed? > >Otherwise, I find the charter mystifying. If the assumption is >that existing mechanisms are perfect and should not be thought >about or improved upon, then we don't need this group. > >But obviously, we do need this group. I think we need to approach >the problem from both sides: we need to understand what routing >security means (I tried to do some of that in my talk at the BOF). >Then, how draconian are we willing to be? What kinds of solutions >answer what kinds of threats and what are the costs >of these solutions (e.g., CPU, configuration, bandwidth)? >(and studying them generically, not worrying about shoehorning >things into packet formats of existing protocols). > >Then also approaching it from another angle: looking >at what we have in existing protocols and evaluating them for >minor tweaking (perhaps a mechanism doesn't avoid replay, but could >with minor enhancements), as well as noting that an existing mechanism >only solves some problems that might be called "routing security", >and deciding whether the mechanism should be enhanced with mechanisms >that solve more, or perhaps replacing that mechanism with more >powerful mechanisms. > >Radia > > > >_______________________________________________ >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-admin@ietf.org Fri Apr 5 22:14:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20165 for ; Fri, 5 Apr 2002 22:14:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15806; Fri, 5 Apr 2002 22:14:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15756 for ; Fri, 5 Apr 2002 22:14:32 -0500 (EST) Received: from chrome.nexsi.com (system149.nexsi.com [66.35.207.149]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20162; Fri, 5 Apr 2002 22:14:24 -0500 (EST) Received: from khonsu.Winnet.NEXSI.NET (khonsu.winnet.nexsi.net [192.168.104.125]) by chrome.nexsi.com (Postfix) with ESMTP id 0B3BBF024; Fri, 5 Apr 2002 19:14:12 -0800 (PST) Date: Fri, 5 Apr 2002 19:10:43 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.60c) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <150197950888.20020405191043@nexsi.com> To: rpsec-admin@ietf.org, Russ White Cc: Tony Tauber , Russ White , rpsec@ietf.org Subject: Re: [RPSEC] Charter Bashing... In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit >> >> What about generalizing to other network control signalling >> protocols like LDP and RSVP? > As long as they are within the routing area, then I don't see any > problem with extending to these.... Mumble... they are not, at least not at the moment, so I guess I'm not sure this would be a good idea so far. >> I know I mentioned this idea to you prior to the BOF and >> someone beat me to mentioning it on the mic, but that comment >> didn't make it into the published minutes. > First, you'll have to sit closer to the mic next time. Second, > I'll have to try and write faster, or learn to bring a second > notebook to type on (since I type faster than I write, at least > legibally). ...or have a dedicated scribe person :) Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri Apr 5 22:30:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20541 for ; Fri, 5 Apr 2002 22:30:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16377; Fri, 5 Apr 2002 22:30:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16312 for ; Fri, 5 Apr 2002 22:30:18 -0500 (EST) Received: from mesa.bbnplanet.com (mesa.bbnplanet.com [199.94.208.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20386; Fri, 5 Apr 2002 22:30:12 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id g363UGs18454; Fri, 5 Apr 2002 22:30:16 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Fri, 5 Apr 2002 22:30:16 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Alex Zinin cc: rpsec-admin@ietf.org, Russ White , Russ White , Subject: Re: [RPSEC] Charter Bashing... In-Reply-To: <150197950888.20020405191043@nexsi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org On Fri, 5 Apr 2002, Alex Zinin wrote: > >> What about generalizing to other network control signalling > >> protocols like LDP and RSVP? > > > As long as they are within the routing area, then I don't see any > > problem with extending to these.... > > Mumble... they are not, at least not at the moment, > so I guess I'm not sure this would be a good idea so far. Which seems to me to beg the question whether this work belongs in the Routing Area necessarily. After all, the practical point of the security is to maintain network integrity. Right? Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Sat Apr 6 08:06:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10673 for ; Sat, 6 Apr 2002 08:06:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15928; Sat, 6 Apr 2002 08:06:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15876 for ; Sat, 6 Apr 2002 08:06:02 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10669; Sat, 6 Apr 2002 08:05:54 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA27837; Sat, 6 Apr 2002 08:05:25 -0500 (EST) Date: Sat, 6 Apr 2002 08:05:25 -0500 (EST) From: Russ White Reply-To: Russ White To: Tony Tauber cc: Alex Zinin , rpsec-admin@ietf.org, rpsec@ietf.org Subject: Re: [RPSEC] Charter Bashing... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > > >> What about generalizing to other network control signalling > > >> protocols like LDP and RSVP? > > > > > As long as they are within the routing area, then I don't see any > > > problem with extending to these.... > > > > Mumble... they are not, at least not at the moment, > > so I guess I'm not sure this would be a good idea so far. > > Which seems to me to beg the question whether this work > belongs in the Routing Area necessarily. Hmmm.... I think we do need something for rp specifically. Otherwise, we end up with something which is so general as to border on not accomlishing anything, probably. > After all, the practical point of the security is to maintain > network integrity. Right? Yep--but there are a lot of different security spaces.... Systemic security for the network, device security, systemic security for rp's, etc. I think we are just trying to secure the routing system at the moment... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Sat Apr 6 08:27:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10860 for ; Sat, 6 Apr 2002 08:27:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16242; Sat, 6 Apr 2002 08:27:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16208 for ; Sat, 6 Apr 2002 08:27:16 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10857 for ; Sat, 6 Apr 2002 08:27:11 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA28324; Sat, 6 Apr 2002 08:26:13 -0500 (EST) Date: Sat, 6 Apr 2002 08:26:13 -0500 (EST) From: Russ White Reply-To: Russ White To: Thomas Hardjono cc: rpsec@ietf.org, Radia.Perlman@Sun.COM Subject: Re: [RPSEC] Charter Bashing... In-Reply-To: <5.0.0.25.2.20020405102129.0196e098@10.25.1.45> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > I think one of the most important tasks of this group is to > get a buy-in from the router vendors (as many as possible). > For many vendors, security-related functions are low-priority > (and in my experience, trying to convince a product manager > of the need of security-related features is a > thankless/fruitless task :). Perhaps, but it's getting easier, I think. :-) > People in different routing-related WGs (both unicast and > multicast) have been aware of the need of "security". > However, between the routing community and the security > community there seems to be some differing understandings of > what "security" means. It would be good if this group could > be the forum where the two communities could meet. Agreed.... Maybe I should add some wording to the charter to this effect. Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Sat Apr 6 10:21:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11768 for ; Sat, 6 Apr 2002 10:21:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20038; Sat, 6 Apr 2002 10:21:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20004 for ; Sat, 6 Apr 2002 10:21:19 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11765 for ; Sat, 6 Apr 2002 10:21:14 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA29795 for ; Sat, 6 Apr 2002 10:20:47 -0500 (EST) Date: Sat, 6 Apr 2002 10:20:47 -0500 (EST) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Charter Update.... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Okay, based on the recent discussion, I've updated the draft charter; I've included it below. Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone ----- Routing Protocol Security Requirements (rpsec) CHAIRS: Russ White (riw@cisco.com) Danny McPherson (danny@tcb.net) Description ----------- 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 protcool designers to ensure adequate coverage of security in the future, including well known and possible threats. The RPSEC working group is charged with the following tasks: - Document threat models for routing protocols - Document security requirements for routing protocols - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Proposed WG milestones: 1. Jul 2002: Submit initial I-D (or set of I-Ds) which details the threats to routing protocols. 2. Oct 2002: Submit initial I-D (or set of I-Ds) which outlines security requirements for routing protocols. 3. Dec 2002: Submit I-Ds documenting threats to routing protocols for publication as Informational RFC. 4. Mar 2003: Submit the I-D documenting security requirements to routing protocols for publication as Informational RFC. 5. Mar 2003: Evaluate progress, recharter with new goals (see possible future work below) or shutdown. Possible Future Work -------------------- - Document the feasibility of various types of security mechinisms within routing protocols - Document requirements for new security mechanisms - Document security requirements for the next generation routing system _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Sat Apr 6 10:26:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11803 for ; Sat, 6 Apr 2002 10:26:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20187; Sat, 6 Apr 2002 10:26:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20153 for ; Sat, 6 Apr 2002 10:26:40 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11800 for ; Sat, 6 Apr 2002 10:26:35 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA29849; Sat, 6 Apr 2002 10:25:36 -0500 (EST) Date: Sat, 6 Apr 2002 10:25:36 -0500 (EST) From: Russ White Reply-To: Russ White To: "Manral, Vishwas" cc: Tony Tauber , rpsec@ietf.org Subject: RE: [RPSEC] Charter Bashing... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > I wanted to know what we should consider security threats? In > the sense, the set of threats when we use security mechanisms > such as MD5 etc are used are different from when they are > not. Because as for many existing protocols now, the simple > answer to a lot of security issues seems to be "use MD5". This is another interesting question that was brought up at the bof.... Perhaps there should be some doc that lays out what the concept and definition of a 'threat' is, including such things as inentional and unintentional misconfigurations.... > Also as most of the threats and solutions will be based on > experience we have from existing protocols, I guess we can > always have suggestions for existing protocols too and not > preclude it from the charter. At the least least we can > remove the sentence "It is not the goal of this working group > to revisit current routing protocol security mechanisms." > even if we do not add anything more to the charter regarding > this. Agree??? See the last verison of the charter I just sent out. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Sun Apr 7 08:39:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25888 for ; Sun, 7 Apr 2002 08:39:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20013; Sun, 7 Apr 2002 08:39:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02552 for ; Sat, 6 Apr 2002 15:27:45 -0500 (EST) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15081 for ; Sat, 6 Apr 2002 15:27:41 -0500 (EST) Received: from bcn.East.Sun.COM ([129.148.75.4]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13831; Sat, 6 Apr 2002 13:27:42 -0700 (MST) Received: from bcn (bcn [129.148.75.4]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with SMTP id PAA10660; Sat, 6 Apr 2002 15:27:41 -0500 (EST) Message-Id: <200204062027.PAA10660@bcn.East.Sun.COM> Date: Sat, 6 Apr 2002 15:27:41 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [RPSEC] Charter Update.... To: rpsec@ietf.org, riw@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7WpSyXInCrlNqVz9D6l6+w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org I like the updated draft charter. Radia _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Sun Apr 7 08:43:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25925 for ; Sun, 7 Apr 2002 08:43:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20135; Sun, 7 Apr 2002 08:43:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20103 for ; Sun, 7 Apr 2002 08:43:02 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25910 for ; Sun, 7 Apr 2002 08:42:59 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA20212; Sun, 7 Apr 2002 08:42:30 -0400 (EDT) Date: Sun, 7 Apr 2002 08:42:30 -0400 (EDT) From: Russ White Reply-To: Russ White To: Radia Perlman - Boston Center for Networking cc: rpsec@ietf.org Subject: Re: [RPSEC] Charter Update.... In-Reply-To: <200204062027.PAA10660@bcn.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Any oher takers? :-) Russ On Sat, 6 Apr 2002, Radia Perlman - Boston Center for Networking wrote: > I like the updated draft charter. > > Radia > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Mon Apr 8 13:57:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01266 for ; Mon, 8 Apr 2002 13:57:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25174; Mon, 8 Apr 2002 13:57:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25138 for ; Mon, 8 Apr 2002 13:57:37 -0400 (EDT) Received: from chntva1-smrt1.gtei.net (chntva1-smrt1.gtei.net [128.11.156.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01252 for ; Mon, 8 Apr 2002 13:57:34 -0400 (EDT) Received: from beetlejuice.bbnplanet.com (beetlejuice.bbnplanet.com [199.94.208.170]) by chntva1-smrt1.gtei.net (8.11.3/8.11.3) with ESMTP id g38HvZo20007; Mon, 8 Apr 2002 17:57:36 GMT Received: (from pheller@localhost) by beetlejuice.bbnplanet.com (8.9.3/8.9.3) id NAA27626; Mon, 8 Apr 2002 13:57:35 -0400 (EDT) Date: Mon, 8 Apr 2002 13:57:35 -0400 From: Phillip Heller To: Russ White Cc: Radia Perlman - Boston Center for Networking , rpsec@ietf.org Subject: Re: [RPSEC] Charter Update.... Message-ID: <20020408175735.GW29610@beetlejuice.bbnplanet.com> Mail-Followup-To: Russ White , Radia Perlman - Boston Center for Networking , rpsec@ietf.org References: <200204062027.PAA10660@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Looks good to me. --phil On Sun, Apr 07, 2002 at 08:42:30AM -0400, Russ White wrote: Any oher takers? :-) Russ On Sat, 6 Apr 2002, Radia Perlman - Boston Center for Networking wrote: > I like the updated draft charter. > > Radia > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Mon Apr 8 16:28:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05335 for ; Mon, 8 Apr 2002 16:28:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08153; Mon, 8 Apr 2002 16:28:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08117 for ; Mon, 8 Apr 2002 16:28:09 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05316 for ; Mon, 8 Apr 2002 16:28:05 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id QAA07224; Mon, 8 Apr 2002 16:33:47 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma007215; Mon, 8 Apr 02 16:33:05 -0400 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g38KRKH26233; Mon, 8 Apr 2002 16:27:20 -0400 (EDT) Date: Mon, 8 Apr 2002 16:27:20 -0400 (EDT) Message-Id: <200204082027.g38KRKH26233@raven.gw.tislabs.com> To: riw@cisco.com Subject: RE: [RPSEC] Charter Bashing... Cc: rpsec@ietf.org, sandy@tislabs.com Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >Perhaps there should be some doc that lays out what the >concept and definition of a 'threat' is, including such things as >inentional and unintentional misconfigurations.... This is related to a comment you made earlier, that I'm just now getting around to responding to: >Do we want to include things which >aren't attacks, but rather things which are 'mistakes,' or >'configuration errors,' or 'implementation errors?' I think we >probably do, but if anyone has a different opinion.... I think we certainly do want to consider "mistakes", "unintentional misconfigurations", "configuration errors," and "implementation errors" as examples of mis-behavior. But I strongly doubt that we would be able to distinguish accidents and mistakes from deliberate malicious attacks. I don't think that it matters one whit to yahoo or ebay whether the mis-announcement of their server network is the result of maliciousness or cluelessness. They'd like the routing to work properly in either case. Anything that can happen by accident can be made to happen on purpose (and vice versa, I suppose). Maliciousness vs. cluelessness is an issue of guilt and liability and is best left to lawyers (which is probably the one whit where it does matter to yahoo and ebay :-)). --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue Apr 9 08:04:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02558 for ; Tue, 9 Apr 2002 08:04:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13496; Tue, 9 Apr 2002 08:04:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13464 for ; Tue, 9 Apr 2002 08:04:15 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02554 for ; Tue, 9 Apr 2002 08:04:13 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA26315; Tue, 9 Apr 2002 08:03:44 -0400 (EDT) Date: Tue, 9 Apr 2002 08:03:43 -0400 (EDT) From: Russ White Reply-To: Russ White To: sandy@tislabs.com cc: rpsec@ietf.org Subject: RE: [RPSEC] Charter Bashing... In-Reply-To: <200204082027.g38KRKH26233@raven.gw.tislabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Okay, we'll take it that failures, misconfigurations, and attacks are all in the charter. I don't think we need any change in the proposed charter for this, but we could explicitely add them in (?).... :-) Russ On Mon, 8 Apr 2002 sandy@tislabs.com wrote: > >Perhaps there should be some doc that lays out what the > >concept and definition of a 'threat' is, including such things as > >inentional and unintentional misconfigurations.... > > This is related to a comment you made earlier, that I'm just now getting > around to responding to: > > >Do we want to include things which > >aren't attacks, but rather things which are 'mistakes,' or > >'configuration errors,' or 'implementation errors?' I think we > >probably do, but if anyone has a different opinion.... > > I think we certainly do want to consider "mistakes", "unintentional > misconfigurations", "configuration errors," and "implementation > errors" as examples of mis-behavior. > > But I strongly doubt that we would be able to distinguish accidents > and mistakes from deliberate malicious attacks. I don't think that > it matters one whit to yahoo or ebay whether the mis-announcement > of their server network is the result of maliciousness or cluelessness. > They'd like the routing to work properly in either case. > > Anything that can happen by accident can be made to happen on purpose > (and vice versa, I suppose). Maliciousness vs. cluelessness is an > issue of guilt and liability and is best left to lawyers (which is > probably the one whit where it does matter to yahoo and ebay :-)). > > --Sandy > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue Apr 9 11:06:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08059 for ; Tue, 9 Apr 2002 11:06:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25824; Tue, 9 Apr 2002 11:05:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25782 for ; Tue, 9 Apr 2002 11:05:18 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08021 for ; Tue, 9 Apr 2002 11:05:15 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id LAA20927; Tue, 9 Apr 2002 11:11:02 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma020917; Tue, 9 Apr 02 11:10:03 -0400 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g39F4HH17368; Tue, 9 Apr 2002 11:04:17 -0400 (EDT) Date: Tue, 9 Apr 2002 11:04:17 -0400 (EDT) Message-Id: <200204091504.g39F4HH17368@raven.gw.tislabs.com> To: rpsec@ietf.org Subject: RE: [RPSEC] Charter Bashing... Cc: sandy@tislabs.com Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >Okay, we'll take it that failures, misconfigurations, and attacks >are all in the charter. I don't think we need any change in the >proposed charter for this, but we could explicitely add them in No, I didn't mean that anything about the charter needed changing. This was a vote for inclusion and a caution against trying to make the document distinguish intentional and unintentional mis-behavior. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Wed Apr 10 11:41:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22625 for ; Wed, 10 Apr 2002 11:41:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29750; Wed, 10 Apr 2002 11:40:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29717 for ; Wed, 10 Apr 2002 11:40:32 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22603 for ; Wed, 10 Apr 2002 11:40:26 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA18818; Wed, 10 Apr 2002 11:39:59 -0400 (EDT) Date: Wed, 10 Apr 2002 11:39:58 -0400 (EDT) From: Russ White Reply-To: Russ White To: sandy@tislabs.com cc: rpsec@ietf.org Subject: RE: [RPSEC] Charter Bashing... In-Reply-To: <200204091504.g39F4HH17368@raven.gw.tislabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Okay--Steve's suggested one other small change to the charter, which I'll do tonight, and ship it out again. If we don't have any further objections, we'll ship it to Alex to have it placed in the hands of the IESG/et al. for becoming a working group. :-) Russ On Tue, 9 Apr 2002 sandy@tislabs.com wrote: > >Okay, we'll take it that failures, misconfigurations, and attacks > >are all in the charter. I don't think we need any change in the > >proposed charter for this, but we could explicitely add them in > > No, I didn't mean that anything about the charter needed changing. > > This was a vote for inclusion and a caution against trying to > make the document distinguish intentional and unintentional mis-behavior. > > --Sandy > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu Apr 11 08:43:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25728 for ; Thu, 11 Apr 2002 08:43:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14177; Thu, 11 Apr 2002 08:43:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14147 for ; Thu, 11 Apr 2002 08:43:02 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25704 for ; Thu, 11 Apr 2002 08:42:59 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA28261 for ; Thu, 11 Apr 2002 08:42:31 -0400 (EDT) Date: Thu, 11 Apr 2002 08:42:31 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Draft charter update.... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Changed protocol(s) to system(s), to reflect the larger problem. :-) Russ ---- Routing Protocol Security Requirements (rpsec) CHAIRS: Russ White (riw@cisco.com) Danny McPherson (danny@tcb.net) Description ----------- 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 protcool designers to ensure adequate coverage of security in the future, including well known and possible threats. The RPSEC working group is charged with the following tasks: - Document threat models for routing systems - Document security requirements for routing systems - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Proposed WG milestones: 1. Jul 2002: Submit initial I-D (or set of I-Ds) which details the threats to routing systems. 2. Oct 2002: Submit initial I-D (or set of I-Ds) which outlines security requirements for routing systems. 3. Dec 2002: Submit I-Ds documenting threats to routing systems for publication as Informational RFC. 4. Mar 2003: Submit the I-D documenting security requirements to routing systems for publication as Informational RFC. 5. Mar 2003: Evaluate progress, recharter with new goals (see possible future work below) or shutdown. Possible Future Work -------------------- - Document the feasibility of various types of security mechinisms within routing systems - Document requirements for new security mechanisms - Document security requirements for the next generation routing system _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu Apr 11 11:23:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29833 for ; Thu, 11 Apr 2002 11:23:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23121; Thu, 11 Apr 2002 11:22:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23089 for ; Thu, 11 Apr 2002 11:22:42 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29782 for ; Thu, 11 Apr 2002 11:22:37 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3BFM9S07201 for ; Thu, 11 Apr 2002 11:22:09 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJAM4DM>; Thu, 11 Apr 2002 11:22:09 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E601F650D7@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: rpsec@ietf.org Date: Thu, 11 Apr 2002 11:22:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E16C.A2E3D0E2" Subject: [RPSEC] April 11, 2002 WG Charter Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1E16C.A2E3D0E2 Content-Type: text/plain; charset="iso-8859-1" Hello Russ et al, I find the April 11, 2002 revised text for the WG Charter to be sufficiently specific with realistic documentation milestone deliveries. That being said, how will the membership know that the Charter language that we see today not get changed tomorrow? For those of us that wish to support the needed efforts in the RPsec space, we must have some assurance that our marching orders are fixed. So, is this (April 11 version) the baseline Charter we can accept? Please acknowledge one way or the other. Best regards, Dennis Beard Nortel Networks Portfolio Integration - Network Infrastructure Security 613-768-0323 ------_=_NextPart_001_01C1E16C.A2E3D0E2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable April 11, 2002 WG Charter

Hello Russ et al,

I find the April 11, 2002 revised text = for the WG Charter to be sufficiently specific with realistic = documentation milestone deliveries.  That being said, how will the = membership know that the Charter language that we see today not get = changed tomorrow?  For those of us that wish to support the needed = efforts in the RPsec space, we must have some assurance that our = marching orders are fixed.  So, is this (April 11 version) the = baseline Charter we can accept?  Please acknowledge one way or the = other.

Best regards,

Dennis Beard
Nortel Networks
Portfolio Integration - Network = Infrastructure Security
613-768-0323

------_=_NextPart_001_01C1E16C.A2E3D0E2-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri Apr 12 08:25:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14637 for ; Fri, 12 Apr 2002 08:25:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11863; Fri, 12 Apr 2002 08:20:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11831 for ; Fri, 12 Apr 2002 08:20:06 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14261 for ; Fri, 12 Apr 2002 08:20:03 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA10878; Fri, 12 Apr 2002 08:19:31 -0400 (EDT) Date: Fri, 12 Apr 2002 08:19:31 -0400 (EDT) From: Russ White Reply-To: Russ White To: Dennis Beard cc: rpsec@ietf.org Subject: Re: [RPSEC] April 11, 2002 WG Charter In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E601F650D7@zcard0ke.ca.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Well, we're waiting on concesnsus for that, I think. I think we'll waitabout a week for any further comments, and then send it on to the IESG for approval. I don't think it will change much, so I would take it that if you wanted to start writing one of these docs tobe presented once the charter is through the process and we are wg's, you could based on what we have thus far. :-) Russ On Thu, 11 Apr 2002, Dennis Beard wrote: > Hello Russ et al, > > I find the April 11, 2002 revised text for the WG Charter to be sufficiently > specific with realistic documentation milestone deliveries. That being > said, how will the membership know that the Charter language that we see > today not get changed tomorrow? For those of us that wish to support the > needed efforts in the RPsec space, we must have some assurance that our > marching orders are fixed. So, is this (April 11 version) the baseline > Charter we can accept? Please acknowledge one way or the other. > > Best regards, > > Dennis Beard > Nortel Networks > Portfolio Integration - Network Infrastructure Security > 613-768-0323 > > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri Apr 12 08:28:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14908 for ; Fri, 12 Apr 2002 08:27:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12079; Fri, 12 Apr 2002 08:23:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12042 for ; Fri, 12 Apr 2002 08:23:09 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14544 for ; Fri, 12 Apr 2002 08:23:06 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA10996 for ; Fri, 12 Apr 2002 08:22:38 -0400 (EDT) Date: Fri, 12 Apr 2002 08:22:38 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Multicast Routing System Security.... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Y'all: Due tosome questions which came up elsewhere, I had a brief conversation with the ADs about multicast routing security. The impression I have from everyone thus far is that the msec group is mostly concerned with securing multicast streams, and not the multicast routing system. As such, I think it's appropriate to assume this group is going to dwal with the same areas of concern for multicast routing system security as unicast--defining requirements and such, and letting the actual working groups work on the protocol specific mechanisms, with this group as a meeting ground between the security and multicast routing folks as needed/etc. Just putting this out for comments.... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri Apr 12 10:53:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02368 for ; Fri, 12 Apr 2002 10:53:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19684; Fri, 12 Apr 2002 10:40:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19646 for ; Fri, 12 Apr 2002 10:40:22 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01078 for ; Fri, 12 Apr 2002 10:40:14 -0400 (EDT) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CEdbn05351; Fri, 12 Apr 2002 10:39:37 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GWB0QTCN; Fri, 12 Apr 2002 10:39:37 -0400 Received: from nortelnetworks.com (ELTON-THINKPAD [192.32.225.230]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2KA3776F; Fri, 12 Apr 2002 10:39:36 -0400 Message-ID: <3CB6F219.F131C14A@nortelnetworks.com> Date: Fri, 12 Apr 2002 10:41:29 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: Haixiang He X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh,zh-CN,zh-TW MIME-Version: 1.0 To: Russ White CC: rpsec@ietf.org Subject: Re: [RPSEC] Multicast Routing System Security.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit As Thomas said in the RPsec BOF, IRTF GSEC WG has started discussing Multicast Infrastructure Security (multicast routing system security). The focus right now is IGMP security and we had a discussion on IGMP Security Problem Statement and Requirements and some solutions in Mpls.(I personally think IGMP is part of multicast routing system.) Thanks! Regards, Haixiang Russ White wrote: > Y'all: > > Due tosome questions which came up elsewhere, I had a brief > conversation with the ADs about multicast routing security. The > impression I have from everyone thus far is that the msec group > is mostly concerned with securing multicast streams, and not the > multicast routing system. As such, I think it's appropriate to > assume this group is going to dwal with the same areas of concern > for multicast routing system security as unicast--defining > requirements and such, and letting the actual working groups work > on the protocol specific mechanisms, with this group as a meeting > ground between the security and multicast routing folks as > needed/etc. > > Just putting this out for comments.... > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > _______________________________________________ > 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-admin@ietf.org Fri Apr 12 10:58:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03026 for ; Fri, 12 Apr 2002 10:58:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20020; Fri, 12 Apr 2002 10:48:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19984 for ; Fri, 12 Apr 2002 10:48:29 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01944 for ; Fri, 12 Apr 2002 10:48:25 -0400 (EDT) Received: from yiya-u10.cisco.com (yiya-u10.cisco.com [64.102.48.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3CEluq7015725; Fri, 12 Apr 2002 07:47:57 -0700 (PDT) Date: Fri, 12 Apr 2002 10:47:56 -0400 (EDT) From: Yi Yang To: Russ White cc: rpsec@ietf.org Subject: Re: [RPSEC] Multicast Routing System Security.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Russ, Are you talking about Multicasting Routing Protocols (PIM and etc) or Routing Protocols using Multicasting (OSPF/RIP and etc)? I am a little confused here. Yi > Due tosome questions which came up elsewhere, I had a brief > conversation with the ADs about multicast routing security. The > impression I have from everyone thus far is that the msec group > is mostly concerned with securing multicast streams, and not the > multicast routing system. As such, I think it's appropriate to > assume this group is going to dwal with the same areas of concern > for multicast routing system security as unicast--defining > requirements and such, and letting the actual working groups work > on the protocol specific mechanisms, with this group as a meeting > ground between the security and multicast routing folks as > needed/etc. > > Just putting this out for comments.... > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > > > _______________________________________________ > 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-admin@ietf.org Fri Apr 12 11:49:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08768 for ; Fri, 12 Apr 2002 11:49:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23646; Fri, 12 Apr 2002 11:44:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23610 for ; Fri, 12 Apr 2002 11:44:55 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07868 for ; Fri, 12 Apr 2002 11:44:46 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA18228; Fri, 12 Apr 2002 11:44:14 -0400 (EDT) Date: Fri, 12 Apr 2002 11:44:14 -0400 (EDT) From: Russ White Reply-To: Russ White To: Haixiang He cc: rpsec@ietf.org Subject: Re: [RPSEC] Multicast Routing System Security.... In-Reply-To: <3CB6F219.F131C14A@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Okay, then we'll need some clarification, I think, which is why I bring it up. Bil? Alex? Anyone? :-) Russ On Fri, 12 Apr 2002, Haixiang He wrote: > As Thomas said in the RPsec BOF, IRTF GSEC WG has started discussing > Multicast Infrastructure Security (multicast routing system security). > The focus right now is IGMP security and we had a discussion on IGMP > Security Problem Statement and Requirements and some solutions in > Mpls.(I personally think IGMP is part of multicast routing system.) > Thanks! > > Regards, > > Haixiang > > Russ White wrote: > > > Y'all: > > > > Due tosome questions which came up elsewhere, I had a brief > > conversation with the ADs about multicast routing security. The > > impression I have from everyone thus far is that the msec group > > is mostly concerned with securing multicast streams, and not the > > multicast routing system. As such, I think it's appropriate to > > assume this group is going to dwal with the same areas of concern > > for multicast routing system security as unicast--defining > > requirements and such, and letting the actual working groups work > > on the protocol specific mechanisms, with this group as a meeting > > ground between the security and multicast routing folks as > > needed/etc. > > > > Just putting this out for comments.... > > > > :-) > > > > Russ > > > > __________________________________ > > riw@cisco.com CCIE <>< Grace Alone > > > > _______________________________________________ > > RPSEC mailing list > > RPSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/rpsec > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri Apr 12 11:53:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09383 for ; Fri, 12 Apr 2002 11:53:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23537; Fri, 12 Apr 2002 11:44:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAB23497 for ; Fri, 12 Apr 2002 11:44:08 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07741 for ; Fri, 12 Apr 2002 11:43:59 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA18216; Fri, 12 Apr 2002 11:43:28 -0400 (EDT) Date: Fri, 12 Apr 2002 11:43:27 -0400 (EDT) From: Russ White Reply-To: Russ White To: Yi Yang cc: rpsec@ietf.org Subject: Re: [RPSEC] Multicast Routing System Security.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org PIM and such.... :-) Russ On Fri, 12 Apr 2002, Yi Yang wrote: > Russ, > > Are you talking about Multicasting Routing Protocols (PIM and etc) or > Routing Protocols using Multicasting (OSPF/RIP and etc)? I am a little > confused here. > > Yi > > > Due tosome questions which came up elsewhere, I had a brief > > conversation with the ADs about multicast routing security. The > > impression I have from everyone thus far is that the msec group > > is mostly concerned with securing multicast streams, and not the > > multicast routing system. As such, I think it's appropriate to > > assume this group is going to dwal with the same areas of concern > > for multicast routing system security as unicast--defining > > requirements and such, and letting the actual working groups work > > on the protocol specific mechanisms, with this group as a meeting > > ground between the security and multicast routing folks as > > needed/etc. > > > > Just putting this out for comments.... > > > > :-) > > > > Russ > > > > __________________________________ > > riw@cisco.com CCIE <>< Grace Alone > > > > > > > > _______________________________________________ > > RPSEC mailing list > > RPSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/rpsec > > > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri Apr 12 14:32:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29854 for ; Fri, 12 Apr 2002 14:32:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02946; Fri, 12 Apr 2002 14:22:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02911 for ; Fri, 12 Apr 2002 14:22:33 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29563 for ; Fri, 12 Apr 2002 14:22:31 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA24655 for ; Fri, 12 Apr 2002 14:22:03 -0400 (EDT) Date: Fri, 12 Apr 2002 14:21:34 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@cisco.com Subject: Re: [RPSEC] Multicast Routing System Security.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Fri, 12 Apr 2002 14:21:58 -0400 (EDT) ReSent-From: Russ White ReSent-To: rpsec@ietf.org ReSent-Subject: Re: [RPSEC] Multicast Routing System Security.... ReSent-Message-ID: Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org My (personal) take on this, after some thought, is that the work should still be done in the protocol groups. It would be a bad thing for a group over in the security area to work on security systems for PIM, or other multicast routing protocols. That work should be undertaken in the working groups for those protocols. Similarly, I think that work undertaken to be define the security requirements for multicast routing should also be in routing, so it seems to me that it should be here. :-) Russ On Fri, 12 Apr 2002, Russ White wrote: > > Okay, then we'll need some clarification, I think, which is why I > bring it up. Bil? Alex? Anyone? > > :-) > > Russ > > On Fri, 12 Apr 2002, Haixiang He wrote: > > > As Thomas said in the RPsec BOF, IRTF GSEC WG has started discussing > > Multicast Infrastructure Security (multicast routing system security). > > The focus right now is IGMP security and we had a discussion on IGMP > > Security Problem Statement and Requirements and some solutions in > > Mpls.(I personally think IGMP is part of multicast routing system.) > > Thanks! > > > > Regards, > > > > Haixiang > > > > Russ White wrote: > > > > > Y'all: > > > > > > Due tosome questions which came up elsewhere, I had a brief > > > conversation with the ADs about multicast routing security. The > > > impression I have from everyone thus far is that the msec group > > > is mostly concerned with securing multicast streams, and not the > > > multicast routing system. As such, I think it's appropriate to > > > assume this group is going to dwal with the same areas of concern > > > for multicast routing system security as unicast--defining > > > requirements and such, and letting the actual working groups work > > > on the protocol specific mechanisms, with this group as a meeting > > > ground between the security and multicast routing folks as > > > needed/etc. > > > > > > Just putting this out for comments.... > > > > > > :-) > > > > > > Russ > > > > > > __________________________________ > > > riw@cisco.com CCIE <>< Grace Alone > > > > > > _______________________________________________ > > > RPSEC mailing list > > > RPSEC@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri Apr 12 15:26:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01463 for ; Fri, 12 Apr 2002 15:26:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06472; Fri, 12 Apr 2002 15:15:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06438 for ; Fri, 12 Apr 2002 15:15:35 -0400 (EDT) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01020 for ; Fri, 12 Apr 2002 15:15:32 -0400 (EDT) Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g3CJBlO25304; Fri, 12 Apr 2002 12:11:47 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (THARDJONO-LAP [10.35.42.239]) by vhqpostal-gw1.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G4SCZRBY; Fri, 12 Apr 2002 12:16:51 -0700 Message-Id: <5.0.0.25.2.20020412143238.019af670@10.25.1.45> X-Sender: thardjono@10.25.1.45 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 12 Apr 2002 15:16:49 -0400 To: Russ White , rpsec@ietf.org From: Thomas Hardjono Subject: Re: [RPSEC] Multicast Routing System Security.... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org I think RPSEC would be effective if it could focus on (a) addressing the unicast routing protocols for the moment, and (b) to get vendors to implement it. (I realize the current RPSEC charter doesn't say anything about vendors or implementations, but I think (b) should be the unwritten end-goal). Also, if you can solve needs related to unicast routing security, it will also help with some multicast routing protocols For example, a group-authentication or source-authentication method for broadcast of a message in a unicast flood/prune protocol may be useful for a multicast routing protocol that uses a special-multicast-routers group. W.R.T. multicast routing and MSEC. Multicast routing security was part of the SMuG end-goal. The folks at SMuG quickly realized thatin a multicast routing protocol (e.g. PIM-SM) that employed IP multicast itself to disseminate routing-related messages, some form of cryptographic MAC or signing would be needed. This, in turn, would need functions for key management, namely group-key management and group-SA management for the sepcial-multicast group. Hence the initial focus in SMuG on group-key and group-SA management, which happens to be the first piece work to be formally passed-on from SMuG RG to MSEC WG. I don't expect the Security-ADs to be aware of this history, as SMuG was run under the IRTF. I think the Security-ADs are only aware of the pieces of SMuG that has been passed-on to MSEC WG. I copy the following three items below from a piece of text written in SMuG about 3 years ago regarding the roadmap ahead for SMuG. (Note that 3 years ago MSEC did not exist). Item (2) refers to multicast routing security. SMuG General Roadmap: -------------------- 1. End-to-End data protection: Data protection consists of the application of cryptographic means end-to-end to ensure that data delivered through the multicast group is protection against illegal modifications (data integrity), that the data is verifiable as coming from its original sender (source authentication) and that the data is only readable by valid members of the group (data confidentiality). The use of cryptography entails the delivery and management of keying material to valid members of the group. 2. Multicast distribution tree protection: The multicast distribution tree protection typically consists of security mechanisms to ensure that tree behavior follows the specified protocol. In practice, this entails the protection of the control messages exchanged amongst tree-entities, resulting in the correct operation of the tree. Examples of this includes authentication of control messages in M-OSPF and in PIMv2. Although the aim is uniform across all routing protocols, the methods used to achieved tree protection is specific to each multicast routing protocol. 3. Membership access control at the subnet level: Membership access control at the subnet level consists of membership authentication/verification of the Querier (host) in a subnet in the context of a specific multicast group. In general this consists of the host proving its membership eligibility to a trusted authority in the subnet (eg. an authentication server, the subnet router, or others). thomas ------ At 4/12/2002||08:22 AM, Russ White wrote: >Y'all: > >Due tosome questions which came up elsewhere, I had a brief >conversation with the ADs about multicast routing security. The >impression I have from everyone thus far is that the msec group >is mostly concerned with securing multicast streams, and not the >multicast routing system. As such, I think it's appropriate to >assume this group is going to dwal with the same areas of concern >for multicast routing system security as unicast--defining >requirements and such, and letting the actual working groups work >on the protocol specific mechanisms, with this group as a meeting >ground between the security and multicast routing folks as >needed/etc. > >Just putting this out for comments.... > >:-) > >Russ > >__________________________________ >riw@cisco.com CCIE <>< Grace Alone > > > >_______________________________________________ >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-admin@ietf.org Fri Apr 12 15:35:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01784 for ; Fri, 12 Apr 2002 15:35:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07381; Fri, 12 Apr 2002 15:27:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07331 for ; Fri, 12 Apr 2002 15:27:39 -0400 (EDT) Received: from chrome.nexsi.com (system149.nexsi.com [66.35.207.149]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01522; Fri, 12 Apr 2002 15:27:35 -0400 (EDT) Received: from khonsu.Winnet.NEXSI.NET (khonsu.winnet.nexsi.net [192.168.104.132]) by chrome.nexsi.com (Postfix) with ESMTP id 93562F02E; Fri, 12 Apr 2002 12:27:30 -0700 (PDT) Date: Fri, 12 Apr 2002 12:23:38 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.60c) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <98265808782.20020412122338@nexsi.com> To: rpsec-admin@ietf.org, Russ White Cc: Haixiang He , Russ White , rpsec@ietf.org Subject: Re: [RPSEC] Multicast Routing System Security.... In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Russ, all: My position is that RPSEC should deal with security requirements for all routing protocols (including the multicast ones), and function as a forum for RTG & SEC cooperation. And yes, I envision protocol-specific work being done within the protocol WGs with possible input from GSEC or other RGs if this is applicable. Regarding MSEC, my reading of its charter is that it is supposed to work on securing communication within the group (i.e. actual data senders and receivers) and not the routing piece of story. I'll let the SEC ADs correct me if necessary. So, I guess, I have just confirmed what Russ said in his first e-mail in this thread. Alex Friday, April 12, 2002, 8:44:14 AM, Russ White wrote: > Okay, then we'll need some clarification, I think, which is why I > bring it up. Bil? Alex? Anyone? > :-) > Russ > On Fri, 12 Apr 2002, Haixiang He wrote: >> As Thomas said in the RPsec BOF, IRTF GSEC WG has started discussing >> Multicast Infrastructure Security (multicast routing system security). >> The focus right now is IGMP security and we had a discussion on IGMP >> Security Problem Statement and Requirements and some solutions in >> Mpls.(I personally think IGMP is part of multicast routing system.) >> Thanks! >> >> Regards, >> >> Haixiang >> >> Russ White wrote: >> >> > Y'all: >> > >> > Due tosome questions which came up elsewhere, I had a brief >> > conversation with the ADs about multicast routing security. The >> > impression I have from everyone thus far is that the msec group >> > is mostly concerned with securing multicast streams, and not the >> > multicast routing system. As such, I think it's appropriate to >> > assume this group is going to dwal with the same areas of concern >> > for multicast routing system security as unicast--defining >> > requirements and such, and letting the actual working groups work >> > on the protocol specific mechanisms, with this group as a meeting >> > ground between the security and multicast routing folks as >> > needed/etc. >> > >> > Just putting this out for comments.... >> > >> > :-) >> > >> > Russ >> > >> > __________________________________ >> > riw@cisco.com CCIE <>< Grace Alone >> > >> > _______________________________________________ >> > RPSEC mailing list >> > RPSEC@ietf.org >> > https://www1.ietf.org/mailman/listinfo/rpsec >> > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > _______________________________________________ > 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-admin@ietf.org Fri Apr 12 18:18:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05431 for ; Fri, 12 Apr 2002 18:18:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17395; Fri, 12 Apr 2002 18:18:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17361 for ; Fri, 12 Apr 2002 18:18:17 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05413 for ; Fri, 12 Apr 2002 18:18:12 -0400 (EDT) Received: from aretana-u10.cisco.com (aretana-u10.cisco.com [64.102.48.77]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3CMHj88020961; Fri, 12 Apr 2002 15:17:45 -0700 (PDT) Date: Fri, 12 Apr 2002 18:17:44 -0400 (EDT) From: Alvaro Retana To: Thomas Hardjono cc: Russ White , Subject: Re: [RPSEC] Multicast Routing System Security.... In-Reply-To: <5.0.0.25.2.20020412143238.019af670@10.25.1.45> Message-ID: X-Save: no MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org On Fri, 12 Apr 2002, Thomas Hardjono wrote: Thomas: -> Also, if you can solve needs related to unicast routing security, it -> will also help with some multicast routing protocols For example, a -> group-authentication or source-authentication method for broadcast of a -> message in a unicast flood/prune protocol may be useful for a multicast -> routing protocol that uses a special-multicast-routers group. -> -> W.R.T. multicast routing and MSEC. Multicast routing security was part -> of the SMuG end-goal. The folks at SMuG quickly realized thatin a -> multicast routing protocol (e.g. PIM-SM) that employed IP multicast -> itself to disseminate routing-related messages, some form of -> cryptographic MAC or signing would be needed. This, in turn, would -> need functions for key management, namely group-key management and -> group-SA management for the sepcial-multicast group. -> -> Hence the initial focus in SMuG on group-key and group-SA management, -> which happens to be the first piece work to be formally passed-on from -> SMuG RG to MSEC WG. That's exactly it! :-) Note that the distinction between unicast and multicast RPs is not necessarily the method used to propagate the information, but the information that they propagate. 8-) My point is that unicast RPs (OSPF, for example) *also* use IP multicast to propagate routing information (the hello protocol and the route propagation to DRs on a LAN are two examples). In other words, the work in MSEC realted to group key management, etc. is definetly of interest to the unicast RPs...and is part of the "routing system". Bringing us back to the overlap...or the need to clearly define where the boundaries are. If both WGs are going to work on different parts of the 'routing system'...clear limits and collaboration must exist. My 2c. Alvaro. -> 2. Multicast distribution tree protection: -> The multicast distribution tree protection typically consists of security -> mechanisms to ensure that tree behavior follows the specified -> protocol. In practice, this entails the protection of the control -> messages exchanged amongst tree-entities, resulting in the correct -> operation of the tree. Examples of this includes authentication of -> control messages in M-OSPF and in PIMv2. Although the aim is -> uniform across all routing protocols, the methods used to achieved -> tree protection is specific to each multicast routing protocol. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Sun Apr 14 08:26:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17234 for ; Sun, 14 Apr 2002 08:26:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26937; Sun, 14 Apr 2002 08:25:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26905 for ; Sun, 14 Apr 2002 08:25:26 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17230 for ; Sun, 14 Apr 2002 08:25:23 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA13648 for ; Sun, 14 Apr 2002 08:24:55 -0400 (EDT) Date: Sun, 14 Apr 2002 08:24:55 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Charter Update.... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org One minor change.... ---- Routing Protocol Security Requirements (rpsec) CHAIRS: Russ White (riw@cisco.com) Marcus Leech (mleech@nortelnetworks.com) Description ----------- 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 protcool designers to ensure adequate coverage of security in the future, including well known and possible threats. The RPSEC working group is charged with the following tasks: - Document threat models for routing systems - Document security requirements for routing systems - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Proposed WG milestones: 1. Jul 2002: Submit initial I-D (or set of I-Ds) which details the threats to routing systems. 2. Oct 2002: Submit initial I-D (or set of I-Ds) which outlines security requirements for routing systems. 3. Dec 2002: Submit I-Ds documenting threats to routing systems for publication as Informational RFC. 4. Mar 2003: Submit the I-D documenting security requirements to routing systems for publication as Informational RFC. 5. Mar 2003: Evaluate progress, recharter with new goals (see possible future work below) or shutdown. Possible Future Work -------------------- - Document the feasibility of various types of security mechinisms within routing systems - Document requirements for new security mechanisms - Document security requirements for the next generation routing system __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Sun Apr 14 08:39:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17300 for ; Sun, 14 Apr 2002 08:39:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27576; Sun, 14 Apr 2002 08:38:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27537 for ; Sun, 14 Apr 2002 08:38:37 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17287 for ; Sun, 14 Apr 2002 08:38:33 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA13945; Sun, 14 Apr 2002 08:38:00 -0400 (EDT) Date: Sun, 14 Apr 2002 08:38:00 -0400 (EDT) From: Russ White Reply-To: Russ White To: Alvaro Retana cc: Thomas Hardjono , rpsec@ietf.org Subject: Re: [RPSEC] Multicast Routing System Security.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > Bringing us back to the overlap...or the need to clearly > define where the boundaries are. If both WGs are going to > work on different parts of the 'routing system'...clear > limits and collaboration must exist. Agreed.... I think we should address the same stuff in multicast that we are in unicast--requirements, etc.--and let other groups do the actual mechanisms. I'm surprised the actual mechanisms aren't in the pim and other multicast-rp groups, though, rather than in a security group. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue Apr 16 12:20:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13849 for ; Tue, 16 Apr 2002 12:20:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27123; Tue, 16 Apr 2002 12:19:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27088 for ; Tue, 16 Apr 2002 12:19:46 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13713 for ; Tue, 16 Apr 2002 12:19:41 -0400 (EDT) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id MAA21920 for ; Tue, 16 Apr 2002 12:19:40 -0400 (EDT) Received: from DonVaioNT (DONVAIONT.arin.net [192.149.252.235]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA18398 for ; Tue, 16 Apr 2002 12:19:39 -0400 (EDT) From: "Don Wilder" To: Subject: RE: [RPSEC] Charter Update.... Date: Tue, 16 Apr 2002 12:19:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Looks good to me... :) Don Wilder American Registry for Internet Numbers > -----Original Message----- > From: rpsec-admin@ietf.org [mailto:rpsec-admin@ietf.org]On Behalf Of > Russ White > Sent: Sunday, April 14, 2002 8:25 AM > To: rpsec@ietf.org > Subject: [RPSEC] Charter Update.... > > > > One minor change.... > > ---- > > Routing Protocol Security Requirements (rpsec) > > CHAIRS: Russ White (riw@cisco.com) > Marcus Leech (mleech@nortelnetworks.com) > > > Description > ----------- > > 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 protcool > designers to ensure adequate coverage of security in the future, > including well known and possible threats. > > The RPSEC working group is charged with the following tasks: > > - Document threat models for routing systems > - Document security requirements for routing systems > - Provide a common area for discussion between security and routing > experts on the topic of securing the routing system > > Proposed WG milestones: > > 1. Jul 2002: Submit initial I-D (or set of I-Ds) which details > the threats to routing systems. > > 2. Oct 2002: Submit initial I-D (or set of I-Ds) which outlines > security requirements for routing systems. > > 3. Dec 2002: Submit I-Ds documenting threats to routing systems > for publication as Informational RFC. > > 4. Mar 2003: Submit the I-D documenting security requirements to > routing systems for publication as Informational RFC. > > 5. Mar 2003: Evaluate progress, recharter with new goals (see possible > future work below) or shutdown. > > Possible Future Work > -------------------- > > - Document the feasibility of various types of security mechinisms > within routing systems > - Document requirements for new security mechanisms > - Document security requirements for the next generation routing > system _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue Apr 16 12:30:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15173 for ; Tue, 16 Apr 2002 12:30:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27509; Tue, 16 Apr 2002 12:29:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27477 for ; Tue, 16 Apr 2002 12:29:42 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15059 for ; Tue, 16 Apr 2002 12:29:38 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25935; Tue, 16 Apr 2002 12:29:04 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24528; Tue, 16 Apr 2002 12:29:04 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Apr 2002 12:28:57 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55763106@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: rpsec@ietf.org Cc: "'irtf-rr@pukc.nether.net'" Subject: RE: [RPSEC] Charter Update....NextGen Routing Security Date: Tue, 16 Apr 2002 12:29:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org -> > - Document security requirements for the next generation routing -> > system IRTF RRG Group A and B are working on this. Isn't this a duplicate work *or* Is that RPSEC going to work with IRTF RRG?!? Venkata. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue Apr 16 12:33:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15634 for ; Tue, 16 Apr 2002 12:33:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28070; Tue, 16 Apr 2002 12:32:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28031 for ; Tue, 16 Apr 2002 12:32:30 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15543 for ; Tue, 16 Apr 2002 12:32:27 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26250; Tue, 16 Apr 2002 12:31:45 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA25258; Tue, 16 Apr 2002 12:31:45 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Apr 2002 12:31:38 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55763107@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'rpsec@ietf.org'" Cc: "'irtf-rr@puck.nether.net'" Subject: RE: [RPSEC] Charter Update....NextGen Routing Security Date: Tue, 16 Apr 2002 12:31:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org -> > - Document security requirements for the next generation routing -> > system IRTF RRG Group A and B are working on this. Isn't this a duplicate work *or* Is that RPSEC going to work with IRTF RRG?!? Venkata. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue Apr 16 13:37:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24170 for ; Tue, 16 Apr 2002 13:37:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01906; Tue, 16 Apr 2002 13:37:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01869 for ; Tue, 16 Apr 2002 13:37:02 -0400 (EDT) Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24052 for ; Tue, 16 Apr 2002 13:36:59 -0400 (EDT) Received: from bgreenew2k (dhcp-10-24-19-68.cisco.com [10.24.19.68]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA20299; Tue, 16 Apr 2002 10:36:23 -0700 (PDT) From: "Barry Raveendran Greene" To: "Naidu, Venkata" , Cc: Subject: RE: [RPSEC] Charter Update....NextGen Routing Security Date: Tue, 16 Apr 2002 10:35:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <39469E08BD83D411A3D900204840EC55763106@vie-msgusr-01.dc.fore.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit What the status of this work? It would be nice to sync any sort of router security requirements work. There are a couple of other efforts out there. > -----Original Message----- > From: rpsec-admin@ietf.org [mailto:rpsec-admin@ietf.org]On Behalf Of > Naidu, Venkata > Sent: Tuesday, April 16, 2002 9:29 AM > To: rpsec@ietf.org > Cc: 'irtf-rr@pukc.nether.net' > Subject: RE: [RPSEC] Charter Update....NextGen Routing Security > > > -> > - Document security requirements for the next generation routing > -> > system > > IRTF RRG Group A and B are working on this. > Isn't this a duplicate work *or* > Is that RPSEC going to work with IRTF RRG?!? > > Venkata. > > _______________________________________________ > 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-admin@ietf.org Tue Apr 16 13:51:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25896 for ; Tue, 16 Apr 2002 13:51:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02518; Tue, 16 Apr 2002 13:51:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02479 for ; Tue, 16 Apr 2002 13:51:02 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25802 for ; Tue, 16 Apr 2002 13:50:55 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05699; Tue, 16 Apr 2002 13:50:19 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14767; Tue, 16 Apr 2002 13:50:19 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Apr 2002 13:50:12 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55763108@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Barry Raveendran Greene'" , rpsec@ietf.org Cc: "'irtf-rr@puck.nether.net'" Subject: RE: [RPSEC] Charter Update....NextGen Routing Security Date: Tue, 16 Apr 2002 13:50:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Barry: -> What the status of this work? You might want to look at section 3.9 (Group A) http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-groupa-00.txt AND section 2.3.8 and section 9 in (Group B) http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-groupb-00.txt -> It would be nice to sync any sort of router security -> requirements work. Yes! -> There are a couple of other efforts out there. What are the other Routing Security work you are referring? Venkata. -> > -----Original Message----- -> > From: rpsec-admin@ietf.org [mailto:rpsec-admin@ietf.org]On -> Behalf Of -> > Naidu, Venkata -> > Sent: Tuesday, April 16, 2002 9:29 AM -> > To: rpsec@ietf.org -> > Cc: 'irtf-rr@puck.nether.net' -> > Subject: RE: [RPSEC] Charter Update....NextGen Routing Security -> > -> > -> > -> > - Document security requirements for the next -> generation routing -> > -> > system -> > -> > IRTF RRG Group A and B are working on this. -> > Isn't this a duplicate work *or* -> > Is that RPSEC going to work with IRTF RRG?!? -> > -> > Venkata. -> > -> > _______________________________________________ -> > 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-admin@ietf.org Tue Apr 16 15:09:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05502 for ; Tue, 16 Apr 2002 15:09:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07936; Tue, 16 Apr 2002 15:09:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07901 for ; Tue, 16 Apr 2002 15:09:01 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05427 for ; Tue, 16 Apr 2002 15:08:57 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id PAA24032; Tue, 16 Apr 2002 15:14:48 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma024017; Tue, 16 Apr 02 15:14:35 -0400 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g3GJ8ju13245; Tue, 16 Apr 2002 15:08:45 -0400 (EDT) Date: Tue, 16 Apr 2002 15:08:45 -0400 (EDT) Message-Id: <200204161908.g3GJ8ju13245@raven.gw.tislabs.com> To: Venkata.Naidu@marconi.com, bgreene@cisco.com, rpsec@ietf.org Subject: RE: [RPSEC] Charter Update....NextGen Routing Security Cc: irtf-rr@pukc.nether.net Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >What the status of this work? It would be nice to sync any sort of router >security requirements work. There are a couple of other efforts out there. The irtf work divided itself into two groups. Each has mentioned security in their requirements documents. See: draft-irtf-routing-reqs-groupb-00.txt Future Domain Routing Requirements Group B contribution (Avri Doria, Elwyn Davies) and draft-irtf-routing-reqs-groupa-00.txt Requirements For a Next Generation Routing and Addressing Architecture (Frank Kastenholz) (Actually, Frank refers to the second group as "Group ~B" and in "not B") --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue Apr 16 17:37:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23198 for ; Tue, 16 Apr 2002 17:37:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16233; Tue, 16 Apr 2002 17:37:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16199 for ; Tue, 16 Apr 2002 17:37:00 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23129 for ; Tue, 16 Apr 2002 17:36:56 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA27550; Tue, 16 Apr 2002 17:36:27 -0400 (EDT) Date: Tue, 16 Apr 2002 17:36:27 -0400 (EDT) From: Russ White Reply-To: Russ White To: "Naidu, Venkata" cc: "'Barry Raveendran Greene'" , rpsec@ietf.org, "'irtf-rr@puck.nether.net'" Subject: RE: [RPSEC] Charter Update....NextGen Routing Security In-Reply-To: <39469E08BD83D411A3D900204840EC55763108@vie-msgusr-01.dc.fore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org But are they stating what security should look like, with what capabilities, and defining what security means within a routing protocol, or more of just stating that the nextgen routing protocol must be secure? I think there is a difference between the two, most likely, although they should be coordinated. I also think this is a possible future work item, right, rather than a current one. So, we could coordinate with the irtf groups when that comes to it, or they could hand that part off to this group to define more clearly on top of what they've laid out the groundwork for. :-) Russ On Tue, 16 Apr 2002, Naidu, Venkata wrote: > Barry: > > -> What the status of this work? > > You might want to look at section 3.9 (Group A) > http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-groupa-00.txt > > AND section 2.3.8 and section 9 in (Group B) > http://www.ietf.org/internet-drafts/draft-irtf-routing-reqs-groupb-00.txt > > -> It would be nice to sync any sort of router security > -> requirements work. > > Yes! > > -> There are a couple of other efforts out there. > > What are the other Routing Security work you are referring? > > Venkata. > > -> > -----Original Message----- > -> > From: rpsec-admin@ietf.org [mailto:rpsec-admin@ietf.org]On > -> Behalf Of > -> > Naidu, Venkata > -> > Sent: Tuesday, April 16, 2002 9:29 AM > -> > To: rpsec@ietf.org > -> > Cc: 'irtf-rr@puck.nether.net' > -> > Subject: RE: [RPSEC] Charter Update....NextGen Routing Security > -> > > -> > > -> > -> > - Document security requirements for the next > -> generation routing > -> > -> > system > -> > > -> > IRTF RRG Group A and B are working on this. > -> > Isn't this a duplicate work *or* > -> > Is that RPSEC going to work with IRTF RRG?!? > -> > > -> > Venkata. > -> > > -> > _______________________________________________ > -> > 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 > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Wed Apr 17 14:02:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29630 for ; Wed, 17 Apr 2002 14:02:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04423; Wed, 17 Apr 2002 14:01:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03310 for ; Wed, 17 Apr 2002 13:50:39 -0400 (EDT) Received: from mailwest2.unispherenetworks.com (mailwest2.unispheresolutions.com [65.194.140.146]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29316 for ; Wed, 17 Apr 2002 13:50:33 -0400 (EDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <2V5HNZMR>; Wed, 17 Apr 2002 13:45:32 -0400 Received: from fkastenholzpc.unispherenetworks.com (FKASTENHOLZPC [10.10.121.110]) by mailwest.unispherenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2V5N3HJW; Wed, 17 Apr 2002 13:49:56 -0400 Message-ID: <5.0.2.1.2.20020417134758.00ae6ac0@uniwest1> From: "Kastenholz, Frank" To: "Naidu, Venkata" , "'rpsec@ietf.org'" Cc: "'irtf-rr@puck.nether.net'" Subject: RE: [RPSEC] Charter Update....NextGen Routing Security Date: Wed, 17 Apr 2002 13:52:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org At 12:31 PM 4/16/02 -0400, Naidu, Venkata wrote: >-> > - Document security requirements for the next generation routing >-> > system > > IRTF RRG Group A and B are working on this. > Isn't this a duplicate work *or* > Is that RPSEC going to work with IRTF RRG?!? > >Venkata. First, the RRG does not have a monopoly on routing work :-) Second, if the RPSEC group takes the work we've done and carrys it forward, perhaps adding more detailed information, perhaps doing some of the engineering to apply enhanced security features to current protocols, perhaps identifying new threats that need to be addressed, etc, etc, well, isn't that the way things should work? In the requirements development that we do, we can always spin our documents to refer to the work in RPSEC (and vice versa). I do not see this as an issue to worry about. Frank Kastenholz co-chair, IRTF RRG ================================================== My preferrred signature is: This information is for the sole use of whoever receives it and may contain confusing, enlightening, enraging, entertaining, irritating, or just plain stupid information, including without limitation, double-secret- probation information belonging to [CENSORED BY THE NSA/FBI/MOUSE]. Any unauthorized review, use, disclosure, or distribution outside of an establishment serving alchohol is prohibited on days that do not end in Y. But our ******'d lawyers would rather have: ======================================= This email message is for the sole use of the intended recipient (s) and may contain confidential and privileged information, including without limitation, Confidential and/or Proprietary Information belonging to Unisphere Networks, Inc. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Mon Apr 22 16:21:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11622 for ; Mon, 22 Apr 2002 16:21:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16817; Mon, 22 Apr 2002 16:19:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16783 for ; Mon, 22 Apr 2002 16:19:36 -0400 (EDT) Received: from rftzy05y.ca.nortel.com (h161s130a130n47.user.nortelnetworks.com [47.130.130.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11537 for ; Mon, 22 Apr 2002 16:19:32 -0400 (EDT) Received: from rftzy232.ca.nortel.com (rftzy232.ca.nortel.com [47.129.192.32]) by rftzy05y.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3MKJ3P28112 for ; Mon, 22 Apr 2002 16:19:03 -0400 (EDT) Received: from NORTELNETWORKS.COM (wcarh0vc.ca.nortel.com [47.129.148.226]) by rftzy232.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JKNVBTKK; Mon, 22 Apr 2002 16:18:15 -0400 Message-ID: <3CC47046.A13EE5F7@NORTELNETWORKS.COM> Date: Mon, 22 Apr 2002 16:19:18 -0400 From: "Leech, Marcus (EXCHANGE:FITZ:8M86)" X-Mailer: Mozilla 4.73C-CCK-MCD [en] (X11; U; HP-UX B.10.20 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: rpsec@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [RPSEC] Charter munging Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit I've been away on vacation for the last two weeks, so I'm just catching up now. With respect to "future" work: Possible Future Work -------------------- - Document the feasibility of various types of security mechinisms within routing systems - Document requirements for new security mechanisms - Document security requirements for the next generation routing system I would change it to: - Evaluate and document existing and proposed routing security mechanisms with respect to established RPSEC requirements - Recommend mechanism(s) -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Security Architecture and Planning Fax: (ESN) 393-9435 +1 613 763 9435 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue Apr 23 09:20:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16595 for ; Tue, 23 Apr 2002 09:20:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29229; Tue, 23 Apr 2002 09:19:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29197 for ; Tue, 23 Apr 2002 09:19:31 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16543 for ; Tue, 23 Apr 2002 09:19:22 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3NDIsM14322 for ; Tue, 23 Apr 2002 09:18:54 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 09:18:54 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E602111D02@zcard0ke.ca.nortel.com> From: "Dennis Beard" To: "Marcus Leech", rpsec@ietf.org Subject: RE: [RPSEC] Charter munging Date: Tue, 23 Apr 2002 09:18:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EAC9.6C553D7A" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1EAC9.6C553D7A Content-Type: text/plain; charset="ISO-8859-1" I like the new words. Says about the same thing but smoother yet still keeps the goal of recommending RP security requirements. Cheers, Dennis Beard -----Original Message----- From: Leech, Marcus [CAR:8M70:EXCH] Sent: Monday, April 22, 2002 4:19 PM To: rpsec@ietf.org Subject: [RPSEC] Charter munging I've been away on vacation for the last two weeks, so I'm just catching up now. With respect to "future" work: Possible Future Work -------------------- - Document the feasibility of various types of security mechinisms within routing systems - Document requirements for new security mechanisms - Document security requirements for the next generation routing system I would change it to: - Evaluate and document existing and proposed routing security mechanisms with respect to established RPSEC requirements - Recommend mechanism(s) -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M70, MS 012, FITZ Advisor Phone: (ESN) 393-9145 +1 613 763 9145 Security Architecture and Planning Fax: (ESN) 393-9435 +1 613 763 9435 Nortel Networks mleech@nortelnetworks.com -----------------Expressed opinions are my own, not my employer's------ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec ------_=_NextPart_001_01C1EAC9.6C553D7A Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [RPSEC] Charter munging

I like the new words.  Says about the same thing = but smoother yet still keeps the goal of recommending RP security = requirements.

Cheers,

Dennis Beard

-----Original Message-----
From: Leech, Marcus [CAR:8M70:EXCH]
Sent: Monday, April 22, 2002 4:19 PM
To: rpsec@ietf.org
Subject: [RPSEC] Charter munging


I've been away on vacation for the last two weeks, so = I'm just catching up now.

With respect to "future" work:

  Possible Future Work
  --------------------

   - Document the feasibility of various = types of security mechinisms
     within routing = systems
   - Document requirements for new = security mechanisms
   - Document security requirements for = the next generation routing
     system

I would change it to:

   - Evaluate and document existing and = proposed routing security mechanisms with
     respect to established = RPSEC requirements

   - Recommend mechanism(s)



--
---------------------------------------------------------------= -------
Marcus = Leech           &= nbsp;           &= nbsp;     Mail:   Dept 8M70, MS 012, = FITZ
Advisor         &n= bsp;           &n= bsp;            = Phone: (ESN) 393-9145  +1 613 763 9145
Security Architecture and = Planning       Fax:   (ESN) = 393-9435  +1 613 763 9435
Nortel = Networks          &nbs= p;           &nbs= p;   mleech@nortelnetworks.com
-----------------Expressed opinions are my own, not = my employer's------

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec

------_=_NextPart_001_01C1EAC9.6C553D7A-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue Apr 23 09:27:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16776 for ; Tue, 23 Apr 2002 09:27:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29621; Tue, 23 Apr 2002 09:26:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29588 for ; Tue, 23 Apr 2002 09:26:26 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16761 for ; Tue, 23 Apr 2002 09:26:22 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA27355; Tue, 23 Apr 2002 09:25:46 -0400 (EDT) Date: Tue, 23 Apr 2002 09:25:45 -0400 (EDT) From: Russ White Reply-To: Russ White To: Dennis Beard cc: Marcus Leech , rpsec@ietf.org Subject: RE: [RPSEC] Charter munging In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E602111D02@zcard0ke.ca.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org 'kay.... I'll send out a new version in a bit with this wording. :-) Russ On Tue, 23 Apr 2002, Dennis Beard wrote: > I like the new words. Says about the same thing but smoother yet still > keeps the goal of recommending RP security requirements. > > Cheers, > > Dennis Beard > > -----Original Message----- > From: Leech, Marcus [CAR:8M70:EXCH] > Sent: Monday, April 22, 2002 4:19 PM > To: rpsec@ietf.org > Subject: [RPSEC] Charter munging > > > I've been away on vacation for the last two weeks, so I'm just catching up > now. > > With respect to "future" work: > > Possible Future Work > -------------------- > > - Document the feasibility of various types of security mechinisms > within routing systems > - Document requirements for new security mechanisms > - Document security requirements for the next generation routing > system > > I would change it to: > > - Evaluate and document existing and proposed routing security mechanisms > with > respect to established RPSEC requirements > > - Recommend mechanism(s) > > > > -- > ---------------------------------------------------------------------- > Marcus Leech Mail: Dept 8M70, MS 012, FITZ > Advisor Phone: (ESN) 393-9145 +1 613 763 > 9145 > Security Architecture and Planning Fax: (ESN) 393-9435 +1 613 763 > 9435 > Nortel Networks mleech@nortelnetworks.com > -----------------Expressed opinions are my own, not my employer's------ > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Sun Apr 28 21:21:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20543 for ; Sun, 28 Apr 2002 21:21:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06947; Sun, 28 Apr 2002 21:14:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06919 for ; Sun, 28 Apr 2002 21:14:40 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20080 for ; Sun, 28 Apr 2002 21:14:34 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA22522; Sun, 28 Apr 2002 21:14:08 -0400 (EDT) Date: Sun, 28 Apr 2002 21:14:08 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@ietf.org cc: Bill Fenner , alexzinin@attbi.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Charter Draft Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Okay, this is what I have thus far. I'd like to get Bill and Alex to turn this over to the IESG real soon now, as in the next day or two, so if anyone has comments, please hurry them along. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone ----- Operation of the Routing Protocol Security Requirements Working Group (rpsec) ----------------------------------------------------------------------------- Charter Last Modified: 28-Apr-02 Current Status: Proposed Working Group Chairs: Russ White (riw@cisco.com) Marcus Leech (mleech@nortelnetworks.com) General Area Directors: Alex Zinin (zinin@psg.com) Bill Fenner (fenner@research.att.com Mailing Lists: General Discussion: rpsec@ietf.org To Subscribe: rpsec-request@ietf.org Description of Working Group: 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 protcool designers to ensure adequate coverage of security in the future, including well known and possible threats. The RPSEC working group is charged with the following tasks: - Document threat models for routing systems - Document security requirements for routing systems - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Goals and Milestones: Aug 2002: Submit initial I-D (or set of I-Ds) which details the threats to routing systems. Nov 2002: Submit initial I-D (or set of I-Ds) which outlines security requirements for routing systems. Jan 2003: Submit I-Ds documenting threats to routing systems for publication as Informational RFC. Apr 2003: Submit the I-D documenting security requirements to routing systems for publication as Informational RFC. Jun 2003: Evaluate progress, recharter with new goals (see possible future work below) or shutdown. Possible Future Work: o Document the feasibility of various types of security mechinisms within routing systems o Document requirements for new security mechanisms o Document security requirements for the next generation routing system _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec