From exim@www1.ietf.org Mon Mar 1 10:21:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02125 for ; Mon, 1 Mar 2004 10:21:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxpEE-00082x-R3 for rpsec-archive@odin.ietf.org; Mon, 01 Mar 2004 10:21:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21FLA6w030925 for rpsec-archive@odin.ietf.org; Mon, 1 Mar 2004 10:21:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxpEE-00082f-Ms for rpsec-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 10:21:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01972 for ; Mon, 1 Mar 2004 10:21:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxpEC-0005uF-00 for rpsec-web-archive@ietf.org; Mon, 01 Mar 2004 10:21:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axoei-0005cJ-00 for rpsec-web-archive@ietf.org; Mon, 01 Mar 2004 09:44:32 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxoW2-0003KS-00 for rpsec-web-archive@ietf.org; Mon, 01 Mar 2004 09:35:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxoRq-0005TX-MX for rpsec-web-archive@ietf.org; Mon, 01 Mar 2004 09:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoRi-0006IL-DH; Mon, 01 Mar 2004 09:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoRV-0006GR-SY for rpsec@optimus.ietf.org; Mon, 01 Mar 2004 09:30:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25107 for ; Mon, 1 Mar 2004 09:30:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxoRT-00029O-00 for rpsec@ietf.org; Mon, 01 Mar 2004 09:30:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxoE6-0006QY-00 for rpsec@ietf.org; Mon, 01 Mar 2004 09:17:02 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1Axo2Y-0003YU-00 for rpsec@ietf.org; Mon, 01 Mar 2004 09:05:02 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D0E23313B28; Mon, 1 Mar 2004 06:05:00 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04796-02; Mon, 1 Mar 2004 06:05:00 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.196]) by prattle.redback.com (Postfix) with SMTP id 7C2C0313B34; Mon, 1 Mar 2004 06:04:59 -0800 (PST) Message-ID: <004f01c3ff96$2ba07860$0302a8c0@aceeinspiron> From: "Acee Lindem" To: "Mailing List" Cc: "RPSEC WG List" References: <39469E08BD83D411A3D900204840EC55FB7201@vie-msgusr-01.dc.fore.com> Date: Mon, 1 Mar 2004 09:04:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: 7bit Subject: [RPSEC] Re: OSPFv3 Destination Address Filter Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Naidu, Venkata" To: Sent: Friday, February 27, 2004 5:59 PM Subject: Re: OSPFv3 Destination Address Filter Hi Venkata, > Hi Acee, > > -> We've implemented the subject draft to mitigate some of the > -> OSPFv3 vulnerabilities. While the solution isn't perfect, it is > -> lightweight, easy to deploy, and fully compatible with the current > -> OSPFv3 specification (RFC 2740). > -> > -> http://www.ietf.org/internet-drafts/draft-lindem-ospfv3-dest- > -> filter-00.txt > > After a quick look, here are few comments: > > 1. Check should be: > if (((first-two-octets & 0xffc0) != 0xfe80) && > <<<< > ((first-two-octets & 0xff0f) != 0xff02)) { > ==== > ((first-two-octets & 0xffff) != 0xff02)) { > >>>> > drop the packet; > } > > I think, OSPFv3 SHOULD work on permanently flagged multicast > addresses not with T flag on'ed ones. We used our IPv6 stack macro that checks for a link scoped multicast. It may be somewhat better to check the flags field as well since in the case we envision usage non-zero flags will result in the packet being dropped anyway. However, strictly speaking, one does not need to check the flags in order to check for a link scoped IPv6 multicast address. I'll update either to allow both options or include the flag dependent on which seems to fit better. > > 2. The draft reads: > > The granularity of the check will limit the usage of virtual > links at the granularity which it is applied. For example, if > it is applied at the BSD socket level, virtual links may not > be used by any OSPF instance utilizing that socket. > Alternately, additional configuration and checking could be > added at the socket level so that the destination filter is > only applied to certain instances, areas, or interfaces. > > There is another way to support what this draft does with out > loss of generality. If these checks are applied at the Raw-IPv6 > stack level (using local address binding socket options) > virtual link support will not be jeopardized. > > Doing below steps will solve DOS attack for IPv4 applications > (i.e., OSPFv2, RSVP-TE etc) and IPv6 applications (i.e., OSPFv3 > etc.) - at least for the ones which operate on per interface > basis. > > 1. Bind to the local interface (either using link-layer address/ > ifindex) and make it strong-end socket. That is the socket > will accept incoming packets only from the binded interface. > > 2. Listen only for appropriate multicast address groups using > various MULTICAST socket options. This will make sure the > above checks are done at the Raw-IP level instead of at the > OSPF level. > > 3. Open another INADDR_ANY socket ONLY when virtual links are > operational. Note that, this socket will receive all types > of OSPF packets. But, that is fine, OSPF will anyway make > sure (have to make sure) validity of every packet received > on this socket. > > It is a good idea to enhance socket APIs to have filters based > on list of IP addresses instead of all-or-one (i.e., multiple > bindings like). May be, Bill Fenner can answer why it is not > incorporated in IPv6 at least. I expected this in his recent > Book. :) One could certainly support virtual links with a separate socket. However, as long as a globally routable address is used, it is subject to DOS attack and one would have to deal with substantially more complexity in terms of perferring protect socket, etc. I don't like #3 at all since my experience has been that OSPF scaling is I/O bound and receiving a given OSPF packet on more than one socket is not a good idea. If someone did want to do this I'd think the separate socket would need to support a list of bind addresses (one for each virtual link endpoint). However, IMHO, virtual links aren't that widely deployed and administrative ACLs can be used to protect OSPFv3 routers where they are used. > > Venakta. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Mar 11 20:07:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08778 for ; Thu, 11 Mar 2004 20:07:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1b8m-0005gB-Jc for rpsec-archive@odin.ietf.org; Thu, 11 Mar 2004 20:07:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C178ZU021820 for rpsec-archive@odin.ietf.org; Thu, 11 Mar 2004 20:07:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1b8m-0005fj-6G for rpsec-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 20:07:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08762 for ; Thu, 11 Mar 2004 20:07:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1b8k-0006tR-00 for rpsec-web-archive@ietf.org; Thu, 11 Mar 2004 20:07:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1b7k-0006lb-00 for rpsec-web-archive@ietf.org; Thu, 11 Mar 2004 20:06:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1b6x-0006eH-00 for rpsec-web-archive@ietf.org; Thu, 11 Mar 2004 20:05:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1b6j-0005Su-FA; Thu, 11 Mar 2004 20:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1b5v-0005RJ-GB for rpsec@optimus.ietf.org; Thu, 11 Mar 2004 20:04:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08690 for ; Thu, 11 Mar 2004 20:04:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1b5t-0006Vj-00 for rpsec@ietf.org; Thu, 11 Mar 2004 20:04:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1b59-0006NN-00 for rpsec@ietf.org; Thu, 11 Mar 2004 20:03:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B1b4P-0006E6-00 for rpsec@ietf.org; Thu, 11 Mar 2004 20:02:37 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1b4P-000N2A-My for rpsec@ietf.org; Fri, 12 Mar 2004 01:02:37 +0000 Date: Thu, 11 Mar 2004 17:02:10 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <41148965330.20040311170210@psg.com> To: rpsec@ietf.org In-Reply-To: <66148620605.20040311165625@psg.com> References: <66148620605.20040311165625@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [RPSEC] Extending RPSEC charter Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As a result of the discussion about bringing protocol-specific analysis and requirements draft to the WG, we're updating the charter. Below is my request to the secretariat. The tag identifies the places where changes have been made. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: iesg-secretary@ietf.org Cc: Date: Thursday, March 11, 2004, 4:56:25 PM Subject: Recharter: RPSEC ===8<==============Original message text=============== Please add the following updated RPSEC charter text to the telechat agenda for March 18th, and send out an IESG-internal review message. -- Alex http://www.psg.com/~zinin/ Chair(s): Tony Tauber Russ White Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Mailing Lists: General Discussion: rpsec@ietf.org To Subscribe: rpsec-request@ietf.org In Body: (un)subscribe Archive: http://www1.ietf.org/mail-archive/working-groups/rpsec 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 protocol designers to ensure adequate coverage of security in the future, including well known and possible threats. The scope of work is limited to router-to-router protocols only for both unicast and multicast systems, and does NOT include host-to-router protocol such as IGMP, ICMP, ARP, or ND. It is also a non-goal at this point to produce new or change the current security mechanisms in the existing routing protocols. The RPSEC working group is charged with the following tasks: - Document threat models for routing systems - Document security requirements for routing systems - Document security analysis and requirements for specific routing protocols (e.g., OSPF, BGP) - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Possible Future Work - Evaluate and document existing and proposed routing security mechanisms with respect to established RPSEC requirements - Recommend mechanism(s) Goals and Milestones: Done Submit initial I-D (or set of I-Ds) which details the threats to routing systems. Mar 04 Submit initial I-D (or set of I-Ds) which outlines security requirements for routing systems. Mar 04 Submit initial I-D describing BGP Attack-Tree analysis. Mar 04 Submit initial I-D describing OSPF vulnerability analysis. May 04 Submit initial I-D describing BGP security requirements. Done Submit I-Ds documenting threats to routing systems for publication as Informational RFC. Jul 04 Submit the I-D documenting security requirements to routing systems for publication as Informational RFC. Nov 04 Submit BGP Attack-Tree analysis for publication as Informational RFC. Nov 04 Submit OSPF vulnerability analysis for publication as Informational RFC. Mar 05 Submit BGP security requirements for publication as Informational RFC. May 05 Evaluate progress, recharter with new goals (see possible future work above) or shutdown. ===8<===========End of original message text=========== _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Mar 12 18:15:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26651 for ; Fri, 12 Mar 2004 18:15:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vrg-0007cW-1A for rpsec-archive@odin.ietf.org; Fri, 12 Mar 2004 18:14:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CNEq6H029288 for rpsec-archive@odin.ietf.org; Fri, 12 Mar 2004 18:14:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vrf-0007cJ-TA for rpsec-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 18:14:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26548 for ; Fri, 12 Mar 2004 18:14:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vrc-0007DE-00 for rpsec-web-archive@ietf.org; Fri, 12 Mar 2004 18:14:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1vqj-0007Ai-00 for rpsec-web-archive@ietf.org; Fri, 12 Mar 2004 18:13:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1vpw-00078A-00 for rpsec-web-archive@ietf.org; Fri, 12 Mar 2004 18:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vps-00074B-HT; Fri, 12 Mar 2004 18:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1vpe-00070v-HG for rpsec@optimus.ietf.org; Fri, 12 Mar 2004 18:12:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26324 for ; Fri, 12 Mar 2004 18:12:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1vpb-00076A-00 for rpsec@ietf.org; Fri, 12 Mar 2004 18:12:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1voe-00073S-00 for rpsec@ietf.org; Fri, 12 Mar 2004 18:11:45 -0500 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm2.ca.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 1B1vnk-0006zk-00 for rpsec@ietf.org; Fri, 12 Mar 2004 18:10:48 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by tm2.ca.alcatel.com (8.12.10/8.12.10) with ESMTP id i2CNAkm5016583; Fri, 12 Mar 2004 18:10:47 -0500 (EST) Message-ID: <40524371.2010207@alcatel.com> Date: Fri, 12 Mar 2004 18:10:41 -0500 From: Emanuele Jones Organization: Alcatel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: acee@redback.com, rpsec Subject: Re: [RPSEC] Comments on draft-jones-ospf-vuln-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Acee, thank you for your comments regarding the OSPF vulnerabilities draft. Please find my further comments in line. Acee Lindem wrote: > Comments > > 1. General - Define what you mean by an OSPF routing session > or replace it with a generally accepted term. > It is not a term from RFC 2328 and appears to be used > in more than one context. In some cases it refers to an > OSPF routing domain, other cases an OSPF router, and > other cases an OSPF adjacency. > Agreed > 2. Page 8, top paragraph. An RFC 2328 compliant router will > not consider reflooding the same as originating the LSA > itself. So, the statement that the router will not fight > back at all is incorrect. Anyway, as we discussed, I > believe this sequence is wrong and the check for a > self-originated LSA must be done before reflooding the > LSA. I know my implemenation does this. > Agreed. I will rephrase this paragraph to state that a 2328 compliant router will fight back only every MinLSInterval. > 3. Page 8, 3.1.3.2 - You might want to elaborate. Once the > network is partitioned the attacker's bogus LSAs will be > ignored unless the attacker is able to maintain the > real router's adjacencies. > Agreed. What we really meant to say with this paragraph was that the network is still entirely connected, but the attacker is sitting on a critical node that *would* partition the network if removed. In this position the attacker could inject a forged LSA *only* to one part of the network, pretending this LSA is coming from an existing router from the other part. Thus, the legitimate owner of the LSA will never be aware of the forged information on his behalf and never initiate a fightback. > 4. Page 8, 3.1.5 - "stub or NSSA areas" rather than "stub areas". > Agreed > 5. Page 10, You should state that any attacks in sections > subsequent sections require the no authentication or must > be carried out by an inside attacker. > Agreed > 6. Page 10, last paragraph - Actually this is harder than it > looks since you also have assure you list all the routers > on the network in your bogus hello. However, once you've > done that effectively you can keep the network LSA from > being originated permanently. > Partially Agreed. At least the DR and BDR must be present in the neighbor's list of any malicious Hello in order to initiate any DR-change attack. If the current DR and BDR are the only routers listed in the neighbors' list then: 1) the current DR and BDR will acknowledge the malicious Hello and drop their DR and BDR role immediately 2) the remaining routers on the network (i.e. all the ones that were not listed in the malicious Hello) will not acknowledge any DR/BDR change and thus they would still consider the previous DR and BDR to be in charge. This will create inconsistencies and disrupt data traffic. > 7. Page 11, Paragraph beginning "Finally...". I don't understand > what this is getting at, the source would ignore it's replayed > hello anyway. So if you replayed an old one that wasn't > protected by auth sequence numbers you could still wreck > havoc by forcing routers to 1-Way state. > Not understanding. Just a bit of context here, with this paragraph I am arguing that one of the attacks previously described in [7] is not doable, and hence this is why it will not be listed in the draft. Based on the first part of your comment, you seem to be in agreement with my statement. Given we both agree that this attack does not work (and I have decided to list it in here only for the sake of completeness), I am not sure I understand how you could force a router to go back to the 1-Way state with a non-authenticated Hello. > 8. Page, Section 3.2.4 - All attacks to LSAs require the orginating > router to be in state exchange or higher with a router in the > domain. > Agreed > 9. Page 12, 3.2.4.2 - Replace "refreshment" with "refresh". > Agreed > 10. Page 12, 3.2.4.2, Second paragraph. - I'm not sure it makes > sense to publish this since most deployed implementations > do not have the bug. > I would to keep this section (maybe shortened) just as a reminder of an historical OSPF's implementation problem. Just to sort of keep track of it. > 11. Page 16, Number of Neighbors on multicast networks - Hello messages > are not retained. Rather, a neighbor data structure is created. > However, the latter probably requires as much or more resources as > the former. > Agreed > 12. Page 16 and page 17 - I'm not sure whether the specific Zebra > bugs are relevant. At some point a fragmented packet that is > arbitrarily large may be rejected by an implementation. Many > times that number is less than 65535 since in practice fragmented > IP packets that large are not sent. > Agreed. Regards, Emanuele _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Sat Mar 13 14:03:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25948 for ; Sat, 13 Mar 2004 14:03:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2EPQ-0004KH-TU for rpsec-archive@odin.ietf.org; Sat, 13 Mar 2004 14:02:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DJ2u5M016629 for rpsec-archive@odin.ietf.org; Sat, 13 Mar 2004 14:02:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2EPQ-0004K8-NK for rpsec-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 14:02:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25900 for ; Sat, 13 Mar 2004 14:02:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2EPO-0002rN-00 for rpsec-web-archive@ietf.org; Sat, 13 Mar 2004 14:02:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2EOd-0002jB-00 for rpsec-web-archive@ietf.org; Sat, 13 Mar 2004 14:02:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2ENi-0002Ze-00 for rpsec-web-archive@ietf.org; Sat, 13 Mar 2004 14:01:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ENa-0004Bi-KT; Sat, 13 Mar 2004 14:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2EN1-0004Au-KD for rpsec@optimus.ietf.org; Sat, 13 Mar 2004 14:00:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25686 for ; Sat, 13 Mar 2004 14:00:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2EMz-0002Vn-00 for rpsec@ietf.org; Sat, 13 Mar 2004 14:00:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2EM4-0002Ra-00 for rpsec@ietf.org; Sat, 13 Mar 2004 13:59:29 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B2ELE-0002Ny-00 for rpsec@ietf.org; Sat, 13 Mar 2004 13:58:36 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1065E702061; Sat, 13 Mar 2004 10:58:31 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26148-03; Sat, 13 Mar 2004 10:58:30 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.211]) by prattle.redback.com (Postfix) with SMTP id E603E702060; Sat, 13 Mar 2004 10:58:29 -0800 (PST) Message-ID: <099d01c4092d$27fa7440$0302a8c0@aceeinspiron> From: "Acee Lindem" To: "Emanuele Jones" , "rpsec" References: <40524371.2010207@alcatel.com> Subject: Re: [RPSEC] Comments on draft-jones-ospf-vuln-00.txt Date: Sat, 13 Mar 2004 13:58:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Emanuele, See inline. ----- Original Message ----- From: "Emanuele Jones" To: ; "rpsec" Sent: Friday, March 12, 2004 6:10 PM Subject: Re: [RPSEC] Comments on draft-jones-ospf-vuln-00.txt > Acee, > > thank you for your comments regarding the OSPF vulnerabilities draft. > Please find my further comments in line. > > Acee Lindem wrote: > > > Comments > > > > 1. General - Define what you mean by an OSPF routing session > > or replace it with a generally accepted term. > > It is not a term from RFC 2328 and appears to be used > > in more than one context. In some cases it refers to an > > OSPF routing domain, other cases an OSPF router, and > > other cases an OSPF adjacency. > > > Agreed > > > 2. Page 8, top paragraph. An RFC 2328 compliant router will > > not consider reflooding the same as originating the LSA > > itself. So, the statement that the router will not fight > > back at all is incorrect. Anyway, as we discussed, I > > believe this sequence is wrong and the check for a > > self-originated LSA must be done before reflooding the > > LSA. I know my implemenation does this. > > > Agreed. > I will rephrase this paragraph to state that a 2328 compliant router > will fight back only every MinLSInterval. > > > 3. Page 8, 3.1.3.2 - You might want to elaborate. Once the > > network is partitioned the attacker's bogus LSAs will be > > ignored unless the attacker is able to maintain the > > real router's adjacencies. > > > Agreed. > What we really meant to say with this paragraph was that the network is > still entirely connected, but the attacker is sitting on a critical node > that *would* partition the network if removed. In this position the > attacker could inject a forged LSA *only* to one part of the network, > pretending this LSA is coming from an existing router from the other > part. Thus, the legitimate owner of the LSA will never be aware of the > forged information on his behalf and never initiate a fightback. > > > 4. Page 8, 3.1.5 - "stub or NSSA areas" rather than "stub areas". > > > Agreed > > > 5. Page 10, You should state that any attacks in sections > > subsequent sections require the no authentication or must > > be carried out by an inside attacker. > > > Agreed > > > 6. Page 10, last paragraph - Actually this is harder than it > > looks since you also have assure you list all the routers > > on the network in your bogus hello. However, once you've > > done that effectively you can keep the network LSA from > > being originated permanently. > > > Partially Agreed. > At least the DR and BDR must be present in the neighbor's list of any > malicious Hello in order to initiate any DR-change attack. > If the current DR and BDR are the only routers listed in the neighbors' > list then: > 1) the current DR and BDR will acknowledge the malicious Hello and drop > their DR and BDR role immediately > 2) the remaining routers on the network (i.e. all the ones that were not > listed in the malicious Hello) will not acknowledge any DR/BDR change > and thus they would still consider the previous DR and BDR to be in charge. > This will create inconsistencies and disrupt data traffic. Agreed. The case of messing up only the DR and BDR may be worse because the DR re-election could take longer. > > > 7. Page 11, Paragraph beginning "Finally...". I don't understand > > what this is getting at, the source would ignore it's replayed > > hello anyway. So if you replayed an old one that wasn't > > protected by auth sequence numbers you could still wreck > > havoc by forcing routers to 1-Way state. > > > Not understanding. > Just a bit of context here, with this paragraph I am arguing that one of > the attacks previously described in [7] is not doable, and hence this > is why it will not be listed in the draft. Based on the first part of > your comment, you seem to be in agreement with my statement. Given we > both agree that this attack does not work (and I have decided to list it > in here only for the sake of completeness), I am not sure I understand > how you could force a router to go back to the 1-Way state with a > non-authenticated Hello. I can't remember what I was thinking here. The only way an attacker could make this work would be to have saved a hello with a higher auth sequence number (indicating the router's auth sequence number has been reset). > > > 8. Page, Section 3.2.4 - All attacks to LSAs require the orginating > > router to be in state exchange or higher with a router in the > > domain. > > > Agreed > > > 9. Page 12, 3.2.4.2 - Replace "refreshment" with "refresh". > > > Agreed > > > 10. Page 12, 3.2.4.2, Second paragraph. - I'm not sure it makes > > sense to publish this since most deployed implementations > > do not have the bug. > > > I would to keep this section (maybe shortened) just as a reminder of > an historical OSPF's implementation problem. Just to sort of keep track > of it. Fair enough since you indicate that it is a bug. > > > 11. Page 16, Number of Neighbors on multicast networks - Hello messages > > are not retained. Rather, a neighbor data structure is created. > > However, the latter probably requires as much or more resources as > > the former. > > > Agreed > > > 12. Page 16 and page 17 - I'm not sure whether the specific Zebra > > bugs are relevant. At some point a fragmented packet that is > > arbitrarily large may be rejected by an implementation. Many > > times that number is less than 65535 since in practice fragmented > > IP packets that large are not sent. > > > Agreed. > > Regards, > > Emanuele > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Mar 18 16:23:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09423 for ; Thu, 18 Mar 2004 16:23:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44yV-0006TQ-EB for rpsec-archive@odin.ietf.org; Thu, 18 Mar 2004 16:22:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ILMleB024878 for rpsec-archive@odin.ietf.org; Thu, 18 Mar 2004 16:22:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44yV-0006TB-20 for rpsec-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 16:22:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09401 for ; Thu, 18 Mar 2004 16:22:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B44yT-0005Vt-00 for rpsec-web-archive@ietf.org; Thu, 18 Mar 2004 16:22:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B44xh-0005RR-00 for rpsec-web-archive@ietf.org; Thu, 18 Mar 2004 16:21:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B44wz-0005M9-00 for rpsec-web-archive@ietf.org; Thu, 18 Mar 2004 16:21:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44wn-0006Gh-4t; Thu, 18 Mar 2004 16:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44wO-0006Eg-A9 for rpsec@optimus.ietf.org; Thu, 18 Mar 2004 16:20:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09321 for ; Thu, 18 Mar 2004 16:20:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B44wM-0005HX-00 for rpsec@ietf.org; Thu, 18 Mar 2004 16:20:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B44vR-00059o-00 for rpsec@ietf.org; Thu, 18 Mar 2004 16:19:37 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B44uZ-00055d-00 for rpsec@ietf.org; Thu, 18 Mar 2004 16:18:43 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B44uZ-000Bcf-MK for rpsec@ietf.org; Thu, 18 Mar 2004 21:18:43 +0000 Date: Thu, 18 Mar 2004 13:17:02 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <176223183.20040318131702@psg.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Extending RPSEC charter In-Reply-To: <41148965330.20040311170210@psg.com> References: <66148620605.20040311165625@psg.com> <41148965330.20040311170210@psg.com> 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-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit FYI, the IESG approved the updated charter today. The secretariat will send a formal announcement. We are looking forward to seeing more activity in the WG towards completing its goals. -- Alex http://www.psg.com/~zinin/ Thursday, March 11, 2004, 5:02:10 PM, Alex Zinin wrote: > As a result of the discussion about bringing protocol-specific analysis and > requirements draft to the WG, we're updating the charter. Below is my request to > the secretariat. The tag identifies the places where changes > have been made. > -- > Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Mar 18 22:42:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26541 for ; Thu, 18 Mar 2004 22:42:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4AtQ-0004cD-B9 for rpsec-archive@odin.ietf.org; Thu, 18 Mar 2004 22:41:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J3fuFe017737 for rpsec-archive@odin.ietf.org; Thu, 18 Mar 2004 22:41:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4AtQ-0004c0-4o for rpsec-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 22:41:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26522 for ; Thu, 18 Mar 2004 22:41:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4AtM-0000iR-00 for rpsec-web-archive@ietf.org; Thu, 18 Mar 2004 22:41:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Asd-0000ek-00 for rpsec-web-archive@ietf.org; Thu, 18 Mar 2004 22:41:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Ark-0000bA-00 for rpsec-web-archive@ietf.org; Thu, 18 Mar 2004 22:40:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Arf-0004T9-E3; Thu, 18 Mar 2004 22:40:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ArY-0004Rx-UA for rpsec@optimus.ietf.org; Thu, 18 Mar 2004 22:40:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26465 for ; Thu, 18 Mar 2004 22:39:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4ArV-0000a8-00 for rpsec@ietf.org; Thu, 18 Mar 2004 22:39:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Aqa-0000VZ-00 for rpsec@ietf.org; Thu, 18 Mar 2004 22:39:00 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1B4Apq-0000Mm-00 for rpsec@ietf.org; Thu, 18 Mar 2004 22:38:15 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id i2J3bfUx006832; Thu, 18 Mar 2004 19:37:41 -0800 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.12.11/8.12.10/Submit) with ESMTP id i2J3bfBK006829; Thu, 18 Mar 2004 19:37:41 -0800 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Thu, 18 Mar 2004 19:37:41 -0800 (PST) From: Tony Tauber To: Alex Zinin cc: rpsec@ietf.org Subject: Re: [RPSEC] Extending RPSEC charter In-Reply-To: <176223183.20040318131702@psg.com> Message-ID: References: <66148620605.20040311165625@psg.com> <41148965330.20040311170210@psg.com> <176223183.20040318131702@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Thu, 18 Mar 2004, Alex Zinin wrote: > Thursday, March 11, 2004, 5:02:10 PM, Alex Zinin wrote: > > As a result of the discussion about bringing protocol-specific > > analysis and requirements draft to the WG, we're updating the > > charter. Below is my request to the secretariat. The > > tag identifies the places where changes have been made. > > FYI, the IESG approved the updated charter today. The secretariat > will send a formal announcement. > > We are looking forward to seeing more activity in the WG towards > completing its goals. > -- > Alex Alex, Thanks for stewarding along this change! Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Mar 24 15:38:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20001 for ; Wed, 24 Mar 2004 15:38:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6F93-0002HR-QI for rpsec-archive@odin.ietf.org; Wed, 24 Mar 2004 15:38:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OKcbkf008761 for rpsec-archive@odin.ietf.org; Wed, 24 Mar 2004 15:38:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6F93-0002HE-LT for rpsec-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 15:38:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19998 for ; Wed, 24 Mar 2004 15:38:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6F92-00068y-00 for rpsec-web-archive@ietf.org; Wed, 24 Mar 2004 15:38:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6F8D-000646-00 for rpsec-web-archive@ietf.org; Wed, 24 Mar 2004 15:37:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6F7d-0005yN-00 for rpsec-web-archive@ietf.org; Wed, 24 Mar 2004 15:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6F7V-0001Em-8o; Wed, 24 Mar 2004 15:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6F7C-0001C2-QK for rpsec@optimus.ietf.org; Wed, 24 Mar 2004 15:36:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19827; Wed, 24 Mar 2004 15:36:36 -0500 (EST) Message-Id: <200403242036.PAA19827@ietf.org> From: The IESG To: IETF-Announce: ; Cc: rpsec@ietf.org, Tony Tauber , Russ White Date: Wed, 24 Mar 2004 15:36:35 -0500 Subject: [RPSEC] WG Action: RECHARTER: Routing Protocol Security Requirements (rpsec) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The charter of the Routing Protocol Security Requirements (rpsec) working group in the Routing Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Routing Protocol Security Requirements (rpsec) ---------------------------------------------- Current Status: Active Working Group Chair(s): Tony Tauber Russ White Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Mailing Lists: General Discussion: rpsec@ietf.org To Subscribe: rpsec-request@ietf.org In Body: (un)subscribe Archive: http://www1.ietf.org/mail-archive/working-groups/rpsec 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 protocol designers to ensure adequate coverage of security in the future, including well known and possible threats. The scope of work is limited to router-to-router protocols only for both unicast and multicast systems, and does NOT include host-to-router protocol such as IGMP, ICMP, ARP, or ND. It is also a non-goal at this point to produce new or change the current security mechanisms in the existing routing protocols. The RPSEC working group is charged with the following tasks: - Document threat models for routing systems - Document security requirements for routing systems - Document security analysis and requirements for specific routing protocols (e.g., OSPF, BGP) - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Possible Future Work - Evaluate and document existing and proposed routing security mechanisms with respect to established RPSEC requirements - Recommend mechanism(s) Goals and Milestones: Done Submit initial I-D (or set of I-Ds) which details the threats to routing systems. Mar 04 Submit initial I-D (or set of I-Ds) which outlines security requirements for routing systems. Mar 04 Submit initial I-D describing BGP Attack-Tree analysis. Mar 04 Submit initial I-D describing OSPF vulnerability analysis. May 04 Submit initial I-D describing BGP security requirements. Done Submit I-Ds documenting threats to routing systems for publication as Informational RFC. Jul 04 Submit the I-D documenting security requirements to routing systems for publication as Informational RFC. Nov 04 Submit BGP Attack-Tree analysis for publication as Informational RFC. Nov 04 Submit OSPF vulnerability analysis for publication as Informational RFC. Mar 05 Submit BGP security requirements for publication as Informational RFC. May 05 Evaluate progress, recharter with new goals (see possible future work above) or shutdown. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Mar 30 18:27:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00537 for ; Tue, 30 Mar 2004 18:27:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006WI-Ce for rpsec-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAJ7KsH032108 for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 14:07:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9g8-0008Ln-Eh for rpsec-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 14:07:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10259 for ; Wed, 10 Dec 2003 14:07:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU9RJ-0005dR-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 13:52:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU9RI-0005dO-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 13:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9RJ-0007Jz-6k; Wed, 10 Dec 2003 13:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9R0-0007Ir-Fa for rpsec@optimus.ietf.org; Wed, 10 Dec 2003 13:51:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09346 for ; Wed, 10 Dec 2003 13:51:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU9Qw-0005cw-00 for rpsec@ietf.org; Wed, 10 Dec 2003 13:51:38 -0500 Received: from machine77.level3.com ([209.244.4.106] helo=scanner1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 1AU9Qw-0005cX-00 for rpsec@ietf.org; Wed, 10 Dec 2003 13:51:38 -0500 Received: from scanner1.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id EDFB578AFA2; Wed, 10 Dec 2003 18:51:07 +0000 (GMT) Received: from buzz.idc1.level3.com (qfe0.buzz.idc1.oss.level3.com [10.1.116.4]) by scanner1.level3.com (Postfix) with ESMTP id ADAF478AF98; Wed, 10 Dec 2003 18:51:07 +0000 (GMT) Received: from localhost (ttauber@localhost) by buzz.idc1.level3.com (8.8.8p2+Sun/8.8.8) with ESMTP id SAA22925; Wed, 10 Dec 2003 18:51:06 GMT X-Authentication-Warning: buzz.idc1.level3.com: ttauber owned process doing -bs Date: Wed, 10 Dec 2003 18:51:06 +0000 (GMT) From: Tony Tauber X-X-Sender: ttauber@buzz.idc1.level3.com To: Abbie Barbir Cc: rpsec@ietf.org Subject: RE: [RPSEC] Consensus calls In-Reply-To: <87609AFB433BD5118D5E0002A52CD75407DCFB6C@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75407DCFB6C@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Wed, 10 Dec 2003, Abbie Barbir wrote: > > -----Original Message----- > > > > Hi, > > > > I am just curious about item 2 below. Do you mean just protocol > > specific threats and requirements, or solutions as well? > > > > Lakshminath I believe that the solutions will need to be vetted in the group which "owns" the protocol (if there is one, perhaps some may come up someday for which no WG still exists.) Might it be possible to have the Routing ADs provide guidance on where solutions get worked on a case-by-case basis instead of writing it into the charter? > Hi, > > Same here, I think you need to be specific to what protocols are in > scope. > > Abbie I'm wondering why any routing protocols should not be? Maybe a reason, I just don't know what it is. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Mar 30 18:43:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04658 for ; Tue, 30 Mar 2004 18:43:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj5-0006WI-IJ for rpsec-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAJ8G2A001183 for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 14:08:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9gz-0000Gk-Cu for rpsec-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 14:08:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10459 for ; Wed, 10 Dec 2003 14:08:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU9gw-00064x-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 14:08:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU9gw-00064u-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 14:08:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9gx-0000EX-AH; Wed, 10 Dec 2003 14:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9g6-0008LV-EK for rpsec@optimus.ietf.org; Wed, 10 Dec 2003 14:07:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10228 for ; Wed, 10 Dec 2003 14:07:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU9Ty-0005f2-00 for rpsec@ietf.org; Wed, 10 Dec 2003 13:54:46 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AU9Tx-0005el-00 for rpsec@ietf.org; Wed, 10 Dec 2003 13:54:45 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBAIs7H09292; Wed, 10 Dec 2003 13:54:08 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Dec 2003 13:54:08 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75407DCFBC2@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Tony Tauber Cc: rpsec@ietf.org Subject: RE: [RPSEC] Consensus calls Date: Wed, 10 Dec 2003 13:54:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BF4E.FBAD6EEC" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , 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_01C3BF4E.FBAD6EEC Content-Type: text/plain Tony, For many reasons, one of them is as you said, it depenedns on which WG owns the protocol. Abbie > -----Original Message----- > From: Tony Tauber [mailto:tony.tauber@level3.com] > Sent: Wednesday, December 10, 2003 1:51 PM > To: Barbir, Abbie [CAR:1A11:EXCH] > Cc: rpsec@ietf.org > Subject: RE: [RPSEC] Consensus calls > > > On Wed, 10 Dec 2003, Abbie Barbir wrote: > > > > -----Original Message----- > > > > > > Hi, > > > > > > I am just curious about item 2 below. Do you mean just protocol > > > specific threats and requirements, or solutions as well? > > > > > > Lakshminath > > I believe that the solutions will need to be vetted in the > group which "owns" the protocol (if there is one, perhaps > some may come up someday for which no WG still exists.) > Might it be possible to have the Routing ADs provide guidance > on where solutions get worked on a case-by-case basis instead > of writing it into the charter? > > > Hi, > > > > Same here, I think you need to be specific to what protocols are in > > scope. > > > > Abbie > > I'm wondering why any routing protocols should not be? > Maybe a reason, I just don't know what it is. > > Tony > ------_=_NextPart_001_01C3BF4E.FBAD6EEC Content-Type: text/html RE: [RPSEC] Consensus calls

Tony,

For many reasons, one of them is as you said, it depenedns on which WG owns the protocol.

Abbie




> -----Original Message-----
> From: Tony Tauber [mailto:tony.tauber@level3.com]
> Sent: Wednesday, December 10, 2003 1:51 PM
> To: Barbir, Abbie [CAR:1A11:EXCH]
> Cc: rpsec@ietf.org
> Subject: RE: [RPSEC] Consensus calls
>
>
> On Wed, 10 Dec 2003, Abbie Barbir wrote:
>
> > > -----Original Message-----
> > >
> > > Hi,
> > >
> > > I am just curious about item 2 below.  Do you mean just protocol
> > > specific threats and requirements, or solutions as well?
> > >
> > > Lakshminath
>
> I believe that the solutions will need to be vetted in the
> group which "owns" the protocol (if there is one, perhaps
> some may come up someday for which no WG still exists.) 
> Might it be possible to have the Routing ADs provide guidance
> on where solutions get worked on a case-by-case basis instead
> of writing it into the charter?
>
> > Hi,
> >
> > Same here, I think you need to be specific to what protocols are in
> > scope.
> >
> > Abbie
>
> I'm wondering why any routing protocols should not be?
> Maybe a reason, I just don't know what it is.
>
> Tony
>

------_=_NextPart_001_01C3BF4E.FBAD6EEC-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Mar 30 18:44:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04834 for ; Tue, 30 Mar 2004 18:44:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj4-0006WI-QJ for rpsec-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAJ89FJ000524 for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 14:08:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9gt-00007j-Fs for rpsec-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 14:08:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10443 for ; Wed, 10 Dec 2003 14:08:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU9gq-00064G-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 14:08:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU9gq-00064D-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 14:08:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9gp-0008WV-Vg; Wed, 10 Dec 2003 14:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9fv-0008JF-HL for rpsec@optimus.ietf.org; Wed, 10 Dec 2003 14:07:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10102 for ; Wed, 10 Dec 2003 14:07:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU9du-0005rQ-00 for rpsec@ietf.org; Wed, 10 Dec 2003 14:05:02 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1AU9du-0005po-00 for rpsec@ietf.org; Wed, 10 Dec 2003 14:05:02 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hBAJ4O7o018313; Wed, 10 Dec 2003 14:04:24 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 10 Dec 2003 14:01:29 -0500 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] Consensus calls Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 5:08 +0000 12/10/03, Tony Tauber wrote: >Folks, > >At the meeting in Minneapolis, the sense of the room was that there >was positive support for these proposals: > >1) Should draft-puig-rpsec-generic-requirements-01.txt be accepted as > a WG work item? No. This document is a hodge podge. It mixes the authors's solution ideas with requirements statements. It is very uneven in its treatment of topics, and has numerous errors, e.g., characterizing anti-replay as a crypto mechanism. It is not a generic requirements document, as the title suggests. > >2) Should the RPSEC charter be amended to allow for the acceptance of > protocol-specific work? (Removing the sentence below should do that.) > > ++> It is also a non-goal at this point to produce new or change the > ++> current security mechanisms in the existing routing protocols. No. I believe the current WG is not appropriately constituted to take on this task. >3) Should draft-convery-bgpattack-01.txt be accepted as a WG work item? I think an attack tree is useful as part of a broader analysis of security concerns. But since I do not believe that this WG, as currently constituted, should pursue protocol-specific tasks, I would not recommend accepting this document. >4) Should draft-jones-OSPF-vuln-01.txt be accepted as a WG work item? no, see my response to #2 above. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec