From mailnull@www1.ietf.org Wed Mar 5 06:36:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26932 for ; Wed, 5 Mar 2003 06:36:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25Bllh17763 for rpsec-archive@odin.ietf.org; Wed, 5 Mar 2003 06:47:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Bll517760 for ; Wed, 5 Mar 2003 06:47:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26902 for ; Wed, 5 Mar 2003 06:36:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BkZ517592; Wed, 5 Mar 2003 06:46:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BeL516912 for ; Wed, 5 Mar 2003 06:40:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25589; Wed, 5 Mar 2003 06:28:53 -0500 (EST) Message-Id: <200303051128.GAA25589@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: rpsec@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 05 Mar 2003 06:28:52 -0500 Subject: [RPSEC] I-D ACTION:draft-beard-rpsec-routing-threats-01.txt 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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Generic Threats to Routing Protocols Author(s) : B. Beard et al. Filename : draft-beard-rpsec-routing-threats-01.txt Pages : 34 Date : 2003-3-4 Routing protocols are subject to attacks that can harm individual users or the network operations as a whole. The lack of a common set of security requirements has led to the use in existing routing protocol of a variety of different security solutions, which provide various levels of security coverage. The RPSEC working group intends to deliver in a separate document a set of security requirements for consideration of routing protocol designers. The first step in developing the security requirements is to analyze the threats that face routing protocols. This document describes the threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-beard-rpsec-routing-threats-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-beard-rpsec-routing-threats-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-beard-rpsec-routing-threats-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-4173855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-beard-rpsec-routing-threats-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-beard-rpsec-routing-threats-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4173855.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 7 20:24:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25220 for ; Fri, 7 Mar 2003 20:24:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h281aPM05738 for rpsec-archive@odin.ietf.org; Fri, 7 Mar 2003 20:36:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281aPO05735 for ; Fri, 7 Mar 2003 20:36:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25215 for ; Fri, 7 Mar 2003 20:24:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281ZIO05679; Fri, 7 Mar 2003 20:35:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h281Y4O05429 for ; Fri, 7 Mar 2003 20:34:04 -0500 Received: from nomad.tcb.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25178 for ; Fri, 7 Mar 2003 20:21:47 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id B885D55F62; Fri, 7 Mar 2003 18:24:01 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id B554E3E83 for ; Fri, 7 Mar 2003 18:24:01 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: rpsec@ietf.org From: Danny McPherson Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Mar 2003 18:23:56 -0700 Message-Id: <20030308012401.B885D55F62@nomad.tcb.net> Subject: [RPSEC] RPSEC Requirements Document 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: , Folks, I'm working on putting together a list of topics that should be discussed in the Routing Protocol Security Requirements document. Please send me (or the list) comments or suggestions on specific topics that should be covered in the document. Thanks. -danny _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 10:22:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23373 for ; Tue, 11 Mar 2003 10:22:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BFZl905603 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 10:35:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFZlO05600 for ; Tue, 11 Mar 2003 10:35:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23347 for ; Tue, 11 Mar 2003 10:21:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFYVO05493; Tue, 11 Mar 2003 10:34:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFVpO05375 for ; Tue, 11 Mar 2003 10:31:51 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23249 for ; Tue, 11 Mar 2003 10:17:50 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2BFJvSc012872 for ; Tue, 11 Mar 2003 10:19:57 -0500 (EST) Received: from dhcp-64-102-48-241.cisco.com (dhcp-64-102-48-241.cisco.com [64.102.48.241]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA00688 for ; Tue, 11 Mar 2003 10:19:56 -0500 (EST) Date: Tue, 11 Mar 2003 10:19:57 -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] Scribe Needed.... 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: , We might as wellget this little piece of business now, if possible. We need a scribe for the meeting in LA, preferrably someone who knows how to work Jabber. We'd like to get the meeting out on jabber in real time, so other folks can watch what's going on, even if they're not there. If we could log the jabber session, then we could use those, plus any other notes that anyone might take, as a basis for good minutes. How do you step back in email? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 10:45:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24292 for ; Tue, 11 Mar 2003 10:45:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BFwlC07779 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 10:58:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFwlO07776 for ; Tue, 11 Mar 2003 10:58:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24282 for ; Tue, 11 Mar 2003 10:44:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFv4O07628; Tue, 11 Mar 2003 10:57:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFu9O07579 for ; Tue, 11 Mar 2003 10:56:09 -0500 Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24180 for ; Tue, 11 Mar 2003 10:42:08 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h2BFhno26317; Tue, 11 Mar 2003 10:43:49 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Tue, 11 Mar 2003 10:43:49 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Russ White cc: rpsec@ietf.org Subject: Re: [RPSEC] Scribe Needed.... 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-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 Tue, 11 Mar 2003, Russ White wrote: > We might as wellget this little piece of business now, if possible. > We need a scribe for the meeting in LA, Not to mention the meeting in SF. 8-) > preferrably someone who knows how to work Jabber. We'd like to get > the meeting out on jabber in real time, so other folks can watch > what's going on, even if they're not there. Just FYI, last meeting a number of WGs used Jabber to do real-time text-conferencing of their meetings. What's needed is: A scribe who will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) > If we could log the jabber session, then we could use those, plus > any other notes that anyone might take, as a basis for good minutes. The sessions get logged, apparently, automatically. So hopefully only one scribe would be needed, though the more the better the quality of the minutes, I find. So, step right up.. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 10:45:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24306 for ; Tue, 11 Mar 2003 10:45:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BFwn907799 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 10:58:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFwnO07796 for ; Tue, 11 Mar 2003 10:58:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24286 for ; Tue, 11 Mar 2003 10:44:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFw1O07715; Tue, 11 Mar 2003 10:58:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BFvMO07654 for ; Tue, 11 Mar 2003 10:57:22 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24210 for ; Tue, 11 Mar 2003 10:43:20 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2BFjQvD022262; Tue, 11 Mar 2003 10:45:26 -0500 (EST) Received: from dhcp-64-102-48-241.cisco.com (dhcp-64-102-48-241.cisco.com [64.102.48.241]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA01841; Tue, 11 Mar 2003 10:45:26 -0500 (EST) Date: Tue, 11 Mar 2003 10:45:26 -0500 (EST) From: Russ White Reply-To: Russ White To: Tony Tauber cc: rpsec@ietf.org Subject: Re: [RPSEC] Scribe Needed.... In-Reply-To: Message-ID: References: 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: , Hey, I made the wrong hotel reservations! SF has a Ghiradhelli's, though, so I think I'll switch them. :-) Russ On Tue, 11 Mar 2003, Tony Tauber wrote: > On Tue, 11 Mar 2003, Russ White wrote: > > > We might as wellget this little piece of business now, if possible. > > We need a scribe for the meeting in LA, > > Not to mention the meeting in SF. 8-) > > > preferrably someone who knows how to work Jabber. We'd like to get > > the meeting out on jabber in real time, so other folks can watch > > what's going on, even if they're not there. > > Just FYI, last meeting a number of WGs used Jabber to do real-time > text-conferencing of their meetings. What's needed is: > > A scribe who will be typing in a running commentary as to what's going > on in the room (who's presenting, what question is being asked, etc.) > > > If we could log the jabber session, then we could use those, plus > > any other notes that anyone might take, as a basis for good minutes. > > The sessions get logged, apparently, automatically. > So hopefully only one scribe would be needed, though the more the > better the quality of the minutes, I find. > > So, step right up.. > > Tony > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 19:45:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20922 for ; Tue, 11 Mar 2003 19:45:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C0xG017174 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 19:59:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0xGO17169 for ; Tue, 11 Mar 2003 19:59:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20883 for ; Tue, 11 Mar 2003 19:45:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0wfO17106; Tue, 11 Mar 2003 19:58:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0vLO16934 for ; Tue, 11 Mar 2003 19:57:21 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20831 for ; Tue, 11 Mar 2003 19:43:07 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id TAA27641; Tue, 11 Mar 2003 19:46:07 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xmad27493; Tue, 11 Mar 03 19:45:24 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMcHW26517; Tue, 11 Mar 2003 17:38:17 -0500 (EST) Date: Tue, 11 Mar 2003 17:38:17 -0500 (EST) Message-Id: <200303112238.h2BMcHW26517@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] Topic 3: Section 4.4 Spoofing 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: , The text itself recognizes that spoofing in and of itself is often not the true attack: Spoofing is special in that it can be used to carry out other threat actions causing other threat consequences. For example, after an attacker spoofs successfully, it can send out unrealistic routing information that might cause disruption of network services. Please note these consequences are directly resulted from other threat actions instead of spoofing, which are also discussed in this documentation. So by spoofing, you might inject bogus routing information - but that's falsification, section 4.5. You might send more messages than your neighbor can handle - but that's overload. You might get access to routing information than you are not entitled to - but that's, er, "deliberate exposure"? (I'm actually not sure about deliberate exposure, see later message.) There are a few cases where spoofing is in and of itself an attack. - If a router established a neighbor/peering relationship, spoofing the identity of a legitimate router, and by that action was able to prevent the legitimate router from establishing a relationship, that would be an attack, denying service to the good router. (Hm. Denial of service - to the routers - is not on any list. Hm. Maybe that falls under "interference.") - If a router is doing auditing, then the ability to spoof an identity would be an attack - because the audit data would be false. Oops, maybe that makes this a falsification attack. So I would say that the text in this section should recognize the circumstances where spoofing is in and of itself an attack, and distinguish this from the cases where spoofing is a means to launch other attacks. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 19:46:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20998 for ; Tue, 11 Mar 2003 19:46:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C104T17307 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 20:00:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C104O17304 for ; Tue, 11 Mar 2003 20:00:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20953 for ; Tue, 11 Mar 2003 19:45:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0waO16992; Tue, 11 Mar 2003 19:58:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0vGO16906 for ; Tue, 11 Mar 2003 19:57:16 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20811 for ; Tue, 11 Mar 2003 19:43:03 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id TAA27569; Tue, 11 Mar 2003 19:46:03 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma027493; Tue, 11 Mar 03 19:45:24 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMcw726567; Tue, 11 Mar 2003 17:38:58 -0500 (EST) Date: Tue, 11 Mar 2003 17:38:58 -0500 (EST) Message-Id: <200303112238.h2BMcw726567@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] Topic 4: Section 4.5 terminology - "Ownership" 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: , The threat actions overclaiming, underclaiming and misclaiming are stated in terms of "ownership" of addresses. But that's not the only concern - some attacks aren't just that the router is claiming ownership, but that it is claiming a route. In manet protocols, for example, if a wireless protocol advertises a route to a destination, that can be an attack. (And what does "ownership" mean in a multicast routing protocol?) And even in the BGP world, I think there are cases where addresses are loaned to other ISP's, so ownership does not transfer. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 19:46:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21014 for ; Tue, 11 Mar 2003 19:46:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C10F217323 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 20:00:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C10FO17320 for ; Tue, 11 Mar 2003 20:00:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20959 for ; Tue, 11 Mar 2003 19:46:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0wdO17057; Tue, 11 Mar 2003 19:58:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0vIO16922 for ; Tue, 11 Mar 2003 19:57:18 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20820 for ; Tue, 11 Mar 2003 19:43:05 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id TAA27597; Tue, 11 Mar 2003 19:46:04 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xmac27491; Tue, 11 Mar 03 19:45:22 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMnUf27013; Tue, 11 Mar 2003 17:49:30 -0500 (EST) Date: Tue, 11 Mar 2003 17:49:30 -0500 (EST) Message-Id: <200303112249.h2BMnUf27013@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] Topic 7: Section 4.8 Byzantine Failures 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: , Faulty routers were listed as a threat source, and faulty routers doing faulty actions show up as a threat action (attack). It would appear from the definition of Byzantine Failures that all attacks, if done by a faulty router, are actually Byzantine Failure attacks, not falsification/overload/etc attacks. Why? Each of the previous attacks descriptions in Section 4 mention that they could be done by a "compromised router", i.e., by a faulty router. So why is there a separate (redundant?) subsection for those attacks as done by a faulty router? "Detecting a Byzantine error is harder than the fail-stop model in the sense that at least one other processor must do the same computation to confirm the results." This sounds like it came from some fault tolerant textbook. It doesn't fit the language used elsewhere. "processor"? "computation"? "Fail-stop model"? "confirm the results"? I don't think this section is necessary. It appears redundant. [Also, this section uses the term blackhole as selectively dropping packets, which is not how it is used in 3.3.] --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 19:46:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21024 for ; Tue, 11 Mar 2003 19:46:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C10FF17339 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 20:00:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C10FO17336 for ; Tue, 11 Mar 2003 20:00:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20961 for ; Tue, 11 Mar 2003 19:46:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0wXO16974; Tue, 11 Mar 2003 19:58:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0vGO16902 for ; Tue, 11 Mar 2003 19:57:16 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20808 for ; Tue, 11 Mar 2003 19:43:02 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id TAA27565; Tue, 11 Mar 2003 19:46:02 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma027491; Tue, 11 Mar 03 19:45:21 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMpke27074; Tue, 11 Mar 2003 17:51:46 -0500 (EST) Date: Tue, 11 Mar 2003 17:51:46 -0500 (EST) Message-Id: <200303112251.h2BMpke27074@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] Topic 11: Section 3.2 Threat Actions vs Section 4 "Generally...Threat Actions" 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: , Why are these lists different? There are attacks listed in one not listed in the other and vice versa. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 19:46:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21040 for ; Tue, 11 Mar 2003 19:46:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C10J217356 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 20:00:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C10IO17353 for ; Tue, 11 Mar 2003 20:00:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20970 for ; Tue, 11 Mar 2003 19:46:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0wbO17008; Tue, 11 Mar 2003 19:58:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0vIO16910 for ; Tue, 11 Mar 2003 19:57:18 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20815 for ; Tue, 11 Mar 2003 19:43:04 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id TAA27583; Tue, 11 Mar 2003 19:46:03 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xmaa27491; Tue, 11 Mar 03 19:45:22 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMoDx27032; Tue, 11 Mar 2003 17:50:13 -0500 (EST) Date: Tue, 11 Mar 2003 17:50:13 -0500 (EST) Message-Id: <200303112250.h2BMoDx27032@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] Topic 8: Section 4.9 Discarding of Control Packets (aka underclaiming?) 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: , "If the compromised (bad) router partitions the network, i.e. the router is the only path between two good routers, then the bad router can avoid forwarding the routing information on to the network on the other side." Does this make a similar claim to the "underclaiming" part that routers are under some obligation to advertise everything that they know? Or to maintain a peering/connection/neighbor adjacency when they don't want to? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 19:46:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21053 for ; Tue, 11 Mar 2003 19:46:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C10JU17372 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 20:00:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C10JO17369 for ; Tue, 11 Mar 2003 20:00:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20972 for ; Tue, 11 Mar 2003 19:46:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0weO17073; Tue, 11 Mar 2003 19:58:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0vJO16926 for ; Tue, 11 Mar 2003 19:57:19 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20824 for ; Tue, 11 Mar 2003 19:43:05 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id TAA27615; Tue, 11 Mar 2003 19:46:05 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xmad27491; Tue, 11 Mar 03 19:45:22 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMpJg27057; Tue, 11 Mar 2003 17:51:19 -0500 (EST) Date: Tue, 11 Mar 2003 17:51:19 -0500 (EST) Message-Id: <200303112251.h2BMpJg27057@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] Topic 10: Section 4.7 Overload 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 section combines overload of the control plane and the data plane (the control and data plane of the router, I presume, i.e., the routing protocol messages and the data traffic, not the control and data plane of the routing protocol itself as discussed in section 2.1). I think those are two very different topics. For one thing, the routing protocol design might have a chance to limit control plane traffic. But I don't think the routing protocol has much of a chance to limit the data traffic. Effect on the behavior of the entire routing system of data plane activity is another case where there's no doubt that there's an opportunity for attack, but not much chance that the routing protocol could do anything about it. (The ability of someone to break the transport protocol connection (e.g., TCP RST) is another. Traffic analysis is another. Overload on the data plane is another.) How do we handle these? Leave them out of the Routing *PROTOCOL* threat list? Or list them here as threats but eliminate from the requirements draft? Specially designate them here as threats but not through the routing protocol? I'm not sure - I think we have to decide what the purpose of the document is to make a choice. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 19:46:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21066 for ; Tue, 11 Mar 2003 19:46:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C10MQ17395 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 20:00:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C10MO17386 for ; Tue, 11 Mar 2003 20:00:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20980 for ; Tue, 11 Mar 2003 19:46:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0wfO17089; Tue, 11 Mar 2003 19:58:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0vKO16930 for ; Tue, 11 Mar 2003 19:57:20 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20829 for ; Tue, 11 Mar 2003 19:43:07 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id TAA27632; Tue, 11 Mar 2003 19:46:06 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xmab27493; Tue, 11 Mar 03 19:45:24 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMUpm26322; Tue, 11 Mar 2003 17:30:51 -0500 (EST) Date: Tue, 11 Mar 2003 17:30:51 -0500 (EST) Message-Id: <200303112230.h2BMUpm26322@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] comments on draft-beard-rpsec-routing-threats-01.txt 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: , I'm attempting to send some comments on the threats draft. I've tried to organize them so it's not so daunting to read through. There are 10 (most are real small, don't despair) Topic 1: Section 3.1 Threat Sources Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? Topic 3: Section 4.4 Spoofing Topic 4: Section 4.5 terminology - "Ownership" Topic 5: 4.3 Traffic Analysis - really a threat against routing protocol? Topic 6: Section 4.1 Deliberate Exposure Topic 7: Section 4.8 Byzantine Failures Topic 8: Section 4.9 Discarding of Control Packets (aka underclaiming?) Topic 9: Section 4.10 Network Mapping Threat Topic 10: Section 4.7 Overload Topic 11: Section 3.2 Threat Actions vs Section 4 "Generally...Threat Actions" --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 19:46:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21067 for ; Tue, 11 Mar 2003 19:46:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C10M017421 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 20:00:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C10MO17393 for ; Tue, 11 Mar 2003 20:00:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20981 for ; Tue, 11 Mar 2003 19:46:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0wcO17024; Tue, 11 Mar 2003 19:58:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0vIO16914 for ; Tue, 11 Mar 2003 19:57:18 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20816 for ; Tue, 11 Mar 2003 19:43:04 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id TAA27578; Tue, 11 Mar 2003 19:46:03 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xmab27491; Tue, 11 Mar 03 19:45:22 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMome27044; Tue, 11 Mar 2003 17:50:48 -0500 (EST) Date: Tue, 11 Mar 2003 17:50:48 -0500 (EST) Message-Id: <200303112250.h2BMome27044@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat 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: , Not sure of the purpose of this section. If network mapping is a threat action (attack), what is it an attack against? It seems to me to fit better as a threat consequence - if your routing info is exposed (through an interception attack), then people could map your network. Given that there are those who worry that a map of their network would assist bad guys in launching some other sort of attack, I could understand why the ability to develop a network map would be a problem. But the discussion of deriving a prediction of future situations is unclear in purpose. I'm not exactly sure what is being predicted about future situations or why someone would care to predict what your network would do - perhaps an example of what could be done with this prediction would help. What are "informal knowledge networks within an organization"? Is that supposed to be the routing network? Or is this comment taken from some other context? What does "unauthorized access to intelligence" mean? Is "intelligence" in this case the routing information? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 19:46:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21114 for ; Tue, 11 Mar 2003 19:46:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C10Ui17448 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 20:00:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C10UO17445 for ; Tue, 11 Mar 2003 20:00:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20991 for ; Tue, 11 Mar 2003 19:46:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0whO17139; Tue, 11 Mar 2003 19:58:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0vMO16942 for ; Tue, 11 Mar 2003 19:57:22 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20836 for ; Tue, 11 Mar 2003 19:43:08 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id TAA27647; Tue, 11 Mar 2003 19:46:08 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xmae27493; Tue, 11 Mar 03 19:45:25 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMYTK26435; Tue, 11 Mar 2003 17:34:29 -0500 (EST) Date: Tue, 11 Mar 2003 17:34:29 -0500 (EST) Message-Id: <200303112234.h2BMYTK26435@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] Topic 1: Section 3.1 Threat Sources 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: , Section 3.1 Threat Sources says: Specifically, threats can be classified into four categories, based on their sources [DV-SECURITY]: I'd like to see some changes in this categorization. (1) The use of the term "compromised" is defined to mean faulty or misconfigured routers. In the first place, this leaves out subverted routers, which is a big concern. Secondly, to most people, the term "compromised" means "subverted", not faulty. So the text uses a term with a typical meaning to mean everything except the typical meaning. Were subverted routers left out on purpose? (2) The outsiders are divided into "unauthorized devices" and "masquerading devices". (2.a) That doesn't apply to some (many?) protocols. For some protocols, there is no sense of an authorized peer. For OSPF (that is, before the MD5 part got added), OSPF speaks to all routers on the local link that answer to the AllSPFRouters multicast address. MANET protocols frequently speak over the broadcast link (as mentioned earlier in the draft). And so forth. (2.b) There's no good reason to make the distinction. When I spoke at the last IETF, I said that there is never a case (i.e., I grepped and I couldn't find one) where the attacks that can be launched by the masqueraders are different from the attacks that can be launched by the unauthorized routers (except spoofing, which is a tautology - if you spoof, you are a masquerader, if you are a masquerader, you are spoofing). (2.c) It's misleading, security wise. When I saw this in the draft, I got to thinking about what makes a threat source distinct. A threat source should be considered separately if it has a capability that gives it extra power, if it can launch attacks that others cannot, or if there are security defenses that work against it and not against others. Now an unauthorized router has the same capabilities and can perform the same attacks as a masquerader, but it can be eliminated by doing pure address based filtering of some sort where masqueraders cannot. By that criterion, the unauthorized router is a separate threat source only if one considers pure address based filtering as a "security defense". I don't. In a big way, I don't. To call such an easily circumvented mechanism a security defense makes me extremely uneasy. I was emboldened to speak up about this by reading the IAS security mechanisms draft draft-iab-secmech-02.txt that came out a few weeks ago. Bellovin, Kaufman and Schiller list address-based authentication as an "Insecurity Mechanism", along with plaintext passwords (emphasis on the "In"). To quote, "Some common security mechanisms are part of the problem rather than part of the solution." I think if we left unauthorized routers as a distinct threat source, we'd see claims like ".. and our ACME router's address filtering eliminates unauthorized routers, recognized by the IETF as one of the biggest threats to routing.." Just so you know - faulty/misconfigured/subverted routers definitely are distinct from the outsiders - they can do more damage because they have access to context and timing and they can't be eliminated by the strong authentication mechanisms that would eliminate outsiders. (3) Compromised links terminology [Nitpick: links never do things - it is the hosts that are compromising the links who do things. This terminology leads to sentences like "Compromised links can sniff the links over which they have control."] As stated in the text, these threat sources are acting "without participating in the routing exchange". So these threats are attacking the transport subsystem, as mentioned in Section 2. Can we say that routing protocol designers should do anything about these threat sources? Can AODV do anything to prevent jamming? The BGP world had a similar problem in that injected TCP RST's could break a connection. This was solved in the current draft by mandating that BGP must always be used in conjunction with TCP MD5 (RFC2385) - in other words, they mandated a use scenario, they did not solve the problem in the protocol. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 20:15:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21754 for ; Tue, 11 Mar 2003 20:15:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C1TDF19360 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 20:29:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C1TDO19353 for ; Tue, 11 Mar 2003 20:29:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21741 for ; Tue, 11 Mar 2003 20:14:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C1S4O19296; Tue, 11 Mar 2003 20:28:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C1RBO19270 for ; Tue, 11 Mar 2003 20:27:11 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21696 for ; Tue, 11 Mar 2003 20:12:57 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id UAA29056; Tue, 11 Mar 2003 20:15:57 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma028982; Tue, 11 Mar 03 20:15:21 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMaPA26482; Tue, 11 Mar 2003 17:36:25 -0500 (EST) Date: Tue, 11 Mar 2003 17:36:25 -0500 (EST) Message-Id: <200303112236.h2BMaPA26482@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: curtis@fictitious.org, gih@telstra.net, sandy@tislabs.com, shares@nexthop.com Subject: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? 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: , "An underclaiming threat is defined as an action that an attacker illegitimately hides its authorized ownership of some network resources." By this we seem to be stating that a router is under an obligation to advertise network resources it owns. Surely that is not so. An ISP can be assigned whole blocks of addresses that it has not yet given to customers. Or the ISP might want to stop advertising an address because of some dispute with the customer, e.g., the customer might be serving up some objectionable material. Or not paying its bills. Or a wireless router might decide to stop announcing a route because it is overloaded and wants to reserve capacity for existing routes. Perhaps those cases are supposed to be distinguished by the phrase "illegitimately hides". So the listed cases would be where the router was *legitimately* hiding an address. But to keep to our purpose of guiding the protocol designers - how on earth would the protocol carry data to prove the legitimacy of *not* announcing an address? I do not believe this should be included as an attack on routing protocols. Imagine the hue-and-cry from customers wanting router vendors or ISP's to provide assurance against this "attack". Yes, of course hiding an address would be a concern to the customer. But that's a financial dispute between the customer and the ISP, not a routing attack. Just like providing insufficient bandwidth is a customer concern that is a financial dispute, not a routing attack. I've cc'd some people who I know have their fingers on the pulse of the operator community better than I. They are invited to toss stones in my general direction. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 20:40:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21068 for ; Tue, 11 Mar 2003 19:46:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C10Mt17398 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 20:00:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C10MO17388 for ; Tue, 11 Mar 2003 20:00:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20982 for ; Tue, 11 Mar 2003 19:46:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0wcO17040; Tue, 11 Mar 2003 19:58:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0vIO16918 for ; Tue, 11 Mar 2003 19:57:18 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20818 for ; Tue, 11 Mar 2003 19:43:04 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id TAA27591; Tue, 11 Mar 2003 19:46:04 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xmaa27493; Tue, 11 Mar 03 19:45:24 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMfDr26617; Tue, 11 Mar 2003 17:41:13 -0500 (EST) Date: Tue, 11 Mar 2003 17:41:13 -0500 (EST) Message-Id: <200303112241.h2BMfDr26617@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] Topic 5: 4.3 Traffic Analysis - really a threat against routing protocol? 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: , As the text states, in this case a "compromised link(*) can analyze the data traffic over the links where they have control." So this attack is taking place in a host that is not a router, is not taking place in the routing protocol, and does not affect the routing information. Why is this considered a threat against the routing protocol? Even if you considered this an attack against the routing protocol, would this be a threat that the routing protocol could do anything about? (*) I repeat my earlier nitpick about this term and the sentences that result. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 20:40:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20923 for ; Tue, 11 Mar 2003 19:45:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C0xGu17183 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 19:59:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0xGO17171 for ; Tue, 11 Mar 2003 19:59:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20884 for ; Tue, 11 Mar 2003 19:45:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0wgO17122; Tue, 11 Mar 2003 19:58:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0vLO16938 for ; Tue, 11 Mar 2003 19:57:21 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20834 for ; Tue, 11 Mar 2003 19:43:08 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id TAA27637; Tue, 11 Mar 2003 19:46:07 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xmac27493; Tue, 11 Mar 03 19:45:24 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2BMgk426639; Tue, 11 Mar 2003 17:42:46 -0500 (EST) Date: Tue, 11 Mar 2003 17:42:46 -0500 (EST) Message-Id: <200303112242.h2BMgk426639@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] Topic 6: Section 4.1 Deliberate Exposure 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: , I'm confused by the language in the deliberate exposure section. The text says that deliberate exposure is when the "attackers" release routing information to routers that are not authorized to access the routing information. Presumably these attackers are legitimate routers (otherwise how did they get access to the info). The text seems to excuse a router from releasing routing information to masqueraders (but only when it has been deceived). Does that mean that a router that masquerades and then gets access to routing information it is not authorized to access is NOT a deliberate exposure? The sense of this section is that deliberate exposure is when the router sends information knowingly to some router (or person, or host, I would think) that is not supposed to have it. That's about what I'd expect the words "deliberate exposure" to mean. But that leaves uncovered the case where an outsider obtains, by some means (eavesdropping, spoofing, etc.), access to routing information it should not have. Is this not considered a problem? (BTW: Section 3.2 lists interception as "gains access to routing information that is considered sensitive". That seems to fit. Why is it not included in the Section 4 list of threat actions?) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 11 21:06:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22989 for ; Tue, 11 Mar 2003 21:06:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C2K9j22796 for rpsec-archive@odin.ietf.org; Tue, 11 Mar 2003 21:20:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C2K9O22793 for ; Tue, 11 Mar 2003 21:20:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22983 for ; Tue, 11 Mar 2003 21:05:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C2JIO22733; Tue, 11 Mar 2003 21:19:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C2ILO22694 for ; Tue, 11 Mar 2003 21:18:21 -0500 Received: from nwkea-mail-2.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22944 for ; Tue, 11 Mar 2003 21:04:05 -0500 (EST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21657 for ; Tue, 11 Mar 2003 18:06:14 -0800 (PST) Received: from sydney.East.Sun.COM (esun1as-be21-ge0.Central.Sun.COM [129.147.60.148]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h2C265012733 for ; Tue, 11 Mar 2003 21:06:07 -0500 (EST) From: Radia Perlman - Boston Center for Networking Message-Id: <200303120206.h2C265012733@sydney.East.Sun.COM> Date: Tue, 11 Mar 2003 21:06:16 -0500 To: Reply-To: Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? X-Mailer: Sun NetMail 2.3 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree completely with Sandy on this. BGP even has a way of configuring a router to only tell certain information to certain neighbors. Besides, if a router is maliciously not saying what it can reach, it's doing the world a favor, since the fewer things that get routed through such a router, the better. Radia wrote: > > "An underclaiming threat is defined as an action that an attacker > illegitimately hides its authorized ownership of some network > resources." > >By this we seem to be stating that a router is under an obligation to >advertise network resources it owns. Surely that is not so. An ISP >can be assigned whole blocks of addresses that it has not yet given to >customers. Or the ISP might want to stop advertising an address >because of some dispute with the customer, e.g., the customer might be >serving up some objectionable material. Or not paying its bills. Or >a wireless router might decide to stop announcing a route because it >is overloaded and wants to reserve capacity for existing routes. > >Perhaps those cases are supposed to be distinguished by the phrase >"illegitimately hides". So the listed cases would be where the router >was *legitimately* hiding an address. But to keep to our purpose of >guiding the protocol designers - how on earth would the protocol carry >data to prove the legitimacy of *not* announcing an address? > >I do not believe this should be included as an attack on routing >protocols. Imagine the hue-and-cry from customers wanting router >vendors or ISP's to provide assurance against this "attack". > >Yes, of course hiding an address would be a concern to the customer. >But that's a financial dispute between the customer and the ISP, not a >routing attack. Just like providing insufficient bandwidth is a >customer concern that is a financial dispute, not a routing attack. > >I've cc'd some people who I know have their fingers on the pulse of >the operator community better than I. They are invited to toss >stones in my general direction. > >--Sandy >_______________________________________________ >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 mailnull@www1.ietf.org Wed Mar 12 04:39:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27250 for ; Wed, 12 Mar 2003 04:39:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C9rLa29195 for rpsec-archive@odin.ietf.org; Wed, 12 Mar 2003 04:53:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C9rLO29192 for ; Wed, 12 Mar 2003 04:53:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27246 for ; Wed, 12 Mar 2003 04:38:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C9qJO29137; Wed, 12 Mar 2003 04:52:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C9phO29094 for ; Wed, 12 Mar 2003 04:51:43 -0500 Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27234 for ; Wed, 12 Mar 2003 04:37:20 -0500 (EST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2C9dmV72070; Wed, 12 Mar 2003 10:39:48 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 12 Mar 2003 10:39:48 +0100 (CET) From: Iljitsch van Beijnum To: cc: Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources In-Reply-To: <200303112234.h2BMYTK26435@raven.gw.tislabs.com> Message-ID: <20030312095335.D69506-100000@sequoia.muada.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 Tue, 11 Mar 2003 sandy@tislabs.com wrote: [This may be stupid... but I'm not sure which document you're talking about here.] > By that criterion, the unauthorized router is a separate threat source > only if one considers pure address based filtering as a "security > defense". > I don't. In a big way, I don't. To call such an easily circumvented > mechanism a security defense makes me extremely uneasy. We should first say what we mean by "address based filtering". Addresses show up in many places performing many different roles in routing protocols. But phrased along the following lines I fully agree: "filtering based on the unauthenticated source address in the IP header of routing protocol messages can never be considered to provide any security at all; this functionality, if implemented, should be assumed to protect only against accidental configuration errors". _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Mar 12 06:00:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29160 for ; Wed, 12 Mar 2003 06:00:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CBE5a03085 for rpsec-archive@odin.ietf.org; Wed, 12 Mar 2003 06:14:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBE5O03082 for ; Wed, 12 Mar 2003 06:14:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29137 for ; Wed, 12 Mar 2003 05:59:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBDEO03029; Wed, 12 Mar 2003 06:13:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CBCWO02982 for ; Wed, 12 Mar 2003 06:12:32 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29114 for ; Wed, 12 Mar 2003 05:58:06 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id GAA12623; Wed, 12 Mar 2003 06:01:06 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma012584; Wed, 12 Mar 03 06:00:20 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2CAlM005225; Wed, 12 Mar 2003 05:47:22 -0500 (EST) Date: Wed, 12 Mar 2003 05:47:22 -0500 (EST) Message-Id: <200303121047.h2CAlM005225@raven.gw.tislabs.com> To: iljitsch@muada.com Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources Cc: rpsec@ietf.org, sandy@tislabs.com 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: , >We should first say what we mean by "address based filtering". Addresses >show up in many places performing many different roles in routing >protocols. But phrased along the following lines I fully agree: >"filtering based on the unauthenticated source address in the IP header >of routing protocol messages can never be considered to provide any >security at all; this functionality, if implemented, should be >assumed to protect only against accidental configuration errors". So here's the question that needs answering for the threat draft: Do we want to separately consider a class of hosts as a distinct threat if the only thing that makes the class different is the ability to identify those hosts by this "no security at all" mechanism. (A difference that makes no difference (security wise) is no difference.) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Mar 12 16:01:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22450 for ; Wed, 12 Mar 2003 16:01:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLFLk14997 for rpsec-archive@odin.ietf.org; Wed, 12 Mar 2003 16:15:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLFKO14994 for ; Wed, 12 Mar 2003 16:15:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22403 for ; Wed, 12 Mar 2003 16:00:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLEJO14833; Wed, 12 Mar 2003 16:14:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKeAO12059 for ; Wed, 12 Mar 2003 15:40:10 -0500 Received: from postmark.nist.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20731 for ; Wed, 12 Mar 2003 15:25:31 -0500 (EST) Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h2CKRXCZ029074 for ; Wed, 12 Mar 2003 15:27:33 -0500 (EST) Message-ID: <004901c2e8d5$d1c08b50$b9370681@barnacle> From: "Scott Rose" To: References: <200303112250.h2BMome27044@raven.gw.tislabs.com> Subject: Re: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat Date: Wed, 12 Mar 2003 15:27:36 -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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----- Original Message ----- From: To: Cc: Sent: Tuesday, March 11, 2003 5:50 PM Subject: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat > Not sure of the purpose of this section. If network mapping is a threat > action (attack), what is it an attack against? > Agree. It is really more of a "threat" than an "attack" since it could be seen as a prelude to an attack, or something that makes an attack more possible or more effective. > It seems to me to fit better as a threat consequence - if your routing > info is exposed (through an interception attack), then people could map your > network. > This issue comes up in the DNS security area as well. Every few months the issue of "zone mapping" as a security risk is discussed on the mailing list. The usual answer is: "Is that really a threat/attack, given that the information is public anyway?" If there are other ways of finding the same public information, then it is not really an threat. If an observer can obtain the same information (network map/routing info) through normal transactions, then this type of threat is impossible to defend against (or too expensive to be worth defending). One questions that needs to be asked is whether the network map or "global routing table" (if there could be said to be one) is to be considered public knowledge or not. > Given that there are those who worry that a map of their network would > assist bad guys in launching some other sort of attack, I could > understand why the ability to develop a network map would be a > problem. But the discussion of deriving a prediction of future > situations is unclear in purpose. I'm not exactly sure what is being > predicted about future situations or why someone would care to predict > what your network would do - perhaps an example of what could be done > with this prediction would help. > > What are "informal knowledge networks within an organization"? Is that > supposed to be the routing network? Or is this comment taken from > some other context? > > What does "unauthorized access to intelligence" mean? Is "intelligence" > in this case the routing information? > > --Sandy Scott ================================= Scott Rose Adv. Network Technology Div., NIST http://www.antd.nist.gov/proj/dnssec ph - 301-975-8439 ================================== _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Mar 12 16:54:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24954 for ; Wed, 12 Mar 2003 16:54:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CM96p20109 for rpsec-archive@odin.ietf.org; Wed, 12 Mar 2003 17:09:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CM95O20106 for ; Wed, 12 Mar 2003 17:09:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24941 for ; Wed, 12 Mar 2003 16:54:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CM57O19183; Wed, 12 Mar 2003 17:05:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CM35O19096 for ; Wed, 12 Mar 2003 17:03:05 -0500 Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24733 for ; Wed, 12 Mar 2003 16:48:27 -0500 (EST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2CLosW73446; Wed, 12 Mar 2003 22:50:55 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 12 Mar 2003 22:50:54 +0100 (CET) From: Iljitsch van Beijnum To: Scott Rose cc: Subject: Re: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat In-Reply-To: <004901c2e8d5$d1c08b50$b9370681@barnacle> Message-ID: <20030312223931.S69506-100000@sequoia.muada.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, 12 Mar 2003, Scott Rose wrote: > One questions that needs to be asked is whether the network map or "global > routing table" (if there could be said to be one) is to be considered public > knowledge or not. Obviously that's not the real question (try "telnet route-views.oregon-ix.net" if you disagree). If there even is a question here, it would "is it possible to for the global routing table to not be public knowledge". Every multiconnected non-stub AS needs path information for loop protection. The number of people running these networks is too large (and also spread out over the entire world) so having them keep it a secret won't really work. Also, the operators are probably not going to like anything like this as it makes troubleshooting hell. And of course there's always tracroute. I think if certain organizations want to keep their topology secret they should probably hide behind some big fat layer 4 (or higher) firewalls. Just filtering or NAT isn't enough because the other side still gets to see the TTL and RTTs which are enough for rudimentary network mapping. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 13 07:51:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28658 for ; Thu, 13 Mar 2003 07:51:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DD68P23697 for rpsec-archive@odin.ietf.org; Thu, 13 Mar 2003 08:06:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DD68O23694 for ; Thu, 13 Mar 2003 08:06:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28631 for ; Thu, 13 Mar 2003 07:51:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DD5DO23598; Thu, 13 Mar 2003 08:05:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D8ONO04612 for ; Thu, 13 Mar 2003 03:24:23 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23473 for ; Thu, 13 Mar 2003 03:09:31 -0500 (EST) Received: from sarah ([65.27.11.57] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Mar 2003 02:11:23 -0600 Reply-To: From: "Dijiang Huang" To: "Iljitsch van Beijnum" Cc: Subject: RE: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat Date: Thu, 13 Mar 2003 02:10:29 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030312223931.S69506-100000@sequoia.muada.com> X-OriginalArrivalTime: 13 Mar 2003 08:11:23.0446 (UTC) FILETIME=[23005560:01C2E938] 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >Obviously that's not the real question (try "telnet >route-views.oregon-ix.net" if you disagree). If there even is a question >here, it would "is it possible to for the global routing table to not be >public knowledge". Every multiconnected non-stub AS needs path >information for loop protection. The number of people running these >networks is too large (and also spread out over the entire world) so >having them keep it a secret won't really work. Also, the operators are >probably not going to like anything like this as it makes >troubleshooting hell. And of course there's always tracroute. Hiding routing information is a very interesting issue. If we categorize the attack source by insiders and outsiders, we can easily guard against outsiders using strong authentication (Sandy's comments on attack source). But, considering insider attacks, the routing information may be (or should be) very valuable to attackers. (Here, I assume the one who can physically access to the communication links or routers as an insider, where the outsider can not access to). There are two type of hiding information: the network topology and traffic pattern (i.e. ospf, the metric in LSA can tell attackers the BW allocation). The network topology information may help the insiders to quickly identify the partition (cut) nodes and disable the network more easily, such as destroy the partition nodes or cut the partition links. The traffic pattern information can help attackers to guess what communication links may carry the "important" data traffic, then exert passive attacks (wiretap etc.), or can help to figure out how to inject forged routing information to switch the traffic to the routers or links that under the attackers control. There are can be multiple ways to derive network topology and traffic pattern. But, I think that analyze the routing data is one of the easy ways to do it. Obviously, hiding routing information violate the fundamental philosophy of the Internet. Moreover, the fundamental relationship among routers are cooperation and coordination. Hiding routing information may require additional key management overhead. And the network operator may also get "mad" that make him feel like losing the control of the network. I consider this is a tussle within current Internet. As described in David Clark's paper (http://www.acm.org/sigs/sigcomm/sigcomm2002/papers/tussle.pdf): "One of the most profound and irreversible changes in the Internet is that by and large, many of the users don't trust each other. The users of the Internet no longer represent a single community with common motivation and shared trust. There are parties with adverse interests, and some genuine "bad guys" out there. This implies that mechanisms that regulate interaction on the basis of mutual trust should be a fundamental part of the Internet of tomorrow." I consider the tussle between hiding routing information and the openness, transparency is another design consideration of network routing protocol. Besides the cooperation's network, in public routing domain, BGP can also hide some information through its policy from some Internet users. I don't know how to solve the "curiosity" of some operators to know the network topology. Maybe the trust relations can help network operators to know the routing information belong to their trust region. I am not sure my arguments are valid or not, please "hit" me if they are not correct. --Dijiang Huang _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 13 07:51:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28680 for ; Thu, 13 Mar 2003 07:51:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DD6IV23740 for rpsec-archive@odin.ietf.org; Thu, 13 Mar 2003 08:06:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DD6IO23737 for ; Thu, 13 Mar 2003 08:06:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28646 for ; Thu, 13 Mar 2003 07:51:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DD5SO23620; Thu, 13 Mar 2003 08:05:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DD0iO23405 for ; Thu, 13 Mar 2003 08:00:44 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28524 for ; Thu, 13 Mar 2003 07:45:48 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Mar 2003 06:47:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 13 Mar 2003 06:47:57 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02D025@KC-MAIL4.kc.umkc.edu> Thread-Topic: DDoS of routing ? Thread-Index: AcLpXsU7stgpkfdzQxOO9+j7RBlA2A== From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: X-OriginalArrivalTime: 13 Mar 2003 12:47:57.0511 (UTC) FILETIME=[C5D5B570:01C2E95E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DD0iO23406 Subject: [RPSEC] DDoS of routing ? 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit while a DoS attack of routing pkts by a peer can lead to RT exhaustion, is DDoS of routing pkts observed previously? Actually, i had an offline discussion with sandy long back and she mentioned that it doesn't exist. context: zinin-rtg-dos-00 I guess, zinin draft talks only about DDoS of data traffic. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 13 07:52:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28700 for ; Thu, 13 Mar 2003 07:52:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DD6mc23781 for rpsec-archive@odin.ietf.org; Thu, 13 Mar 2003 08:06:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DD6mO23778 for ; Thu, 13 Mar 2003 08:06:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28675 for ; Thu, 13 Mar 2003 07:51:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DD5xO23676; Thu, 13 Mar 2003 08:05:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DCGkO20662 for ; Thu, 13 Mar 2003 07:16:46 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27760 for ; Thu, 13 Mar 2003 07:01:50 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Mar 2003 06:04:00 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [RPSEC] Topic 7: Section 4.8 Byzantine Failures Date: Thu, 13 Mar 2003 06:03:59 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02D023@KC-MAIL4.kc.umkc.edu> Thread-Index: AcLpUdYTR3rkooWLQb2VWEP761cpIgAAAPCg From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: , X-OriginalArrivalTime: 13 Mar 2003 12:04:00.0100 (UTC) FILETIME=[A1D0BA40:01C2E958] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DCGkO20663 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sandy, > "Detecting a Byzantine error is harder than the fail-stop model in the > sense that at least one other processor must do the same computation > to confirm the results." This sounds like it came from some fault > tolerant textbook. It doesn't fit the language used elsewhere. > "processor"? "computation"? "Fail-stop model"? "confirm the > results"? I accept that this text is out of tune and doesn't fit with the rest of the draft contents. As for as fail-stop, the term itself explains. If there is a failure, the system stops functioning. To be precise, we can easily detect that there is some kind of failure. As you say, I studied about fail-stop in my distributed systems class. I am afraid, this is not true with respect to Internet. The Internet based attacks are random, arbitrary and unpredictable. We are living in a world were even a simple implementation bug and misconfiguration lead to widespread catastrophe and provide opportunities for backdoors and zombies. Please refer to caida's analysis on code-red and slammer. In short, I don't think Internet failures follow fail-stop model, at least seeing recent threats. > I don't think this section is necessary. It appears redundant. But, we should have a section on byzantine failures(?). As for as radia's work on byzantine robustness, its in the solution space which is clearly out of scope for the draft. Radia, any comments? _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 13 08:57:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00633 for ; Thu, 13 Mar 2003 08:57:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DECIs29863 for rpsec-archive@odin.ietf.org; Thu, 13 Mar 2003 09:12:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DECIO29860 for ; Thu, 13 Mar 2003 09:12:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00593 for ; Thu, 13 Mar 2003 08:57:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEBLO29789; Thu, 13 Mar 2003 09:11:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DEAUO29755 for ; Thu, 13 Mar 2003 09:10:30 -0500 Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00522 for ; Thu, 13 Mar 2003 08:55:31 -0500 (EST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2DDw0K75204; Thu, 13 Mar 2003 14:58:00 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 13 Mar 2003 14:58:00 +0100 (CET) From: Iljitsch van Beijnum To: "Ayyasamy, Senthilkumar (UMKC-Student)" cc: Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02D025@KC-MAIL4.kc.umkc.edu> Message-ID: <20030313143414.V69506-100000@sequoia.muada.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 Thu, 13 Mar 2003, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > while a DoS attack of routing pkts by a peer can lead to RT > exhaustion, is DDoS of routing pkts observed previously? I think attacks on port 179 of routers have been observed in the wild. > Actually, i had an offline discussion with sandy long back and she > mentioned that it doesn't exist. You're not saying we should wait to fix holes until someone falls in them, are you? At the same time, IGPs are somewhat hard to attack as they use multicasts that routers aren't going to forward. > context: zinin-rtg-dos-00 > I guess, zinin draft talks only about DDoS of data traffic. Doesn't look that way to me. One point we should all take to heart: "It is interesting to observe that as security mechanisms in routing protocols become more sophisticated and computationally expensive, it becomes easier for an attacker to mount a CPU-exhaustion-based attack against a router." _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 13 11:52:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08637 for ; Thu, 13 Mar 2003 11:52:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DH6un11835 for rpsec-archive@odin.ietf.org; Thu, 13 Mar 2003 12:06:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DH6uO11832 for ; Thu, 13 Mar 2003 12:06:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08605 for ; Thu, 13 Mar 2003 11:51:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DH5wO11767; Thu, 13 Mar 2003 12:05:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DH4dO11614 for ; Thu, 13 Mar 2003 12:04:39 -0500 Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08508; Thu, 13 Mar 2003 11:49:37 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h2DGpkZ28223; Thu, 13 Mar 2003 11:51:46 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Thu, 13 Mar 2003 11:51:45 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: agenda@ietf.org cc: rpsec@ietf.org, Russ White Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] RPSEC Agenda for IETF 56 (San Francisco) 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: , Routing Protocol Security Requirements WG (rpsec) Tuesday, March 18 at 0900-1130 =================================== CHAIRS: Russ White Tony Tauber AGENDA: Agenda Bashing Threats document draft-beard-rpsec-routing-threats-01.txt Requirements document development Direction of protocol-specific work Control-plane protection draft-zinin-rtg-dos-00.txt General discussion Please Read: draft-iab-sec-cons-03.txt draft-iab-secmech-01.txt _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 13 14:32:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14252 for ; Thu, 13 Mar 2003 14:32:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DJkx624743 for rpsec-archive@odin.ietf.org; Thu, 13 Mar 2003 14:46:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJkwO24740 for ; Thu, 13 Mar 2003 14:46:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14225 for ; Thu, 13 Mar 2003 14:31:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJk6O24678; Thu, 13 Mar 2003 14:46:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJjvO24640 for ; Thu, 13 Mar 2003 14:45:57 -0500 Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14116 for ; Thu, 13 Mar 2003 14:30:51 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h2DJWlS28387; Thu, 13 Mar 2003 14:32:47 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Thu, 13 Mar 2003 14:32:46 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Dijiang Huang cc: Iljitsch van Beijnum , Subject: RE: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat 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-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 Thu, 13 Mar 2003, Dijiang Huang wrote: > > >Obviously that's not the real question (try "telnet > >route-views.oregon-ix.net" if you disagree). If there even is a question > >here, it would "is it possible to for the global routing table to not be > >public knowledge". Every multiconnected non-stub AS needs path > >information for loop protection. The number of people running these > >networks is too large (and also spread out over the entire world) so > >having them keep it a secret won't really work. Also, the operators are > >probably not going to like anything like this as it makes > >troubleshooting hell. And of course there's always tracroute. > > Hiding routing information is a very interesting issue. A few comments: Remember, the work is not just for the public Internet but for the protocols which comprise it. Most or all of these can also be used in more circumscribed settings, but the security considerations often won't change. That is, don't just think about "the Internet" but any place a routing protocol is used. Certainly the "route servers" (a technical misnomer and "looking glass" is unfortunately no better) are orthogonal to protocol design; just an operational contrivance. Not to say anyone was confused, just thoguht I'd throw that clarification out there. To the real meat: Routing Protocols share or hide information by design - - share to discover topology and get traffic moving quickly and efficiently - hide to improve scaling by supressing extraneous topology details or as an instrument of policy I'm not sure that security can really speak to these directly other than to improve the "assuredness" of their operation, eg. in the authorization of the exchange or the validation of its contexts. I had a similar thought about the "deliberate exposure" idea. Is it not the job of the routing protocol to expose information? What do others think? I'm wondering if there should be (or is?) some parallel routing requirements description as there are things that a routing protocol must do to be effective which can't be "compromised" by over-zealous security design. Tony > I consider the tussle between hiding routing information and the > openness, transparency is another design consideration of network > routing protocol. Besides the cooperation's network, in public > routing domain, BGP can also hide some information through its > policy from some Internet users. I don't know how to solve the > "curiosity" of some operators to know the network topology. Maybe > the trust relations can help network operators to know the routing > information belong to their trust region. > > I am not sure my arguments are valid or not, please "hit" me if they > are not correct. > > --Dijiang Huang _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 13 15:42:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18329 for ; Thu, 13 Mar 2003 15:42:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DKum630302 for rpsec-archive@odin.ietf.org; Thu, 13 Mar 2003 15:56:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DKumO30299 for ; Thu, 13 Mar 2003 15:56:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18310 for ; Thu, 13 Mar 2003 15:41:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DKtfO30248; Thu, 13 Mar 2003 15:55:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DKs9O30139 for ; Thu, 13 Mar 2003 15:54:09 -0500 Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18186 for ; Thu, 13 Mar 2003 15:39:01 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h2DKf9128423; Thu, 13 Mar 2003 15:41:09 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Thu, 13 Mar 2003 15:41:09 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: sandy@tislabs.com cc: rpsec@ietf.org Subject: Re: [RPSEC] Topic 6: Section 4.1 Deliberate Exposure In-Reply-To: <200303112242.h2BMgk426639@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-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: , I'm confused as well. The sense I take from "deliberate" is that it's intentional. If information is intentionally revealed to parties who aren't authorized, it would seem to be a malicious act in itself, perhaps meant to deceive? Tony On Tue, 11 Mar 2003 sandy@tislabs.com wrote: > I'm confused by the language in the deliberate exposure section. > > The text says that deliberate exposure is when the "attackers" > release routing information to routers that are not authorized to > access the routing information. Presumably these attackers are > legitimate routers (otherwise how did they get access to the info). > The text seems to excuse a router from releasing routing information > to masqueraders (but only when it has been deceived). Does that > mean that a router that masquerades and then gets access to routing > information it is not authorized to access is NOT a deliberate > exposure? > > The sense of this section is that deliberate exposure is when the > router sends information knowingly to some router (or person, or > host, I would think) that is not supposed to have it. That's about > what I'd expect the words "deliberate exposure" to mean. > > But that leaves uncovered the case where an outsider obtains, by > some means (eavesdropping, spoofing, etc.), access to routing > information it should not have. Is this not considered a problem? > > (BTW: Section 3.2 lists interception as "gains access to routing > information that is considered sensitive". That seems to fit. Why > is it not included in the Section 4 list of threat actions?) > > --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 13 17:37:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22237 for ; Thu, 13 Mar 2003 17:37:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DMqEN06722 for rpsec-archive@odin.ietf.org; Thu, 13 Mar 2003 17:52:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMqEO06719 for ; Thu, 13 Mar 2003 17:52:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22232 for ; Thu, 13 Mar 2003 17:37:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMpFO06697; Thu, 13 Mar 2003 17:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DMoWO06667 for ; Thu, 13 Mar 2003 17:50:32 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22202 for ; Thu, 13 Mar 2003 17:35:22 -0500 (EST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2DMbX5w012771; Thu, 13 Mar 2003 17:37:33 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200303112230.h2BMUpm26322@raven.gw.tislabs.com> References: <200303112230.h2BMUpm26322@raven.gw.tislabs.com> Date: Thu, 13 Mar 2003 17:34:51 -0500 To: sandy@tislabs.com From: Stephen Kent Subject: Re: [RPSEC] comments on draft-beard-rpsec-routing-threats-01.txt Cc: rpsec@ietf.org, sandy@tislabs.com 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:30 PM -0500 3/11/03, sandy@tislabs.com wrote: >I'm attempting to send some comments on the threats draft. I've tried >to organize them so it's not so daunting to read through. > >There are 10 (most are real small, don't despair) >Topic 1: Section 3.1 Threat Sources >Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? >Topic 3: Section 4.4 Spoofing >Topic 4: Section 4.5 terminology - "Ownership" >Topic 5: 4.3 Traffic Analysis - really a threat against routing protocol? >Topic 6: Section 4.1 Deliberate Exposure >Topic 7: Section 4.8 Byzantine Failures >Topic 8: Section 4.9 Discarding of Control Packets (aka underclaiming?) >Topic 9: Section 4.10 Network Mapping Threat >Topic 10: Section 4.7 Overload >Topic 11: Section 3.2 Threat Actions vs Section 4 "Generally...Threat Actions" > >--Sandy BTW, these are attacks, not threats. (not your fault, Sandy.) I still maintain that we need a threat model, not just a list of attacks. As I noted some time ago, this list does not persuade anyone that we have performed a top-down analysis of the problem space and are in a position to generate requirements as a result. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 13 21:57:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00477 for ; Thu, 13 Mar 2003 21:57:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E3C9a23978 for rpsec-archive@odin.ietf.org; Thu, 13 Mar 2003 22:12:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E3C9O23975 for ; Thu, 13 Mar 2003 22:12:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00463 for ; Thu, 13 Mar 2003 21:56:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E3BJO23950; Thu, 13 Mar 2003 22:11:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E3AJO23894 for ; Thu, 13 Mar 2003 22:10:19 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00445 for ; Thu, 13 Mar 2003 21:55:04 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tfNf-000HTX-00; Thu, 13 Mar 2003 18:57:11 -0800 Date: Thu, 13 Mar 2003 18:55:21 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <137211665048.20030313185521@psg.com> To: Iljitsch van Beijnum CC: "Ayyasamy, Senthilkumar (UMKC-Student)" , rpsec@ietf.org Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: <20030313143414.V69506-100000@sequoia.muada.com> References: <20030313143414.V69506-100000@sequoia.muada.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Iljitsch, Senthil- Thursday, March 13, 2003, 5:58:00 AM, Iljitsch van Beijnum wrote: > On Thu, 13 Mar 2003, Ayyasamy, Senthilkumar (UMKC-Student) wrote: >> while a DoS attack of routing pkts by a peer can lead to RT >> exhaustion, is DDoS of routing pkts observed previously? > I think attacks on port 179 of routers have been observed in the wild. This is what I have heard second hand too. Note, btw, that user-level attacks against routers are not limited to those using routing protocols or targeted to CPU/queue exhaustion. Vulnerabilities related to various forms of buffer overflow, and other implementations bugs/suboptimalities have been known for long time. Those can be potentially exploited too. And the attacks are getting more and more sophisticated, an example is the recently announced OSPF exploit where an attacker can make a router execute malicious code. >> Actually, i had an offline discussion with sandy long back and she >> mentioned that it doesn't exist. > You're not saying we should wait to fix holes until someone falls in > them, are you? > At the same time, IGPs are somewhat hard to attack as they use > multicasts that routers aren't going to forward. This is not entirely true. IS-IS is indeed not susceptible to user-level attacks, as, in its original form it uses L2 encapsulation for its PDUs, and because those are unroutable, a user can't sent an IS-IS packet to a router. However, I'm hearing that some vendors have actually implemented ISIS-over-IPv4 though it wasn't accepted by the IS-IS WG. This could leave a potential backdoor for an attacker if the implementation just listens to this IP protocol or has it enabled on a set of interfaces. It would be as good/bad as in the OSPF case, no extra. OSPF, on the other hand, uses unicast quite extensively. First, on broadcast media all neighbor-to-neighbor OSPF packet exchanges from ExStart and higher are done in unicast. Plus we have virtual links that are exclusively unicast. Besides, the specification suggests to treat both unicast and multicast packets equally, which is what many implementations do, especially if they allow manually configured neighbors. So, it is very possible for an attacker to send a packet to a router and it will be allowed to go all the way up to the OSPF process (unless MD5 is done on the LC, of course). >> context: zinin-rtg-dos-00 >> I guess, zinin draft talks only about DDoS of data traffic. > Doesn't look that way to me. Right. In fact, it does not talk at all about data traffic DDoS. It is all about protecting routers' control plane from user-level attacks. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 13 23:49:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03054 for ; Thu, 13 Mar 2003 23:49:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E54Lt30878 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 00:04:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E54LO30875 for ; Fri, 14 Mar 2003 00:04:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03027 for ; Thu, 13 Mar 2003 23:49:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E53QO30806; Fri, 14 Mar 2003 00:03:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E52wO30747 for ; Fri, 14 Mar 2003 00:02:58 -0500 Received: from mail-red.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02957 for ; Thu, 13 Mar 2003 23:47:40 -0500 (EST) Received: (from postfixfilter@localhost) by mail-red.research.att.com (8.11.6/8.11.6) id h2E4pvE02538; Thu, 13 Mar 2003 23:51:57 -0500 X-Authentication-Warning: mail-red.research.att.com: postfixfilter set sender to ji@research.att.com using -f Received: from bual.research.att.com (H-135-207-24-19.research.att.com [135.207.24.19]) by mail-red.research.att.com (Postfix) with ESMTP id 15E3F1AB4BD; Thu, 13 Mar 2003 23:51:57 -0500 (EST) Received: (from ji@localhost) by bual.research.att.com (8.11.6+Sun/8.8.7) id h2E4nkY04344; Thu, 13 Mar 2003 23:49:46 -0500 (EST) Date: Thu, 13 Mar 2003 23:49:46 -0500 From: John Ioannidis To: Alex Zinin Cc: Iljitsch van Beijnum , "Ayyasamy, Senthilkumar (UMKC-Student)" , rpsec@ietf.org Subject: Re: Re: [RPSEC] DDoS of routing ? Message-ID: <20030314044946.GC4215@bual.research.att.com> References: <20030313143414.V69506-100000@sequoia.muada.com> <137211665048.20030313185521@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <137211665048.20030313185521@psg.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-138.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT, USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) 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: , DoS attacks on the BGP port are apparently fairly common, at least according to what I heard at the last NANOG. The problem is that the pipe *to* the RP in many current routers is not all that fat, and even a small flooding attack against port 179 can take out the RP, and hence the router. That particular vulnerability is fairly easy to fix; just deny anything *to* port 179 that's not coming from an adjacent router (that is, with TTL 255 or 254, depending on exactly what you are running), and that can stop all simple attacks. Obviously, this doesn't work against multihop BGP; there you need crypto that's actually terminated at the line card (or outside the router); again, you don't want the cryptographic verification of your packets happening on the RP, for obvious reasons. /ji On Thu, Mar 13, 2003 at 06:55:21PM -0800, Alex Zinin wrote: > Iljitsch, Senthil- > > > > Thursday, March 13, 2003, 5:58:00 AM, Iljitsch van Beijnum wrote: > > On Thu, 13 Mar 2003, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > > >> while a DoS attack of routing pkts by a peer can lead to RT > >> exhaustion, is DDoS of routing pkts observed previously? > > > I think attacks on port 179 of routers have been observed in the wild. > > This is what I have heard second hand too. > > Note, btw, that user-level attacks against routers are not limited to > those using routing protocols or targeted to CPU/queue exhaustion. > Vulnerabilities related to various forms of buffer overflow, and other > implementations bugs/suboptimalities have been known for long time. > Those can be potentially exploited too. > > And the attacks are getting more and more sophisticated, an example > is the recently announced OSPF exploit where an attacker can make > a router execute malicious code. > > >> Actually, i had an offline discussion with sandy long back and she > >> mentioned that it doesn't exist. > > > You're not saying we should wait to fix holes until someone falls in > > them, are you? > > > At the same time, IGPs are somewhat hard to attack as they use > > multicasts that routers aren't going to forward. > > This is not entirely true. > > IS-IS is indeed not susceptible to user-level attacks, as, in its > original form it uses L2 encapsulation for its PDUs, and because those > are unroutable, a user can't sent an IS-IS packet to a router. > However, I'm hearing that some vendors have actually implemented > ISIS-over-IPv4 though it wasn't accepted by the IS-IS WG. This could > leave a potential backdoor for an attacker if the implementation just > listens to this IP protocol or has it enabled on a set of interfaces. > It would be as good/bad as in the OSPF case, no extra. > > OSPF, on the other hand, uses unicast quite extensively. First, on > broadcast media all neighbor-to-neighbor OSPF packet exchanges from > ExStart and higher are done in unicast. Plus we have virtual links > that are exclusively unicast. Besides, the specification suggests to > treat both unicast and multicast packets equally, which is what many > implementations do, especially if they allow manually configured > neighbors. So, it is very possible for an attacker to send a packet to > a router and it will be allowed to go all the way up to the OSPF > process (unless MD5 is done on the LC, of course). > > >> context: zinin-rtg-dos-00 > >> I guess, zinin draft talks only about DDoS of data traffic. > > > Doesn't look that way to me. > > Right. > > In fact, it does not talk at all about data traffic DDoS. It is all > about protecting routers' control plane from user-level attacks. > > Alex > > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Mar 13 23:50:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03077 for ; Thu, 13 Mar 2003 23:50:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E54mR30906 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 00:04:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E54mO30903 for ; Fri, 14 Mar 2003 00:04:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03043 for ; Thu, 13 Mar 2003 23:49:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E541O30836; Fri, 14 Mar 2003 00:04:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E53WO30815 for ; Fri, 14 Mar 2003 00:03:32 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02970 for ; Thu, 13 Mar 2003 23:48:15 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Mar 2003 22:50:26 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [RPSEC] DDoS of routing ? Date: Thu, 13 Mar 2003 22:50:25 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02D02A@KC-MAIL4.kc.umkc.edu> Thread-Topic: [RPSEC] DDoS of routing ? Thread-Index: AcLp1WrWi1PCYRbPRzygKgxSaeUoCAACYUiA From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Alex Zinin" , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 14 Mar 2003 04:50:26.0138 (UTC) FILETIME=[3AB2E3A0:01C2E9E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2E53WO30816 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Iljitsch/Alex, > >> while a DoS attack of routing pkts by a peer can lead to RT > >> exhaustion, is DDoS of routing pkts observed previously? > > > I think attacks on port 179 of routers have been observed > in the wild. > > This is what I have heard second hand too. But, its not so wild like port 80 (www), 137(netbios) and 1434(sql) Cisco routers avoids this by accepting tcp sessions from configured peers. How does other systems avoids this port 179 attack... particularly zebra? port 179 attack is a way for cpu resource exhaustion. If vendors are clever enough, heuristics can be provided at ASIC level to avoid such attacks. > >> context: zinin-rtg-dos-00 > >> I guess, zinin draft talks only about DDoS of data traffic. > > It is all about protecting routers' control plane from user-level attacks. Yes. I will read and sent detailed comments later. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 00:14:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03552 for ; Fri, 14 Mar 2003 00:14:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E5Sxu32386 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 00:28:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5SwO32382 for ; Fri, 14 Mar 2003 00:28:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03541 for ; Fri, 14 Mar 2003 00:13:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5S6O32351; Fri, 14 Mar 2003 00:28:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5RJO32323 for ; Fri, 14 Mar 2003 00:27:19 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03511 for ; Fri, 14 Mar 2003 00:12:03 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Mar 2003 23:14:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Re: [RPSEC] DDoS of routing ? Date: Thu, 13 Mar 2003 23:14:12 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02D02B@KC-MAIL4.kc.umkc.edu> Thread-Topic: Re: [RPSEC] DDoS of routing ? Thread-Index: AcLp5SlclBL7KegbSO2eHj3aMeETUQAAHCKA From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "John Ioannidis" , "Alex Zinin" Cc: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 14 Mar 2003 05:14:12.0956 (UTC) FILETIME=[8D2609C0:01C2E9E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2E5RJO32324 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit ji, > again, you don't want the cryptographic verification of your packets > happening on the RP, for obvious reasons. yes. In general, documented solutions(s-bgp) for routing security is difficult to deploy due to the involved cost. The only clever solution seems to be utilize registries for maintaining a consistent view by enforcing RPSL and rfc 2725. - Senthil. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 00:18:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03611 for ; Fri, 14 Mar 2003 00:18:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E5X1p32578 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 00:33:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5X1O32575 for ; Fri, 14 Mar 2003 00:33:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03603 for ; Fri, 14 Mar 2003 00:17:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5WDO32530; Fri, 14 Mar 2003 00:32:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5W0O32516 for ; Fri, 14 Mar 2003 00:32:00 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03592 for ; Fri, 14 Mar 2003 00:16:43 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2E5IqIG011488 for ; Thu, 13 Mar 2003 22:18:52 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id WAA25922 for ; Thu, 13 Mar 2003 22:18:52 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Mar 2003 00:18:49 -0500 Message-ID: From: "Manral, Vishwas" To: "'John Ioannidis'" , Alex Zinin Cc: Iljitsch van Beijnum , "Ayyasamy, Senthilkumar (UMKC-Student)" , rpsec@ietf.org Subject: RE: Re: [RPSEC] DDoS of routing ? Date: Fri, 14 Mar 2003 00:20:27 -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-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: , Hi ji, Maybe the same thing can be done for OSPF too. All non-ABR's allow only a one hop reduced in TTL/hop limit, so a value of 254 or 255. Only ABR's that have virtual links configured should be allowed to process packets that are not received from one hop away. And it could clearly be speciefied that allowing virtual links could allow such an attack. Thanks, Vishwas -----Original Message----- From: John Ioannidis [mailto:ji@research.att.com] Sent: Friday, March 14, 2003 10:20 AM To: Alex Zinin Cc: Iljitsch van Beijnum; Ayyasamy, Senthilkumar (UMKC-Student); rpsec@ietf.org Subject: Re: Re: [RPSEC] DDoS of routing ? DoS attacks on the BGP port are apparently fairly common, at least according to what I heard at the last NANOG. The problem is that the pipe *to* the RP in many current routers is not all that fat, and even a small flooding attack against port 179 can take out the RP, and hence the router. That particular vulnerability is fairly easy to fix; just deny anything *to* port 179 that's not coming from an adjacent router (that is, with TTL 255 or 254, depending on exactly what you are running), and that can stop all simple attacks. Obviously, this doesn't work against multihop BGP; there you need crypto that's actually terminated at the line card (or outside the router); again, you don't want the cryptographic verification of your packets happening on the RP, for obvious reasons. /ji On Thu, Mar 13, 2003 at 06:55:21PM -0800, Alex Zinin wrote: > Iljitsch, Senthil- > > > > Thursday, March 13, 2003, 5:58:00 AM, Iljitsch van Beijnum wrote: > > On Thu, 13 Mar 2003, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > > >> while a DoS attack of routing pkts by a peer can lead to RT > >> exhaustion, is DDoS of routing pkts observed previously? > > > I think attacks on port 179 of routers have been observed in the wild. > > This is what I have heard second hand too. > > Note, btw, that user-level attacks against routers are not limited to > those using routing protocols or targeted to CPU/queue exhaustion. > Vulnerabilities related to various forms of buffer overflow, and other > implementations bugs/suboptimalities have been known for long time. > Those can be potentially exploited too. > > And the attacks are getting more and more sophisticated, an example > is the recently announced OSPF exploit where an attacker can make > a router execute malicious code. > > >> Actually, i had an offline discussion with sandy long back and she > >> mentioned that it doesn't exist. > > > You're not saying we should wait to fix holes until someone falls in > > them, are you? > > > At the same time, IGPs are somewhat hard to attack as they use > > multicasts that routers aren't going to forward. > > This is not entirely true. > > IS-IS is indeed not susceptible to user-level attacks, as, in its > original form it uses L2 encapsulation for its PDUs, and because those > are unroutable, a user can't sent an IS-IS packet to a router. > However, I'm hearing that some vendors have actually implemented > ISIS-over-IPv4 though it wasn't accepted by the IS-IS WG. This could > leave a potential backdoor for an attacker if the implementation just > listens to this IP protocol or has it enabled on a set of interfaces. > It would be as good/bad as in the OSPF case, no extra. > > OSPF, on the other hand, uses unicast quite extensively. First, on > broadcast media all neighbor-to-neighbor OSPF packet exchanges from > ExStart and higher are done in unicast. Plus we have virtual links > that are exclusively unicast. Besides, the specification suggests to > treat both unicast and multicast packets equally, which is what many > implementations do, especially if they allow manually configured > neighbors. So, it is very possible for an attacker to send a packet to > a router and it will be allowed to go all the way up to the OSPF > process (unless MD5 is done on the LC, of course). > > >> context: zinin-rtg-dos-00 > >> I guess, zinin draft talks only about DDoS of data traffic. > > > Doesn't look that way to me. > > Right. > > In fact, it does not talk at all about data traffic DDoS. It is all > about protecting routers' control plane from user-level attacks. > > Alex > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 00:31:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03949 for ; Fri, 14 Mar 2003 00:31:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E5jtL01915 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 00:45:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5jtO01912 for ; Fri, 14 Mar 2003 00:45:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03910 for ; Fri, 14 Mar 2003 00:30:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5j7O01876; Fri, 14 Mar 2003 00:45:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5iwO01849 for ; Fri, 14 Mar 2003 00:44:58 -0500 Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03882 for ; Fri, 14 Mar 2003 00:29:41 -0500 (EST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2E5UqL76988; Fri, 14 Mar 2003 06:30:52 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 14 Mar 2003 06:30:51 +0100 (CET) From: Iljitsch van Beijnum To: John Ioannidis cc: Alex Zinin , "Ayyasamy, Senthilkumar (UMKC-Student)" , Subject: Re: Re: [RPSEC] DDoS of routing ? In-Reply-To: <20030314044946.GC4215@bual.research.att.com> Message-ID: <20030314061858.B69506-100000@sequoia.muada.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 Thu, 13 Mar 2003, John Ioannidis wrote: > DoS attacks on the BGP port are apparently fairly common, at least > according to what I heard at the last NANOG. The problem is that the > pipe *to* the RP in many current routers is not all that fat, and even > a small flooding attack against port 179 can take out the RP, and > hence the router. > That particular vulnerability is fairly easy to fix; just deny > anything *to* port 179 that's not coming from an adjacent router (that > is, with TTL 255 or 254, depending on exactly what you are running), > and that can stop all simple attacks. Overloading the path to the CPU can be done using any service that must be terminated on the CPU, which is much more than routing protocols: telnet/ssh, ICMP, any packet with TTL 1... Unfortunately, there is no one size fits all solution here as far that I'm aware of. > Obviously, this doesn't work > against multihop BGP; there you need crypto that's actually terminated > at the line card (or outside the router); When fighting DoS, crypto is NOT your friend. In nearly all cases, it just makes the problem worse. I haven't heard of any vendor who includes line rate MD5 processing on the linecard (good luck doing this at 10 Gbps anyway...) _just_ to protect ebgp-multihop BGP sessions. A better way to deal with this is use some kind of magic cookie in each packet that can be precomputed and easily checked. For instance, each segment includes an MD5 over the previous segment and a secret key. Since the MD5 operation needs to be done only after processing a valid segment rather than after each segment, an attacker can't trigger unnecessary MD5 operations, just some 16 byte compare operations. These are somewhat less costly to implement in a linecard than even the fastest crypto... Iljitsch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 00:38:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04063 for ; Fri, 14 Mar 2003 00:38:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E5r0s02226 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 00:53:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5r0O02221 for ; Fri, 14 Mar 2003 00:53:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04051 for ; Fri, 14 Mar 2003 00:37:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5q3O02092; Fri, 14 Mar 2003 00:52:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5pxO02077 for ; Fri, 14 Mar 2003 00:51:59 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04026 for ; Fri, 14 Mar 2003 00:36:42 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18thu4-000O7j-00; Thu, 13 Mar 2003 21:38:48 -0800 Date: Thu, 13 Mar 2003 21:38:28 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <0221452091.20030313213828@psg.com> To: John Ioannidis CC: Iljitsch van Beijnum , "Ayyasamy, Senthilkumar (UMKC-Student)" , Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: <20030314044946.GC4215@bual.research.att.com> References: <20030313143414.V69506-100000@sequoia.muada.com> <137211665048.20030313185521@psg.com> <20030314044946.GC4215@bual.research.att.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit JI, Thursday, March 13, 2003, 8:49:46 PM, John Ioannidis wrote: > DoS attacks on the BGP port are apparently fairly common, at least > according to what I heard at the last NANOG. The problem is that the > pipe *to* the RP in many current routers is not all that fat, and even > a small flooding attack against port 179 can take out the RP, and > hence the router. The problem is actually not BGP specific. BGP (as well as OSPF, or LDP) just opens a generic queue and CPU exhaustion vulnerability. Whenever a potentially forged packet (be that OSPF, RIP, or BGP) shares resources with a valid packet (any type again), an attack is possible. Strictly speaking, the attack is not even MD5-specific, MD5 just makes its success chances higher because it reduces the rate of queue draining and increases CPU utilization. > That particular vulnerability is fairly easy to fix; just deny > anything *to* port 179 that's not coming from an adjacent router (that > is, with TTL 255 or 254, depending on exactly what you are running), > and that can stop all simple attacks. Obviously, this doesn't work > against multihop BGP; Correct. BTSH solves a very focused problem--eBGP. The TTL hack principle could be described using the notion of "trust radius", which is (255-TTL). When it is 0 or 1, you're fine, because you don't expect an attacker to be so close to your eBGP speaker. Once you increase it, the probability of an attacker being within the trust proximity grows very fast. So, this does not work for iBGP, or OSPF VLs (as well as other multihop protocols used within a SP's network such as SSH or SNMP). > there you need crypto that's actually terminated > at the line card (or outside the router); again, you don't want the > cryptographic verification of your packets happening on the RP, for > obvious reasons. draft-zinin-rtg actually tries to solve a generic problem of attacks from users (the iBGP and OSPF included) without the need for additional HW, which should allow it to be implemented even on already installed routers. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 00:41:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04215 for ; Fri, 14 Mar 2003 00:41:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E5tui02436 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 00:55:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5tuO02433 for ; Fri, 14 Mar 2003 00:55:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04203 for ; Fri, 14 Mar 2003 00:40:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5t7O02409; Fri, 14 Mar 2003 00:55:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5sTO02327 for ; Fri, 14 Mar 2003 00:54:29 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04135 for ; Fri, 14 Mar 2003 00:39:12 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Mar 2003 23:41:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat Date: Thu, 13 Mar 2003 23:41:21 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02D02C@KC-MAIL4.kc.umkc.edu> Thread-Topic: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat Thread-Index: AcLpl3EcrcnrSbubQLSi+UFGSKl5FAAU6CIg From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Tony Tauber" , "Dijiang Huang" Cc: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 14 Mar 2003 05:41:22.0029 (UTC) FILETIME=[5826D9D0:01C2E9EC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2E5sTO02328 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Tony, > I had a similar thought about the "deliberate exposure" idea. > Is it not the job of the routing protocol to expose information? > > What do others think? It was documented in 1995 and so, we have registeries. RFC 1787. "7. Routing Information Sharing While ensuring Internet-wide coordination may be more and more difficult, as the Internet continues to grow, stability and consistency of the Internet-wide routing could significantly benefit if the information about routing requirements of various organizations could be shared across organizational boundaries. Such information could be used in a wide variety of situations ranging from troubleshooting to detecting and eliminating conflicting routing requirements. The scale of the Internet implies that the information should be distributed. " _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 00:44:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04264 for ; Fri, 14 Mar 2003 00:44:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E5ww502607 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 00:58:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5wwO02604 for ; Fri, 14 Mar 2003 00:58:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04252 for ; Fri, 14 Mar 2003 00:43:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5w2O02538; Fri, 14 Mar 2003 00:58:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5v8O02507 for ; Fri, 14 Mar 2003 00:57:08 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04237 for ; Fri, 14 Mar 2003 00:41:52 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18thz4-000OLB-00; Thu, 13 Mar 2003 21:43:58 -0800 Date: Thu, 13 Mar 2003 21:43:36 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <139221759883.20030313214336@psg.com> To: "Ayyasamy, Senthilkumar (UMKC-Student)" CC: "Iljitsch van Beijnum" , rpsec@ietf.org Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02D02A@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B02D02A@KC-MAIL4.kc.umkc.edu> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Senthil, >> This is what I have heard second hand too. > But, its not so wild like port 80 (www), 137(netbios) and 1434(sql) changing the port number is not extremely hard... > Cisco routers avoids this by accepting tcp sessions from configured > peers. This is not a solution to the problem. An attacker can spoof the source address easily. > How does other systems avoids this port 179 attack... > particularly zebra? Zebra works on the apps level. In zebra case the attack would affects the code and queues below. > port 179 attack is a way for cpu resource exhaustion. If vendors are > clever enough, heuristics can be provided at ASIC level to avoid > such attacks. I'm sure many people here would be interested to know how. > Yes. I will read and sent detailed comments later. Please do. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 00:46:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04307 for ; Fri, 14 Mar 2003 00:46:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E60x902741 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 01:00:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E60xO02738 for ; Fri, 14 Mar 2003 01:00:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04300 for ; Fri, 14 Mar 2003 00:45:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E601O02698; Fri, 14 Mar 2003 01:00:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E5wEO02550 for ; Fri, 14 Mar 2003 00:58:14 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04246 for ; Fri, 14 Mar 2003 00:42:57 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18ti07-000OMj-00; Thu, 13 Mar 2003 21:45:03 -0800 Date: Thu, 13 Mar 2003 21:44:42 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <192221826229.20030313214442@psg.com> To: "Ayyasamy, Senthilkumar (UMKC-Student)" CC: "John Ioannidis" , "Iljitsch van Beijnum" , Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02D02B@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B02D02B@KC-MAIL4.kc.umkc.edu> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Senthil, >> again, you don't want the cryptographic verification of your packets >> happening on the RP, for obvious reasons. > yes. In general, documented solutions(s-bgp) for routing security is > difficult to deploy due to the involved cost. The only clever solution > seems to be utilize registries for maintaining a consistent view by > enforcing RPSL and rfc 2725. You're confusing two different issues: transport-level message authentication and authentication and authorization of actual prefix announcements. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 00:53:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04424 for ; Fri, 14 Mar 2003 00:53:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E67qK03775 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 01:07:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E67qO03772 for ; Fri, 14 Mar 2003 01:07:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04412 for ; Fri, 14 Mar 2003 00:52:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E674O03102; Fri, 14 Mar 2003 01:07:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E66BO02937 for ; Fri, 14 Mar 2003 01:06:11 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04390 for ; Fri, 14 Mar 2003 00:50:54 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 13 Mar 2003 23:53:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [RPSEC] DDoS of routing ? Date: Thu, 13 Mar 2003 23:53:03 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02D02D@KC-MAIL4.kc.umkc.edu> Thread-Topic: [RPSEC] DDoS of routing ? Thread-Index: AcLp7LX97iN14+HcTY+T0fu/6iiotwAAA/Pg From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Alex Zinin" Cc: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 14 Mar 2003 05:53:03.0797 (UTC) FILETIME=[FA702650:01C2E9ED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2E66BO02938 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Alex, > > port 179 attack is a way for cpu resource exhaustion. If vendors are > > clever enough, heuristics can be provided at ASIC level to avoid > > such attacks. > > I'm sure many people here would be interested to know how. I meant router mechanisms to avoid DoS attacks. by means of packet sampling. a tight filter, say 1:100 will help us drill down DoS attacks. also, some recent proposals. RED-PD and pushback. - Senthil. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 01:10:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05106 for ; Fri, 14 Mar 2003 01:10:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E6PK104480 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 01:25:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E6PKO04477 for ; Fri, 14 Mar 2003 01:25:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05019 for ; Fri, 14 Mar 2003 01:10:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E6O7O04425; Fri, 14 Mar 2003 01:24:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E6NYO04379 for ; Fri, 14 Mar 2003 01:23:34 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04956 for ; Fri, 14 Mar 2003 01:08:16 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tiOa-000PmQ-00; Thu, 13 Mar 2003 22:10:20 -0800 Date: Thu, 13 Mar 2003 22:09:52 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <53223335709.20030313220952@psg.com> To: "Manral, Vishwas" CC: "'John Ioannidis'" , Iljitsch van Beijnum , "Ayyasamy, Senthilkumar (UMKC-Student)" , Subject: Re: [RPSEC] DDoS of routing ? 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-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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vishwas, Before I came up with this draft, I was thinking about this approach too. While it would solve most problems with VL-less OSPF, I wasn't happy about a) the fact that VL is still open (AFAIR some ISPs actually used it, at least a couple of years ago, though I may be mistaken), b) that modification of routing protocols was required, and more importantly c) other vulnerabilities like iBGP, SSH, SNMP, etc. still remained open. I was trying to come up with a simple to implement solution that would solve a more generic problem... Not trying to say that the TTL hack for OSPF wouldn't work, though... -- Alex Thursday, March 13, 2003, 9:20:27 PM, Manral, Vishwas wrote: > Hi ji, > Maybe the same thing can be done for OSPF too. All non-ABR's allow only a > one hop reduced in TTL/hop limit, so a value of 254 or 255. Only ABR's that > have virtual links configured should be allowed to process packets that are > not received from one hop away. > And it could clearly be speciefied that allowing virtual links could allow > such an attack. > Thanks, > Vishwas _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 01:15:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05216 for ; Fri, 14 Mar 2003 01:15:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E6Tni04659 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 01:29:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E6TnO04656 for ; Fri, 14 Mar 2003 01:29:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05196 for ; Fri, 14 Mar 2003 01:14:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E6T1O04610; Fri, 14 Mar 2003 01:29:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E6SDO04569 for ; Fri, 14 Mar 2003 01:28:13 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05146 for ; Fri, 14 Mar 2003 01:12:55 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tiT3-000Q0n-00; Thu, 13 Mar 2003 22:14:58 -0800 Date: Thu, 13 Mar 2003 22:14:29 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <97223612738.20030313221429@psg.com> To: "Ayyasamy, Senthilkumar (UMKC-Student)" CC: "Iljitsch van Beijnum" , rpsec@ietf.org Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02D02D@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B02D02D@KC-MAIL4.kc.umkc.edu> 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Senthil, >> I'm sure many people here would be interested to know how. > I meant router mechanisms to avoid DoS attacks. > by means of packet sampling. a tight filter, say 1:100 will help us > drill down DoS attacks. hmmm... but you can't avoid an attack by sampling... you could probably detect something, but not avoid > also, some recent proposals. RED-PD and pushback. the key problem with these attacks is that forged packets look exactly like valid up until you do the MD5 check, so RED, filters, etc. won't be able to tell them apart... Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 10:50:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00104 for ; Fri, 14 Mar 2003 10:50:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EG5m120137 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 11:05:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EG5mO20134 for ; Fri, 14 Mar 2003 11:05:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00087 for ; Fri, 14 Mar 2003 10:50:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EG4pO20053; Fri, 14 Mar 2003 11:04:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EFvqO19675 for ; Fri, 14 Mar 2003 10:57:52 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29928 for ; Fri, 14 Mar 2003 10:42:22 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Fri, 14 Mar 2003 09:44:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [RPSEC] comments on draft-beard-rpsec-routing-threats-01.txt Date: Fri, 14 Mar 2003 09:44:32 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02D030@KC-MAIL4.kc.umkc.edu> Thread-Topic: Re: [RPSEC] comments on draft-beard-rpsec-routing-threats-01.txt Thread-Index: AcLqQJsS+5ECLArlQwGbbdfQLFeUgw== From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: Cc: , X-OriginalArrivalTime: 14 Mar 2003 15:44:32.0666 (UTC) FILETIME=[9B73CFA0:01C2EA40] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2EFvqO19676 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Steve, > BTW, these are attacks, not threats. I still maintain that > we need a threat model, not just a list of attacks. Yes. But, It's good to list the attacks...Possibly, the title and scope of the draft can be modified to reflect your comments. anyway, I don't think a big gap exists between attacks and possible threats. You have anything specific in mind? - Senthil. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 14:22:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09622 for ; Fri, 14 Mar 2003 14:22:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EJbRf03262 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 14:37:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJbRO03259 for ; Fri, 14 Mar 2003 14:37:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09618 for ; Fri, 14 Mar 2003 14:21:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJaIO02515; Fri, 14 Mar 2003 14:36:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EJZUO02464 for ; Fri, 14 Mar 2003 14:35:31 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09521 for ; Fri, 14 Mar 2003 14:19:55 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id OAA29052; Fri, 14 Mar 2003 14:22:55 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma029017; Fri, 14 Mar 03 14:22:07 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2EJLGU09201; Fri, 14 Mar 2003 14:21:16 -0500 (EST) Date: Fri, 14 Mar 2003 14:21:16 -0500 (EST) Message-Id: <200303141921.h2EJLGU09201@raven.gw.tislabs.com> To: rpsec@ietf.org, sandy@tislabs.com, saq66@umkc.edu Subject: Re: [RPSEC] Topic 7: Section 4.8 Byzantine Failures Cc: sandy@tislabs.com 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: , >I accept that this text is out of tune and doesn't fit with >the rest of the draft contents. As for as fail-stop, the term itself >explains. If there is a failure, the system stops functioning. To be >precise, we can easily detect that there is some kind of failure. As >you say, I studied about fail-stop in my distributed systems class. I know very well what fail-stop is. The point is that the term is not mentioned earlier. We don't address the problem of fail-stop errors anywhere, so it makes little sense to try to distinguish this from a fail-stop error. >In short, I don't think Internet failures follow fail-stop model, at least >seeing recent threats. So the draft need not address them. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 15:27:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13251 for ; Fri, 14 Mar 2003 15:27:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EKgLq08229 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 15:42:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKgKO08226 for ; Fri, 14 Mar 2003 15:42:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13232 for ; Fri, 14 Mar 2003 15:26:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKfEO08175; Fri, 14 Mar 2003 15:41:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKe4O08135 for ; Fri, 14 Mar 2003 15:40:04 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13157 for ; Fri, 14 Mar 2003 15:24:28 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tvlB-0009cA-00; Fri, 14 Mar 2003 12:26:33 -0800 Date: Fri, 14 Mar 2003 12:26:10 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <70274714638.20030314122610@psg.com> To: Iljitsch van Beijnum CC: John Ioannidis , "Ayyasamy, Senthilkumar (UMKC-Student)" , Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: <20030314061858.B69506-100000@sequoia.muada.com> References: <20030314061858.B69506-100000@sequoia.muada.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Iljitsch, > Overloading the path to the CPU can be done using any service that must > be terminated on the CPU, which is much more than routing protocols: > telnet/ssh, ICMP, any packet with TTL 1... Unfortunately, there is no > one size fits all solution here as far that I'm aware of. BTW, a little unrelated, but still within the topic: from the router DoS protection point of view, a big difference between ICMP plus traceroute's UDP packets and others (routing, ssh, etc.) is that rate limiting the combined (trusted + untrusted) ICMP stream is fine because even if we loose some valid ICMP packets when an attack is going on, we do not loose the network or ability to control it. While for other packets (routing included) we need very strict separation of resources for trusted and untrusted packets. Basically the difference is in the criticality of packets. >> Obviously, this doesn't work >> against multihop BGP; there you need crypto that's actually terminated >> at the line card (or outside the router); > When fighting DoS, crypto is NOT your friend. In nearly all cases, it > just makes the problem worse. Not sure what you mean here. If it is able to parse data at line rate, why would it make the problem worse? > I haven't heard of any vendor who includes > line rate MD5 processing on the linecard (good luck doing this at 10 > Gbps anyway...) _just_ to protect ebgp-multihop BGP sessions. I think a quick google search would reveal some developments in this field, even for gige speeds, don't remember about 10G, and no idea about how expensive this is. What would really be needed is a chip that would be able to identify packets that need to be checked (such as BGP's TCP sessions, IPSec SAs, etc) and do the required authentication checks, all at line rate. I actually think that vendors should go in this direction. On the other hand, the time required to upgrade sufficient number of routers to substantially increase security of the Internet routing infrastructure can be quite long, that's why I was thinking about an interim solution that would minimize the chances for HW upgrades required... > A better way to deal with this is use some kind of magic cookie in each > packet that can be precomputed and easily checked. For instance, each > segment includes an MD5 over the previous segment and a secret key. > Since the MD5 operation needs to be done only after processing a valid > segment rather than after each segment, an attacker can't trigger > unnecessary MD5 operations, just some 16 byte compare operations. These > are somewhat less costly to implement in a linecard than even the > fastest crypto... Hmmm... not sure if I understand this correctly... Do you mean that the control plane would calculate the needed signature for the next expected packet and inform the line cards about it, so the line card can do a quick != check for the next packet? If this is what you mean, this won't solve a problem. We need to remember that valid packets should not be punished. This means that the line card should have the signature for the next packet ready right after it has checked the previous one. Which means that a) signature calculation still has to happen at line rate, and b) you can't allow the delays of sending packets to the control plane and waiting for the signature to come back. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 16:40:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15479 for ; Fri, 14 Mar 2003 16:40:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ELtMu12932 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 16:55:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELtMO12929 for ; Fri, 14 Mar 2003 16:55:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15442 for ; Fri, 14 Mar 2003 16:39:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELsTO12812; Fri, 14 Mar 2003 16:54:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ELrvO12766 for ; Fri, 14 Mar 2003 16:53:57 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15395 for ; Fri, 14 Mar 2003 16:38:20 -0500 (EST) Received: from yiya-u10.cisco.com (yiya-u10.cisco.com [64.102.48.79]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2ELeShs005394; Fri, 14 Mar 2003 13:40:29 -0800 (PST) Received: from localhost (yiya@localhost) by yiya-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA02492; Fri, 14 Mar 2003 16:40:28 -0500 (EST) X-Authentication-Warning: yiya-u10.cisco.com: yiya owned process doing -bs Date: Fri, 14 Mar 2003 16:40:28 -0500 (EST) From: Yi Yang To: sandy@tislabs.com cc: rpsec@ietf.org Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources In-Reply-To: <200303112234.h2BMYTK26435@raven.gw.tislabs.com> Message-ID: References: <200303112234.h2BMYTK26435@raven.gw.tislabs.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: , Sandy, > (2.a) That doesn't apply to some (many?) protocols. > > For some protocols, there is no sense of an authorized peer. For > OSPF (that is, before the MD5 part got added), OSPF speaks to all > routers on the local link that answer to the AllSPFRouters multicast > address. MANET protocols frequently speak over the broadcast link > (as mentioned earlier in the draft). And so forth. You are right. IMHO, however, this is because in most IGPs, authentication (such as MD5) is used a mechanism of authorization, instead of identication. And current implementations just don't care the identification in most cases. But in the future, we might also want to care about the identification as well. > (2.c) It's misleading, security wise. > > When I saw this in the draft, I got to thinking about what makes a > threat source distinct. A threat source should be considered > separately if it has a capability that gives it extra power, if it can > launch attacks that others cannot, or if there are security > defenses that work against it and not against others. Now an > unauthorized router has the same capabilities and can perform the same > attacks as a masquerader, but it can be eliminated by doing pure > address based filtering of some sort where masqueraders cannot. > > By that criterion, the unauthorized router is a separate threat source > only if one considers pure address based filtering as a "security > defense". > > I don't. In a big way, I don't. To call such an easily circumvented > mechanism a security defense makes me extremely uneasy. > > I was emboldened to speak up about this by reading the IAS security > mechanisms draft draft-iab-secmech-02.txt that came out a few weeks > ago. Bellovin, Kaufman and Schiller list address-based authentication > as an "Insecurity Mechanism", along with plaintext passwords (emphasis > on the "In"). To quote, "Some common security mechanisms are part of > the problem rather than part of the solution." > > I think if we left unauthorized routers as a distinct threat source, > we'd see claims like ".. and our ACME router's address filtering > eliminates unauthorized routers, recognized by the IETF as one of the > biggest threats to routing.." I agree w/ you using a pure address filtering mechanism is insecure. But I don't think it is the only mechanism to seperate masqueraders from the unauthorized. For example, digital signature can be used for identification while MD5 can be used for authorization. Yi _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 16:55:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16127 for ; Fri, 14 Mar 2003 16:55:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EMAqs15181 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 17:10:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMAqO15178 for ; Fri, 14 Mar 2003 17:10:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16107 for ; Fri, 14 Mar 2003 16:55:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMA4O15150; Fri, 14 Mar 2003 17:10:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EM96O15089 for ; Fri, 14 Mar 2003 17:09:06 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16040 for ; Fri, 14 Mar 2003 16:53:28 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id QAA06774; Fri, 14 Mar 2003 16:56:30 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma006716; Fri, 14 Mar 03 16:56:08 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2ELtHH23914; Fri, 14 Mar 2003 16:55:17 -0500 (EST) Date: Fri, 14 Mar 2003 16:55:17 -0500 (EST) Message-Id: <200303142155.h2ELtHH23914@raven.gw.tislabs.com> To: sandy@tislabs.com, yiya@cisco.com Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources Cc: rpsec@ietf.org 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: , >You are right. IMHO, however, this is because in most IGPs, authentication >(such as MD5) is used a mechanism of authorization, instead of >identication. And current implementations just don't care the >identification in most cases. > >But in the future, we might also want to care about the identification as >well. There are two reasons for doing authentication of identities: that you have an authorization policy to enforce, and that you are doing auditing. So if you are doing authorization, then you sure want to be sure that you know that you are communicating with the authentic person. Even if your authorization policy is so broad that it is just "only these people are allowed to send me packets", you still need authentication. If you are doing logging/auditing (see also: accounting), then you sure want to be sure that the entries you are making are correct. So you need authentication there, also. So I don't know what you mean by "its used for authorization but at some point we'd want to do identification" For what reasons would we be doing identification (and why do you consider that different from authorization)? >I agree w/ you using a pure address filtering mechanism is insecure. But I >don't think it is the only mechanism to seperate masqueraders from the >unauthorized. For example, digital signature can be used for >identification while MD5 can be used for authorization. I don't understand this comment at all. Can you explain what you mean by digital signatures being used for identification only (I presume you mean identification but not authorization) while MD5 was used for authorization (I presume you mean not identification)? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 16:58:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16201 for ; Fri, 14 Mar 2003 16:58:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EMDsO15315 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 17:13:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMDsO15312 for ; Fri, 14 Mar 2003 17:13:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16190 for ; Fri, 14 Mar 2003 16:58:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMD1O15274; Fri, 14 Mar 2003 17:13:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMCIO15236 for ; Fri, 14 Mar 2003 17:12:18 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16150 for ; Fri, 14 Mar 2003 16:56:40 -0500 (EST) Received: from yiya-u10.cisco.com (yiya-u10.cisco.com [64.102.48.79]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2ELwe0E025820; Fri, 14 Mar 2003 13:58:40 -0800 (PST) Received: from localhost (yiya@localhost) by yiya-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA02497; Fri, 14 Mar 2003 16:58:39 -0500 (EST) X-Authentication-Warning: yiya-u10.cisco.com: yiya owned process doing -bs Date: Fri, 14 Mar 2003 16:58:39 -0500 (EST) From: Yi Yang To: sandy@tislabs.com cc: rpsec@ietf.org, , , Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? In-Reply-To: <200303112236.h2BMaPA26482@raven.gw.tislabs.com> Message-ID: References: <200303112236.h2BMaPA26482@raven.gw.tislabs.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: , Sandy, > Yes, of course hiding an address would be a concern to the customer. > But that's a financial dispute between the customer and the ISP, not a > routing attack. Just like providing insufficient bandwidth is a > customer concern that is a financial dispute, not a routing attack. One example in my mind is, an underclaiming by misconfiguration, which doesn't have to happen on the provider side. Customer is running BGP to its provider and makes some mis-configuration on the customer side so no one prefix is advertised to the provider. Isn't this mis-configuration a threat launched by a subverted router?:-) Yi _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 17:05:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16481 for ; Fri, 14 Mar 2003 17:05:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EMKuK15618 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 17:20:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMKuO15615 for ; Fri, 14 Mar 2003 17:20:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16464 for ; Fri, 14 Mar 2003 17:05:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMK3O15576; Fri, 14 Mar 2003 17:20:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMJPO15513 for ; Fri, 14 Mar 2003 17:19:25 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16411 for ; Fri, 14 Mar 2003 17:03:47 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id RAA07383; Fri, 14 Mar 2003 17:06:49 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma007281; Fri, 14 Mar 03 17:05:44 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2EM4rD25044; Fri, 14 Mar 2003 17:04:53 -0500 (EST) Date: Fri, 14 Mar 2003 17:04:53 -0500 (EST) Message-Id: <200303142204.h2EM4rD25044@raven.gw.tislabs.com> To: iljitsch@muada.com, ji@research.att.com Subject: Re: Re: [RPSEC] DDoS of routing ? Cc: rpsec@ietf.org, saq66@umkc.edu, zinin@psg.com 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: , >A better way to deal with this is use some kind of magic cookie in each >packet that can be precomputed and easily checked. For instance, each >segment includes an MD5 over the previous segment and a secret key. >Since the MD5 operation needs to be done only after processing a valid >segment rather than after each segment, an attacker can't trigger >unnecessary MD5 operations, just some 16 byte compare operations. These >are somewhat less costly to implement in a linecard than even the >fastest crypto... Could you explain what you mean some more? First, an MD5 over data+shared secret *is* a crypto operation. (Not the best, most people recommend the HMAC-MD5 over data+sharedsecret, but hey) When you say "segment" are you talking TCP segment? You imply that this is a win because the bad guy would have a hard time coming up with valid segments. Is that the advantage? If so, why do you think that's hard? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 17:11:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16618 for ; Fri, 14 Mar 2003 17:11:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EMQt615894 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 17:26:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMQtO15891 for ; Fri, 14 Mar 2003 17:26:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16612 for ; Fri, 14 Mar 2003 17:11:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMQ4O15813; Fri, 14 Mar 2003 17:26:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMPZO15787 for ; Fri, 14 Mar 2003 17:25:35 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16564 for ; Fri, 14 Mar 2003 17:09:57 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id RAA07703; Fri, 14 Mar 2003 17:12:59 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma007653; Fri, 14 Mar 03 17:12:45 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2EMBpL25904; Fri, 14 Mar 2003 17:11:51 -0500 (EST) Date: Fri, 14 Mar 2003 17:11:51 -0500 (EST) Message-Id: <200303142211.h2EMBpL25904@raven.gw.tislabs.com> To: sandy@tislabs.com, yiya@cisco.com Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? Cc: curtis@fictitious.org, gih@telstra.net, rpsec@ietf.org, shares@nexthop.com 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: , >One example in my mind is, an underclaiming by misconfiguration, which >doesn't have to happen on the provider side. Customer is running BGP to >its provider and makes some mis-configuration on the customer side so no >one prefix is advertised to the provider. Isn't this mis-configuration a >threat launched by a subverted router?:-) I don't think of the customer's failure to announce his own address as a threat. It certainly doesn't hurt anyone but the customer. And I regard anything that a router says about its own state, the data that it is exclusively knowledgeable about, as its own exclusive authority. So whatever it says is authentic. Suppose a BGP peer is mis-configured and doesn't accept connections from its legitimate peer? I don't consider that an attack. A failure, sure, but not an attack. And to reiterate: can you imagine that the routing protocol would have any chance in the world of distinguishing a legitimate case of hiding from an illegitimate case? In your example, is there any way the routing protocol at the customer could protect itself from that mis-configuration? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 17:20:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16713 for ; Fri, 14 Mar 2003 17:20:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EMZwm16273 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 17:35:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMZwO16270 for ; Fri, 14 Mar 2003 17:35:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16706 for ; Fri, 14 Mar 2003 17:20:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMZ9O16201; Fri, 14 Mar 2003 17:35:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMYiO16165 for ; Fri, 14 Mar 2003 17:34:44 -0500 Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16683 for ; Fri, 14 Mar 2003 17:19:04 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h2EML1M00647; Fri, 14 Mar 2003 17:21:02 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Fri, 14 Mar 2003 17:21:01 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: "Ayyasamy, Senthilkumar (UMKC-Student)" cc: Dijiang Huang , Iljitsch van Beijnum , Subject: RE: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02D02C@KC-MAIL4.kc.umkc.edu> 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-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 Thu, 13 Mar 2003, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > Tony, > > > I had a similar thought about the "deliberate exposure" idea. > > Is it not the job of the routing protocol to expose information? > > > > What do others think? > > It was documented in 1995 and so, we have registeries. Again, let's not focus on just the operation of "the Internet", which is what this paragraph and RFC discuss, but also the function of the protocols on which it is based (be they used on private networks or whatever). Routing Registries aren't part of BGP in any formal sense. They are an operational contrivance which can be used in a given BGP deployment. Or not. Tony > RFC 1787. > > "7. Routing Information Sharing > > While ensuring Internet-wide coordination may be more and more > difficult, as the Internet continues to grow, stability and > consistency of the Internet-wide routing could significantly > benefit if the information about routing requirements of various > organizations could be shared across organizational boundaries. > Such information could be used in a wide variety of situations > ranging from troubleshooting to detecting and eliminating > conflicting routing requirements. The scale of the Internet > implies that the information should be distributed. " > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 17:32:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16999 for ; Fri, 14 Mar 2003 17:32:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EMlpC17452 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 17:47:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMlpO17449 for ; Fri, 14 Mar 2003 17:47:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16983 for ; Fri, 14 Mar 2003 17:32:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMl3O17407; Fri, 14 Mar 2003 17:47:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EMkXO17387 for ; Fri, 14 Mar 2003 17:46:33 -0500 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16950 for ; Fri, 14 Mar 2003 17:30:55 -0500 (EST) Received: from yiya-u10.cisco.com (yiya-u10.cisco.com [64.102.48.79]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2EMX4EY003580; Fri, 14 Mar 2003 14:33:04 -0800 (PST) Received: from localhost (yiya@localhost) by yiya-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA02508; Fri, 14 Mar 2003 17:33:04 -0500 (EST) X-Authentication-Warning: yiya-u10.cisco.com: yiya owned process doing -bs Date: Fri, 14 Mar 2003 17:33:03 -0500 (EST) From: Yi Yang To: sandy@tislabs.com cc: rpsec@ietf.org Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources In-Reply-To: <200303142155.h2ELtHH23914@raven.gw.tislabs.com> Message-ID: References: <200303142155.h2ELtHH23914@raven.gw.tislabs.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: , Sandy, > So I don't know what you mean by "its used for authorization but at some > point we'd want to do identification" For what reasons would we be doing > identification (and why do you consider that different from authorization)? Let's say we want to do some policy routing based on identity. So when a router receives an routing message, the router needs to: 1 know and verify the originator of the message; and 2 verify the originator has been authorized to send this type of message The first step can be done w/ digital signature and the second step can be done w/ checking a policy database. But the query/response process might be slow. Or, the administrator can just assign a MD5 password to the originator to authenticate its packets. When the receiver verified the digest, it believes that the originator has been authorized. A similar example in the real world is the badges are being used. The pictures on the badge are used for identification and the shape/color/barcode decide the authorization. Permitted or not to enter a lab is the policy routing. Yi _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 18:36:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19602 for ; Fri, 14 Mar 2003 18:36:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ENpEc20834 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 18:51:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ENpEO20831 for ; Fri, 14 Mar 2003 18:51:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19559 for ; Fri, 14 Mar 2003 18:35:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ENoDO20791; Fri, 14 Mar 2003 18:50:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ENnlO20765 for ; Fri, 14 Mar 2003 18:49:47 -0500 Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19541 for ; Fri, 14 Mar 2003 18:34:06 -0500 (EST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2ENZKR78493; Sat, 15 Mar 2003 00:35:20 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 15 Mar 2003 00:35:20 +0100 (CET) From: Iljitsch van Beijnum To: Alex Zinin cc: Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: <70274714638.20030314122610@psg.com> Message-ID: <20030315000631.P69506-100000@sequoia.muada.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 Fri, 14 Mar 2003, Alex Zinin wrote: > BTW, a little unrelated, but still within the topic: from the router > DoS protection point of view, a big difference between ICMP plus > traceroute's UDP packets and others (routing, ssh, etc.) is that rate > limiting the combined (trusted + untrusted) ICMP stream is fine > because even if we loose some valid ICMP packets when an attack is > going on, we do not loose the network or ability to control it. True. > > When fighting DoS, crypto is NOT your friend. In nearly all cases, it > > just makes the problem worse. > Not sure what you mean here. If it is able to parse data at line rate, > why would it make the problem worse? Ok, if the crypto can be done at line rate then there is no problem. However, my assertion is that doing crypto line rate at the highest available line rates is always going to be so expensive that won't be supported widely. > > I haven't heard of any vendor who includes > > line rate MD5 processing on the linecard (good luck doing this at 10 > > Gbps anyway...) _just_ to protect ebgp-multihop BGP sessions. > I think a quick google search would reveal some developments in this > field, even for gige speeds, don't remember about 10G, and no idea > about how expensive this is. Even if this could be done in the future without significant additional expense, it still means a fork lift upgrade for *everything* that's deployed right now. We can't simply assume line rate crypto because it makes our life easier. > What would really be needed is a chip > that would be able to identify packets that need to be checked (such > as BGP's TCP sessions, IPSec SAs, etc) and do the required > authentication checks, all at line rate. > I actually think that vendors should go in this direction. I think this is indeed a very useful capability (I'm working on a draft for proxy AH verification in service provider networks to protect end-user networks from DoS that needs exactly this) but I don't see it happening for each and every linecard in each and every router in each and every network any time soon. > On the other hand, the time required to upgrade sufficient number of > routers to substantially increase security of the Internet routing > infrastructure can be quite long, that's why I was thinking about > an interim solution that would minimize the chances for HW upgrades > required... Ok then. > Hmmm... not sure if I understand this correctly... Do you mean that > the control plane would calculate the needed signature for the next > expected packet and inform the line cards about it, so the line card > can do a quick != check for the next packet? Yes, more or less. (Obviously this wouldn't be the _signature_ for the next packet but just an opaque value that can be predicted by the other end but not by an attacker. You'd still need a signature against MitM.) > If this is what you mean, this won't solve a problem. We need to > remember that valid packets should not be punished. This means that > the line card should have the signature for the next packet ready > right after it has checked the previous one. Which means that a) > signature calculation still has to happen at line rate, and b) you > can't allow the delays of sending packets to the control plane > and waiting for the signature to come back. A problem that occurred to me after writing this that I'm more concerned with it the state that may be needed. If the line card can't be set up to receive the next packet at line rate: too bad, send them slower. We're talking about control traffic here, this doesn't have to be line rate. Iljitsch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 18:59:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20194 for ; Fri, 14 Mar 2003 18:59:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F0Evc22398 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 19:14:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0EvO22395 for ; Fri, 14 Mar 2003 19:14:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20175 for ; Fri, 14 Mar 2003 18:59:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0E9O22348; Fri, 14 Mar 2003 19:14:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0DHO22270 for ; Fri, 14 Mar 2003 19:13:17 -0500 Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20141 for ; Fri, 14 Mar 2003 18:57:38 -0500 (EST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2F007C78535; Sat, 15 Mar 2003 01:00:08 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 15 Mar 2003 01:00:07 +0100 (CET) From: Iljitsch van Beijnum To: cc: Subject: Re: Re: [RPSEC] DDoS of routing ? In-Reply-To: <200303142204.h2EM4rD25044@raven.gw.tislabs.com> Message-ID: <20030315003529.X69506-100000@sequoia.muada.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 Fri, 14 Mar 2003 sandy@tislabs.com wrote: > >A better way to deal with this is use some kind of magic cookie in each > >packet that can be precomputed and easily checked. For instance, each > >segment includes an MD5 over the previous segment and a secret key. > >Since the MD5 operation needs to be done only after processing a valid > >segment rather than after each segment, an attacker can't trigger > >unnecessary MD5 operations, just some 16 byte compare operations. > Could you explain what you mean some more? > First, an MD5 over data+shared secret *is* a crypto operation. I know. > (Not the best, most people recommend the HMAC-MD5 over data+sharedsecret, but hey) Of course, but let's leave some details for an actual draft. :-) > When you say "segment" are you talking TCP segment? Yes. If the magic cookie for packet n is created by doing an HMAC over packet n - 1 then we have to be sure we don't miss any packets. This is possible with TCP, I don't see how with IP. Of course there can also be other ways to set up the magic cookie: derive it from the time, simply communicate it to the other side, stuff like that. > You imply that this is a win because the bad guy would have a hard > time coming up with valid segments. Is that the advantage? If so, > why do you think that's hard? I'm not sure what you mean here by "valid segments". I'm not suggesting we should forget about regular authentication (IPsec or BGP TCP MD5 hack). (But maybe further study will show we can. Probably not, though.) So we know which segments are valid and which aren't the same way we do now. The advantage is that if we receive 1 valid packet and 999 DoS packets per second, doing regular IPsec/RFC2385 needs 1000 crypto operations per second. My suggestion would need 2: one for the regular IPsec/RFC2385 for the valid packet and then another to generate the cookie for the next packet. The 999 DoS packets don't have the right cookie so they can be discarded without having to do any crypto. Iljitsch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 19:01:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20268 for ; Fri, 14 Mar 2003 19:01:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F0Gnl22487 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 19:16:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0GmO22484 for ; Fri, 14 Mar 2003 19:16:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20255 for ; Fri, 14 Mar 2003 19:01:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0G1O22452; Fri, 14 Mar 2003 19:16:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F0F6O22419 for ; Fri, 14 Mar 2003 19:15:06 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20179 for ; Fri, 14 Mar 2003 18:59:26 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18tz7G-000Jd2-00; Fri, 14 Mar 2003 16:01:34 -0800 Date: Fri, 14 Mar 2003 16:01:07 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <122287611183.20030314160107@psg.com> To: Iljitsch van Beijnum CC: rpsec@ietf.org Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: <20030315000631.P69506-100000@sequoia.muada.com> References: <20030315000631.P69506-100000@sequoia.muada.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Iljitsch, >> Not sure what you mean here. If it is able to parse data at line rate, >> why would it make the problem worse? > Ok, if the crypto can be done at line rate then there is no problem. > However, my assertion is that doing crypto line rate at the highest > available line rates is always going to be so expensive that won't be > supported widely. Hmmm... Yes, good point. I suspect that the router vendors would then need to always own crypto HW they put on the LCs so they can scale it together with throughput. >> > I haven't heard of any vendor who includes >> > line rate MD5 processing on the linecard (good luck doing this at 10 >> > Gbps anyway...) _just_ to protect ebgp-multihop BGP sessions. >> I think a quick google search would reveal some developments in this >> field, even for gige speeds, don't remember about 10G, and no idea >> about how expensive this is. > Even if this could be done in the future without significant additional > expense, it still means a fork lift upgrade for *everything* that's > deployed right now. We can't simply assume line rate crypto because it > makes our life easier. I think we agree here. >> Hmmm... not sure if I understand this correctly... Do you mean that >> the control plane would calculate the needed signature for the next >> expected packet and inform the line cards about it, so the line card >> can do a quick != check for the next packet? > Yes, more or less. (Obviously this wouldn't be the _signature_ for the > next packet but just an opaque value that can be predicted by the other > end but not by an attacker. You'd still need a signature against MitM.) Right. It is not the signature _of_ the n+1'st packet, but of the n'th packet _for_ n+1'st. What about the very 1st packet in the connection, btw? And, of course, Man-in-the-Middle attacks would still be open, as you mention... I think we should avoid this... >> If this is what you mean, this won't solve a problem. We need to >> remember that valid packets should not be punished. This means that >> the line card should have the signature for the next packet ready >> right after it has checked the previous one. Which means that a) >> signature calculation still has to happen at line rate, and b) you >> can't allow the delays of sending packets to the control plane >> and waiting for the signature to come back. > A problem that occurred to me after writing this that I'm more concerned > with it the state that may be needed. Seems that the amount of state would be approx the same as if you did actual MD5. And, btw, you still need to do flow identification to know which value to check the packet against. > If the line card can't be set up > to receive the next packet at line rate: too bad, send them slower. > We're talking about control traffic here, this doesn't have to be line > rate. I am not sure I would be that optimistic about this. This may really affect TCP performance--I expect slow restart would be kicking in continuously, and this will affect BGP convergence... Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 20:26:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22120 for ; Fri, 14 Mar 2003 20:26:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F1g6M27753 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 20:42:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1g6O27750 for ; Fri, 14 Mar 2003 20:42:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22117 for ; Fri, 14 Mar 2003 20:26:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1fHO27717; Fri, 14 Mar 2003 20:41:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F1epO27696 for ; Fri, 14 Mar 2003 20:40:51 -0500 Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22079 for ; Fri, 14 Mar 2003 20:25:10 -0500 (EST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2F1QOg78671; Sat, 15 Mar 2003 02:26:24 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 15 Mar 2003 02:26:24 +0100 (CET) From: Iljitsch van Beijnum To: Alex Zinin cc: Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: <122287611183.20030314160107@psg.com> Message-ID: <20030315014920.F69506-100000@sequoia.muada.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 Fri, 14 Mar 2003, Alex Zinin wrote: > Right. It is not the signature _of_ the n+1'st packet, but of the n'th > packet _for_ n+1'st. > What about the very 1st packet in the connection, btw? Both ends must negotiate a session key anyway, so an initial value for the first cookie shouldn't be much of an (extra) problem. However, if the DoS is already in effect at this point, this negotiation will be hard to complete. Or maybe preshared with a fixed seed for the initial key would be the way to go. > And, of course, Man-in-the-Middle attacks would still be open, as > you mention... I think we should avoid this... Regular authentication that's still in place should take care of this. > > A problem that occurred to me after writing this that I'm more concerned > > with it the state that may be needed. > Seems that the amount of state would be approx the same as if you did > actual MD5. Good point. However, this probably means the number of sessions that can be protected in this manner will always be fairly limited. > > If the line card can't be set up > > to receive the next packet at line rate: too bad, send them slower. > > We're talking about control traffic here, this doesn't have to be line > > rate. > I am not sure I would be that optimistic about this. This may really > affect TCP performance--I expect slow restart would be kicking in > continuously, and this will affect BGP convergence... Hm, maybe doing this based on the last packet isn't the best way. Ok, how about this: we use a stream cipher to come up with a random-looking data stream on both ends and use the IPsec anti-replay counter as a pointer to the part of the data stream that is used as a magic cookie in the current packet. We can then program the line card with enough data to be able to check a certain number of packets per session without having to wait for the CPU to come up with more cookie data. This also removes the TCP limitation, it could now be a generic IP level mechanism. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 21:20:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23094 for ; Fri, 14 Mar 2003 21:20:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F2a6i29985 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 21:36:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F2a5O29982 for ; Fri, 14 Mar 2003 21:36:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23048 for ; Fri, 14 Mar 2003 21:20:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F2ZGO29951; Fri, 14 Mar 2003 21:35:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F2YhO29919 for ; Fri, 14 Mar 2003 21:34:43 -0500 Received: from sj-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23031 for ; Fri, 14 Mar 2003 21:19:00 -0500 (EST) Received: from yiya-u10.cisco.com (yiya-u10.cisco.com [64.102.48.79]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2F2L10E014102; Fri, 14 Mar 2003 18:21:01 -0800 (PST) Received: from localhost (yiya@localhost) by yiya-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id VAA02591; Fri, 14 Mar 2003 21:21:01 -0500 (EST) X-Authentication-Warning: yiya-u10.cisco.com: yiya owned process doing -bs Date: Fri, 14 Mar 2003 21:21:00 -0500 (EST) From: Yi Yang To: sandy@tislabs.com cc: curtis@fictitious.org, , , Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? In-Reply-To: <200303142211.h2EMBpL25904@raven.gw.tislabs.com> Message-ID: References: <200303142211.h2EMBpL25904@raven.gw.tislabs.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: , Sandy, > I don't think of the customer's failure to announce his own address as > a threat. It certainly doesn't hurt anyone but the customer. And I regard > anything that a router says about its own state, the data that it is > exclusively knowledgeable about, as its own exclusive authority. So > whatever it says is authentic. Based on this, the overclaiming should not be a threat either. > Suppose a BGP peer is mis-configured and doesn't accept connections from > its legitimate peer? I don't consider that an attack. A failure, sure, > but not an attack. > > And to reiterate: can you imagine that the routing protocol would have > any chance in the world of distinguishing a legitimate case of hiding > from an illegitimate case? In your example, is there any way the > routing protocol at the customer could protect itself from that > mis-configuration? You are right that we can't find a way to protect against this. But can we say a threat doesn't exist because we can't find a defense? Yi _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Mar 14 23:35:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28383 for ; Fri, 14 Mar 2003 23:35:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2F4pCg04727 for rpsec-archive@odin.ietf.org; Fri, 14 Mar 2003 23:51:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F4pCO04724 for ; Fri, 14 Mar 2003 23:51:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28367 for ; Fri, 14 Mar 2003 23:35:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F4oLO04662; Fri, 14 Mar 2003 23:50:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2F3s1O01600 for ; Fri, 14 Mar 2003 22:54:01 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27224 for ; Fri, 14 Mar 2003 22:38:15 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA03683; Fri, 14 Mar 2003 22:39:01 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303150339.WAA03683@workhorse.fictitious.org> To: Yi Yang cc: sandy@tislabs.com, curtis@fictitious.org, gih@telstra.net, rpsec@ietf.org, shares@nexthop.com Reply-To: curtis@fictitious.org Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? In-reply-to: Your message of "Fri, 14 Mar 2003 21:21:00 EST." Date: Fri, 14 Mar 2003 22:39:00 -0500 From: Curtis Villamizar 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: , In message , Yi Yan g writes: > Sandy, > > > I don't think of the customer's failure to announce his own address as > > a threat. It certainly doesn't hurt anyone but the customer. And I regard > > anything that a router says about its own state, the data that it is > > exclusively knowledgeable about, as its own exclusive authority. So > > whatever it says is authentic. > > Based on this, the overclaiming should not be a threat either. Not admiting you can reach a destination only affects your own service. It is an error and if there is an alternate path, at worst suboptimal routing occurs. It is not possible to add to the protocols to determine if a site has a misconfiguration, or software error or legitimately can't reach the destination at the moment. By claiming that you can reach a network that you cannot reach and have no authority to be advertising can be used as a DoS attack to divert traffic and black hole it. It is also something that can be verified. If you had any knowledge at all of operational issues you'd know that this has been used as a DoS attack and it has been an issue discussed for over a decade and considerable work has gone into defenses mostly based on cooperative maintenance of routing registries or other out-of-band means of verification. > > Suppose a BGP peer is mis-configured and doesn't accept connections from > > its legitimate peer? I don't consider that an attack. A failure, sure, > > but not an attack. > > > > And to reiterate: can you imagine that the routing protocol would have > > any chance in the world of distinguishing a legitimate case of hiding > > from an illegitimate case? In your example, is there any way the > > routing protocol at the customer could protect itself from that > > mis-configuration? > > You are right that we can't find a way to protect against this. But can we > say a threat doesn't exist because we can't find a defense? There is over a decade of operational experience and where the issues of advertising routes that one has no connectivity to has arisen, been partially or quite completely addressed by some parties, and widely discussed. Identifying routers who are failing to advertise something which is reachable is widely considered an intractable problems for very obvious reasons and while you might find a sematic argument about it ammusing, such an argument is non-productive. Perhaps you should abandon this nonsensical argument and try to contribute some productive comments on this issue. > Yi Have a nice day, Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Sat Mar 15 08:21:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15648 for ; Sat, 15 Mar 2003 08:21:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FDaQK07536 for rpsec-archive@odin.ietf.org; Sat, 15 Mar 2003 08:36:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FDaPO07533 for ; Sat, 15 Mar 2003 08:36:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15643 for ; Sat, 15 Mar 2003 08:20:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FDYVO07464; Sat, 15 Mar 2003 08:34:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FDXFO07392 for ; Sat, 15 Mar 2003 08:33:15 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15572 for ; Sat, 15 Mar 2003 08:17:20 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2FDJSvD019798; Sat, 15 Mar 2003 08:19:29 -0500 (EST) Received: from russpc (rtp-vpn2-406.cisco.com [10.82.241.150]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA10276; Sat, 15 Mar 2003 08:19:28 -0500 (EST) Date: Sat, 15 Mar 2003 08:18:57 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: sandy@tislabs.com cc: rpsec@ietf.org Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources In-Reply-To: <200303112234.h2BMYTK26435@raven.gw.tislabs.com> Message-ID: References: <200303112234.h2BMYTK26435@raven.gw.tislabs.com> X-X-Sender: ruwhite@uzura.cisco.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: , > I'd like to see some changes in this categorization. > > (1) The use of the term "compromised" is defined to mean faulty or > misconfigured routers. In the first place, this leaves out subverted > routers, which is a big concern. Secondly, to most people, the term > "compromised" means "subverted", not faulty. So the text uses a term > with a typical meaning to mean everything except the typical meaning. > Were subverted routers left out on purpose? I think we talked about this before, but I still think we should probably seperate the idea of a compromised router and a faulty router, even if the impact is the same. It's just confusing to the reader. > (2) The outsiders are divided into "unauthorized devices" and > "masquerading devices". Yes, I can see the tautology here--if you're not expecting authorization, then there's no such thing as an unauthorized device. If there is authorization, there's no way in but to masquerade. I'd probably agree with taking these out, at first glance. > (3) Compromised links terminology > > [Nitpick: links never do things - it is the hosts that are > compromising the links who do things. This terminology leads to > sentences like "Compromised links can sniff the links over which they > have control."] Agreed, this should be cleaned up. > As stated in the text, these threat sources are acting "without > participating in the routing exchange". So these threats are attacking > the transport subsystem, as mentioned in Section 2. Can we say that > routing protocol designers should do anything about these threat sources? I think we can mention these attacks, since the RP designers should/could look at thes transport they are using, and try to help the designers of those transports build better security into them. It's also helpful to analyse these to make certain there's nothing you can do in your protocol design to try and make these sorts of attacks harder in any way. But we certainly can't lay any requirements on the rp designer in relation to transport attacks. :-) Russ -- riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Sat Mar 15 08:37:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15951 for ; Sat, 15 Mar 2003 08:37:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FDqq508757 for rpsec-archive@odin.ietf.org; Sat, 15 Mar 2003 08:52:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FDqqO08754 for ; Sat, 15 Mar 2003 08:52:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15937 for ; Sat, 15 Mar 2003 08:36:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FDq4O08732; Sat, 15 Mar 2003 08:52:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FDp3O08698 for ; Sat, 15 Mar 2003 08:51:03 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15915 for ; Sat, 15 Mar 2003 08:35:07 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2FDb9vD020376; Sat, 15 Mar 2003 08:37:10 -0500 (EST) Received: from russpc (rtp-vpn2-406.cisco.com [10.82.241.150]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA10562; Sat, 15 Mar 2003 08:37:08 -0500 (EST) Date: Sat, 15 Mar 2003 08:36:37 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Curtis Villamizar cc: Yi Yang , sandy@tislabs.com, gih@telstra.net, rpsec@ietf.org, shares@nexthop.com Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? In-Reply-To: <200303150339.WAA03683@workhorse.fictitious.org> Message-ID: References: <200303150339.WAA03683@workhorse.fictitious.org> X-X-Sender: ruwhite@uzura.cisco.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: , > > > I don't think of the customer's failure to announce his own address as > > > a threat. It certainly doesn't hurt anyone but the customer. And I regard > > > anything that a router says about its own state, the data that it is > > > exclusively knowledgeable about, as its own exclusive authority. So > > > whatever it says is authentic. > > > > Based on this, the overclaiming should not be a threat either. > > Not admiting you can reach a destination only affects your own service. > It is an error and if there is an alternate path, at worst suboptimal > routing occurs. It is not possible to add to the protocols to determine > if a site has a misconfiguration, or software error or legitimately can't > reach the destination at the moment. Well, I don't know.... I would say that if you have a single path, and someone maliciously breaks into the router and kills that path (the path to your ebusiness site, and your competitor hires a hacker to kill access to your site during your first 24 hours of new product they know will really ruin your business. The only possible defense, however, is to tell the customer not to put themselves in this position; redundancy is your friend. :-) Russ -- riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Sat Mar 15 09:10:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16374 for ; Sat, 15 Mar 2003 09:10:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FEQEj10274 for rpsec-archive@odin.ietf.org; Sat, 15 Mar 2003 09:26:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEQEO10271 for ; Sat, 15 Mar 2003 09:26:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16350 for ; Sat, 15 Mar 2003 09:10:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEPPO10232; Sat, 15 Mar 2003 09:25:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FEOWO10206 for ; Sat, 15 Mar 2003 09:24:32 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16330 for ; Sat, 15 Mar 2003 09:08:35 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2FEAiSc029951; Sat, 15 Mar 2003 09:10:44 -0500 (EST) Received: from russpc (rtp-vpn2-406.cisco.com [10.82.241.150]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA11143; Sat, 15 Mar 2003 09:10:38 -0500 (EST) Date: Sat, 15 Mar 2003 09:10:08 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Iljitsch van Beijnum cc: Scott Rose , rpsec@ietf.org Subject: Re: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat In-Reply-To: <20030312223931.S69506-100000@sequoia.muada.com> Message-ID: References: <20030312223931.S69506-100000@sequoia.muada.com> X-X-Sender: ruwhite@uzura.cisco.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: , I would say that there's a difference between reachability information and topology information. I might have 1000 subnets, but if I advertise them all as one large aggregate, then block pings and traceroutes, and most other icmp into my network that could be used for mapping it out in any way, I've hidden my topology pretty effectively. And there may be reasons for me to want to do this--for instance, I might not want people to find out what my broadcast addresses are, to prevent various sorts of DOS attacks. Discovering topology information isn't an attack, it's a threat, possibly, a prelude to other possible attacks. At least it seems to me that it might be valuable information that some networks may want to hide for various reasons. :-) Russ On Wed, 12 Mar 2003, Iljitsch van Beijnum wrote: > On Wed, 12 Mar 2003, Scott Rose wrote: > > > One questions that needs to be asked is whether the network map or "global > > routing table" (if there could be said to be one) is to be considered public > > knowledge or not. > > Obviously that's not the real question (try "telnet > route-views.oregon-ix.net" if you disagree). If there even is a question > here, it would "is it possible to for the global routing table to not be > public knowledge". Every multiconnected non-stub AS needs path > information for loop protection. The number of people running these > networks is too large (and also spread out over the entire world) so > having them keep it a secret won't really work. Also, the operators are > probably not going to like anything like this as it makes > troubleshooting hell. And of course there's always tracroute. > > I think if certain organizations want to keep their topology secret they > should probably hide behind some big fat layer 4 (or higher) firewalls. > Just filtering or NAT isn't enough because the other side still gets to > see the TTL and RTTs which are enough for rudimentary network mapping. > > _______________________________________________ > 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 mailnull@www1.ietf.org Sat Mar 15 10:57:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19716 for ; Sat, 15 Mar 2003 10:57:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FGCx416327 for rpsec-archive@odin.ietf.org; Sat, 15 Mar 2003 11:12:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FGCxO16324 for ; Sat, 15 Mar 2003 11:12:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19695 for ; Sat, 15 Mar 2003 10:57:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FGCBO16294; Sat, 15 Mar 2003 11:12:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FGBNO16272 for ; Sat, 15 Mar 2003 11:11:23 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19658 for ; Sat, 15 Mar 2003 10:55:23 -0500 (EST) Received: from sarah ([65.27.11.57] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Sat, 15 Mar 2003 09:57:35 -0600 Reply-To: From: "Dijiang Huang" To: "Russ White" , Cc: Subject: RE: [RPSEC] Topic 1: Section 3.1 Threat Sources Date: Sat, 15 Mar 2003 09:56:38 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 15 Mar 2003 15:57:35.0101 (UTC) FILETIME=[983BAAD0:01C2EB0B] 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Russ, > > > (2) The outsiders are divided into "unauthorized devices" and > > "masquerading devices". > > Yes, I can see the tautology here--if you're not expecting authorization, > then there's no such thing as an unauthorized device. If there is > authorization, there's no way in but to masquerade. I'd probably > agree with > taking these out, at first glance. > I think the terms "authorized" and "unauthorized" are a little bit confuse. For example, in ospf, suppose if a router is an eligible routing exchanger, when it modifies or forges other routers' routing information, is it masquerading or not? It is authorized to send and receive routing information, but it is not authorized to changed others routing information. I think the authorized region should be clarified. But, somehow, this will make is complicate. Cause different protocols have different behaviors, such as link state and distance vector. --Dijiang _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Sat Mar 15 11:58:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20541 for ; Sat, 15 Mar 2003 11:58:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FHE3u20097 for rpsec-archive@odin.ietf.org; Sat, 15 Mar 2003 12:14:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FHE3O20094 for ; Sat, 15 Mar 2003 12:14:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20528 for ; Sat, 15 Mar 2003 11:58:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FHDCO20029; Sat, 15 Mar 2003 12:13:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FH7LO19537 for ; Sat, 15 Mar 2003 12:07:21 -0500 Received: from workhorse.fictitious.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20334 for ; Sat, 15 Mar 2003 11:51:19 -0500 (EST) Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA07707; Sat, 15 Mar 2003 11:52:03 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200303151652.LAA07707@workhorse.fictitious.org> To: Russ White cc: Curtis Villamizar , Yi Yang , sandy@tislabs.com, gih@telstra.net, rpsec@ietf.org, shares@nexthop.com Reply-To: curtis@fictitious.org Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? In-reply-to: Your message of "Sat, 15 Mar 2003 08:36:37 EST." Date: Sat, 15 Mar 2003 11:52:03 -0500 From: Curtis Villamizar 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: , In message , Russ White writes: > > > > > I don't think of the customer's failure to announce his own address as > > > > a threat. It certainly doesn't hurt anyone but the customer. And I re > gard > > > > anything that a router says about its own state, the data that it is > > > > exclusively knowledgeable about, as its own exclusive authority. So > > > > whatever it says is authentic. > > > > > > Based on this, the overclaiming should not be a threat either. > > > > Not admiting you can reach a destination only affects your own service. > > It is an error and if there is an alternate path, at worst suboptimal > > routing occurs. It is not possible to add to the protocols to determine > > if a site has a misconfiguration, or software error or legitimately can't > > reach the destination at the moment. > > Well, I don't know.... I would say that if you have a single path, and > someone maliciously breaks into the router and kills that path (the path to > your ebusiness site, and your competitor hires a hacker to kill access to > your site during your first 24 hours of new product they know will really > ruin your business. > > The only possible defense, however, is to tell the customer not to put > themselves in this position; redundancy is your friend. > > :-) > > Russ This is an attack on an individual network element. There is nothing the protocols can do to prevent this. Redundancy is a partial solution because if an implementation is full of security holes the attacker can just take out network elements at will. If someone breaks into *my* router because I was careless and configured it poorly, protocols can be design to prevent that breach from taking out *your* service. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Sun Mar 16 22:19:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17336 for ; Sun, 16 Mar 2003 22:19:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H3Zft14870 for rpsec-archive@odin.ietf.org; Sun, 16 Mar 2003 22:35:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H3ZfO14867 for ; Sun, 16 Mar 2003 22:35:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17309 for ; Sun, 16 Mar 2003 22:18:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H3YTO14811; Sun, 16 Mar 2003 22:34:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H2upO12731 for ; Sun, 16 Mar 2003 21:56:51 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16644 for ; Sun, 16 Mar 2003 21:40:10 -0500 (EST) Received: from nj0117exch001p.wins.lucent.com (h135-5-177-157.lucent.com [135.5.177.157]) by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2H2gKB14132 for ; Sun, 16 Mar 2003 21:42:21 -0500 (EST) Received: by nj0117exch001p.wh.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 16 Mar 2003 21:42:17 -0500 Message-ID: From: "Reddington, Thomas B (Tom)" To: "'Russ White'" , Iljitsch van Beijnum Cc: Scott Rose , rpsec@ietf.org, "Koller, Daniel P (Dan)" Subject: RE: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat Date: Sun, 16 Mar 2003 21:42:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , > I would say that there's a difference between reachability > information and > topology information. I might have 1000 subnets, but if I > advertise them > all as one large aggregate, then block pings and traceroutes, and most > other icmp into my network that could be used for mapping it > out in any > way, I've hidden my topology pretty effectively. NO. You must block all outgoing ICMP (ttl and probably others if I thought) of all 1000 subnets to be effective. If you do this, what does it do to your management operations and partnerships? Aggregation does nothing for you. I can still devine your internal structure. There are also ways to gerenate network topology from reachability (traceroute) information. > > And there may be reasons for me to want to do this--for > instance, I might > not want people to find out what my broadcast addresses are, > to prevent > various sorts of DOS attacks. > > Discovering topology information isn't an attack, it's a > threat, possibly, > a prelude to other possible attacks. At least it seems to me > that it might > be valuable information that some networks may want to hide > for various > reasons. > This is valuable information that any network would want to hide for security reasons. It is a precursor to an attack whether it be delayed or immediate or covert or overt. > :-) > > Russ > > > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Sun Mar 16 22:56:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18126 for ; Sun, 16 Mar 2003 22:56:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H4Cwt17668 for rpsec-archive@odin.ietf.org; Sun, 16 Mar 2003 23:12:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4CwO17665 for ; Sun, 16 Mar 2003 23:12:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18111 for ; Sun, 16 Mar 2003 22:56:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4C5O17629; Sun, 16 Mar 2003 23:12:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4B3O17577 for ; Sun, 16 Mar 2003 23:11:03 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18053 for ; Sun, 16 Mar 2003 22:54:21 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2H3uQvD004623; Sun, 16 Mar 2003 22:56:27 -0500 (EST) Received: from wl-132-187.wireless.ietf56.ietf.org (sjc-vpn4-1037.cisco.com [10.21.84.12]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA18767; Sun, 16 Mar 2003 22:56:26 -0500 (EST) Date: Sun, 16 Mar 2003 22:56:29 -0500 (EST) From: Russ White X-X-Sender: ruwhite@wl-132-187.wireless.ietf56.ietf.org Reply-To: Russ White To: "Reddington, Thomas B (Tom)" cc: Iljitsch van Beijnum , Scott Rose , rpsec@ietf.org, "Koller, Daniel P (Dan)" Subject: RE: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat In-Reply-To: Message-ID: References: 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: , My point, in general, though, is that it is possible to obsfucate your internal structure, through various means.... This is, as agree, valuable information, so it appears to be a threat, even if the routing protocol can't do anything about the threat. Whether or not it's a specific routing protocol threat is another issue. Anyway, the question originall was: Is it an attack to, through some means, block the advertisment of a given prefix, which then prevents someone from reaching a legitimate destination. It still seems to me that it could be. :-) Russ On Sun, 16 Mar 2003, Reddington, Thomas B (Tom) wrote: > > > I would say that there's a difference between reachability > > information and > > topology information. I might have 1000 subnets, but if I > > advertise them > > all as one large aggregate, then block pings and traceroutes, and most > > other icmp into my network that could be used for mapping it > > out in any > > way, I've hidden my topology pretty effectively. > > NO. You must block all outgoing ICMP (ttl and probably others if I thought) of all 1000 subnets to be effective. If you do this, what does it do to your management operations and partnerships? Aggregation does nothing for you. I can still devine your internal structure. > > There are also ways to gerenate network topology from reachability (traceroute) information. > > > > > And there may be reasons for me to want to do this--for > > instance, I might > > not want people to find out what my broadcast addresses are, > > to prevent > > various sorts of DOS attacks. > > > > Discovering topology information isn't an attack, it's a > > threat, possibly, > > a prelude to other possible attacks. At least it seems to me > > that it might > > be valuable information that some networks may want to hide > > for various > > reasons. > > > This is valuable information that any network would want to hide for security reasons. It is a precursor to an attack whether it be delayed or immediate or covert or overt. > > > :-) > > > > Russ > > > > > > 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 mailnull@www1.ietf.org Mon Mar 17 05:46:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10031 for ; Mon, 17 Mar 2003 05:46:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HB2Pc23059 for rpsec-archive@odin.ietf.org; Mon, 17 Mar 2003 06:02:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HB2PO23056 for ; Mon, 17 Mar 2003 06:02:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10023 for ; Mon, 17 Mar 2003 05:45:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HB1OO23009; Mon, 17 Mar 2003 06:01:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HB06O22958 for ; Mon, 17 Mar 2003 06:00:06 -0500 Received: from lomin.exp-math.uni-essen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10013 for ; Mon, 17 Mar 2003 05:43:14 -0500 (EST) Received: by lomin.exp-math.uni-essen.de (Postfix, from userid 1000) id BCB6E1408; Mon, 17 Mar 2003 11:45:26 +0100 (CET) Date: Mon, 17 Mar 2003 11:45:26 +0100 From: Birger Toedtmann To: rpsec@ietf.org Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? Message-ID: <20030317104526.GA8216@exp-math.uni-essen.de> References: <200303150339.WAA03683@workhorse.fictitious.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303150339.WAA03683@workhorse.fictitious.org> User-Agent: Mutt/1.4i X-Echelon: Cocaine Kill Evil Contract Whitehouse Attack Bomb Money Terror American Hate 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: , Curtis Villamizar schrieb am Fri, Mar 14, 2003 at 10:39:00PM -0500: > > In message , Yi Yan > g writes: > > Sandy, > > > > > I don't think of the customer's failure to announce his own address as > > > a threat. It certainly doesn't hurt anyone but the customer. And I regard > > > anything that a router says about its own state, the data that it is > > > exclusively knowledgeable about, as its own exclusive authority. So > > > whatever it says is authentic. > > > > Based on this, the overclaiming should not be a threat either. > > Not admiting you can reach a destination only affects your own > service. It is an error and if there is an alternate path, at worst > suboptimal routing occurs. It is not possible to add to the protocols > to determine if a site has a misconfiguration, or software error or > legitimately can't reach the destination at the moment. On the other hand, underclaiming may result in adverse effects on the routers of the alternative paths. Guess I want to disrupt the services of some transit net from which I know it won't be able to handle all the traffic for me - underclaiming on the main path might do the trick. I'll be hurting myself as well ('suicide attack' may be the correct name), so this is not very likely to be seen. However it's a threat especially when using networks I "own" but don't use right now. Birger _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Mar 17 09:13:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13854 for ; Mon, 17 Mar 2003 09:13:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HEUOd03481 for rpsec-archive@odin.ietf.org; Mon, 17 Mar 2003 09:30:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HEUOO03478 for ; Mon, 17 Mar 2003 09:30:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13837 for ; Mon, 17 Mar 2003 09:13:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HETXO03411; Mon, 17 Mar 2003 09:29:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HES3O03330 for ; Mon, 17 Mar 2003 09:28:03 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13760 for ; Mon, 17 Mar 2003 09:11:06 -0500 (EST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2HECk64014138; Mon, 17 Mar 2003 09:12:51 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02D02C@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B02D02C@KC-MAIL4.kc.umkc.edu> Date: Sun, 16 Mar 2003 18:37:39 -0500 To: "Ayyasamy, Senthilkumar (UMKC-Student)" From: Stephen Kent Subject: RE: [RPSEC] Topic 9: Section 4.10 Network Mapping Threat Cc: "Tony Tauber" , "Dijiang Huang" , "Iljitsch van Beijnum" , 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 11:41 PM -0600 3/13/03, Ayyasamy, Senthilkumar (UMKC-Student) wrote: >Tony, > >> I had a similar thought about the "deliberate exposure" idea. >> Is it not the job of the routing protocol to expose information? >> >> What do others think? > >It was documented in 1995 and so, we have registeries. > >RFC 1787. > > "7. Routing Information Sharing > > While ensuring Internet-wide coordination may be more and more > difficult, as the Internet continues to grow, stability and > consistency of the Internet-wide routing could significantly benefit > if the information about routing requirements of various > organizations could be shared across organizational boundaries. Such > information could be used in a wide variety of situations ranging > from troubleshooting to detecting and eliminating conflicting routing > requirements. The scale of the Internet implies that the information > should be distributed. " The question is too broad, as stated. Some information must be shared (disclosed) to make routing work. Other information need not be shared. Some of the data that one might place in a routing repository falls into the latter category. That data might justifiably be considered private by an ISP. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Mar 17 10:09:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15680 for ; Mon, 17 Mar 2003 10:09:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HFQ2O07250 for rpsec-archive@odin.ietf.org; Mon, 17 Mar 2003 10:26:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFQ2O07247 for ; Mon, 17 Mar 2003 10:26:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15630 for ; Mon, 17 Mar 2003 10:09:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFNCO07116; Mon, 17 Mar 2003 10:23:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFMKO07086 for ; Mon, 17 Mar 2003 10:22:20 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15185 for ; Mon, 17 Mar 2003 10:05:17 -0500 (EST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2HF6p60017552; Mon, 17 Mar 2003 10:06:52 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20030317104526.GA8216@exp-math.uni-essen.de> References: <200303150339.WAA03683@workhorse.fictitious.org> <20030317104526.GA8216@exp-math.uni-essen.de> Date: Mon, 17 Mar 2003 10:03:57 -0500 To: Birger Toedtmann From: Stephen Kent Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? 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 11:45 AM +0100 3/17/03, Birger Toedtmann wrote: >Curtis Villamizar schrieb am Fri, Mar 14, 2003 at 10:39:00PM -0500: >> >> In message >>, Yi Yan >> g writes: >> > Sandy, >> > >> > > I don't think of the customer's failure to announce his own address as >> > > a threat. It certainly doesn't hurt anyone but the customer. >>And I regard >> > > anything that a router says about its own state, the data that it is >> > > exclusively knowledgeable about, as its own exclusive authority. So >> > > whatever it says is authentic. >> > >> > Based on this, the overclaiming should not be a threat either. >> >> Not admiting you can reach a destination only affects your own >> service. It is an error and if there is an alternate path, at worst >> suboptimal routing occurs. It is not possible to add to the protocols >> to determine if a site has a misconfiguration, or software error or >> legitimately can't reach the destination at the moment. > >On the other hand, underclaiming may result in adverse effects on the >routers of the alternative paths. Guess I want to disrupt the services >of some transit net from which I know it won't be able to handle all >the traffic for me - underclaiming on the main path might do the trick. > >I'll be hurting myself as well ('suicide attack' may be the correct >name), so this is not very likely to be seen. However it's a threat >especially when using networks I "own" but don't use right now. I believe there is no requirement that an ISP advertise all of the address space it holds to all of its neighbors. The decision of what to advertise and to whom is presumably a local ploicy decision. Thus this seems like an inappropriate notion of enforceable correct operation for BGP. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Mar 17 10:25:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17032 for ; Mon, 17 Mar 2003 10:25:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HFg2u08789 for rpsec-archive@odin.ietf.org; Mon, 17 Mar 2003 10:42:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFg2O08785 for ; Mon, 17 Mar 2003 10:42:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17022 for ; Mon, 17 Mar 2003 10:25:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFf9O08725; Mon, 17 Mar 2003 10:41:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFeKO08629 for ; Mon, 17 Mar 2003 10:40:20 -0500 Received: from lomin.exp-math.uni-essen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16897 for ; Mon, 17 Mar 2003 10:23:23 -0500 (EST) Received: by lomin.exp-math.uni-essen.de (Postfix, from userid 1000) id A57181A31; Mon, 17 Mar 2003 16:25:35 +0100 (CET) Date: Mon, 17 Mar 2003 16:25:35 +0100 From: Birger Toedtmann To: Stephen Kent Cc: rpsec@ietf.org Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? Message-ID: <20030317152535.GA9645@exp-math.uni-essen.de> References: <200303150339.WAA03683@workhorse.fictitious.org> <20030317104526.GA8216@exp-math.uni-essen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Echelon: Cocaine Kill Evil Contract Whitehouse Attack Bomb Money Terror American Hate 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: , Stephen Kent schrieb am Mon, Mar 17, 2003 at 10:03:57AM -0500: [...] > > > >On the other hand, underclaiming may result in adverse effects on the > >routers of the alternative paths. Guess I want to disrupt the services > >of some transit net from which I know it won't be able to handle all > >the traffic for me - underclaiming on the main path might do the trick. > > > >I'll be hurting myself as well ('suicide attack' may be the correct > >name), so this is not very likely to be seen. However it's a threat > >especially when using networks I "own" but don't use right now. > > I believe there is no requirement that an ISP advertise all of the > address space it holds to all of its neighbors. The decision of what > to advertise and to whom is presumably a local ploicy decision. Thus > this seems like an inappropriate notion of enforceable correct > operation for BGP. When reading the draft I got the impression that it's about threats, i.e. "things that could be done and cause harm". If underclaiming is such an action in a situation where it is a requirement to advertise address space to avoid overloading (such a situation may be uncommon but existent), I'd refer to it as a valid threat source. Attackers are quite inventive. Regards, Birger _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Mar 17 10:26:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17079 for ; Mon, 17 Mar 2003 10:26:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HFgqg08855 for rpsec-archive@odin.ietf.org; Mon, 17 Mar 2003 10:42:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFgqO08852 for ; Mon, 17 Mar 2003 10:42:52 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17063 for ; Mon, 17 Mar 2003 10:25:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFg1O08774; Mon, 17 Mar 2003 10:42:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFfeO08745 for ; Mon, 17 Mar 2003 10:41:40 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17009 for ; Mon, 17 Mar 2003 10:24:43 -0500 (EST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2HFQS5w018993; Mon, 17 Mar 2003 10:26:28 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: <200303112234.h2BMYTK26435@raven.gw.tislabs.com> Date: Mon, 17 Mar 2003 10:22:31 -0500 To: Yi Yang From: Stephen Kent Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources 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 4:40 PM -0500 3/14/03, Yi Yang wrote: >Sandy, > >> (2.a) That doesn't apply to some (many?) protocols. >> >> For some protocols, there is no sense of an authorized peer. For >> OSPF (that is, before the MD5 part got added), OSPF speaks to all >> routers on the local link that answer to the AllSPFRouters multicast >> address. MANET protocols frequently speak over the broadcast link >> (as mentioned earlier in the draft). And so forth. > >You are right. IMHO, however, this is because in most IGPs, authentication >(such as MD5) is used a mechanism of authorization, instead of >identication. And current implementations just don't care the >identification in most cases. > >But in the future, we might also want to care about the identification as >well. > >> (2.c) It's misleading, security wise. >> >> When I saw this in the draft, I got to thinking about what makes a >> threat source distinct. A threat source should be considered >> separately if it has a capability that gives it extra power, if it can >> launch attacks that others cannot, or if there are security >> defenses that work against it and not against others. Now an >> unauthorized router has the same capabilities and can perform the same >> attacks as a masquerader, but it can be eliminated by doing pure >> address based filtering of some sort where masqueraders cannot. >> >> By that criterion, the unauthorized router is a separate threat source >> only if one considers pure address based filtering as a "security >> defense". >> >> I don't. In a big way, I don't. To call such an easily circumvented >> mechanism a security defense makes me extremely uneasy. >> >> I was emboldened to speak up about this by reading the IAS security >> mechanisms draft draft-iab-secmech-02.txt that came out a few weeks >> ago. Bellovin, Kaufman and Schiller list address-based authentication >> as an "Insecurity Mechanism", along with plaintext passwords (emphasis >> on the "In"). To quote, "Some common security mechanisms are part of >> the problem rather than part of the solution." >> >> I think if we left unauthorized routers as a distinct threat source, >> we'd see claims like ".. and our ACME router's address filtering >> eliminates unauthorized routers, recognized by the IETF as one of the >> biggest threats to routing.." > >I agree w/ you using a pure address filtering mechanism is insecure. But I >don't think it is the only mechanism to seperate masqueraders from the >unauthorized. For example, digital signature can be used for >identification while MD5 can be used for authorization. > >Yi > MD5 is an un-keyed integrity mechanism. Hashed MACs, like HMAC, can be used for authentication to the extent that the key used with them is associated with known entities. The keyed MD5 checksum sometimes used with BGP is a cryptographically poor example of a hashed MAC. In no case should one consider MD5 to be an authorization mechanism. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Mar 17 10:46:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17716 for ; Mon, 17 Mar 2003 10:46:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HG2SH09773 for rpsec-archive@odin.ietf.org; Mon, 17 Mar 2003 11:02:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HG2SO09770 for ; Mon, 17 Mar 2003 11:02:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17709 for ; Mon, 17 Mar 2003 10:45:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFxtO09608; Mon, 17 Mar 2003 10:59:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFpxO09291 for ; Mon, 17 Mar 2003 10:51:59 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17431 for ; Mon, 17 Mar 2003 10:35:02 -0500 (EST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2HFaO5w019660; Mon, 17 Mar 2003 10:36:25 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: <200303142155.h2ELtHH23914@raven.gw.tislabs.com> Date: Mon, 17 Mar 2003 10:28:03 -0500 To: Yi Yang From: Stephen Kent Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources Cc: sandy@tislabs.com, 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:33 PM -0500 3/14/03, Yi Yang wrote: >Sandy, > >> So I don't know what you mean by "its used for authorization but at some >> point we'd want to do identification" For what reasons would we be doing >> identification (and why do you consider that different from authorization)? > >Let's say we want to do some policy routing based on identity. So when a >router receives an routing message, the router needs to: > >1 know and verify the originator of the message; and >2 verify the originator has been authorized to send this type of message > >The first step can be done w/ digital signature and the second step can be >done w/ checking a policy database. But the query/response process might >be slow. this seems to assume checking of some remote database, right? >Or, the administrator can just assign a MD5 password to the originator to >authenticate its packets. When the receiver verified the digest, it >believes that the originator has been authorized. This runs counter to what appear to be unstated assumptions in your previous paragraph. A MAC is not a signature and a major difference is that the holder of a public key can verify but not forge a signature, whereas the holder of a key for a MAC can both verify and generate the MAC. Thus MACs are point-to-point authentication mechanisms, but not multicast authentication mechanisms. In most routing protocols multiple entities must verify an assertion of a router, making MACs inappropriate authentication mechanisms for these contexts. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Mar 17 11:42:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19734 for ; Mon, 17 Mar 2003 11:42:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HGxEQ13988 for rpsec-archive@odin.ietf.org; Mon, 17 Mar 2003 11:59:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGxEO13985 for ; Mon, 17 Mar 2003 11:59:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19713 for ; Mon, 17 Mar 2003 11:42:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGw8O13938; Mon, 17 Mar 2003 11:58:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGvXO13912 for ; Mon, 17 Mar 2003 11:57:34 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19655 for ; Mon, 17 Mar 2003 11:40:35 -0500 (EST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2HGgZ5w024436; Mon, 17 Mar 2003 11:42:36 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20030317152535.GA9645@exp-math.uni-essen.de> References: <200303150339.WAA03683@workhorse.fictitious.org> <20030317104526.GA8216@exp-math.uni-essen.de> <20030317152535.GA9645@exp-math.uni-essen.de> Date: Mon, 17 Mar 2003 11:39:21 -0500 To: Birger Toedtmann From: Stephen Kent Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? 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 4:25 PM +0100 3/17/03, Birger Toedtmann wrote: >Stephen Kent schrieb am Mon, Mar 17, 2003 at 10:03:57AM -0500: >[...] >> > >> >On the other hand, underclaiming may result in adverse effects on the >> >routers of the alternative paths. Guess I want to disrupt the services >> >of some transit net from which I know it won't be able to handle all >> >the traffic for me - underclaiming on the main path might do the trick. >> > >> >I'll be hurting myself as well ('suicide attack' may be the correct >> >name), so this is not very likely to be seen. However it's a threat >> >especially when using networks I "own" but don't use right now. >> >> I believe there is no requirement that an ISP advertise all of the >> address space it holds to all of its neighbors. The decision of what >> to advertise and to whom is presumably a local ploicy decision. Thus >> this seems like an inappropriate notion of enforceable correct >> operation for BGP. > >When reading the draft I got the impression that it's about threats, >i.e. "things that could be done and cause harm". If underclaiming is >such an action in a situation where it is a requirement to advertise >address space to avoid overloading (such a situation may be uncommon >but existent), I'd refer to it as a valid threat source. Attackers >are quite inventive. > > >Regards, > >Birger Briger, Fair point, but as noted before, while a list of attacks has some merit, it is not a substitute for a well-reasoned, top-down requirements list, which is what we eventually need. Essentially, the list of attacks we know of now is useful mostly as a check to make sure that the requirements specification has not missed anything. Also, we have enough trouble dealing with what are arguably violations of correct operation by routing protocols. I think we are ill served by worrying about behavior that might be adverse. We don't want to inherit the problems that intrusion detection systems exhibit, overwhelming operators with largely false positive warnings about "suspicious" behavior. Steve Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Mar 17 13:55:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24901 for ; Mon, 17 Mar 2003 13:55:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HJCPk25757 for rpsec-archive@odin.ietf.org; Mon, 17 Mar 2003 14:12:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HJCOO25754 for ; Mon, 17 Mar 2003 14:12:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24892 for ; Mon, 17 Mar 2003 13:55:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HJBKO25706; Mon, 17 Mar 2003 14:11:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HJAtO25656 for ; Mon, 17 Mar 2003 14:10:55 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24864 for ; Mon, 17 Mar 2003 13:53:52 -0500 (EST) Received: from yiya-u10.cisco.com (yiya-u10.cisco.com [64.102.48.79]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2HItmhs012738; Mon, 17 Mar 2003 10:55:48 -0800 (PST) Received: from localhost (yiya@localhost) by yiya-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA03486; Mon, 17 Mar 2003 13:55:47 -0500 (EST) X-Authentication-Warning: yiya-u10.cisco.com: yiya owned process doing -bs Date: Mon, 17 Mar 2003 13:55:47 -0500 (EST) From: Yi Yang To: Stephen Kent cc: sandy@tislabs.com, Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources In-Reply-To: Message-ID: References: <200303142155.h2ELtHH23914@raven.gw.tislabs.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: , Steve, > >The first step can be done w/ digital signature and the second step can be > >done w/ checking a policy database. But the query/response process might > >be slow. > > this seems to assume checking of some remote database, right? Yes. > >Or, the administrator can just assign a MD5 password to the originator to > >authenticate its packets. When the receiver verified the digest, it > >believes that the originator has been authorized. > > This runs counter to what appear to be unstated assumptions in your > previous paragraph. A MAC is not a signature and a major difference > is that the holder of a public key can verify but not forge a > signature, whereas the holder of a key for a MAC can both verify and > generate the MAC. Thus MACs are point-to-point authentication > mechanisms, but not multicast authentication mechanisms. In most > routing protocols multiple entities must verify an assertion of a > router, making MACs inappropriate authentication mechanisms for these > contexts. How about this way: Use MAC as a proof of authorization and use private key to sign this MAC to prevent masquerading? Of course, we don't have to use MAC for authorization. The administrator can assign a private/public key to a group as authorization, so the routers in the group can share the same key for authorization, while each member use its individual key for identification. Back to the original question: Should we to distinguish unauthorized routers/masquerading routers? I think we should.:-) Yi _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Mar 17 18:19:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07445 for ; Mon, 17 Mar 2003 18:19:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HNa9r13415 for rpsec-archive@odin.ietf.org; Mon, 17 Mar 2003 18:36:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HNa9O13412 for ; Mon, 17 Mar 2003 18:36:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07440 for ; Mon, 17 Mar 2003 18:19:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HNZKO13370; Mon, 17 Mar 2003 18:35:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HNYfO13346 for ; Mon, 17 Mar 2003 18:34:41 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07411 for ; Mon, 17 Mar 2003 18:17:35 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id SAA04621; Mon, 17 Mar 2003 18:20:40 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma004588; Mon, 17 Mar 03 18:19:39 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2HNIki05521; Mon, 17 Mar 2003 18:18:46 -0500 (EST) Date: Mon, 17 Mar 2003 18:18:46 -0500 (EST) Message-Id: <200303172318.h2HNIki05521@raven.gw.tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources Cc: sandy@tislabs.com 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: , >Let's say we want to do some policy routing based on identity. So when a >router receives an routing message, the router needs to: > >1 know and verify the originator of the message; and >2 verify the originator has been authorized to send this type of message > >The first step can be done w/ digital signature and the second step can be >done w/ checking a policy database. But the query/response process might >be slow. >Or, the administrator can just assign a MD5 password to the originator to >authenticate its packets. When the receiver verified the digest, it >believes that the originator has been authorized. I guess you are say "query/response" because you are talking about something like an LDAP server of policy rules. But the first step uses digital signature to assure you of the authenticity of the identity and then uses the assured identity to check the policy rule. The second step uses MD5 to assure you of the authenticity of the identity and then uses the assured identity to check the policy rule where the policy rule is "TRUE". In other words, I think you are calling this second case "identification" because the policy is very broad - if you are in the group of people that know the key, you get to do anything you want. But nothing prevents you from having two shared keys, for "trusted" and "super trusted" customers, with different activities authorized for each. So the type of crypto does not dictate what policies one can enforce with it. (Personally, myself, I'd use the stronger crypto for the broad "anything he wants" case, but that's just me.) So there's no difference between authorization with digital signatures and authorization with a MD5 authentication of the identity. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Mar 17 18:26:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07739 for ; Mon, 17 Mar 2003 18:26:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HNghV14644 for rpsec-archive@odin.ietf.org; Mon, 17 Mar 2003 18:42:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HNghO14641 for ; Mon, 17 Mar 2003 18:42:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07719 for ; Mon, 17 Mar 2003 18:25:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HNe2O14427; Mon, 17 Mar 2003 18:40:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HNdhO14349 for ; Mon, 17 Mar 2003 18:39:43 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07583 for ; Mon, 17 Mar 2003 18:22:36 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id SAA04731; Mon, 17 Mar 2003 18:25:42 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma004715; Mon, 17 Mar 03 18:24:54 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2HNO1v05793; Mon, 17 Mar 2003 18:24:01 -0500 (EST) Date: Mon, 17 Mar 2003 18:24:01 -0500 (EST) Message-Id: <200303172324.h2HNO1v05793@raven.gw.tislabs.com> To: rpsec@ietf.org, sandy@tislabs.com Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources 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: , >So there's no difference between authorization with digital signatures and >authorization with a MD5 authentication of the identity. Since you mention keys, I presume that you mean "keyed-MD5" (or, even better, HMAC-MD5), and not just a MD5 hash. Which would give you no assurance at all of the identity. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 11:30:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16569 for ; Tue, 18 Mar 2003 11:30:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IGlbM26647 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 11:47:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IGlbO26644 for ; Tue, 18 Mar 2003 11:47:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16553 for ; Tue, 18 Mar 2003 11:30:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IGiCO26417; Tue, 18 Mar 2003 11:44:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IGhrO26390 for ; Tue, 18 Mar 2003 11:43:53 -0500 Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16310 for ; Tue, 18 Mar 2003 11:26:24 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h2IGSc504244 for ; Tue, 18 Mar 2003 11:28:39 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Tue, 18 Mar 2003 11:28:38 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Scribe and Jabber 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: , Folks, We still haven't gotten any volunteers for the role of either scribe or someone to join a Jabber session from here in SF. Please speak up if you can do this. For those hoping to Jabber at home, you may be out of luck, sorry. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 11:53:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17876 for ; Tue, 18 Mar 2003 11:53:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IHAm729733 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 12:10:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHAlO29730 for ; Tue, 18 Mar 2003 12:10:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17829 for ; Tue, 18 Mar 2003 11:53:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IH77O28850; Tue, 18 Mar 2003 12:07:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IH6bO28660 for ; Tue, 18 Mar 2003 12:06:37 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17559 for ; Tue, 18 Mar 2003 11:49:09 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2IGp060000429; Tue, 18 Mar 2003 11:51:05 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 18 Mar 2003 11:50:22 -0500 To: From: Stephen Kent Subject: RE: [RPSEC] Topic 1: Section 3.1 Threat Sources Cc: 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 9:56 AM -0600 3/15/03, Dijiang Huang wrote: >Russ, > >> >> > (2) The outsiders are divided into "unauthorized devices" and >> > "masquerading devices". >> >> Yes, I can see the tautology here--if you're not expecting authorization, >> then there's no such thing as an unauthorized device. If there is >> authorization, there's no way in but to masquerade. I'd probably >> agree with >> taking these out, at first glance. >> >I think the terms "authorized" and "unauthorized" are a little bit confuse. >For example, in ospf, suppose if a router is an eligible routing exchanger, >when it modifies or forges >other routers' routing information, is it masquerading or not? It is >authorized >to send and receive routing information, but it is not authorized to changed >others >routing information. I think the authorized region should be clarified. But, >somehow, >this will make is complicate. Cause different protocols have different >behaviors, such >as link state and distance vector. > Masquarading is asserting an identity other than one's own, and thus it is an attack against authentication. Changing data passed on by another router, outside the constraints allowed by a routing protocol, is an integrity attack against that data, more than an authentication attack. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 11:55:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18064 for ; Tue, 18 Mar 2003 11:55:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IHCX729895 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 12:12:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHCXO29892 for ; Tue, 18 Mar 2003 12:12:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18037 for ; Tue, 18 Mar 2003 11:55:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IH9BO29622; Tue, 18 Mar 2003 12:09:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IH6gO28671 for ; Tue, 18 Mar 2003 12:06:42 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17549 for ; Tue, 18 Mar 2003 11:48:58 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2IGp05w000429; Tue, 18 Mar 2003 11:51:03 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: <200303112234.h2BMYTK26435@raven.gw.tislabs.com> Date: Tue, 18 Mar 2003 11:50:22 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources 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 8:18 AM -0500 3/15/03, Russ White wrote: > > I'd like to see some changes in this categorization. >> >> (1) The use of the term "compromised" is defined to mean faulty or >> misconfigured routers. In the first place, this leaves out subverted >> routers, which is a big concern. Secondly, to most people, the term >> "compromised" means "subverted", not faulty. So the text uses a term >> with a typical meaning to mean everything except the typical meaning. >> Were subverted routers left out on purpose? > >I think we talked about this before, but I still think we should probably >seperate the idea of a compromised router and a faulty router, even if the >impact is the same. It's just confusing to the reader. It's appropriate to note that both benign and malicious failures of routers are of concern. As you note, they are separable in that there are different paths by which each of these problems arises. From a security perspective, Byzantine failures are indistinguishable from benign failures, so we do tend to lump them together from the perspective of what we need to do to deal with both forms of failures. > >> (2) The outsiders are divided into "unauthorized devices" and >> "masquerading devices". > >Yes, I can see the tautology here--if you're not expecting authorization, >then there's no such thing as an unauthorized device. If there is >authorization, there's no way in but to masquerade. I'd probably agree with >taking these out, at first glance. > >> (3) Compromised links terminology >> >> [Nitpick: links never do things - it is the hosts that are >> compromising the links who do things. This terminology leads to >> sentences like "Compromised links can sniff the links over which they >> have control."] > >Agreed, this should be cleaned up. > >> As stated in the text, these threat sources are acting "without >> participating in the routing exchange". So these threats are attacking >> the transport subsystem, as mentioned in Section 2. Can we say that >> routing protocol designers should do anything about these threat sources? > >I think we can mention these attacks, since the RP designers should/could >look at thes transport they are using, and try to help the designers of >those transports build better security into them. It's also helpful to >analyse these to make certain there's nothing you can do in your protocol >design to try and make these sorts of attacks harder in any way. > >But we certainly can't lay any requirements on the rp designer in relation >to transport attacks. Routing protocol designers get to choose the transport protocols that they employ, and so it is appropriate to discuss the implications of different choices of transport protocols, right? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 11:57:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18219 for ; Tue, 18 Mar 2003 11:57:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IHEYY30050 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 12:14:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHEYO30047 for ; Tue, 18 Mar 2003 12:14:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18180 for ; Tue, 18 Mar 2003 11:57:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHBCO29783; Tue, 18 Mar 2003 12:11:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IH6lO28679 for ; Tue, 18 Mar 2003 12:06:47 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17617 for ; Tue, 18 Mar 2003 11:49:20 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2IGp062000429; Tue, 18 Mar 2003 11:51:06 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: <200303142211.h2EMBpL25904@raven.gw.tislabs.com> Date: Tue, 18 Mar 2003 11:50:22 -0500 To: Yi Yang From: Stephen Kent Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? Cc: 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 9:21 PM -0500 3/14/03, Yi Yang wrote: >Sandy, > >> I don't think of the customer's failure to announce his own address as >> a threat. It certainly doesn't hurt anyone but the customer. And I regard >> anything that a router says about its own state, the data that it is >> exclusively knowledgeable about, as its own exclusive authority. So >> whatever it says is authentic. > >Based on this, the overclaiming should not be a threat either. How do you justify this statement? not choosing to advertise a prefix might be justified by a local policy decision. Advertising what you have not been authorized to advertise is clearly a security problem that cannot be justified by local policy in the normal meaning of the term. > > Suppose a BGP peer is mis-configured and doesn't accept connections from >> its legitimate peer? I don't consider that an attack. A failure, sure, >> but not an attack. >> >> And to reiterate: can you imagine that the routing protocol would have >> any chance in the world of distinguishing a legitimate case of hiding >> from an illegitimate case? In your example, is there any way the >> routing protocol at the customer could protect itself from that >> mis-configuration? > >You are right that we can't find a way to protect against this. But can we >say a threat doesn't exist because we can't find a defense? The point is not that one does not have a defense for this, but that the behavior is indistinguishable from legitimate behavior, at least in some contexts. For example, maybe the ISP is not advertising the prefix because the subscriber failed to pay its bills :-). Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 12:00:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18397 for ; Tue, 18 Mar 2003 12:00:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IHHUb30371 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 12:17:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHHUO30368 for ; Tue, 18 Mar 2003 12:17:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18380 for ; Tue, 18 Mar 2003 12:00:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHE4O30031; Tue, 18 Mar 2003 12:14:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IH7lO29551 for ; Tue, 18 Mar 2003 12:07:47 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17684 for ; Tue, 18 Mar 2003 11:50:19 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2IGp06C000429; Tue, 18 Mar 2003 11:52:32 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02D030@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B02D030@KC-MAIL4.kc.umkc.edu> Date: Tue, 18 Mar 2003 11:50:21 -0500 To: "Ayyasamy, Senthilkumar (UMKC-Student)" From: Stephen Kent Subject: Re: [RPSEC] comments on draft-beard-rpsec-routing-threats-01.txt Cc: 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 9:44 AM -0600 3/14/03, Ayyasamy, Senthilkumar (UMKC-Student) wrote: >Steve, > >> BTW, these are attacks, not threats. I still maintain that >> we need a threat model, not just a list of attacks. > >Yes. But, It's good to list the attacks...Possibly, the title >and scope of the draft can be modified to reflect your comments. > >anyway, I don't think a big gap exists between attacks and >possible threats. You have anything specific in mind? > >- Senthil. I would characterize threats based on their goals and capabilities. So, for example, some threats focus on DoS on a local or global basis, others strive to divert traffic for passive or active wiretapping, etc. The means by which the threats act is a function of their capabilities and their aversion to detection. So, for example, anyone can try to send traffic to an interface with a spoofed IP address, but some adversaries also can engage in active wiretapping on an inter-router link, others could compromise a router or a management station used to control a router, others might bribe an operator, etc. Before listing attacks, I think we should characterize threats in this fashion, and then show how different attacks fit into different threat models. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 12:02:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18521 for ; Tue, 18 Mar 2003 12:02:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IHJUm30530 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 12:19:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHJUO30527 for ; Tue, 18 Mar 2003 12:19:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18505 for ; Tue, 18 Mar 2003 12:02:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHFwO30154; Tue, 18 Mar 2003 12:15:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IH81O29559 for ; Tue, 18 Mar 2003 12:08:01 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17687 for ; Tue, 18 Mar 2003 11:50:33 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2IGp06G000429; Tue, 18 Mar 2003 11:52:46 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <20030315003529.X69506-100000@sequoia.muada.com> References: <20030315003529.X69506-100000@sequoia.muada.com> Date: Tue, 18 Mar 2003 11:50:21 -0500 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: Re: [RPSEC] DDoS of routing ? Cc: 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 1:00 AM +0100 3/15/03, Iljitsch van Beijnum wrote: >On Fri, 14 Mar 2003 sandy@tislabs.com wrote: > >> >A better way to deal with this is use some kind of magic cookie in each >> >packet that can be precomputed and easily checked. For instance, each >> >segment includes an MD5 over the previous segment and a secret key. >> >Since the MD5 operation needs to be done only after processing a valid >> >segment rather than after each segment, an attacker can't trigger >> >unnecessary MD5 operations, just some 16 byte compare operations. > >> Could you explain what you mean some more? > >> First, an MD5 over data+shared secret *is* a crypto operation. > >I know. > >> (Not the best, most people recommend the HMAC-MD5 over >>data+sharedsecret, but hey) > >Of course, but let's leave some details for an actual draft. :-) > >> When you say "segment" are you talking TCP segment? > >Yes. If the magic cookie for packet n is created by doing an HMAC over >packet n - 1 then we have to be sure we don't miss any packets. This is >possible with TCP, I don't see how with IP. Of course there can also be >other ways to set up the magic cookie: derive it from the time, simply >communicate it to the other side, stuff like that. > >> You imply that this is a win because the bad guy would have a hard >> time coming up with valid segments. Is that the advantage? If so, >> why do you think that's hard? > >I'm not sure what you mean here by "valid segments". I'm not >suggesting we should forget about regular authentication (IPsec or BGP >TCP MD5 hack). (But maybe further study will show we can. Probably not, >though.) So we know which segments are valid and which aren't the same >way we do now. > >The advantage is that if we receive 1 valid packet and 999 DoS packets >per second, doing regular IPsec/RFC2385 needs 1000 crypto operations per >second. My suggestion would need 2: one for the regular IPsec/RFC2385 >for the valid packet and then another to generate the cookie for the >next packet. The 999 DoS packets don't have the right cookie so they can >be discarded without having to do any crypto. > >Iljitsch > I think you're getting pretty far ahead re details of engineering a solution, when we don't even have a good characterization of, or agreement on, the requirements. On that basis, I think we ought not spend the time now trying to evaluate a proposal such as this one. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 12:02:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18538 for ; Tue, 18 Mar 2003 12:02:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IHJlb30551 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 12:19:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHJlO30548 for ; Tue, 18 Mar 2003 12:19:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18515 for ; Tue, 18 Mar 2003 12:02:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHGIO30188; Tue, 18 Mar 2003 12:16:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IH83O29564 for ; Tue, 18 Mar 2003 12:08:03 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17690 for ; Tue, 18 Mar 2003 11:50:35 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2IGp06I000429; Tue, 18 Mar 2003 11:52:48 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <20030315014920.F69506-100000@sequoia.muada.com> References: <20030315014920.F69506-100000@sequoia.muada.com> Date: Tue, 18 Mar 2003 11:50:21 -0500 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] DDoS of routing ? Cc: Alex Zinin , 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 2:26 AM +0100 3/15/03, Iljitsch van Beijnum wrote: >On Fri, 14 Mar 2003, Alex Zinin wrote: > >> Right. It is not the signature _of_ the n+1'st packet, but of the n'th >> packet _for_ n+1'st. > >> What about the very 1st packet in the connection, btw? > >Both ends must negotiate a session key anyway, so an initial value for >the first cookie shouldn't be much of an (extra) problem. However, if >the DoS is already in effect at this point, this negotiation will be >hard to complete. Or maybe preshared with a fixed seed for the initial >key would be the way to go. As I noted in my previous message on this thread, this seems awfully premature. But, note that there are ways to generate a series of values that can be quickly verified by a receiver, if that's what we decide that we need, and if we are doing this for only a point-to-point link. > >> And, of course, Man-in-the-Middle attacks would still be open, as >> you mention... I think we should avoid this... > >Regular authentication that's still in place should take care of this. > >> > A problem that occurred to me after writing this that I'm more concerned >> > with it the state that may be needed. > >> Seems that the amount of state would be approx the same as if you did >> actual MD5. > >Good point. However, this probably means the number of sessions that can >be protected in this manner will always be fairly limited. > >> > If the line card can't be set up >> > to receive the next packet at line rate: too bad, send them slower. >> > We're talking about control traffic here, this doesn't have to be line >> > rate. > >> I am not sure I would be that optimistic about this. This may really >> affect TCP performance--I expect slow restart would be kicking in >> continuously, and this will affect BGP convergence... > >Hm, maybe doing this based on the last packet isn't the best way. Ok, >how about this: we use a stream cipher to come up with a random-looking >data stream on both ends and use the IPsec anti-replay counter as a >pointer to the part of the data stream that is used as a magic cookie in >the current packet. We can then program the line card with enough data >to be able to check a certain number of packets per session without >having to wait for the CPU to come up with more cookie data. This also >removes the TCP limitation, it could now be a generic IP level >mechanism. > How about if we don't play cryptographer here? As I said, the literature has lots of options for what may be a solution if we come to agreement on the problem, which we have yet to do ... Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 12:04:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18603 for ; Tue, 18 Mar 2003 12:04:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IHLPs30675 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 12:21:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHLPO30672 for ; Tue, 18 Mar 2003 12:21:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18570 for ; Tue, 18 Mar 2003 12:03:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHI1O30448; Tue, 18 Mar 2003 12:18:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHHrO30413 for ; Tue, 18 Mar 2003 12:17:53 -0500 Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18391 for ; Tue, 18 Mar 2003 12:00:25 -0500 (EST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2IH2pq89152; Tue, 18 Mar 2003 18:02:51 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 18 Mar 2003 18:02:51 +0100 (CET) From: Iljitsch van Beijnum To: Stephen Kent cc: Subject: Re: Re: [RPSEC] DDoS of routing ? In-Reply-To: Message-ID: <20030318180219.V87639-100000@sequoia.muada.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 Tue, 18 Mar 2003, Stephen Kent wrote: > I think you're getting pretty far ahead re details of engineering a > solution, when we don't even have a good characterization of, or > agreement on, the requirements. On that basis, I think we ought not > spend the time now trying to evaluate a proposal such as this one. Fine. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 12:11:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18836 for ; Tue, 18 Mar 2003 12:11:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IHSWR31159 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 12:28:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHSWO31156 for ; Tue, 18 Mar 2003 12:28:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18832 for ; Tue, 18 Mar 2003 12:11:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHP6O30952; Tue, 18 Mar 2003 12:25:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHOMO30880 for ; Tue, 18 Mar 2003 12:24:22 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18693 for ; Tue, 18 Mar 2003 12:06:54 -0500 (EST) Received: from sarah ([134.193.2.143] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Mar 2003 11:09:06 -0600 Reply-To: From: "Dijiang Huang" To: "Stephen Kent" Cc: Subject: RE: [RPSEC] Topic 1: Section 3.1 Threat Sources Date: Tue, 18 Mar 2003 11:08:06 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 18 Mar 2003 17:09:06.0940 (UTC) FILETIME=[159B93C0:01C2ED71] 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > >> > (2) The outsiders are divided into "unauthorized devices" and > >> > "masquerading devices". > >> > >> Yes, I can see the tautology here--if you're not expecting > authorization, > >> then there's no such thing as an unauthorized device. If there is > >> authorization, there's no way in but to masquerade. I'd probably > >> agree with > >> taking these out, at first glance. > >> > >I think the terms "authorized" and "unauthorized" are a little > bit confuse. > >For example, in ospf, suppose if a router is an eligible routing > exchanger, > >when it modifies or forges > >other routers' routing information, is it masquerading or not? It is > >authorized > >to send and receive routing information, but it is not > authorized to changed > >others > >routing information. I think the authorized region should be > clarified. But, > >somehow, > >this will make is complicate. Cause different protocols have different > >behaviors, such > >as link state and distance vector. > > > > Masquarading is asserting an identity other than one's own, and thus > it is an attack against authentication. Changing data passed on by > another router, outside the constraints allowed by a routing > protocol, is an integrity attack against that data, more than an > authentication attack. > I agree Changing data passed on by another router should be the problem targeted by integrity check. But, when this router sends the modified/forged routing data out, it also impersonates other routers for those routing data belongs to. --Dijiang _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 12:17:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19012 for ; Tue, 18 Mar 2003 12:17:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IHYce31453 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 12:34:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHYcO31450 for ; Tue, 18 Mar 2003 12:34:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18996 for ; Tue, 18 Mar 2003 12:17:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHV6O31339; Tue, 18 Mar 2003 12:31:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IHUhO31291 for ; Tue, 18 Mar 2003 12:30:43 -0500 Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18895 for ; Tue, 18 Mar 2003 12:13:15 -0500 (EST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2IHFf589213; Tue, 18 Mar 2003 18:15:41 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 18 Mar 2003 18:15:41 +0100 (CET) From: Iljitsch van Beijnum To: Stephen Kent cc: Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: Message-ID: <20030318180625.B87639-100000@sequoia.muada.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 Tue, 18 Mar 2003, Stephen Kent wrote: > As I noted in my previous message on this thread, this seems awfully > premature. So why not take your own advice? > But, note that there are ways to generate a series of > values that can be quickly verified by a receiver, if that's what we > decide that we need, and if we are doing this for only a > point-to-point link. Why would we only want to do this on a point-to-point link? > How about if we don't play cryptographer here? As I said, the > literature has lots of options for what may be a solution So why doesn't IPsec have something like this already? > if we come to agreement on the problem, which we have yet to do ... Defining the problem isn't a goal in its own right. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 12:56:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20665 for ; Tue, 18 Mar 2003 12:56:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IIDcu02911 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 13:13:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIDcO02908 for ; Tue, 18 Mar 2003 13:13:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20653 for ; Tue, 18 Mar 2003 12:56:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIADO02665; Tue, 18 Mar 2003 13:10:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2II9IO02589 for ; Tue, 18 Mar 2003 13:09:18 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20408 for ; Tue, 18 Mar 2003 12:51:49 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2IHrx60006160; Tue, 18 Mar 2003 12:54:02 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <20030318180625.B87639-100000@sequoia.muada.com> References: <20030318180625.B87639-100000@sequoia.muada.com> Date: Tue, 18 Mar 2003 12:52:11 -0500 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] DDoS of routing ? Cc: 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 6:15 PM +0100 3/18/03, Iljitsch van Beijnum wrote: >On Tue, 18 Mar 2003, Stephen Kent wrote: > >> As I noted in my previous message on this thread, this seems awfully >> premature. > >So why not take your own advice? because I was catching up on your messages :-) > > But, note that there are ways to generate a series of >> values that can be quickly verified by a receiver, if that's what we >> decide that we need, and if we are doing this for only a >> point-to-point link. > >Why would we only want to do this on a point-to-point link? I thought that was the context you were describing, since otherwise the mechanisms you suggested are not very secure, in general ... > > How about if we don't play cryptographer here? As I said, the >> literature has lots of options for what may be a solution > >So why doesn't IPsec have something like this already? IPsec includes some features to facilitate rapid discard of "bad" traffic, including the ordering of the checks performed for integrity and authentication. IPsec is algorithm independent, and so one could choose to employ an algorithm that emphasizes fast checking, consistent with the protocol design. The IPsec WG has not focused on developing such algorithms, perhaps because the context in which the implementations operate do not generally view this as a major problem. > > if we come to agreement on the problem, which we have yet to do ... > >Defining the problem isn't a goal in its own right. defining the problem is an essential first step, unless one wants to waste time proposing solutions absent agreement on the problem being solved. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 13:15:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21789 for ; Tue, 18 Mar 2003 13:15:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IIWSH04163 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 13:32:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIWSO04160 for ; Tue, 18 Mar 2003 13:32:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21740 for ; Tue, 18 Mar 2003 13:14:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIT4O03873; Tue, 18 Mar 2003 13:29:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IISHO03811 for ; Tue, 18 Mar 2003 13:28:17 -0500 Received: from nomad.tcb.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21394 for ; Tue, 18 Mar 2003 13:10:47 -0500 (EST) Received: by nomad.tcb.net (Postfix, from userid 500) id DE1C155F62; Tue, 18 Mar 2003 11:12:59 -0700 (MST) Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id DD0B93E83 for ; Tue, 18 Mar 2003 11:12:59 -0700 (MST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: rpsec@ietf.org From: Danny McPherson Reply-To: danny@tcb.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Mar 2003 11:12:54 -0700 Message-Id: <20030318181259.DE1C155F62@nomad.tcb.net> Subject: [RPSEC] Requirements Document 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: , Folks, As mentioned in the WG meeting, I'm currently serving as editor for the requirements document(s). I hope to generate something akin to a toc and then solicit authors to help develop sections with which they're interested. If you have ideas about what should be in the document(s), or are interested in authoring one or more sections, please send me (or the list) email. I hope to have something for review well before the next meeting. Thanks! -danny _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 13:41:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20667 for ; Tue, 18 Mar 2003 12:56:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IIDcN02927 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 13:13:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIDcO02924 for ; Tue, 18 Mar 2003 13:13:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20651 for ; Tue, 18 Mar 2003 12:56:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIAHO02689; Tue, 18 Mar 2003 13:10:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2II9YO02602 for ; Tue, 18 Mar 2003 13:09:34 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20412 for ; Tue, 18 Mar 2003 12:52:01 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2IHrx5w006160; Tue, 18 Mar 2003 12:54:00 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 18 Mar 2003 12:42:21 -0500 To: From: Stephen Kent Subject: RE: [RPSEC] Topic 1: Section 3.1 Threat Sources Cc: 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 11:08 AM -0600 3/18/03, Dijiang Huang wrote: > > >> > (2) The outsiders are divided into "unauthorized devices" and >> >> > "masquerading devices". >> >> >> >> Yes, I can see the tautology here--if you're not expecting >> authorization, >> >> then there's no such thing as an unauthorized device. If there is >> >> authorization, there's no way in but to masquerade. I'd probably >> >> agree with >> >> taking these out, at first glance. >> >> >> >I think the terms "authorized" and "unauthorized" are a little >> bit confuse. >> >For example, in ospf, suppose if a router is an eligible routing >> exchanger, >> >when it modifies or forges >> >other routers' routing information, is it masquerading or not? It is >> >authorized >> >to send and receive routing information, but it is not >> authorized to changed >> >others >> >routing information. I think the authorized region should be >> clarified. But, >> >somehow, >> >this will make is complicate. Cause different protocols have different >> >behaviors, such >> >as link state and distance vector. >> > >> >> Masquarading is asserting an identity other than one's own, and thus >> it is an attack against authentication. Changing data passed on by >> another router, outside the constraints allowed by a routing >> protocol, is an integrity attack against that data, more than an >> authentication attack. >> > >I agree Changing data passed on by another router should be the problem >targeted >by integrity check. But, when this router sends the modified/forged routing >data >out, it also impersonates other routers for those routing >data belongs to. > >--Dijiang One can distinguish between masquerading as a router (an authentication issue) vs. making unauthorized changes to routing data (an integrity or authorization issue) and we ought not confuse the two. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 18:08:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04667 for ; Tue, 18 Mar 2003 18:08:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2INPoC28952 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 18:25:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2INPoO28949 for ; Tue, 18 Mar 2003 18:25:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04591 for ; Tue, 18 Mar 2003 18:08:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2INMLO28831; Tue, 18 Mar 2003 18:22:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2INLRO28805 for ; Tue, 18 Mar 2003 18:21:27 -0500 Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04099 for ; Tue, 18 Mar 2003 18:03:51 -0500 (EST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2IN6BF89762; Wed, 19 Mar 2003 00:06:12 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 19 Mar 2003 00:06:11 +0100 (CET) From: Iljitsch van Beijnum To: Stephen Kent cc: Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: Message-ID: <20030318235115.S87639-100000@sequoia.muada.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 Tue, 18 Mar 2003, Stephen Kent wrote: > >Defining the problem isn't a goal in its own right. > defining the problem is an essential first step, unless one wants to > waste time proposing solutions absent agreement on the problem being > solved. I see no dichotomy here. At some point the added value in continuing to work on the requirements no longer outweighs the delay in getting a working solution. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 18:26:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05919 for ; Tue, 18 Mar 2003 18:26:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2INhNX30347 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 18:43:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2INhNO30344 for ; Tue, 18 Mar 2003 18:43:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05913 for ; Tue, 18 Mar 2003 18:25:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2INe3O30209; Tue, 18 Mar 2003 18:40:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2INd6O30144 for ; Tue, 18 Mar 2003 18:39:06 -0500 Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05828 for ; Tue, 18 Mar 2003 18:21:30 -0500 (EST) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id SAA12514; Tue, 18 Mar 2003 18:24:37 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma012483; Tue, 18 Mar 03 18:24:13 -0500 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2INNJi11589; Tue, 18 Mar 2003 18:23:19 -0500 (EST) Date: Tue, 18 Mar 2003 18:23:19 -0500 (EST) Message-Id: <200303182323.h2INNJi11589@raven.gw.tislabs.com> To: dhuang@conrel.sice.umkc.edu, kent@bbn.com Subject: RE: [RPSEC] Topic 1: Section 3.1 Threat Sources Cc: rpsec@ietf.org 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: , >I agree Changing data passed on by another router should be the problem >targeted >by integrity check. But, when this router sends the modified/forged routing >data >out, it also impersonates other routers for those routing >data belongs to. I would disagree. The router Bob says "hi, I'm Bob. Here's a message I got from router George." And the message was not one sent by George. Bob is forgeing/falsifying/modifying a message from George. That's not impersonation. The receiver is under no misimpression of which router it is speaking to. But the integrity or authenticity of the message has been attacked. If the postman delivers a letter to you and the letter is forged, the postman is not impersonating the sender. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 19:30:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08231 for ; Tue, 18 Mar 2003 19:30:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J0lEq02081 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 19:47:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J0lEO02078 for ; Tue, 18 Mar 2003 19:47:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08150 for ; Tue, 18 Mar 2003 19:29:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J0hoO01736; Tue, 18 Mar 2003 19:43:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J0eWO01604 for ; Tue, 18 Mar 2003 19:40:32 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07792 for ; Tue, 18 Mar 2003 19:22:55 -0500 (EST) Received: from sarah ([134.193.2.143] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Mar 2003 18:25:07 -0600 Reply-To: From: "Dijiang Huang" To: , Cc: Subject: RE: [RPSEC] Topic 1: Section 3.1 Threat Sources Date: Tue, 18 Mar 2003 18:24:06 -0600 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.6604 (9.0.2911.0) In-Reply-To: <200303182323.h2INNJi11589@raven.gw.tislabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 19 Mar 2003 00:25:07.0302 (UTC) FILETIME=[FE660860:01C2EDAD] 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sandy, > >I agree Changing data passed on by another router should be the problem > >targeted > >by integrity check. But, when this router sends the > modified/forged routing > >data > >out, it also impersonates other routers for those routing > >data belongs to. > > I would disagree. The router Bob says "hi, I'm Bob. Here's a > message I got from router George." > And the message was not one sent by George. Bob is > forgeing/falsifying/modifying a message > from George. That's not impersonation. The receiver is under no > misimpression of which router > it is speaking to. But the integrity or authenticity of the > message has been attacked. > > If the postman delivers a letter to you and the letter is forged, > the postman is not > impersonating the sender. > Sometimes it is hard for a router to tell the message is from a originator or a forwarder. A router only can receive routing information from its immediate neighbors, but the routing information may have been already passed via multiple hops (such as through flooding). In this sense, the router may not have clues where the routing information comes from, it may be impersonated. The router Bob maliciously says "hi, I'm Bob. Here's a message about George.", When its neighbor John forwards this message to Tom and says "hi, I'm John. Here's a message about George." Will Tom really believe it originated from George or not? Especially, in link state routing domain, when a subverted router partition the network, it can not directly but indirectly impersonate routers from one partition to another partition. --Dijiang _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 18 20:33:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11110 for ; Tue, 18 Mar 2003 20:33:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J1oxD06929 for rpsec-archive@odin.ietf.org; Tue, 18 Mar 2003 20:50:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J1oxO06926 for ; Tue, 18 Mar 2003 20:50:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11092 for ; Tue, 18 Mar 2003 20:33:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J1lWO06762; Tue, 18 Mar 2003 20:47:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J1kgO06731 for ; Tue, 18 Mar 2003 20:46:42 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10916 for ; Tue, 18 Mar 2003 20:29:02 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2J1V9Sc000566; Tue, 18 Mar 2003 20:31:10 -0500 (EST) Received: from wl-137-227.wireless.ietf56.ietf.org (sjc-vpn2-247.cisco.com [10.21.112.247]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA19693; Tue, 18 Mar 2003 20:31:08 -0500 (EST) Date: Tue, 18 Mar 2003 20:31:14 -0500 (EST) From: Russ White X-X-Sender: ruwhite@wl-137-227.wireless.ietf56.ietf.org Reply-To: Russ White To: Stephen Kent cc: rpsec@ietf.org Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources In-Reply-To: Message-ID: References: <200303112234.h2BMYTK26435@raven.gw.tislabs.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: , > >> (1) The use of the term "compromised" is defined to mean faulty or > >> misconfigured routers. In the first place, this leaves out subverted > >> routers, which is a big concern. Secondly, to most people, the term > >> "compromised" means "subverted", not faulty. So the text uses a term > >> with a typical meaning to mean everything except the typical meaning. > >> Were subverted routers left out on purpose? > > > >I think we talked about this before, but I still think we should probably > >seperate the idea of a compromised router and a faulty router, even if the > >impact is the same. It's just confusing to the reader. > > It's appropriate to note that both benign and malicious failures of > routers are of concern. As you note, they are separable in that there are > different paths by which each of these problems arises. From a security > perspective, Byzantine failures are indistinguishable from benign > failures, so we do tend to lump them together from the perspective of > what we need to do to deal with both forms of failures. Yes, I agree. It seems to me that it's worth defining the difference, but then treating them as the same after explaining why the doc treats them the same, after that explaination (?). I think that made sense, anyway. > >> As stated in the text, these threat sources are acting "without > >> participating in the routing exchange". So these threats are attacking > >> the transport subsystem, as mentioned in Section 2. Can we say that > >> routing protocol designers should do anything about these threat sources? > > > >I think we can mention these attacks, since the RP designers should/could > >look at thes transport they are using, and try to help the designers of > >those transports build better security into them. It's also helpful to > >analyse these to make certain there's nothing you can do in your protocol > >design to try and make these sorts of attacks harder in any way. > > > >But we certainly can't lay any requirements on the rp designer in relation > >to transport attacks. > > Routing protocol designers get to choose the transport protocols that > they employ, and so it is appropriate to discuss the implications of > different choices of transport protocols, right? Right.... So, maybe there should be at least some area in the threats doc, and a corresponding area in the requirements (suggestions) doc, which talks about the choice of transport, and the security implications of that choice. Hmmm... Perhaps that section should actually be split off and made into a seperate doc, since it could be argued, as above, that it's not a part of the "protocol?" Thoughts? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Mar 19 13:13:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28639 for ; Wed, 19 Mar 2003 13:13:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JIUn418362 for rpsec-archive@odin.ietf.org; Wed, 19 Mar 2003 13:30:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JIUnO18359 for ; Wed, 19 Mar 2003 13:30:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28610 for ; Wed, 19 Mar 2003 13:12:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JITTO18223; Wed, 19 Mar 2003 13:29:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JISrO18172 for ; Wed, 19 Mar 2003 13:28:53 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28507 for ; Wed, 19 Mar 2003 13:10:54 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2JIAD66016260; Wed, 19 Mar 2003 13:12:48 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: <200303112234.h2BMYTK26435@raven.gw.tislabs.com> Date: Wed, 19 Mar 2003 12:46:17 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources 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 8:31 PM -0500 3/18/03, Russ White wrote: > > > >But we certainly can't lay any requirements on the rp designer in relation >> >to transport attacks. >> >> Routing protocol designers get to choose the transport protocols that >> they employ, and so it is appropriate to discuss the implications of >> different choices of transport protocols, right? > >Right.... So, maybe there should be at least some area in the threats doc, >and a corresponding area in the requirements (suggestions) doc, which talks >about the choice of transport, and the security implications of that >choice. > >Hmmm... Perhaps that section should actually be split off and made into a >seperate doc, since it could be argued, as above, that it's not a part of >the "protocol?" > >Thoughts? > >:-) > >Russ One could separate the transport protocol security issues, but I don't think the threat analysis will be so big as to warrant that. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Mar 19 13:14:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28760 for ; Wed, 19 Mar 2003 13:14:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JIWI618620 for rpsec-archive@odin.ietf.org; Wed, 19 Mar 2003 13:32:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JIWHO18617 for ; Wed, 19 Mar 2003 13:32:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28696 for ; Wed, 19 Mar 2003 13:14:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JIVZO18437; Wed, 19 Mar 2003 13:31:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JIQ8O18076 for ; Wed, 19 Mar 2003 13:26:08 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28421 for ; Wed, 19 Mar 2003 13:08:09 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2JIAD60016260; Wed, 19 Mar 2003 13:10:16 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <20030318235115.S87639-100000@sequoia.muada.com> References: <20030318235115.S87639-100000@sequoia.muada.com> Date: Wed, 19 Mar 2003 12:01:39 -0500 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] DDoS of routing ? Cc: 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 12:06 AM +0100 3/19/03, Iljitsch van Beijnum wrote: >On Tue, 18 Mar 2003, Stephen Kent wrote: > >> >Defining the problem isn't a goal in its own right. > >> defining the problem is an essential first step, unless one wants to >> waste time proposing solutions absent agreement on the problem being >> solved. > >I see no dichotomy here. > >At some point the added value in continuing to work on the requirements >no longer outweighs the delay in getting a working solution. If we don't have agreement on the requirements, we can't evaluate proposed solutions. We'll just argue about relative merits based on different criteria. Your comment has a sort of "ready, fire, aim" quality that is not likely to yield good results in the long run. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Mar 19 14:25:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02118 for ; Wed, 19 Mar 2003 14:25:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JJhSj26322 for rpsec-archive@odin.ietf.org; Wed, 19 Mar 2003 14:43:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJhSO26319 for ; Wed, 19 Mar 2003 14:43:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02059 for ; Wed, 19 Mar 2003 14:25:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJgbO26088; Wed, 19 Mar 2003 14:42:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJahO24822 for ; Wed, 19 Mar 2003 14:36:43 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01750 for ; Wed, 19 Mar 2003 14:18:39 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2JJJj5w021050; Wed, 19 Mar 2003 14:19:46 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: <200303142155.h2ELtHH23914@raven.gw.tislabs.com> Date: Wed, 19 Mar 2003 14:18:28 -0500 To: Yi Yang From: Stephen Kent Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources Cc: 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 1:55 PM -0500 3/17/03, Yi Yang wrote: >Steve, > >> >The first step can be done w/ digital signature and the second step can be >> >done w/ checking a policy database. But the query/response process might >> >be slow. >> >> this seems to assume checking of some remote database, right? > >Yes. > >> >Or, the administrator can just assign a MD5 password to the originator to >> >authenticate its packets. When the receiver verified the digest, it >> >believes that the originator has been authorized. >> >> This runs counter to what appear to be unstated assumptions in your >> previous paragraph. A MAC is not a signature and a major difference >> is that the holder of a public key can verify but not forge a >> signature, whereas the holder of a key for a MAC can both verify and >> generate the MAC. Thus MACs are point-to-point authentication >> mechanisms, but not multicast authentication mechanisms. In most >> routing protocols multiple entities must verify an assertion of a >> router, making MACs inappropriate authentication mechanisms for these >> contexts. > >How about this way: Use MAC as a proof of authorization and use private >key to sign this MAC to prevent masquerading? Of course, we don't have to >use MAC for authorization. The administrator can assign a private/public >key to a group as authorization, so the routers in the group can share the >same key for authorization, while each member use its individual key for >identification. The words you use above do not match normal security terminology use. MACs are not signed, Generally. MACs are integrity/authentication mechanisms. Keys do not intrinsically provide authorization. What we usually do is map possession of a key to an identity (for one person/device or a group) and then we use an authentication identity to make an access control (authorization) decision. >Back to the original question: Should we to distinguish unauthorized >routers/masquerading routers? I think we should.:-) Yes, to the extent that we first authenticate a router and then we separately decide what the router is authorized to do. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Mar 19 16:30:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09459 for ; Wed, 19 Mar 2003 16:30:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JLm3r07990 for rpsec-archive@odin.ietf.org; Wed, 19 Mar 2003 16:48:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLm3O07987 for ; Wed, 19 Mar 2003 16:48:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09372 for ; Wed, 19 Mar 2003 16:30:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLl8O07863; Wed, 19 Mar 2003 16:47:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLjHO07631 for ; Wed, 19 Mar 2003 16:45:17 -0500 Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09185 for ; Wed, 19 Mar 2003 16:27:13 -0500 (EST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2JLTW692075; Wed, 19 Mar 2003 22:29:33 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 19 Mar 2003 22:29:32 +0100 (CET) From: Iljitsch van Beijnum To: Stephen Kent cc: Subject: Re: [RPSEC] DDoS of routing ? In-Reply-To: Message-ID: <20030319205101.N87639-100000@sequoia.muada.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, 19 Mar 2003, Stephen Kent wrote: > >At some point the added value in continuing to work on the requirements > >no longer outweighs the delay in getting a working solution. > If we don't have agreement on the requirements, we can't evaluate > proposed solutions. We'll just argue about relative merits based on > different criteria. > Your comment has a sort of "ready, fire, aim" quality that is not > likely to yield good results in the long run. It was never my intention to make a huge debate out of this. Spending some time on requirements is good, but that doesn't mean spending lots of time on requirements is even better. If that were the case, we'd all be running CLNS today. Sometimes "ready fire aim" is the right approach. Having said that, I want to make clear I don't have a problem with the current approach of this wg, other than that I think lumping together IGPs and EGPs is probably not the most efficient way to handle things but who cares about efficiency. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Mar 19 19:11:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17111 for ; Wed, 19 Mar 2003 19:11:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K0Saf22210 for rpsec-archive@odin.ietf.org; Wed, 19 Mar 2003 19:28:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0SaO22207 for ; Wed, 19 Mar 2003 19:28:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17102 for ; Wed, 19 Mar 2003 19:10:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0RGO22110; Wed, 19 Mar 2003 19:27:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0QOO22068 for ; Wed, 19 Mar 2003 19:26:24 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17039 for ; Wed, 19 Mar 2003 19:08:18 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2K0AGMR018151; Wed, 19 Mar 2003 19:10:17 -0500 (EST) Received: from wl-137-227.wireless.ietf56.ietf.org (sjc-vpn3-291.cisco.com [10.21.65.35]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA02643; Wed, 19 Mar 2003 19:10:16 -0500 (EST) Date: Wed, 19 Mar 2003 19:10:24 -0500 (EST) From: Russ White X-X-Sender: ruwhite@wl-137-227.wireless.ietf56.ietf.org Reply-To: Russ White To: Stephen Kent cc: Yi Yang , rpsec@ietf.org Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? In-Reply-To: Message-ID: References: <200303142211.h2EMBpL25904@raven.gw.tislabs.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: , So, from this discussion, and the discussion at the mic during the meeting, it seems like underclaiming, by defintion, is _currently_ defined as not advertising something you are authorized to advertise for reasons of configuration or bugs. Is it possible to simply redefine it, so we can seperate the specific threat of someone killing off reachability by maliciously killing off an advertisement, rather than simply bundling that sort of attack under some other category? Is it useful to provide a classification for that sort of attack through redefinition? :-) Russ On Tue, 18 Mar 2003, Stephen Kent wrote: > At 9:21 PM -0500 3/14/03, Yi Yang wrote: > >Sandy, > > > >> I don't think of the customer's failure to announce his own address as > >> a threat. It certainly doesn't hurt anyone but the customer. And I regard > >> anything that a router says about its own state, the data that it is > >> exclusively knowledgeable about, as its own exclusive authority. So > >> whatever it says is authentic. > > > >Based on this, the overclaiming should not be a threat either. > > How do you justify this statement? not choosing to advertise a prefix > might be justified by a local policy decision. Advertising what you > have not been authorized to advertise is clearly a security problem > that cannot be justified by local policy in the normal meaning of the > term. > > > > Suppose a BGP peer is mis-configured and doesn't accept connections from > >> its legitimate peer? I don't consider that an attack. A failure, sure, > >> but not an attack. > >> > >> And to reiterate: can you imagine that the routing protocol would have > >> any chance in the world of distinguishing a legitimate case of hiding > >> from an illegitimate case? In your example, is there any way the > >> routing protocol at the customer could protect itself from that > >> mis-configuration? > > > >You are right that we can't find a way to protect against this. But can we > >say a threat doesn't exist because we can't find a defense? > > The point is not that one does not have a defense for this, but that > the behavior is indistinguishable from legitimate behavior, at least > in some contexts. For example, maybe the ISP is not advertising the > prefix because the subscriber failed to pay its bills :-). > > Steve > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Mar 19 19:11:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17157 for ; Wed, 19 Mar 2003 19:11:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K0THm22253 for rpsec-archive@odin.ietf.org; Wed, 19 Mar 2003 19:29:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0TGO22250 for ; Wed, 19 Mar 2003 19:29:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17151 for ; Wed, 19 Mar 2003 19:11:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0S1O22182; Wed, 19 Mar 2003 19:28:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0RfO22135 for ; Wed, 19 Mar 2003 19:27:41 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17056 for ; Wed, 19 Mar 2003 19:09:35 -0500 (EST) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2K0BgiH028685; Wed, 19 Mar 2003 19:11:43 -0500 (EST) Received: from wl-137-227.wireless.ietf56.ietf.org (sjc-vpn3-291.cisco.com [10.21.65.35]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA02704; Wed, 19 Mar 2003 19:11:41 -0500 (EST) Date: Wed, 19 Mar 2003 19:11:51 -0500 (EST) From: Russ White X-X-Sender: ruwhite@wl-137-227.wireless.ietf56.ietf.org Reply-To: Russ White To: Stephen Kent cc: Yi Yang , rpsec@ietf.org Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources In-Reply-To: Message-ID: References: <200303142155.h2ELtHH23914@raven.gw.tislabs.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: , > >Back to the original question: Should we to distinguish unauthorized > >routers/masquerading routers? I think we should.:-) > > Yes, to the extent that we first authenticate a router and then we > separately decide what the router is authorized to do. In other words, there is a difference between a valid member of the routing system, and a valid member of the routing system doing calid things. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Mar 19 19:22:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17491 for ; Wed, 19 Mar 2003 19:22:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K0duA23670 for rpsec-archive@odin.ietf.org; Wed, 19 Mar 2003 19:39:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0duO23667 for ; Wed, 19 Mar 2003 19:39:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17477 for ; Wed, 19 Mar 2003 19:21:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0d4O23639; Wed, 19 Mar 2003 19:39:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K0cjO23600 for ; Wed, 19 Mar 2003 19:38:45 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17449 for ; Wed, 19 Mar 2003 19:20:39 -0500 (EST) Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2K0Mj60009217; Wed, 19 Mar 2003 19:22:46 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: <200303142155.h2ELtHH23914@raven.gw.tislabs.com> Date: Wed, 19 Mar 2003 19:14:04 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources 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 7:11 PM -0500 3/19/03, Russ White wrote: > > >Back to the original question: Should we to distinguish unauthorized >> >routers/masquerading routers? I think we should.:-) >> >> Yes, to the extent that we first authenticate a router and then we >> separately decide what the router is authorized to do. > >In other words, there is a difference between a valid member of the routing >system, and a valid member of the routing system doing calid things. > >:-) > >Russ exactly _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 20 01:37:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27962 for ; Thu, 20 Mar 2003 01:37:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K6stq16498 for rpsec-archive@odin.ietf.org; Thu, 20 Mar 2003 01:54:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K6seO16492 for ; Thu, 20 Mar 2003 01:54:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27909 for ; Thu, 20 Mar 2003 01:35:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K6qKO16404; Thu, 20 Mar 2003 01:52:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K6owO16356 for ; Thu, 20 Mar 2003 01:50:58 -0500 Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27784 for ; Thu, 20 Mar 2003 01:32:14 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h2K6Y6s05958; Thu, 20 Mar 2003 01:34:06 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Thu, 20 Mar 2003 01:34:06 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Russ White cc: Stephen Kent , Yi Yang , Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? 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-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, 19 Mar 2003, Russ White wrote: > On Tue, 18 Mar 2003, Stephen Kent wrote: > > > >You are right that we can't find a way to protect against this. > > >But can we say a threat doesn't exist because we can't find a > > >defense? > > > > The point is not that one does not have a defense for this, but that > > the behavior is indistinguishable from legitimate behavior, at least > > in some contexts. For example, maybe the ISP is not advertising the > > prefix because the subscriber failed to pay its bills :-). > > > > Steve > > So, from this discussion, and the discussion at the mic during the > meeting, it seems like underclaiming, by defintion, is _currently_ > defined as not advertising something you are authorized to advertise > for reasons of configuration or bugs. Is it possible to simply > redefine it, so we can seperate the specific threat of someone > killing off reachability by maliciously killing off an > advertisement, rather than simply bundling that sort of attack under > some other category? > > Is it useful to provide a classification for that sort of attack > through redefinition? > > Russ Right, like could we decompose things? I'm coming to understand, at last, what Sandy refers to as "correctness" issues. That being that a router correctly functions according to what it thinks to be the state. OTOH, it's not hard to concieve of an attack where a bogus update is injected into a router to cause it to withdraw a legitimate, ie. desired, advertisement. That example of underclaiming could likely be redefined as actually being something else. I can't think of another example right now. A bit sleepy. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 20 14:31:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01134 for ; Thu, 20 Mar 2003 14:31:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KJnSb18967 for rpsec-archive@odin.ietf.org; Thu, 20 Mar 2003 14:49:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJnRO18964 for ; Thu, 20 Mar 2003 14:49:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01112 for ; Thu, 20 Mar 2003 14:30:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJmVO18858; Thu, 20 Mar 2003 14:48:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJlSO18775 for ; Thu, 20 Mar 2003 14:47:28 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00980 for ; Thu, 20 Mar 2003 14:28:58 -0500 (EST) Received: from yiya-u10.cisco.com (yiya-u10.cisco.com [64.102.48.79]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2KJV1Hp004089; Thu, 20 Mar 2003 11:31:01 -0800 (PST) Received: from localhost (yiya@localhost) by yiya-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA04676; Thu, 20 Mar 2003 14:31:01 -0500 (EST) X-Authentication-Warning: yiya-u10.cisco.com: yiya owned process doing -bs Date: Thu, 20 Mar 2003 14:31:00 -0500 (EST) From: Yi Yang To: Stephen Kent cc: rpsec@ietf.org Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources In-Reply-To: Message-ID: References: <200303142155.h2ELtHH23914@raven.gw.tislabs.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: , Steve, > >How about this way: Use MAC as a proof of authorization and use private > >key to sign this MAC to prevent masquerading? Of course, we don't have to > >use MAC for authorization. The administrator can assign a private/public > >key to a group as authorization, so the routers in the group can share the > >same key for authorization, while each member use its individual key for > >identification. > > The words you use above do not match normal security terminology use. Thank you for correcting me. Need to read RFC2828 again and use words more carefully.:-) > >Back to the original question: Should we to distinguish unauthorized > >routers/masquerading routers? I think we should.:-) > > Yes, to the extent that we first authenticate a router and then we > separately decide what the router is authorized to do. I agree.:-) Yi _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 20 14:37:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01354 for ; Thu, 20 Mar 2003 14:37:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KJt4J19266 for rpsec-archive@odin.ietf.org; Thu, 20 Mar 2003 14:55:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJt4O19263 for ; Thu, 20 Mar 2003 14:55:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01341 for ; Thu, 20 Mar 2003 14:36:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJsCO19231; Thu, 20 Mar 2003 14:54:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJrJO19168 for ; Thu, 20 Mar 2003 14:53:19 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01286 for ; Thu, 20 Mar 2003 14:34:49 -0500 (EST) Received: from yiya-u10.cisco.com (yiya-u10.cisco.com [64.102.48.79]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2KJatHp010909; Thu, 20 Mar 2003 11:36:56 -0800 (PST) Received: from localhost (yiya@localhost) by yiya-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA04680; Thu, 20 Mar 2003 14:36:55 -0500 (EST) X-Authentication-Warning: yiya-u10.cisco.com: yiya owned process doing -bs Date: Thu, 20 Mar 2003 14:36:55 -0500 (EST) From: Yi Yang To: Stephen Kent cc: rpsec@ietf.org Subject: Re: [RPSEC] Topic 2: Section 4.5 Underclaiming - is this a legitimate threat? In-Reply-To: Message-ID: References: <200303142211.h2EMBpL25904@raven.gw.tislabs.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: , Steve, > >> I don't think of the customer's failure to announce his own address as > >> a threat. It certainly doesn't hurt anyone but the customer. And I regard > >> anything that a router says about its own state, the data that it is > >> exclusively knowledgeable about, as its own exclusive authority. So > >> whatever it says is authentic. > > > >Based on this, the overclaiming should not be a threat either. > > How do you justify this statement? not choosing to advertise a prefix > might be justified by a local policy decision. there are two cases not advertising a prefix: 1. Legetimatekly not adverting, which can be justified by contract/local policy 2. Illegetimately, which might be caused by subverted router or otehr reasons. As you mentioned, right now, the difficulty is routing systems have no ways to distinguish these two cases, but, IMHO, this doesn't justify that the case 2 is not a threat. Yi > Advertising what you > have not been authorized to advertise is clearly a security problem > that cannot be justified by local policy in the normal meaning of the > term. > > > > Suppose a BGP peer is mis-configured and doesn't accept connections from > >> its legitimate peer? I don't consider that an attack. A failure, sure, > >> but not an attack. > >> > >> And to reiterate: can you imagine that the routing protocol would have > >> any chance in the world of distinguishing a legitimate case of hiding > >> from an illegitimate case? In your example, is there any way the > >> routing protocol at the customer could protect itself from that > >> mis-configuration? > > > >You are right that we can't find a way to protect against this. But can we > >say a threat doesn't exist because we can't find a defense? > > The point is not that one does not have a defense for this, but that > the behavior is indistinguishable from legitimate behavior, at least > in some contexts. For example, maybe the ISP is not advertising the > prefix because the subscriber failed to pay its bills :-). > > Steve > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Sat Mar 22 23:32:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12695 for ; Sat, 22 Mar 2003 23:32:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2N4pZ828896 for rpsec-archive@odin.ietf.org; Sat, 22 Mar 2003 23:51:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N4pYO28893 for ; Sat, 22 Mar 2003 23:51:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12680 for ; Sat, 22 Mar 2003 23:31:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N4oVO28871; Sat, 22 Mar 2003 23:50:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2N4nvO28835 for ; Sat, 22 Mar 2003 23:49:57 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12661 for ; Sat, 22 Mar 2003 23:30:18 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 22 Mar 2003 20:32:35 -0800 Received: from 213.212.207.48 by sea2fd.sea2.hotmail.msn.com with HTTP; Sun, 23 Mar 2003 04:32:34 GMT X-Originating-IP: [213.212.207.48] X-Originating-Email: [maa1074@hotmail.com] From: "Mohammad Awad" To: RPSEC@ietf.org Date: Sun, 23 Mar 2003 06:32:34 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2003 04:32:35.0118 (UTC) FILETIME=[3A09F4E0:01C2F0F5] Subject: [RPSEC] IP spoofing threat 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: , Hi all, Regaring the IP spoofing threat, 1- If an attacker has chosen to send packets with a forged source IP address (e.g. 207.1.1.1), which genuinely belongs to another existing host (not among the attacker's subnet), is he then able to perpetrate any spoofing attack to the routers in order to be able catch back the replies that would of course be targeted to the legitimate host of the address (207.1.1.1)? 2- If Answer#1 is yes, how likely could such an attack happen taking into consideration the level of security already implemented nowadays in the intermediate routers? 3- Is there any reported incidents at CERT or any other publisher's telling the stories about similar attacks? thank you all, in advance. Moh. Awad _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 25 10:50:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19042 for ; Tue, 25 Mar 2003 10:50:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PGAYc22258 for rpsec-archive@odin.ietf.org; Tue, 25 Mar 2003 11:10:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGAYO22255 for ; Tue, 25 Mar 2003 11:10:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19024 for ; Tue, 25 Mar 2003 10:49:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PG9QO22206; Tue, 25 Mar 2003 11:09:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PG8PO22143 for ; Tue, 25 Mar 2003 11:08:25 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18963 for ; Tue, 25 Mar 2003 10:47:33 -0500 (EST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2PFnl62024840; Tue, 25 Mar 2003 10:49:50 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Tue, 25 Mar 2003 10:48:04 -0500 To: "Mohammad Awad" From: Stephen Kent Subject: Re: [RPSEC] IP spoofing threat 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 6:32 AM +0200 3/23/03, Mohammad Awad wrote: >Hi all, >Regaring the IP spoofing threat, >1- If an attacker has chosen to send packets with a forged source IP >address (e.g. 207.1.1.1), which genuinely belongs to another >existing host (not among the attacker's subnet), is he then able to >perpetrate any spoofing attack to the routers in order to be able >catch back the replies that would of course be targeted to the >legitimate host of the address (207.1.1.1)? >2- If Answer#1 is yes, how likely could such an attack happen taking >into consideration the level of security already implemented >nowadays in the intermediate routers? we ought not rely on the correct operation of other routers to protect us, i.e., we ought to be able to deal with Byzantine attacks. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Mar 25 16:27:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04443 for ; Tue, 25 Mar 2003 16:27:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PLlu617827 for rpsec-archive@odin.ietf.org; Tue, 25 Mar 2003 16:47:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PLluO17824 for ; Tue, 25 Mar 2003 16:47:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04407 for ; Tue, 25 Mar 2003 16:26:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PLkGO17744; Tue, 25 Mar 2003 16:46:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PLjHO17699 for ; Tue, 25 Mar 2003 16:45:17 -0500 Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04261 for ; Tue, 25 Mar 2003 16:24:16 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h2PLQai11389 for ; Tue, 25 Mar 2003 16:26:36 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Tue, 25 Mar 2003 16:26:35 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Consensus and Draft Minutes from SF 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: , Hi folks, We've got the minutes put together from SF. There were a few people who are listed as "??" in the conversational part because the takers didn't catch their names. If anyone can fill in those blanks (or has other corrections) please pipe up within the next couple of days. Also somewhat buried in there is the fact that we had a consensus call for accepting draft-beard-rpsec-routing-threats-01.txt (the merged threats doc) as a WG document per our charter to be developed in fulfillment of our first milestone (those need updating). The people in the room in SF voted overwhelmingly to accept the doc as a WG item. I don't recall any opposition, but perhaps there were a few hands. Speak up now if you disagree with this action. Thanks, Tony ---- Routing Protocols Security Meeting Draft Minutes IETF 56, 18 March 2003 0900-1130 PST Co-Chairs: Tony Tauber, Russ White Agenda ------ Tony Tauber presenting Agenda Bashing no comments Merged Threat Doc ------ ------ ------ draft-beard-rpsec-routing-threats-01.txt Sandy Murphy presenting Unauthorized Vs Masquerading Attackers Steve Kent: Should we distinguish unauthorized vs masqerading attackers? Gregory Lebovitz: Distinguishing between the two makes the point that packet filtering is not enough Sandy Murphy: Any security mechanism that would prevent anyone from masquerading would also prevent anyone who is not authorized. Gregory Lebovitz: Keeping them separate makes people think about solving both issues. Packet Filtering Sandy Murphy: We don't want to imply that packet filtering will "solve" the problem Sean Convery: Saying packet filtering is useless is against attacks completely ignores the way security is used today (RFC2327). Sandy Murphy: I don't think it adds value, although it is common use. It's not going to save you from anyone who knows how to get around them Sean Convery: iBGP using packet filtering prevents cannot be circumvented unless the router is compromised. Steve Kent: We haven't defined what a threat is: packet filtering works as long as routers aren't compromised. We can't decide if packet filtering prevents attacks unless we agree on what a threat is. Sandy Murphy: Parts of the original threat document that expands on this didn't make it into the merge; maybe we should expand this part. Steve Kent: We don't have any concept of what assurance is. No mechanism is secure in and of itself, you have to know the context. Not 100% doesn't mean it's not good, we need an agreement on threats to agree on whether something is good. Sean Convery: Security is incremental, you can't provide 100% assurance. Steve Bellovin: Packet filtering is one technique among many which can be useful. It can keep out a nontrivial amount of bad stuff. If the filters are on all perimeters, and no internal compromises, it is good. Bob Hinden: This argument is typical of the real world who think that address filtering does something with security, while those in security don't think it does. Packet filtering has some value, but it's not what security people would call security. It's a tool that people understand and it exists today. Steve Albant: Ingress filtering is a good technology used badly. If the filtering is implemented correctly and there is no subvertion inside, it's a good idea. Sandy Murphy: Some routing protocols (wireless) have no concept of a list of peers. The context matters. Underclaiming Steve Kent: Underclaiming is not necessarily a problem; you may not be required to advertise stuff that you own. We have to be careful about this. Sandy Murphy: I don't like to claim this as an attack Tony Tauber: Underclaiming could be a problem. If you have load sharing, and you force all the traffic onto one link, you have broken the network. Sandy Murphy: There are normal situations that one of the home site has to stop advertising. There's no way to figure out it's intentional or unintentional? It's rather a correctness issue than security issue. Sandy Murphy: Underclaiming is the router doesn't adve what it's supposed to do. Russ White: One business hires a hacker to block advertisement of another business' web site; this is an attack that we should worry about. Sandy Murphy: This is not underclaiming. This is a falsification attack. There's no way to protect against the router stating it's link is down wrongly Geoff Houston: That's threat vs standard operating practice? Insert peers AS may be valid to indicate that common link is not to be used. Underclaiming may also have valid applications: standard operating practice. The issue is to determine intent. Transport Layer Steve Kent: Since the RP's choose the transport they will use, there's reason to include them in the in threat model; protocol designers need to be aware of issues in the transport they use. Sandy Murphy: These are important, but how do we handle them? Steve Kent: Put it in a section that talks about resource consumption. Different security methods can exhaust resources. How can we get rid of things that I don't want as fast as possible. Alex Zinin (as a WG member): Even though something may not be detectable at the routing level, doesn't mean they shouldn't be included. We should include them, and then analyse what can be done about it. Sandy Murphy: If the document pursued a functional breakdown, this would have been more obvious/more places to put it. I'm reluctant to include all threats to the routing system, since that's a huge area. ??: Part of the design of OLSR's design that dropping packets will break the protocol. Should this be included as a threat? Sandy Murphy: How should we handle this? BGP routers are under no obligation to accept a session, but OSPF is. It needs to be addressed somehow, but we don't know how. Sean Convery: We could provide pointers to outside doc's, but we shouldn't ignore the system level threats. The context is missing. More conversation about the routing system Threat consequences in this draft are focused on the rp, not on the routing system. Other Comments Steve Kent: Point out to people what real consequences are of an attack. Some people talk about DOS, but that is only one option. You could try to cause traffic to pass by a point where it can be tapped. Steve Kent: The originator is not the only important part of the route, other modifications may also alter routing. This isn't not just BGP. Steve Kent: Our goal is to try and prevent localalized failures from breaking the system. Sandy Murphy: How many bad routers do we want to protect yourself against? Jeff Haas: Is adding in as' that are not in the path a falsification attack? Sandy Murphy: This is a change in the path that isn't authorized, so this is a falsification attack. Steve Kent: Correct Operation vs What are the Symantics of the RP? Security is very closely aligned with correct operation. We could go far towards security by simply making certain the RP is operating correctly. Some protocols have symantics which are underspecified for local flexibility. This local flexibility makes security impossible ----- Consensus call: Should this doc be a WG doc? (Charter calls for a threats analysis doc. Is this the one we should work on?) Sense of the room is overwhelmingly "yes". No objections. ----- Requirements Doc ------ ------ ------ Danny McPherson presenting Top Down Vs Bottom Up Lots of discussion on whether this was a top down analysis or a bottom up analysis Tony Tauber: We should redefine the terms; it's actually protocol vs attack analysis. Protocol specific discussion ------ ------ ------ Tony Tauber: specific doc is still in our scope. we need to focus on generic stuff first. Alex (hat on): Discussion w/ADs and WG chairs are on-going. We do recognize that rpsec is where the clue (routing + security) is. Encap Draft ------ ------ draft-zinin-rtg-dos-00.txt Alex Zinin presenting Joel Halpern: You have this almost completely wrong; there has been a bit discussion in the routing protocols on how to encap the protocols. IS-IS uses a seperate layer 2 encap, while OSPF when with IP encap. Buffer overflows can only be fixed by the implementations. For an operator, you can deploy IP based protocols with a single filter without new encaps. Creating a new encap doesn't help anything. How does this address BGP? Alex Zinin: BGP is addressed. Most filtering techniques require hardware support. John Ionnadis: Are you moving the data plane to an out of band "network?" Alex Zinin: No, RP follows the same links as user data. The encap is changed, to seperate the traffic. John Ionnadis: I meant that below the network layer you're distinguishing between user data and routing data. ??: I don't know that I believe that RP's need to run at line rate Alex Zinin: The assumption is not that the RP's need to run at line rate, you need to run the security checks at line rate, because they can be attacked at line rate. Steve Kent: Remove the word trusted from the draft; it's not what you're trying to do. Subverting a router destroys the trust. On a point to point basis, you'd like a way to demux the traffic efficiently so you can discard the traffic at a high rate to kill certain attacks. The problem arises is when the traffic comes from a not directly connected (remote) station, and try to propagate it. Alex Zinin: The draft addresses this. Steve Kent: How do you handle this? Alex Zinin: The tag isn't carried up the stack. Packets which are already encap'd in the special encap, it is encap'd on the outbound side. Steve Kent: It does change the forwarding plane. You shouldn't compare this to MD5. Alex Zinin: No, it's changes the encapsulation. Steve Kent: The infrastructure has to be there to keep people in the group, etc. Alex Zinin: Yes, but that's low overhead. Peter Lothberg: This is trying to solve the same problem as all isolation problems are trying to solve. I want to build a vpn for my routing traffic. It adds a lot of complexity. It's better to solve the problem on the router. Alex Zinin: This is a generic mechanism which could be used for anything Bob Hinden: I don't see what the difference is between doing the recognition in the layer 2 bits vs in the layer 3 bits. Alex Zinin: If you change something at L3, you have to filter those packets on the entire perimeter of the network. L2 or MPLS label can be checked before some other authentication is done. Bob Hinden: What if there are forged layer 2 packets? Alex Zinin: They won't be forwarded. ??: Multicast not addressed and won't help at all. Alex Zinin: I'm not trying to solve all the problems. Multicast has a link between the data path and the control plane....that may need to be changed. ??: It's the same box that's doing this encap. Why doesn't just putting the traffic on a separate queue solve this? Alex Zinin: Then the attacker will just send you a lot of packets of the right layer 3 type. Routers will not forward packets that are not encap'd in the correct format, so the filtering at the edge is automatic. John Ionnadis: What we are acheiving is not to use forwarding that belong to these special classes. All these things, however stay on the link and forwarding them because they they are regenerated. Doesn't the TTL Hack solve this problem, as well? Alex Zinin: iBGP requires something more generic than BTSH, but this could work with BTSH for eBGP. There are things that are required to be propagated, SSH, targeted LDP, etc. It looks like you are suggestion to use the TTL hack for these, as well? John Ionnadis: Yep. Alex Zinin: Some things may be secured this way, but not all. Something more generic should be used. Ross Callon: This is semantically equivalent to packet filters. The problem with that is the source address can be spoofed, but it might be a good ides to filter on source address, anyway. Alex Zinin: The problem is that most equipment can't do this at line rate. This is essentially the same as address spoof filtering. Lixia Zhang: Spoofing an mpls packet is not allowed today, since mpls packets are not allowed into the network. Lixia Zhang: I don't understand this reaction. Alex Zinin: It's a crazy idea. Lixia Zhang: Yes, it is. We need mechanisms to protect the routers. The question is when. We should have multiple layers of protection, it won't hurt. Alex Zinin: Yes, we should. We can solve this other ways, but how long will this take to be able to do this. Steve Kent: The anology of how many layers in skin doesn't work. Each layer comes with more overhead management. Sue Hares: What about circular loop with mps reliant on routing, and routing is reliant on mpls? Alex Zinin: Because this is link local hop by hop, and there is no mpls tag distribution or multihop route calculation, there is no circular dependancy. Lack of Classification Ability Considered Harmful ------ ------ ------ ------ ------ ------ ------ Vijay Gill presenting (added at last minute to try and illuminate the problem of DoS attacks against router resources) Steve Kent: Your characterization is a subset of the problem that Alex is talking about. You're looking for a way to tag packets saying this is "routing traffic" Vijay Gill: I'm trying to describe the problem. Steve Kent: You don't have a multihop problem, though? (From several people in the room): iBGP. Alex Zinin: The problem is the same, but Vijay is only concerned about routing, not other control traffic. Steve Kent: Why is MD5 in this discussion? Vijay Gill: Because MD5 does not address the problem. MD5 will not prevent the router's cpu from inundating the router with processing. Doesn't prvent DOS attacks against the router. Steve Kent: The example of MD5 reduces the scope of the problem, but doesn't define the problem. Vijay Gill: The problem is overruning the router. Steve Kent: If the problem was narrower, then we can work on it. Vijay Gill: That is a subset of the problem. ??: You want a zero cost way to tell this is from a neighbor that I care about. You cannot go to the next step without stating why this is a problem Vijay Gill: I'm not supporting an approach. ??: IPv6 allows an interface to have an arbitrary number of addresses. You could have a set of addresses that show up in traceroute, but it doesn't ever accept any traffic on. Alex Zinin: You could also use unroutable addresses. General points to consider ------ ------ Tony Tauber presenting (briefly) See IAB sec drafts: draft-iab-sec-cons- draft-iab-secmech- The latter is likely of less usefulness to the particular case of routing protocols. Some things fall outside protocols but are still of security interest: good operation practice, implementation considerations. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Mar 26 14:02:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07548 for ; Wed, 26 Mar 2003 14:02:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QJNAr23962 for rpsec-archive@odin.ietf.org; Wed, 26 Mar 2003 14:23:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJNAO23959 for ; Wed, 26 Mar 2003 14:23:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07537 for ; Wed, 26 Mar 2003 14:01:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJMIO23871; Wed, 26 Mar 2003 14:22:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QJKGO23763 for ; Wed, 26 Mar 2003 14:20:16 -0500 Received: from BAY0-HMR13.adinternal.hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07372 for ; Wed, 26 Mar 2003 13:58:50 -0500 (EST) Received: from hotmail.com ([207.68.165.33]) by BAY0-HMR13.adinternal.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 26 Mar 2003 11:01:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 26 Mar 2003 11:01:10 -0800 Received: from 217.29.140.15 by sea2fd.sea2.hotmail.msn.com with HTTP; Wed, 26 Mar 2003 19:01:10 GMT X-Originating-IP: [217.29.140.15] X-Originating-Email: [maa1074@hotmail.com] From: "Mohammad Awad" To: RPSEC@ietf.org Subject: Re: [RPSEC] IP spoofing threat Date: Wed, 26 Mar 2003 21:01:10 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Mar 2003 19:01:10.0920 (UTC) FILETIME=[10B78080:01C2F3CA] 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: , Do you mean that the Byzantine attack is the one in which those routers to be forged are frauded, and that this attach is much more likely? >From: Stephen Kent >To: "Mohammad Awad" >CC: RPSEC@ietf.org >Subject: Re: [RPSEC] IP spoofing threat >Date: Tue, 25 Mar 2003 10:48:04 -0500 > >At 6:32 AM +0200 3/23/03, Mohammad Awad wrote: >>Hi all, >>Regaring the IP spoofing threat, >>1- If an attacker has chosen to send packets with a forged source IP >>address (e.g. 207.1.1.1), which genuinely belongs to another existing host >>(not among the attacker's subnet), is he then able to perpetrate any >>spoofing attack to the routers in order to be able catch back the replies >>that would of course be targeted to the legitimate host of the address >>(207.1.1.1)? >>2- If Answer#1 is yes, how likely could such an attack happen taking into >>consideration the level of security already implemented nowadays in the >>intermediate routers? > >we ought not rely on the correct operation of other routers to protect us, >i.e., we ought to be able to deal with Byzantine attacks. > >Steve >_______________________________________________ >RPSEC mailing list >RPSEC@ietf.org >https://www1.ietf.org/mailman/listinfo/rpsec _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Mar 26 21:30:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28751 for ; Wed, 26 Mar 2003 21:30:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2R2q1K27007 for rpsec-archive@odin.ietf.org; Wed, 26 Mar 2003 21:52:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2q1O27004 for ; Wed, 26 Mar 2003 21:52:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28729 for ; Wed, 26 Mar 2003 21:30:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2pCO26959; Wed, 26 Mar 2003 21:51:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R2mhO26863 for ; Wed, 26 Mar 2003 21:48:43 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28687 for ; Wed, 26 Mar 2003 21:27:07 -0500 (EST) Received: from [10.4.58.234] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2R2TQ5w015267; Wed, 26 Mar 2003 21:29:27 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Wed, 26 Mar 2003 21:13:39 -0500 To: "Mohammad Awad" From: Stephen Kent Subject: Re: [RPSEC] IP spoofing threat 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: , >Do you mean that the Byzantine attack is the one in which those >routers to be forged are frauded, and that this attach is much more >likely? > The phrase "Byzantine attacks" refers, loosely, to attacks launched by authorized entities that are misbehaving. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 27 09:03:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29253 for ; Thu, 27 Mar 2003 09:03:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2REOSd19644 for rpsec-archive@odin.ietf.org; Thu, 27 Mar 2003 09:24:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2REOSO19641 for ; Thu, 27 Mar 2003 09:24:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29249 for ; Thu, 27 Mar 2003 09:02:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RENWO19547; Thu, 27 Mar 2003 09:23:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2REMiO19467 for ; Thu, 27 Mar 2003 09:22:44 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29183 for ; Thu, 27 Mar 2003 09:00:55 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 27 Mar 2003 06:03:13 -0800 Received: from 217.29.140.15 by sea2fd.sea2.hotmail.msn.com with HTTP; Thu, 27 Mar 2003 14:03:12 GMT X-Originating-IP: [217.29.140.15] X-Originating-Email: [maa1074@hotmail.com] From: "Mohammad Awad" To: kent@bbn.com Cc: RPSEC@ietf.org Subject: Re: [RPSEC] IP spoofing threat Date: Thu, 27 Mar 2003 16:03:12 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Mar 2003 14:03:13.0441 (UTC) FILETIME=[9B527110:01C2F469] 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: , Then could understand that only the authorized users are those who can launch attacks to the routers resulting in IP spoofing. And that the routers nowadays are well secured against the non-Bezantine attacks? Moh Awad >From: Stephen Kent >To: "Mohammad Awad" >CC: RPSEC@ietf.org >Subject: Re: [RPSEC] IP spoofing threat >Date: Wed, 26 Mar 2003 21:13:39 -0500 > >>Do you mean that the Byzantine attack is the one in which those routers to >>be forged are frauded, and that this attach is much more likely? >> > >The phrase "Byzantine attacks" refers, loosely, to attacks launched by >authorized entities that are misbehaving. > >Steve >_______________________________________________ >RPSEC mailing list >RPSEC@ietf.org >https://www1.ietf.org/mailman/listinfo/rpsec _________________________________________________________________ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 27 10:42:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04111 for ; Thu, 27 Mar 2003 10:42:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RG3Wf26719 for rpsec-archive@odin.ietf.org; Thu, 27 Mar 2003 11:03:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RG3VO26716 for ; Thu, 27 Mar 2003 11:03:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04098 for ; Thu, 27 Mar 2003 10:41:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RG2ZO26676; Thu, 27 Mar 2003 11:02:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RFuLO26320 for ; Thu, 27 Mar 2003 10:56:21 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03556 for ; Thu, 27 Mar 2003 10:34:29 -0500 (EST) Received: from [10.4.58.234] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2RFam60015385; Thu, 27 Mar 2003 10:36:50 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 27 Mar 2003 10:33:45 -0500 To: "Mohammad Awad" From: Stephen Kent Subject: Re: [RPSEC] IP spoofing threat 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 4:03 PM +0200 3/27/03, Mohammad Awad wrote: >Then could understand that only the authorized users are those who >can launch attacks to the routers resulting in IP spoofing. And that >the routers nowadays are well secured against the non-Bezantine >attacks? >Moh Awad > I think we still have terminology confusion here. If a packet carries an inaccurate source address, then it is spoofed, period. If we can distinguish between authorized and unauthorized entities (insiders vs. outsiders) then attacks by insiders are often referred to as Byzantine failures (attacks). Sending a packet with a spoofed address claiming to be that of an insider, is still a spoofing attack, not a Byzantine attack. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Mar 27 11:13:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05398 for ; Thu, 27 Mar 2003 11:13:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RGYuW29012 for rpsec-archive@odin.ietf.org; Thu, 27 Mar 2003 11:34:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGYuO29009 for ; Thu, 27 Mar 2003 11:34:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05371 for ; Thu, 27 Mar 2003 11:13:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGXLO28886; Thu, 27 Mar 2003 11:33:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGIYO28148 for ; Thu, 27 Mar 2003 11:18:34 -0500 Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04739 for ; Thu, 27 Mar 2003 10:56:43 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h2RFwjB13334; Thu, 27 Mar 2003 10:58:45 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Thu, 27 Mar 2003 10:58:44 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Mohammad Awad cc: kent@bbn.com, Subject: Re: [RPSEC] IP spoofing threat 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-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: , Mohammed, let me try and re-construct this thread a little. Hopefully, I'll add some clarity: At first you wrote: ++> Hi all, ++> Regaring the IP spoofing threat, ++> ++> 1- If an attacker has chosen to send packets with a forged source ++> IP address (e.g. 207.1.1.1), which genuinely belongs to another ++> existing host (not among the attacker's subnet), is he then able ++> to perpetrate any spoofing attack to the routers in order to be ++> able catch back the replies that would of course be targeted to ++> the legitimate host of the address (207.1.1.1)? What you seem to be asking is "Can routing be subverted so that an attacker who spoofs his source address is able to receive the reply traffic from the victim intended for the host whose identity he is assuming?" I believe the answer to this question is "yes, through a variety of tactics some which could involve sending spoofed packets to the router (eg. bogus update) or which could involve injecting an inappropriate routing update from a legitimate source (eg. breaking into an ISP's router and reconfiguring it or inducing the ISP staff to do the same)." ++> 2- If Answer#1 is yes, how likely could such an attack happen ++> taking into consideration the level of security already ++> implemented nowadays in the intermediate routers? The answer to the question of "How likely...?" is pretty much impossible to quantify, though it's generally accepted that a determined attacker could perpetrate such an attack successfully. ++> 3- Is there any reported incidents at CERT or any other ++> publisher's telling the stories about similar attacks? Good question, I don't know, specifically. If you do such a search, feel free to summarize your findings to the list. ++> thank you all, in advance. ++> Moh. Awad On to the exchange with Steve, below: On Thu, 27 Mar 2003, Mohammad Awad wrote: > >From: Stephen Kent > > > > > > we ought not rely on the correct operation of other routers to > > > > protect us, i.e., we ought to be able to deal with Byzantine > > > > attacks. > > > Do you mean that the Byzantine attack is the one in which those > > > routers to be forged are frauded, and that this attach is much > > > more likely? > > > > The phrase "Byzantine attacks" refers, loosely, to attacks > > launched by authorized entities that are misbehaving. > > > >Steve Steve's asserting that a solution to this problem, though not part of your question, would protect against either of the approaches I cited above (data insertion or system mis-configuration, either accidental or intentional). > Then could understand that only the authorized users are those who > can launch attacks to the routers resulting in IP spoofing. This sentence doesn't really parse in English. IP spoofing is not generally understood to be a result of an attack but perhaps a means to execute an attack. It's easy to conceive of two ways that IP spoofing might be involved given the discussion thus far: - Attacker sends a spoofed packet to the victim to induce some desired result on that victim. - Attacker sends a spoofed packet to one or more router to induce some desired result such as diverting traffic from its intended path or simply interrupting it. The two might be combined together so that an attacker can receive the reply packets addressed to the host whose identity he is assuming which is what I thought you were describing in your first message above. > And that the routers nowadays are well secured against the > non-Bezantine attacks? > > Moh Awad Again, hard to quantify and quite variable. Moreover, the router design is only one part of the picture. Also to consider is the protocol design (can the design of it be exploited to do the "wrong" thing) as well as the operator practice (do they use the available or recommended features within the routers and/or protocols?) Hope this clarifies the answers to your questions and Steve's somewhat terse replies. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec