From mailman-owner@ietf.org Wed May 1 07:04:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18788 for ; Wed, 1 May 2002 07:04:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17987 for ; Wed, 1 May 2002 07:05:00 -0400 (EDT) Date: Wed, 1 May 2002 07:05:00 -0400 (EDT) Message-Id: <200205011105.HAA17987@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: rpsec-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rpsec-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rpsec-web-archive@ietf.org: List Password // URL ---- -------- rpsec@ietf.org lLFY https://www1.ietf.org/mailman/options/rpsec/rpsec-web-archive@ietf.org From rpsec-admin@ietf.org Thu May 2 18:21:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15812 for ; Thu, 2 May 2002 18:21:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12847; Thu, 2 May 2002 18:20:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12813 for ; Thu, 2 May 2002 18:20:08 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15663 for ; Thu, 2 May 2002 18:20:04 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA16317 for ; Thu, 2 May 2002 18:19:36 -0400 (EDT) Date: Thu, 2 May 2002 18:19:36 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Vulnerabilities docs... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Y'all: Our charter is going before the iesg in the next couple of weeks, and our first milestone already looms large.... Some initial draft(s) on vulnerabilities. We have several questions to answer here: -- Should we just await/expect individual submissions, and merge/work with them as needed/etc.? -- Should we form technical groups within this working group off the main alias to start these drafts? If so, should we have one team, or several? -- Do we like IGP/EGP splits in the docs, or should a given doc cover both? Or do we want to wait and see what's presented, and work from there? Part of the issue is, of course, we'd like to know what kind of agenda we're likely to have in Japan, since we would like to meet there and get this ball rolling. Thoughts? Any ideas on how to get the work rolling? Are there people already working on these sorts of docs? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Wed May 8 22:41:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01310 for ; Wed, 8 May 2002 22:41:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15502; Wed, 8 May 2002 22:36:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13422 for ; Wed, 8 May 2002 22:02:07 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29426 for ; Wed, 8 May 2002 22:01:57 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA05619 for ; Wed, 8 May 2002 22:01:36 -0400 (EDT) Date: Wed, 8 May 2002 22:00:37 -0400 (EDT) From: Russ White Reply-To: Russ White To: rp-sec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ReSent-Date: Wed, 8 May 2002 22:01:30 -0400 (EDT) ReSent-From: Russ White ReSent-To: rpsec@ietf.org ReSent-Subject: Questions.... ReSent-Message-ID: Subject: [RPSEC] Questions.... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Okay, this list is too quiet. So BOO! I think we need to get some discussion rolling here, and decide how we are going to get some drafts up and going. So, to that end, some questions: -- There appear to be several seperate problems in securing routing systems: -- Knowing for certain the the device/as advertising a given address actually should be advertising that address. For instance, you are receiving an advertisement for 10/8 from AS 65000. Should as 6500 really be advertising this destination as reachable? -- Knowing for certain that a device/as advertising a given address is who it claims to be. For instance, some device claiming to be part of as 65000 is advertising 10/8. Is it really part of that as? The second aspect is represented in a couple of ways--a "man in the middls" can grab your traffic (or misdirect it) by claiming as 65000 is behind them, or by stating that they are as 65000. Either one seems to work equally as well. Are these two seperate problems which need to be solved in two seperate ways? Are they applicable to all protocols? How much of a chunk of these two problems does securing the interrouter communications within a given protocol solve any of these problems? Should we address these as seperate problems in seperate documents, or should an entire system stand or fall as one unit? On another topic, should we have two seperate sets of drafts for requirements docs, one for interior protocols, and one for exterior protocols? Should we form technical subgroups to work on these? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 06:02:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14961 for ; Thu, 9 May 2002 06:02:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14872; Thu, 9 May 2002 06:02:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14842 for ; Thu, 9 May 2002 06:02:01 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14957 for ; Thu, 9 May 2002 06:01:51 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA13386 for ; Thu, 9 May 2002 06:01:31 -0400 (EDT) Date: Thu, 9 May 2002 06:01:31 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Quesitons.... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org So, I messed up the address when I sent this, and it still got delivered, somehow, but people seem to be having problems responding, so I'm sending it again to the right address this time. :-) Russ ----- Okay, this list is too quiet. So BOO! I think we need to get some discussion rolling here, and decide how we are going to get some drafts up and going. So, to that end, some questions: -- There appear to be several seperate problems in securing routing systems: -- Knowing for certain the the device/as advertising a given address actually should be advertising that address. For instance, you are receiving an advertisement for 10/8 from AS 65000. Should as 6500 really be advertising this destination as reachable? -- Knowing for certain that a device/as advertising a given address is who it claims to be. For instance, some device claiming to be part of as 65000 is advertising 10/8. Is it really part of that as? The second aspect is represented in a couple of ways--a "man in the middls" can grab your traffic (or misdirect it) by claiming as 65000 is behind them, or by stating that they are as 65000. Either one seems to work equally as well. Are these two seperate problems which need to be solved in two seperate ways? Are they applicable to all protocols? How much of a chunk of these two problems does securing the interrouter communications within a given protocol solve any of these problems? Should we address these as seperate problems in seperate documents, or should an entire system stand or fall as one unit? On another topic, should we have two seperate sets of drafts for requirements docs, one for interior protocols, and one for exterior protocols? Should we form technical subgroups to work on these? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 06:13:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15054 for ; Thu, 9 May 2002 06:13:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15181; Thu, 9 May 2002 06:13:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15149 for ; Thu, 9 May 2002 06:13:14 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15044 for ; Thu, 9 May 2002 06:13:06 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA13484; Thu, 9 May 2002 06:12:43 -0400 (EDT) Date: Thu, 9 May 2002 06:12:43 -0400 (EDT) From: Russ White Reply-To: Russ White To: "Joel M. Halpern" cc: rpsec@ietf.org Subject: Re: [RPSEC] Questions.... In-Reply-To: <5.1.0.14.0.20020508224732.01989410@mail.stevecrocker.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > There is a very big difference between claiming to be part of > a certain AS and claiming to be on the path to a certain AS. > In link state systems that distinction is intrinsic to the > system. Even with vector based systems, there are a range of > counter-measures that are different in dealing with the two > issues. I suggest that they be treated separately. So, you think we should treat the link state igp's different than the path vector bgp.... I would tend to agree that we are going to see a completely different set of problems, and thus should treat them in two seperate sets of drafts, probably. How well can we _really_ secure the concept of "being on a path to a given as?" I've been looking at this problem for some time--while it seems easy enough to verify where an advertisement has gone, it seems much more difficult to actually verify that the path shown is actually a valid and good path to the given destination. In fact, I think we wander into trying to get trust that needs to be based on a relationship out of simple electronic signatures, and I'm not certain it's going to work. The only apparent way to do this is to provide the ability to map the topology of a network, and verify the path against a known topology database maintained by a trusted thrid party. This seems to run counter to good network design (hiding information) and to good business tactics (hiding information). In fact, you could so far as to say that netowrks scale by hiding topology information, while propogating reachability information. Aggregation, as boundaries, area bounderies--they all serve this (implicit) purpose--to hide topology while exposing reachability. I'm not quite certain what the solution is to this apparent contradiction (?). :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 06:24:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15147 for ; Thu, 9 May 2002 06:24:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15457; Thu, 9 May 2002 06:21:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15416 for ; Thu, 9 May 2002 06:21:29 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15132 for ; Thu, 9 May 2002 06:21:21 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA13584; Thu, 9 May 2002 06:20:27 -0400 (EDT) Date: Thu, 9 May 2002 06:20:27 -0400 (EDT) From: Russ White Reply-To: Russ White To: "Jonnala, Nagi" cc: rpsec@ietf.org Subject: RE: [RPSEC] Questions.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org I don't know of any--I'm a novice at the security side of this.... :-) Maybe someone on list can recommand some good security reading for the routing geeks on the list (?). :-) Russ On Thu, 9 May 2002, Jonnala, Nagi wrote: > Hi Russ, > > This is Nagi work for a company called NetPlane in India. > > I have a lot of enthusiasm on Routing Protocols Security topic. > Would like to participate actively in the group. > > Could you please suggest some readings/drafts/books to get hold > of the subject thoroughly. > > Thanks a lot, > Nagi. > > > | -----Original Message----- > | From: Russ White [mailto:ruwhite@cisco.com] > | Sent: Thursday, May 09, 2002 7:32 AM > | To: rpsec@ietf.org > | Subject: [RPSEC] Questions.... > | > | > | > | Okay, this list is too quiet. So BOO! > | > | I think we need to get some discussion rolling here, and decide > | how we are going to get some drafts up and going. So, to that > | end, some questions: > | > | -- There appear to be several seperate problems in securing > | routing systems: > | > | -- Knowing for certain the the device/as advertising a given > | address actually should be advertising that address. For > | instance, you are receiving an advertisement for 10/8 from AS > | 65000. Should as 6500 really be advertising this destination as > | reachable? > | > | -- Knowing for certain that a device/as advertising a given > | address is who it claims to be. For instance, some device > | claiming to be part of as 65000 is advertising 10/8. > | Is it really > | part of that as? > | > | The second aspect is represented in a couple of ways--a "man in > | the middls" can grab your traffic (or misdirect it) by claiming > | as 65000 is behind them, or by stating that they are as > | 65000. Either one seems to work equally as well. > | > | Are these two seperate problems which need to be solved in two > | seperate ways? Are they applicable to all protocols? > | How much of > | a chunk of these two problems does securing the interrouter > | communications within a given protocol solve any of these > | problems? > | > | Should we address these as seperate problems in seperate > | documents, or should an entire system stand or fall as > | one unit? > | > | On another topic, should we have two seperate sets of > | drafts for > | requirements docs, one for interior protocols, and one for > | exterior protocols? Should we form technical subgroups > | to work on > | these? > | > | :-) > | > | Russ > | > | __________________________________ > | riw@cisco.com CCIE <>< Grace Alone > | > | > | > | > | > | > | > | _______________________________________________ > | RPSEC mailing list > | RPSEC@ietf.org > | https://www1.ietf.org/mailman/listinfo/rpsec > | > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 08:42:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17925 for ; Thu, 9 May 2002 08:42:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22541; Thu, 9 May 2002 08:40:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22506 for ; Thu, 9 May 2002 08:40:46 -0400 (EDT) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17805 for ; Thu, 9 May 2002 08:40:36 -0400 (EDT) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 08:36:28 -0400 Message-ID: From: "Manral, Vishwas" To: "'Russ White'" , rpsec@ietf.org Subject: RE: [RPSEC] Quesitons.... Date: Thu, 9 May 2002 08:40:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Hi Russ/group, >On another topic, should we have two seperate sets of drafts for >requirements docs, one for interior protocols, and one for >exterior protocols? Should we form technical subgroups to work on >these? I feel, the security threats would be different in case of interior protocols and exterior protocols, and that is why maybe two different requirements document would be necessary. I feel, the way to exploit the security of a protocol, is to twist the existing mechanisms already existing in the protocols i.e. flooding/Sequence number attacks in case of existing Link state protocols. As the mechanisms used for EGP and IGP's are different we could do with two such documents. However if the requirements came to be similar we could always merge the requirements in the end. Thanks, Vishwas -----Original Message----- From: Russ White [mailto:ruwhite@cisco.com] Sent: Thursday, May 09, 2002 3:32 PM To: rpsec@ietf.org Subject: [RPSEC] Quesitons.... So, I messed up the address when I sent this, and it still got delivered, somehow, but people seem to be having problems responding, so I'm sending it again to the right address this time. :-) Russ ----- Okay, this list is too quiet. So BOO! I think we need to get some discussion rolling here, and decide how we are going to get some drafts up and going. So, to that end, some questions: -- There appear to be several seperate problems in securing routing systems: -- Knowing for certain the the device/as advertising a given address actually should be advertising that address. For instance, you are receiving an advertisement for 10/8 from AS 65000. Should as 6500 really be advertising this destination as reachable? -- Knowing for certain that a device/as advertising a given address is who it claims to be. For instance, some device claiming to be part of as 65000 is advertising 10/8. Is it really part of that as? The second aspect is represented in a couple of ways--a "man in the middls" can grab your traffic (or misdirect it) by claiming as 65000 is behind them, or by stating that they are as 65000. Either one seems to work equally as well. Are these two seperate problems which need to be solved in two seperate ways? Are they applicable to all protocols? How much of a chunk of these two problems does securing the interrouter communications within a given protocol solve any of these problems? Should we address these as seperate problems in seperate documents, or should an entire system stand or fall as one unit? On another topic, should we have two seperate sets of drafts for requirements docs, one for interior protocols, and one for exterior protocols? Should we form technical subgroups to work on these? :-) Russ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 08:47:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18104 for ; Thu, 9 May 2002 08:47:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22975; Thu, 9 May 2002 08:45:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21208 for ; Thu, 9 May 2002 08:19:26 -0400 (EDT) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17049 for ; Thu, 9 May 2002 08:19:17 -0400 (EDT) Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2956678 for rpsec@ietf.org; Thu, 09 May 2002 08:19:25 -0400 Message-Id: <5.1.0.14.0.20020509081616.01b45c88@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 May 2002 08:17:19 -0400 To: rpsec@ietf.org From: "Joel M. Halpern" Subject: Re: [RPSEC] Quesitons.... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org There is a very big difference between claiming to be part of a certain AS and claiming to be on the path to a certain AS. In link state systems that distinction is intrinsic to the system. Even with vector based systems, there are a range of counter-measures that are different in dealing with the two issues. I suggest that they be treated separately. Yours, Joel M. Halpern At 06:01 AM 5/9/2002 -0400, Russ White wrote: >Okay, this list is too quiet. So BOO! > >I think we need to get some discussion rolling here, and decide >how we are going to get some drafts up and going. So, to that >end, some questions: > >-- There appear to be several seperate problems in securing >routing systems: > >-- Knowing for certain the the device/as advertising a given >address actually should be advertising that address. For >instance, you are receiving an advertisement for 10/8 from AS >65000. Should as 6500 really be advertising this destination as >reachable? > >-- Knowing for certain that a device/as advertising a given >address is who it claims to be. For instance, some device >claiming to be part of as 65000 is advertising 10/8. Is it really >part of that as? > >The second aspect is represented in a couple of ways--a "man in >the middls" can grab your traffic (or misdirect it) by claiming >as 65000 is behind them, or by stating that they are as >65000. Either one seems to work equally as well. > >Are these two seperate problems which need to be solved in two >seperate ways? Are they applicable to all protocols? How much of >a chunk of these two problems does securing the interrouter >communications within a given protocol solve any of these >problems? > >Should we address these as seperate problems in seperate >documents, or should an entire system stand or fall as one unit? > >On another topic, should we have two seperate sets of drafts for >requirements docs, one for interior protocols, and one for >exterior protocols? Should we form technical subgroups to work on >these? > >:-) > >Russ > > >__________________________________ >riw@cisco.com CCIE <>< Grace Alone > > > >_______________________________________________ >RPSEC mailing list >RPSEC@ietf.org >https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 08:51:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18283 for ; Thu, 9 May 2002 08:51:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22936; Thu, 9 May 2002 08:45:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21479 for ; Thu, 9 May 2002 08:26:00 -0400 (EDT) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17218 for ; Thu, 9 May 2002 08:25:51 -0400 (EDT) Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2956689 for rpsec@ietf.org; Thu, 09 May 2002 08:25:59 -0400 Message-Id: <5.1.0.14.0.20020509081830.01b20008@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 09 May 2002 08:23:51 -0400 To: rpsec@ietf.org From: "Joel M. Halpern" Subject: Re: [RPSEC] Questions.... In-Reply-To: References: <5.1.0.14.0.20020508224732.01989410@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Yes, I think there are significant threat differences affected by the style of protocol used. However, I was more focussing on the issue you got to in the later portion of your note. We can talk about whether someone has the right to advertise certain internal properties (has internal reachability to certain address blocks for example.) We can talk about whether some can speak on behalf of a given entity (speak for an AS, legitimately introduce an advertisement in either vector or map systems claiming to have been originated by a specific entity, ...) However, in path systems the amount we can practically accomplish with regard to manipulations of the path portion of the advertisement is moderately limitted, and tends to end up with things that are in the earlier set. Trying for example to ensure that an intermediate node in a path does not remove some elements of the path information (but retain the origination) or that the node correctly represents cumulative QoS quantities of the path as it sees them, require MUCH heavier weight mechanisms an specifically require very different mechanisms than the first set of issues. Yours, Joel M. Halpern At 06:12 AM 5/9/2002 -0400, Russ White wrote: > > There is a very big difference between claiming to be part of > > a certain AS and claiming to be on the path to a certain AS. > > In link state systems that distinction is intrinsic to the > > system. Even with vector based systems, there are a range of > > counter-measures that are different in dealing with the two > > issues. I suggest that they be treated separately. > >So, you think we should treat the link state igp's different than >the path vector bgp.... I would tend to agree that we are going >to see a completely different set of problems, and thus should >treat them in two seperate sets of drafts, probably. > >How well can we _really_ secure the concept of "being on a path >to a given as?" I've been looking at this problem for some >time--while it seems easy enough to verify where an advertisement >has gone, it seems much more difficult to actually verify that >the path shown is actually a valid and good path to the given >destination. In fact, I think we wander into trying to get >trust that needs to be based on a relationship out of simple >electronic signatures, and I'm not certain it's going to work. > >The only apparent way to do this is to provide the ability to map >the topology of a network, and verify the path against a known >topology database maintained by a trusted thrid party. This seems >to run counter to good network design (hiding information) and to >good business tactics (hiding information). In fact, you could so >far as to say that netowrks scale by hiding topology information, >while propogating reachability information. Aggregation, as >boundaries, area bounderies--they all serve this (implicit) >purpose--to hide topology while exposing reachability. > >I'm not quite certain what the solution is to this apparent >contradiction (?). > >:-) > >Russ > >__________________________________ >riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 10:11:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22850 for ; Thu, 9 May 2002 10:11:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28770; Thu, 9 May 2002 10:10:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28738 for ; Thu, 9 May 2002 10:10:36 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22767 for ; Thu, 9 May 2002 10:10:27 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id KAA00394; Thu, 9 May 2002 10:16:32 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma000360; Thu, 9 May 02 10:16:15 -0400 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g49EAHW06658; Thu, 9 May 2002 10:10:17 -0400 (EDT) Date: Thu, 9 May 2002 10:10:17 -0400 (EDT) Message-Id: <200205091410.g49EAHW06658@raven.gw.tislabs.com> To: riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... Cc: sandy@tislabs.com Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >> There is a very big difference between claiming to be part of >> a certain AS and claiming to be on the path to a certain AS. >> In link state systems that distinction is intrinsic to the >> system. Even with vector based systems, there are a range of >> counter-measures that are different in dealing with the two >> issues. I suggest that they be treated separately. > >So, you think we should treat the link state igp's different than >the path vector bgp.... I would tend to agree that we are going >to see a completely different set of problems, and thus should >treat them in two seperate sets of drafts, probably. I agree that link state and distance/path vector systems have very different security issues. Link state systems are vulnerable because of the flooding aspect of link state systems - you are communicating the same info everywhere but by relying on intermediate systems to serve as a reliable communication medium. So the intermediate systems have the opportunity to manipulate the flooded information to create any arbitrary topology. Coincidentally, this flooding of the same (unchanged) information everywhere makes protecting link state protocols simple: provide data source authentication protection for the information. Done. (Well, not "done" exactly, the devil is always in the details.) But even link state systems have some aspect of the "is this originator authorized to announce the routing information it is announcing". In OSPF, for example, you still have to have some way to prove the authorization for a router to announce that it is directly connected to a network N. You want to be sure that a router that is producing type 5 LSA's is truly an ASBR. Etc. Is the fact that the counter-measures would be different sufficient reason to provide different security requirements drafts? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 10:12:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22894 for ; Thu, 9 May 2002 10:12:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28883; Thu, 9 May 2002 10:11:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28845 for ; Thu, 9 May 2002 10:11:39 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22865 for ; Thu, 9 May 2002 10:11:29 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id KAA00469; Thu, 9 May 2002 10:17:35 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma000422; Thu, 9 May 02 10:17:17 -0400 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g49EBKF06693; Thu, 9 May 2002 10:11:20 -0400 (EDT) Date: Thu, 9 May 2002 10:11:20 -0400 (EDT) Message-Id: <200205091411.g49EBKF06693@raven.gw.tislabs.com> To: riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... Cc: sandy@tislabs.com Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org There are hints that some responders are equating the IGP/EGP characterization of routing protocols with the link/vector characterization. >So, you think we should treat the link state igp's different than >the path vector bgp.... >I feel, the way to exploit the security of a protocol, is to twist the >existing mechanisms already existing in the protocols i.e. flooding/Sequence >number attacks in case of existing Link state protocols. As the mechanisms >used for EGP and IGP's are different we could do with two such documents. I see no reason to suppose that IGP and EGP protocols have instrinsically different security requirements. (Furthermore, not all IGP's are link state (see RIP), not all EGP's are vector (see IDPR, RFC1479).) Now, the damage that might be done by subverting the IGP routing information vs subverting EGP routing information certainly has different Internet wide topological *scope*, no question. But the difference to me is the protocol behavior, not its field of use. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 10:14:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23033 for ; Thu, 9 May 2002 10:14:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29028; Thu, 9 May 2002 10:13:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28996 for ; Thu, 9 May 2002 10:13:41 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22992 for ; Thu, 9 May 2002 10:13:32 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id KAA00612; Thu, 9 May 2002 10:19:38 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma000600; Thu, 9 May 02 10:19:28 -0400 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g49EDVe07413; Thu, 9 May 2002 10:13:31 -0400 (EDT) Date: Thu, 9 May 2002 10:13:31 -0400 (EDT) Message-Id: <200205091413.g49EDVe07413@raven.gw.tislabs.com> To: riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... Cc: sandy@tislabs.com Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >How well can we _really_ secure the concept of "being on a path >to a given as?" I've been looking at this problem for some >time--while it seems easy enough to verify where an advertisement >has gone, it seems much more difficult to actually verify that >the path shown is actually a valid and good path to the given >destination. "Gone"? I would say you can verify where the advertisement has "come from" - is that what you meant? I don't know how one would verify where something had gone. The protocol could return acks, but that would only give you a lower bound on receivers. But I agree completely with the "much more difficult" part for vector sorts of protocols. And with Joel, who talked about "MUCH heavier weight mechanisms". Because each participant transmits the result of a computation on its input data, and what you want is some assurance that the computation is based on legitimate input. >The only apparent way to do this is to provide the ability to map >the topology of a network, and verify the path against a known >topology database maintained by a trusted thrid party. Two rhetorical questions: If the trusted third party has a known topology database, why do you need a routing protocol to transmit topology information around? Why not just download the trusted database? If you say you need a routing protocol to transmit the up/down status information, why transmit the topology information as well? I think part of the problem at the inter-domain level is that routing decisions are based not only on topology and status, but on business arrangements. So the the route may be exist and be up, but you and your peering partner haven't agreed yet to transit that network's traffic. (If this were not the case, the Smith/Garcia-Lunes-Aceves protections for BGP would be sufficient.) >In fact, you could so >far as to say that netowrks scale by hiding topology information, >while propogating reachability information. Aggregation, as >boundaries, area bounderies--they all serve this (implicit) >purpose--to hide topology while exposing reachability. But hiding information is exactly what makes the system vulnerable. "I've got a path to network N, just trust me" affects not only the receiver who believes it but everyplace that the receiver passes it on to. Peers trust their partners, but we're trying to protect the global structure. If that trust is misplaced, it's not just the trusting partner who suffers, it's the global structure. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 10:15:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23116 for ; Thu, 9 May 2002 10:15:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29108; Thu, 9 May 2002 10:14:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29071 for ; Thu, 9 May 2002 10:14:43 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23062 for ; Thu, 9 May 2002 10:14:33 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id KAA00642; Thu, 9 May 2002 10:20:39 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma000626; Thu, 9 May 02 10:20:29 -0400 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g49EEWe07487; Thu, 9 May 2002 10:14:32 -0400 (EDT) Date: Thu, 9 May 2002 10:14:32 -0400 (EDT) Message-Id: <200205091414.g49EEWe07487@raven.gw.tislabs.com> To: joel@stevecrocker.com, rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... Cc: sandy@tislabs.com Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Joel, you said: >There is a very big difference between claiming to be part of a certain AS >and claiming to be on the path to a certain AS. In link state systems that >distinction is intrinsic to the system. Even with vector based systems, >there are a range of counter-measures that are different in dealing with >the two issues. I suggest that they be treated separately. and >However, I was more focussing on the issue you got to in the later portion >of your note. We can talk about whether someone has the right to advertise >certain internal properties (has internal reachability to certain address >blocks for example.) We can talk about whether some can speak on behalf of >a given entity (speak for an AS, legitimately introduce an advertisement in >either vector or map systems claiming to have been originated by a specific >entity, ...) However, in path systems the amount we can practically >accomplish with regard to manipulations of the path portion of the >advertisement is moderately limitted, and tends to end up with things that >are in the earlier set. So you are suggesting a different way of dividing the problem: not by IGP/EGP and not by link/vector, but by the class of properties that we can easily protect? I'm not sure I see a neat way of characterizing the easy from the difficult properties. Are the easy problems the ones having to do with information the ISP is speaking for itself only (i.e., none of this "I heard from Joe" but the "I say for myself"). If so, what would you say about protocol mechanisms that Russ was talking about that aggregate information at some point - is that the "speaking for oneself" information that we would devise some way of protecting or not? Is that a "manipulation of the path portion of the advertisement" or not? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 12:23:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27981 for ; Thu, 9 May 2002 12:23:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07045; Thu, 9 May 2002 12:22:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07020 for ; Thu, 9 May 2002 12:22:33 -0400 (EDT) Received: from jersey.sghosh.org (bgp509372bgs.verona01.nj.comcast.net [68.38.16.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27945 for ; Thu, 9 May 2002 12:22:25 -0400 (EDT) Received: from localhost (sghosh@localhost) by jersey.sghosh.org (8.11.6/8.11.6) with ESMTP id g49GMW811163 for ; Thu, 9 May 2002 12:22:32 -0400 Date: Thu, 9 May 2002 12:22:31 -0400 (EDT) From: Subhendu Ghosh To: rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... In-Reply-To: <200205091414.g49EEWe07487@raven.gw.tislabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Just to throw another twist in the mix... I am working on methods to allow/announce reachability between a manet environment and a standard IGP. The potential for route flapping here is quite large. Security here is something I would like to achieve but am a bit ways off as yet. Would this be considered as part of the scope of this WG? -subhendu _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 16:52:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08538 for ; Thu, 9 May 2002 16:52:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22742; Thu, 9 May 2002 16:51:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22708 for ; Thu, 9 May 2002 16:51:17 -0400 (EDT) Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08486 for ; Thu, 9 May 2002 16:51:07 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 175usb-0001fD-00 for rpsec@ietf.org; Thu, 09 May 2002 13:51:13 -0700 Date: Thu, 9 May 2002 13:50:14 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <90152886874.20020509135014@psg.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Folks Some draft thoughts on this discussion... Assuming that the WG will start with threat description (according to the milestones), why don't we try to identify common subsystems in all routing protocols, e.g.: o Transport subsystem (mechanisms to send messages) o Neighbor state maintenance (how we find/drop nbrs, adjacency/session process) o Database maintenance (additional DBs used for topology and reachability info: LSDBs, RIBs, TIBs,etc.) o Routing state maintenance (how the routing/forwarding state is setup/removed) ... --then describe different categories and subcategories in each subsystem and then go ahead with description of threats specific to each type of subsystem. To give an example, let's take the transport subsystem. A description of it would probably follow an outline like this: 1. Transport Subsystem 1.1 Degree of connectivity -Point-to-point transport -Point-to-multipoint transport -Broadcast/multicast transport 1.2 Used layer -Link-layer transport -Network-layer transport -Transport-layer transport 1.3 Provided service -Connectionless unreliable (link-layer, raw ip, udp) -Connection-oriented reliable (tcp,...) -other (???) I guess we could associate a set of threats with each bullet above. What I like in this approach is that it will allow us to give a good coverage in a structured manner without becoming too protocol-specific. We'll also be able to start with a skeleton document, and go into deeper details as we progress. We can later use the same model for the requirements document. Thoughts? -- Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 17:11:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09358 for ; Thu, 9 May 2002 17:11:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24682; Thu, 9 May 2002 17:11:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24646 for ; Thu, 9 May 2002 17:11:14 -0400 (EDT) Received: from mesa.bbnplanet.com (mesa.bbnplanet.com [199.94.208.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09320 for ; Thu, 9 May 2002 17:11:03 -0400 (EDT) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id g49LBAK25706; Thu, 9 May 2002 17:11:10 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Thu, 9 May 2002 17:11:10 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Alex Zinin cc: rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... In-Reply-To: <90152886874.20020509135014@psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org On Thu, 9 May 2002, Alex Zinin wrote: > Folks > > Some draft thoughts on this discussion... > > Assuming that the WG will start with threat description > (according to the milestones), why don't we try to identify > common subsystems in all routing protocols, e.g.: > I guess we could associate a set of threats with each bullet > above. > > What I like in this approach is that it will allow us to give > a good coverage in a structured manner without becoming too > protocol-specific. We'll also be able to start with a skeleton > document, and go into deeper details as we progress. We can > later use the same model for the requirements document. > > Thoughts? I quite like it. It seems to me that when thinking about security it's often matter of classifying a given situation and then knowing what kinds of questions to ask about such a situation. This way protocol designers, implementors and users can ask "What about DoS?" "What about authorization?", etc. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 21:15:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17824 for ; Thu, 9 May 2002 21:15:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05837; Thu, 9 May 2002 21:07:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05805 for ; Thu, 9 May 2002 21:07:49 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17505 for ; Thu, 9 May 2002 21:07:38 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA10007; Thu, 9 May 2002 21:07:16 -0400 (EDT) Date: Thu, 9 May 2002 21:07:16 -0400 (EDT) From: Russ White Reply-To: Russ White To: sandy@tislabs.com cc: rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... In-Reply-To: <200205091411.g49EBKF06693@raven.gw.tislabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > But the difference to me is the protocol behavior, not its > field of use. I tend to agree with this--but I do think that distance vector and link state protocols are going to wind up with different requirements, and different ways of approaching/thinking about the problems.... I'm not convinced, of course, but I think that any unified requirements doc is actually going to end up being two requirements docs in one, and they will be easier to discuss seperately. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 21:19:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17919 for ; Thu, 9 May 2002 21:19:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06258; Thu, 9 May 2002 21:16:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06225 for ; Thu, 9 May 2002 21:16:22 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17867 for ; Thu, 9 May 2002 21:16:12 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA10229; Thu, 9 May 2002 21:15:45 -0400 (EDT) Date: Thu, 9 May 2002 21:15:45 -0400 (EDT) From: Russ White Reply-To: Russ White To: Subhendu Ghosh cc: rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org I think so... If it's routing related, and requirements/thinking phase, you should feel free to discuss it here. Unless Alex or Bill hit me over the head. :-) Russ On Thu, 9 May 2002, Subhendu Ghosh wrote: > Just to throw another twist in the mix... > > I am working on methods to allow/announce reachability > between a manet environment and a standard IGP. > The potential for route flapping here is quite large. > > > Security here is something I would like to achieve but am a bit ways off > as yet. Would this be considered as part of the scope of this WG? > > -subhendu > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 21:23:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18047 for ; Thu, 9 May 2002 21:23:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05994; Thu, 9 May 2002 21:14:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05962 for ; Thu, 9 May 2002 21:14:38 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17766 for ; Thu, 9 May 2002 21:14:28 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA10191; Thu, 9 May 2002 21:14:07 -0400 (EDT) Date: Thu, 9 May 2002 21:14:07 -0400 (EDT) From: Russ White Reply-To: Russ White To: sandy@tislabs.com cc: rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... In-Reply-To: <200205091413.g49EDVe07413@raven.gw.tislabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > >How well can we _really_ secure the concept of "being on a path > >to a given as?" I've been looking at this problem for some > >time--while it seems easy enough to verify where an advertisement > >has gone, it seems much more difficult to actually verify that > >the path shown is actually a valid and good path to the given > >destination. > > "Gone"? I would say you can verify where the advertisement has "come > from" - is that what you meant? Come from is correct. > But I agree completely with the "much more difficult" part > for vector sorts of protocols. And with Joel, who talked > about "MUCH heavier weight mechanisms". Because each > participant transmits the result of a computation on its > input data, and what you want is some assurance that the > computation is based on legitimate input. > >The only apparent way to do this is to provide the ability to map > >the topology of a network, and verify the path against a known > >topology database maintained by a trusted thrid party. > > Two rhetorical questions: > > If the trusted third party has a known topology database, why > do you need a routing protocol to transmit topology > information around? Why not just download the trusted > database? I'm not so certain this is rhetorical, actually. But we need to seperate topology from reachability--any topology of the as' would tell you what the network looks like, but it won't tell how to reach a given host within that network. The problem is to me that it's _precisely_ topology information that is to be hidden in order to provide scalability, and a lot of provider's aren't going to want topology information distributed--that involves knowing who they are connected to and where, pretty much, and it could be considered information which is subject to security issues of its own. > I think part of the problem at the inter-domain level is that > routing decisions are based not only on topology and status, > but on business arrangements. So the the route may be exist > and be up, but you and your peering partner haven't agreed > yet to transit that network's traffic. (If this were not the > case, the Smith/Garcia-Lunes-Aceves protections for BGP would > be sufficient.) Right. > >In fact, you could so > >far as to say that netowrks scale by hiding topology information, > >while propogating reachability information. Aggregation, as > >boundaries, area bounderies--they all serve this (implicit) > >purpose--to hide topology while exposing reachability. > > But hiding information is exactly what makes the system > vulnerable. "I've got a path to network N, just trust me" > affects not only the receiver who believes it but everyplace > that the receiver passes it on to. > > Peers trust their partners, but we're trying to protect the > global structure. If that trust is misplaced, it's not just > the trusting partner who suffers, it's the global structure. I suppose my question is: At what point do we have to trust the peering relationships, and at what point do we force information into the open to verify the topology? One key difference between igp's and egp's may just be that we have to work within the bounds of what's an acceptable level of information to reveal in terms of topology information within the egp world, while this is not a big deal in the igp world. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 9 21:28:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18190 for ; Thu, 9 May 2002 21:27:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06390; Thu, 9 May 2002 21:19:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06354 for ; Thu, 9 May 2002 21:19:03 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17916 for ; Thu, 9 May 2002 21:18:53 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA10327; Thu, 9 May 2002 21:18:25 -0400 (EDT) Date: Thu, 9 May 2002 21:18:25 -0400 (EDT) From: Russ White Reply-To: Russ White To: Tony Tauber cc: Alex Zinin , rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Agreed.... I would probably divide the routing system into reachability and topology aspects, since this is where they seem to naturally fall. BTW--someone said that reachability was intrinsic to topology in link state protocols, I think (?).... Actually, I think it's the opposite. A link state protocol can clearly give you a topology with no reachability (although it cannot give you reachability with no topology). IS-IS in IP mode with no prefixes to advertise. A distance-vector protocol can't give you topology without reachability, it seems to me. :-) Russ On Thu, 9 May 2002, Tony Tauber wrote: > On Thu, 9 May 2002, Alex Zinin wrote: > > > Folks > > > > Some draft thoughts on this discussion... > > > > Assuming that the WG will start with threat description > > (according to the milestones), why don't we try to identify > > common subsystems in all routing protocols, e.g.: > > > > > I guess we could associate a set of threats with each bullet > > above. > > > > What I like in this approach is that it will allow us to give > > a good coverage in a structured manner without becoming too > > protocol-specific. We'll also be able to start with a skeleton > > document, and go into deeper details as we progress. We can > > later use the same model for the requirements document. > > > > Thoughts? > > I quite like it. > It seems to me that when thinking about security it's often > matter of classifying a given situation and then knowing > what kinds of questions to ask about such a situation. > > This way protocol designers, implementors and users can > ask "What about DoS?" "What about authorization?", etc. > > Tony > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri May 10 03:33:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09818 for ; Fri, 10 May 2002 03:33:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00362; Fri, 10 May 2002 03:31:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00329 for ; Fri, 10 May 2002 03:31:35 -0400 (EDT) Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09806 for ; Fri, 10 May 2002 03:31:26 -0400 (EDT) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 1764sD-000AaM-00; Fri, 10 May 2002 00:31:29 -0700 Date: Fri, 10 May 2002 00:30:27 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <124191303738.20020510003027@psg.com> To: Russ White CC: Tony Tauber , rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Russ, > Agreed.... I would probably divide the routing system into > reachability and topology aspects, since this is where they seem > to naturally fall. Hmmm... I have a different model in mind, I guess: [Note the presence of the database subsystem.] The way I see it is routing/forwarding state is information you maintain to actually forward packets. Creation of this state can be: - Destination-presence driven (current unicast system) - Data traffic driven (MANET: AODV, DSR) - Membership driven (multicast) - [other examples] reachability and topological information is an example of a database (or databases) used to create destination-presence driven routing state. > BTW--someone said that reachability was intrinsic to topology in > link state protocols, I think (?).... Actually, I think it's the > opposite. A link state protocol can clearly give you a topology > with no reachability (although it cannot give you reachability > with no topology). IS-IS in IP mode with no prefixes to > advertise. You're right, of course. One could imagine OSPF routers announcing no reachability info as well. > A distance-vector protocol can't give you topology without > reachability, it seems to me. Not the ones we have at the moment. One could imagine a routing protocol announcing _locations_ of the routers using the DV (BF) rules and then distributing reachability info in a flooding-like fashion (no hop-by-hop metric increment). Route calculation would then be similar to external route calculation in link-state, but the SPT would already be precomputed by BF without having to run Dijkstra. Hope I'm not confusing much ;) Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri May 10 06:09:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11883 for ; Fri, 10 May 2002 06:09:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07274; Fri, 10 May 2002 06:08:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07240 for ; Fri, 10 May 2002 06:08:22 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11859 for ; Fri, 10 May 2002 06:08:12 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA18709; Fri, 10 May 2002 06:07:50 -0400 (EDT) Date: Fri, 10 May 2002 06:07:50 -0400 (EDT) From: Russ White Reply-To: Russ White To: Alex Zinin cc: Tony Tauber , rpsec@ietf.org Subject: Re: [RPSEC] Quesitons.... In-Reply-To: <124191303738.20020510003027@psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > > Agreed.... I would probably divide the routing system into > > reachability and topology aspects, since this is where they seem > > to naturally fall. > > Hmmm... I have a different model in mind, I guess: [Note the > presence of the database subsystem.] > > The way I see it is routing/forwarding state is information > you maintain to actually forward packets. Creation of > this state can be: > - Destination-presence driven (current unicast system) > - Data traffic driven (MANET: AODV, DSR) > - Membership driven (multicast) > - [other examples] > > reachability and topological information is an example of a > database (or databases) used to create destination-presence > driven routing state. Well, I was thinking in terms of what it is you're trying to secure.... You can try to "secure" the topology information (in some sense, though I'm not certain what that would be at the moment?), and you can secure the destination information--can you verify the source of this information, and is that source really the right place to send traffic towards this destination? But both of these fall into the current unicast structure--i'm not certain you can divide the multicast domain in such a way, nor MANET and such.... > > BTW--someone said that reachability was intrinsic to topology in > > link state protocols, I think (?).... Actually, I think it's the > > opposite. A link state protocol can clearly give you a topology > > with no reachability (although it cannot give you reachability > > with no topology). IS-IS in IP mode with no prefixes to > > advertise. > > You're right, of course. One could imagine OSPF routers > announcing no reachability info as well. > > > A distance-vector protocol can't give you topology without > > reachability, it seems to me. > > Not the ones we have at the moment. > > One could imagine a routing protocol announcing _locations_ > of the routers using the DV (BF) rules and then distributing > reachability info in a flooding-like fashion (no hop-by-hop > metric increment). Route calculation would then be similar > to external route calculation in link-state, but the SPT would > already be precomputed by BF without having to run Dijkstra. > Hope I'm not confusing much ;) Actually, some time ago the concept of bgp just advertising what as' different prefixes are attached to, then using some other method of actually mapping out the as'. If a distance vector system were used to map the as', then you would have such a system. In fact, security in bgp today could be broken into these pieces--is this as actually attached to the as that it claims to be, and is the as which is sourcing this information actually authorized to do so, and is the source really the as which claims to be sourcing it? Of course, the problem here is uncovering who is connected to whom, which I'm not certain is palatable to most ISPs, since it also reveals lots of interesting things, like who your customers are, and who all you are peering with. With a little creativity, you could use this information to map an isp's entire network, I think. And by tracking this sort of information on a historical scale, you could uncover business strategies, etc. I would not have a hard time believing that this would be a security risk in and of itself. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri May 10 17:14:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18168 for ; Fri, 10 May 2002 17:14:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14294; Fri, 10 May 2002 17:14:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14260 for ; Fri, 10 May 2002 17:14:09 -0400 (EDT) Received: from mail.reptiles.org (root@mail.reptiles.org [198.96.117.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18126 for ; Fri, 10 May 2002 17:13:59 -0400 (EDT) Received: from mail.reptiles.org([198.96.117.157]) (1816 bytes) by mail.reptiles.org via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Fri, 10 May 2002 17:13:57 -0400 (EDT) (Smail-3.2.0.114 2001-Aug-6 #10 built 2002-Jan-14) Date: Fri, 10 May 2002 17:13:57 -0400 (EDT) From: Gwendolynn ferch Elydyr To: sandy@tislabs.com cc: riw@cisco.com, Subject: Re: [RPSEC] Quesitons.... In-Reply-To: <200205091413.g49EDVe07413@raven.gw.tislabs.com> Message-ID: <20020510171312.X49349-100000@iguana.reptiles.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org On Thu, 9 May 2002 sandy@tislabs.com wrote: > Two rhetorical questions: > > If the trusted third party has a known topology database, why do you > need a routing protocol to transmit topology information around? Why > not just download the trusted database? > > If you say you need a routing protocol to transmit the up/down > status information, why transmit the topology information as well? > > I think part of the problem at the inter-domain level is that routing > decisions are based not only on topology and status, but on business > arrangements. So the the route may be exist and be up, but you and > your peering partner haven't agreed yet to transit that network's > traffic. (If this were not the case, the Smith/Garcia-Lunes-Aceves > protections for BGP would be sufficient.) Not to point out the obvious, but dynamic routing protocols are fun and useful - and imply that it's necessary to transmit both state and topology information. cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Mon May 13 02:00:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20453 for ; Mon, 13 May 2002 02:00:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02338; Mon, 13 May 2002 01:11:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02282 for ; Mon, 13 May 2002 01:11:12 -0400 (EDT) Received: from berkshire.research.att.com (H-135-207-4-78.research.att.com [135.207.4.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17617 for ; Mon, 13 May 2002 01:10:53 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 5F81F7B52; Sun, 12 May 2002 21:10:57 -0400 (EDT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Russ White Cc: "Jonnala, Nagi" , rpsec@ietf.org Subject: Re: [RPSEC] Questions.... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 May 2002 21:10:57 -0400 Message-Id: <20020513011057.5F81F7B52@berkshire.research.att.com> Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org In message , Rus s White writes: > >I don't know of any--I'm a novice at the security side of >this.... :-) Maybe someone on list can recommand some good >security reading for the routing geeks on the list (?). > Are you asking for general security or routing security? For the former, the mechanisms are the easy part; it's learning to think paranoid that's hard... For routing security, there are a number of sources. The oldest that I know of is Radia Perlman's dissertation: @phdthesis{perlman88, author = {Radia Perlman}, school = {M.I.T.}, year = 1988, title = {Network Layer Protocols with Byzantine Robustness} } I discussed some routing security issues a bit later: @article{iphole, author = {Steven M. Bellovin}, journal = {Computer Communications Review}, month = {April}, number = {2}, pages = {32--48}, title = {Security Problems in the {TCP/IP} Protocol Suite}, volume = {19}, year = {1989}, annote = {An early paper describing some security risks from the then-standard protocols in TCP/IP. Not all of the attacks have happened yet\ldots.}, url = "ftp://ftp.research.att.com/dist/internet\_security/ipext.ps.Z" } For some defenses, see RFC 2328, 2154, 2385. For BGP defenses, see @article{sbgp1, author = {Stephen Kent and Charles Lynn and Karen Seo}, title = {Secure Border Gateway Protocol {(Secure-BGP)}}, journal = {IEEE Journal on Selected Areas in Communications}, volume = 18, number = 4, month = {April}, year = 2000, pages = {582--592} } @inproceedings{sbgp2, author = {Stephen Kent and Charles Lynn and Joanne Mikkelson and Karen Seo}, title = {Secure Border Gateway Protocol {(S-BGP)} -- Real World Performance and Deployment Issues}, booktitle = {Proceedings of the IEEE Network and Distributed System Security Symposium}, year = 2000, month = {February} } Other papers include Badger, M.R., and S.L. Murphy. 1996. "Digital Signature Protection of the OSPF Routing Protocol," pp. 93-102 in Proceedings of the Symposium on Network and Distributed System Security. Los Alamitos, CA: IEEE Computer Society Press. Hauser, R., T. Przygienda, and G. Tsudik. 1997. "Reducing the Cost of Security in Link-State Routing," pp. 93-101 in Proceedings of the Symposium on Network and Distributed System Security. Los Alamitos, CA: IEEE Computer Society Press. Sirois, K.E., and Stephen T. Kent. 1997. "Securing the Nimrod Routing Architecture," pp. 74-84 in Proceedings of the Annual Internet Society (ISOC) Symposium on Network and Distributed System Security. Los Alamitos, CA: IEEE Computer Society Press. Smith, B.R., S. Murthy, and J.J. Garcia-Luna-Aceves. 1997. "Securing Distance-Vector Routing Protocols," pp. 85-92 in Proceedings of the Annual Internet Society (ISOC) Symposium on Network and Distributed System Security. Los Alamitos, CA: IEEE Computer Society Press. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue May 14 07:11:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13421 for ; Tue, 14 May 2002 07:11:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28687; Tue, 14 May 2002 07:10:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13547 for ; Mon, 13 May 2002 22:20:18 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15594 for ; Mon, 13 May 2002 22:20:03 -0400 (EDT) Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25805 for ; Mon, 13 May 2002 19:19:45 -0700 (PDT) Received: from sunlabs (sunlabs [129.148.75.250]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id g4E2JUT15904 for ; Mon, 13 May 2002 22:19:32 -0400 (EDT) Message-Id: <200205140219.g4E2JUT15904@sydney.East.Sun.COM> Date: Mon, 13 May 2002 22:19:29 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking To: rpsec@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lcpCRsz9/7FRgAjZWRjZ5Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Subject: [RPSEC] URL to download my thesis on Byzantinely robust routing Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org I managed to find where it's posted, so if anyone is interested: http://www.lcs.mit.edu/publications/specpub.php?id=997 is apparently a place to retrieve and print it. Radia _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Wed May 15 08:51:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00667 for ; Wed, 15 May 2002 08:51:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13041; Wed, 15 May 2002 08:50:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13003 for ; Wed, 15 May 2002 08:49:58 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00583 for ; Wed, 15 May 2002 08:49:44 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA29362 for ; Wed, 15 May 2002 08:49:27 -0400 (EDT) Date: Wed, 15 May 2002 08:49:27 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Current Drafts.... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Y'all: Is anyone working on a requirements draft, or requirements drafts? Should we form a small team to go out and do this? Just trying to figure out if work has started, and how to proceed. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Wed May 15 09:18:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02598 for ; Wed, 15 May 2002 09:18:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17221; Wed, 15 May 2002 09:18:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17139 for ; Wed, 15 May 2002 09:18:04 -0400 (EDT) Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02542; Wed, 15 May 2002 09:17:47 -0400 (EDT) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 21:18:00 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E703C57@MBXSRV26.stu.nus.edu.sg> From: Marwaha Shivanajay To: "'manet@ietf.org'" , "'oldham@grc.nasa.gov'" , rpsec@ietf.org Date: Wed, 15 May 2002 21:17:54 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [RPSEC] RE: [manet] Dumber Question? Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Hi, Assignment of IP adresses is done using "autoconfiguration" in ad hoc networks. The draft that deals with this can be found here http://www.cs.ucsb.edu/~eroyer/txt/autoconf.txt To summarize it in short: If a mobile node wants to have an IP address it broadcasting a RREQ kind of message destined to that IP address. If there exists a mobile device with the same address it gets a RREP back from it and reinitiates the process by choosing a new IP address, otherwise (if it aint get any RREP) it assumes that IP address. The IP address seeking node keeps a temporary address for receiving RREP back to it. It does deal with avoiding duplicacy of IP addresses in one disconnected set of mobiles. But there isn't any central mechanism to allot the same. Nor does it guarentee uniqueness in disconnected networks. Regards, Shivanajay Marwaha -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Research Scholar Electrical and Computer Engg. Dept. National University of Singapore. 10 Kent Ridge Crescent, Singapore 119260. Ph. +65-68742136 -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ -----Original Message----- From: Daniel Oldham [mailto:oldham@grc.nasa.gov] Sent: Wednesday, May 15, 2002 7:20 PM To: Mullen, John P. (Contractor) Cc: Nast, Douglas P; manet@ietf.org Subject: RE: [manet] Dumber Question? Hello Everyone: Good point, on the Internet IP addresses are regulated and assigned to provide a hierarchical structure to allow for proper routing. For an ad-hoc network what controls the assignment of IP addresses? What happens if there are duplicate IP addresses in an ad-hoc network? How is an ad-hoc network connected to the Internet? How do packets from the Internet get an IP address in an ad-hoc network? -- Daniel R. Oldham Ph.D. Computer Engineer Satellite Networks and Architectures Branch NASA Glenn Research Center 21000 Brookpark Road (MS 54-5) Cleveland OH 44135 216.433.6307 - voice 216.433.8705 - fax oldham@grc.nasa.gov >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 5/14/02, 2:16:26 PM, "Mullen, John P. (Contractor)" wrote regarding RE: [manet] Dumb Question?: > Hi Doug, > My concern was that the forwarding process might be called something > else in > a MANET, since it functions differently from the analogous process in wired > networks. However, the consensus seems to be that the same term is > used. I > think I've gotten my answer on that. > The process would be the consequence of the chosen protocol. As I > understand it, the process by which a node obtains link information is > called "routing" and the process by which a node decides which of the three > things to do is called either "forwarding" or "switching," depending > on who > you talk to. The details of the processes would be limited by operational > and hardware constraints and defined in the protocols. > The scheme used to assign node addresses is a key issue in military MANETs. > At the upper levels, one wants a scheme that reflects the hierarchical > military organization. This facilitates the proper routing of orders, > partial orders, etc. However, at the lower levels, one would want an > addressing scheme that reflects the actual network topology. This > would allow clustering, which would make route determination and > forwarding simpler. One solution is to do both, coordinating the > system via the interface. However, the nodes are in constant motion, > so the interface would need to update its information on the fly. > Offsetting the higher efficiency of the clusterable scheme at the > lower levels is a more complicated interface and more difficulty > enforcing security. I don't think > this issue has been resolved yet, so, of course, the protocols are > also up > in the air. > I just started reading _Ad Hoc Networking_, edited by Charles Perkins. In > "A DoD Perspective on Mobile Ad Hoc Networks," James Freebersyser speculates > on p. 33 that it is unlikely a single protocol will be able to operate > efficiently over the full range of conditions under which a military MANET > must operate. If he is correct, the issue may never be fully > resolved. > But, there is always hope, > And, graduate students. > :-) > John Mullen > -----Original Message----- > From: Nast, Douglas P [mailto:douglas.p.nast@boeing.com] > Sent: Tuesday, May 14, 2002 11:10 AM > To: 'Mullen, John P. (Contractor)' > Cc: manet@ietf.org > Subject: RE: [manet] Dumb Question? > John, > You sent a reply saying you understood that layer 3 routing was going > on but > wondered what this other process was. Thanks for the clarification. > Note that in your question you say that "such a thing is not possible. > Instead, each node that receives a packet decides to..." and then you give > 3 possible behaviors, consume, re-broadcast, or discard. > By what process do the nodes come to understand which of these > behaviors is > appropriate for them? Who/What is doing the teaching and to what > purpose? Are the decisions you describe being made on the basis of MAC > layer addresses or IP? > The first thing that occurs to me is that this behavior was learned > via a route discovery process, sort of like source route bridging in > 802 LANs. This approach to routing in Manets was proposed a while back > by David B. Johnson, and is, I think, the basis of the reactive > approach to manet routing. If that's the case, then you can call it > routing or you can call > it switching, but it is not worthy of a new name. > Based on Perkins and Ram responses, I guess I am missing something, though. > Do you think your question has been resolved? If so how? > Doug Nast, Boeing > -----Original Message----- > From: Mullen, John P. (Contractor) > [mailto:mullenjp.contractor@trac.wsmr.army.mil] > Sent: Monday, May 06, 2002 2:08 PM > To: manet@ietf.org > Subject: [manet] Dumb Question? > Hello, > I am looking for a term, but have had no luck. > In wired nets, a packet is routed through the network from node to > node, say > by routing tables. However, in MANETs, in which packets are broadcast via > omnidirectional antennae on a shared channel, such a thing is not possible. > Instead, each node that receives a packet decides to: > 1. Discard the packet, > 2. "Read" the packet, since it is addressed to the node, and/or > 3. Rebroadcast the packet. > If the node is not to be an intermediary node in the end-to-end path between > the source and the destination, or if the node is receiving a copy of > a packet it had previously broadcast, it will not broadcast the packet. This > is necessary to avoid overutilizing the channel. > If the node is an intermediary node on the path, then it must > rebroadcast the packet. > I've got this much figured out, but what I do not know is what this process > is called. It is the MANET equivalent to "routing," but is not really > routing, since the sending node has no way of directing the packet. > I've tried a number of searches and read a few glossaries, but have > not been > able to find this term. > I'd appreciate any help. > Thanks, > John P. Mullen > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 16 05:42:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18735 for ; Thu, 16 May 2002 05:42:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29377; Thu, 16 May 2002 05:42:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27812 for ; Wed, 15 May 2002 23:32:47 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02502; Wed, 15 May 2002 23:32:30 -0400 (EDT) Received: from FRED-W2K6.cisco.com (sjc-vpn3-161.cisco.com [10.21.64.161]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4G3VuPJ015082; Wed, 15 May 2002 20:32:01 -0700 (PDT) Message-Id: <5.1.0.14.2.20020515103000.04c9fd98@mira-sjcm-4.cisco.com> X-Sender: fred@mira-sjcm-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 May 2002 10:31:07 -0700 To: Marwaha Shivanajay From: Fred Baker Cc: "'manet@ietf.org'" , "'oldham@grc.nasa.gov'" , rpsec@ietf.org In-Reply-To: <6330DC96389A924A804F52FA3848930E703C57@MBXSRV26.stu.nus.ed u.sg> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [RPSEC] RE: [manet] Dumber Question? Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org At 09:17 PM 5/15/2002 +0800, Marwaha Shivanajay wrote: >Assignment of IP adresses is done using "autoconfiguration" in ad hoc >networks. ahem; one mechanism for address assignment is autoconfiguration. Never tell your customer that he's not allowed to type it in :^) _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 16 06:07:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19102 for ; Thu, 16 May 2002 06:07:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00754; Thu, 16 May 2002 06:06:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00720 for ; Thu, 16 May 2002 06:06:40 -0400 (EDT) Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19098 for ; Thu, 16 May 2002 06:06:25 -0400 (EDT) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 18:06:39 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E5B3E2F@MBXSRV26.stu.nus.edu.sg> From: Marwaha Shivanajay To: rpsec@ietf.org Subject: FW: [RPSEC] Current Drafts.... Date: Thu, 16 May 2002 18:05:53 +0800 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Hi, I am ready to team up for a draft. I am working on support for real time communication through routing protocols for MANETs. Reagrds, Shivanajay Marwaha -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Research Scholar Electrical and Computer Engg. Dept. National University of Singapore. 10 Kent Ridge Crescent, Singapore 119260. Ph. +65-68742136 -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ > > > > -----Original Message----- > From: Russ White [mailto:ruwhite@cisco.com] > Sent: Wednesday, May 15, 2002 8:49 PM > To: rpsec@ietf.org > Subject: [RPSEC] Current Drafts.... > > > Y'all: > > Is anyone working on a requirements draft, or requirements drafts? > Should we form a small team to go out and do this? Just trying to > figure out if work has started, and how to proceed. > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 16 06:51:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19668 for ; Thu, 16 May 2002 06:51:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03245; Thu, 16 May 2002 06:50:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03210 for ; Thu, 16 May 2002 06:50:47 -0400 (EDT) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19662 for ; Thu, 16 May 2002 06:50:32 -0400 (EDT) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 06:45:59 -0400 Message-ID: From: "Jonnala, Nagi" To: "'Russ White'" , rpsec@ietf.org Subject: RE: [RPSEC] Current Drafts.... Date: Thu, 16 May 2002 06:49:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org I can work on the draft. Being a novice to this kind of work, I need the driving directions though :-) -Nagi. | -----Original Message----- | From: Russ White [mailto:ruwhite@cisco.com] | Sent: Wednesday, May 15, 2002 6:19 PM | To: rpsec@ietf.org | Subject: [RPSEC] Current Drafts.... | | | Y'all: | | Is anyone working on a requirements draft, or requirements | drafts? Should we form a small team to go out and do this? Just | trying to figure out if work has started, and how to proceed. | | :-) | | Russ | | __________________________________ | riw@cisco.com CCIE <>< Grace Alone | | | | _______________________________________________ | RPSEC mailing list | RPSEC@ietf.org | https://www1.ietf.org/mailman/listinfo/rpsec | _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 16 07:13:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19965 for ; Thu, 16 May 2002 07:13:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04556; Thu, 16 May 2002 07:12:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04524 for ; Thu, 16 May 2002 07:12:31 -0400 (EDT) Received: from imc21.ex.nus.edu.sg (imc21.ex.nus.edu.sg [137.132.14.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19952 for ; Thu, 16 May 2002 07:12:14 -0400 (EDT) Received: by imc21.ex.nus.edu.sg with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 19:12:29 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E5B3E31@MBXSRV26.stu.nus.edu.sg> From: Marwaha Shivanajay To: rpsec@ietf.org Subject: RE: [RPSEC] Current Drafts.... Date: Thu, 16 May 2002 19:12:23 +0800 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org One possible area is IP addressing in ad hoc networks. There is already a draft related to this, but it has limitations. http://www.cs.ucsb.edu/~eroyer/txt/autoconf.txt Regards, Ajay -----Original Message----- From: Jonnala, Nagi [mailto:nagij@netplane.com] Sent: Thursday, May 16, 2002 6:49 PM To: 'Russ White'; rpsec@ietf.org Subject: RE: [RPSEC] Current Drafts.... I can work on the draft. Being a novice to this kind of work, I need the driving directions though :-) -Nagi. | -----Original Message----- | From: Russ White [mailto:ruwhite@cisco.com] | Sent: Wednesday, May 15, 2002 6:19 PM | To: rpsec@ietf.org | Subject: [RPSEC] Current Drafts.... | | | Y'all: | | Is anyone working on a requirements draft, or requirements | drafts? Should we form a small team to go out and do this? Just | trying to figure out if work has started, and how to proceed. | | :-) | | Russ | | __________________________________ | riw@cisco.com CCIE <>< Grace Alone | | | | _______________________________________________ | RPSEC mailing list | RPSEC@ietf.org | https://www1.ietf.org/mailman/listinfo/rpsec | _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 16 10:42:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26524 for ; Thu, 16 May 2002 10:42:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16564; Thu, 16 May 2002 10:41:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16540 for ; Thu, 16 May 2002 10:41:17 -0400 (EDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26491 for ; Thu, 16 May 2002 10:41:02 -0400 (EDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g4GEeaP26860; Thu, 16 May 2002 09:40:36 -0500 (CDT) Message-ID: <3CE3C4EF.8F229030@alcatel.com> Date: Thu, 16 May 2002 09:40:47 -0500 From: Alex Audu X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Russ White CC: rpsec@ietf.org Subject: Re: [RPSEC] Current Drafts.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Ross, Add me to the team. Alex. Russ White wrote: > Y'all: > > Is anyone working on a requirements draft, or requirements > drafts? Should we form a small team to go out and do this? Just > trying to figure out if work has started, and how to proceed. > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 16 10:55:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26976 for ; Thu, 16 May 2002 10:55:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17081; Thu, 16 May 2002 10:54:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17045 for ; Thu, 16 May 2002 10:54:01 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26930 for ; Thu, 16 May 2002 10:53:46 -0400 (EDT) From: ram.gopal@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4GEsIS23986 for ; Thu, 16 May 2002 09:54:18 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 May 2002 07:53:53 -0500 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 16 May 2002 09:53:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [RPSEC] Current Drafts.... Date: Thu, 16 May 2002 10:53:51 -0400 Message-ID: Thread-Topic: [RPSEC] Current Drafts.... Thread-Index: AcH8DwxupDxsjExASh2l23HpvsglhwA2mK9A To: , X-OriginalArrivalTime: 16 May 2002 14:53:53.0552 (UTC) FILETIME=[7F3F5100:01C1FCE9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA17046 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Hello all, I would like to join the team and work on the draft. regards ramg -----Original Message----- From: ext Russ White [mailto:ruwhite@cisco.com] Sent: Wednesday, May 15, 2002 8:49 AM To: rpsec@ietf.org Subject: [RPSEC] Current Drafts.... Y'all: Is anyone working on a requirements draft, or requirements drafts? Should we form a small team to go out and do this? Just trying to figure out if work has started, and how to proceed. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 16 13:14:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02705 for ; Thu, 16 May 2002 13:14:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29715; Thu, 16 May 2002 13:13:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29682 for ; Thu, 16 May 2002 13:13:21 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02697 for ; Thu, 16 May 2002 13:13:04 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14323; Thu, 16 May 2002 13:12:42 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15786; Thu, 16 May 2002 11:29:57 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 May 2002 11:29:57 -0400 Message-ID: <39469E08BD83D411A3D900204840EC557631A2@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Russ White'" Cc: "'rpsec@ietf.org'" Subject: RE: [RPSEC] Current Drafts.... Date: Thu, 16 May 2002 11:29:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Russ, Add me to the team. -- Venkata. -> Y'all: -> -> Is anyone working on a requirements draft, or requirements -> drafts? Should we form a small team to go out and do this? Just -> trying to figure out if work has started, and how to proceed. -> -> :-) -> -> Russ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 16 18:33:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12592 for ; Thu, 16 May 2002 18:33:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16556; Thu, 16 May 2002 18:32:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16524 for ; Thu, 16 May 2002 18:32:58 -0400 (EDT) Received: from mail.reptiles.org (root@mail.reptiles.org [198.96.117.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12575 for ; Thu, 16 May 2002 18:32:42 -0400 (EDT) Received: from mail.reptiles.org([198.96.117.157]) (1167 bytes) by mail.reptiles.org via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Thu, 16 May 2002 18:32:54 -0400 (EDT) (Smail-3.2.0.114 2001-Aug-6 #10 built 2002-Jan-14) Date: Thu, 16 May 2002 18:32:54 -0400 (EDT) From: Gwendolynn ferch Elydyr To: "Naidu, Venkata" cc: "'Russ White'" , "'rpsec@ietf.org'" Subject: RE: [RPSEC] Current Drafts.... In-Reply-To: <39469E08BD83D411A3D900204840EC557631A2@vie-msgusr-01.dc.fore.com> Message-ID: <20020516183234.L672-100000@iguana.reptiles.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > -> Is anyone working on a requirements draft, or requirements > -> drafts? Should we form a small team to go out and do this? Just > -> trying to figure out if work has started, and how to proceed. Me too! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri May 17 07:37:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08905 for ; Fri, 17 May 2002 07:37:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01370; Fri, 17 May 2002 07:37:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01336 for ; Fri, 17 May 2002 07:36:58 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08890 for ; Fri, 17 May 2002 07:36:42 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA09677 for ; Fri, 17 May 2002 07:36:23 -0400 (EDT) Date: Fri, 17 May 2002 07:36:23 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Subject: [RPSEC] Current Drafts.... (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org __________________________________ riw@cisco.com CCIE <>< Grace Alone ---------- Forwarded message ---------- Date: Fri, 17 May 2002 00:06:04 -0400 From: Harikrishna G. To: "'riw@cisco.com'" Subject: [RPSEC] Current Drafts.... Russ, I'm intereseted in working on it. -Hari -----Original Message----- From: Naidu, Venkata [mailto:Venkata.Naidu@marconi.com] Sent: Thursday, May 16, 2002 9:00 PM To: 'Russ White' Cc: 'rpsec@ietf.org' Subject: RE: [RPSEC] Current Drafts.... Russ, Add me to the team. -- Venkata. -> Y'all: -> -> Is anyone working on a requirements draft, or requirements -> drafts? Should we form a small team to go out and do this? Just -> trying to figure out if work has started, and how to proceed. -> -> :-) -> -> Russ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Fri May 17 08:43:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10825 for ; Fri, 17 May 2002 08:43:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03762; Fri, 17 May 2002 08:42:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03728 for ; Fri, 17 May 2002 08:42:48 -0400 (EDT) Received: from wolfe.bbn.com (wolfe.BBN.COM [128.89.80.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10805 for ; Fri, 17 May 2002 08:42:34 -0400 (EDT) Received: by wolfe.bbn.com (Postfix, from userid 13538) id A263D16484; Fri, 17 May 2002 08:42:18 -0400 (EDT) From: Charles Lynn To: Russ White Cc: rpsec@ietf.org, CLynn@bbn.com Subject: Re: [RPSEC] Current Drafts.... In-Reply-To: Message-Id: <20020517124218.A263D16484@wolfe.bbn.com> Date: Fri, 17 May 2002 08:42:18 -0400 (EDT) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Russ, I'll help, too. Charlie _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Mon May 20 20:25:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24206 for ; Mon, 20 May 2002 20:25:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29233; Mon, 20 May 2002 20:23:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29199 for ; Mon, 20 May 2002 20:23:25 -0400 (EDT) Received: from mail1.netscreen.com ([63.126.135.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24099 for ; Mon, 20 May 2002 20:23:07 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.10.21]) by mail1.netscreen.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4L0MhL21505 for ; Mon, 20 May 2002 17:22:43 -0700 (PDT) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 17:21:57 -0700 Message-ID: <541402FFDC56DA499E7E13329ABFEA8771A9@SARATOGA> From: Gregory Lebovitz To: "'rpsec@ietf.org'" Subject: fwd: [RPSEC] Current Drafts.... Date: Mon, 20 May 2002 17:20:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2005D.41358420" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2005D.41358420 Content-Type: text/plain; charset="iso-8859-1" count me in ---------- Forwarded message ---------- Date: Fri, 17 May 2002 00:06:04 -0400 From: Harikrishna G. < harikrishnag@netplane.com> To: " 'riw@cisco.com'" < riw@cisco.com> Subject: [RPSEC] Current Drafts.... Russ, I'm intereseted in working on it. -Hari -----Original Message----- From: Naidu, Venkata [mailto:Venkata.Naidu@marconi.com] Sent: Thursday, May 16, 2002 9:00 PM To: 'Russ White' Cc: 'rpsec@ietf.org' Subject: RE: [RPSEC] Current Drafts.... Russ, Add me to the team. -- Venkata. -> Y'all: -> -> Is anyone working on a requirements draft, or requirements -> drafts? Should we form a small team to go out and do this? Just -> trying to figure out if work has started, and how to proceed. -> -> :-) -> -> Russ _______________________________________________ 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 **=====**=====**=====**=====** Gregory M. Lebovitz Staff Architect - CTO Office NetScreen Technologies, Inc. e: gregory@netscreen.com ph: 408.730.6002 text page (<80 Chars): page.gregory@netscreen.com fax: 408.730.6200 web: www.netscreen.com NASDAQ: NSCN **=====**=====**=====**=====** ------_=_NextPart_001_01C2005D.41358420 Content-Type: text/html; charset="iso-8859-1"
count me in
---------- Forwarded message ----------
Date: Fri, 17 May 2002 00:06:04 -0400
From: Harikrishna G. <harikrishnag@netplane.com>
To: "'riw@cisco.com'" <riw@cisco.com>
Subject: [RPSEC] Current Drafts....
 

Russ,
 I'm intereseted in working on it.
 
-Hari
-----Original Message-----
From: Naidu, Venkata [mailto:Venkata.Naidu@marconi.com]
Sent: Thursday, May 16, 2002 9:00 PM
To: 'Russ White'
Cc: 'rpsec@ietf.org'
Subject: RE: [RPSEC] Current Drafts....
 

Russ,
 
Add me to the team.
 
--
Venkata.
 
-> Y'all:
->
-> Is anyone working on a requirements draft, or requirements
-> drafts? Should we form a small team to go out and do this? Just
-> trying to figure out if work has started, and how to proceed.
->
-> :-)
->
-> Russ
 
_______________________________________________
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
 
 

**=====**=====**=====**=====**
Gregory M. Lebovitz
Staff Architect - CTO Office
NetScreen Technologies, Inc.
  e:  gregory@netscreen.com
 ph: 408.730.6002
text page (<80 Chars):   page.gregory@netscreen.com
fax: 408.730.6200
web: www.netscreen.com
NASDAQ:   NSCN
**=====**=====**=====**=====**

 
------_=_NextPart_001_01C2005D.41358420-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Mon May 20 20:39:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24852 for ; Mon, 20 May 2002 20:39:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00022; Mon, 20 May 2002 20:33:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29982 for ; Mon, 20 May 2002 20:33:10 -0400 (EDT) Received: from mail1.netscreen.com ([63.126.135.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24597 for ; Mon, 20 May 2002 20:32:51 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.10.21]) by mail1.netscreen.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4L0WIL22809 for ; Mon, 20 May 2002 17:32:18 -0700 (PDT) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 17:31:28 -0700 Message-ID: <541402FFDC56DA499E7E13329ABFEA8771AC@SARATOGA> From: Gregory Lebovitz To: "'rpsec@ietf.org'" Subject: RE: [RPSEC] URL to download my thesis on Byzantinely robust routi ng Date: Mon, 20 May 2002 17:29:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2005E.972008A0" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2005E.972008A0 Content-Type: text/plain; charset="iso-8859-1" Radia and Sandy- Have you posted the presos you gave at the MN BOF? =================== I managed to find where it's posted, so if anyone is interested: http://www.lcs.mit.edu/publications/specpub.php?id=997 is apparently a place to retrieve and print it. Radia ------_=_NextPart_001_01C2005E.972008A0 Content-Type: text/html; charset="iso-8859-1"
Radia and Sandy-
Have you posted the presos you gave at the MN BOF?
===================
I managed to find where it's posted, so if anyone is interested:
 
 
is apparently a place to retrieve and print it.
 
Radia
------_=_NextPart_001_01C2005E.972008A0-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 30 18:05:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20879 for ; Thu, 30 May 2002 18:05:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08262; Thu, 30 May 2002 18:04:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08228 for ; Thu, 30 May 2002 18:04:08 -0400 (EDT) Received: from sushi.toad.net (sushi.toad.net [162.33.130.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20858 for ; Thu, 30 May 2002 18:03:43 -0400 (EDT) Received: from gwu.edu (dboney-01.dslbr.toad.net [162.33.159.86]) by sushi.toad.net (8.11.6/8.11.6) with ESMTP id g4UM48q27249 for ; Thu, 30 May 2002 18:04:08 -0400 Message-ID: <3CF6A1D7.7000701@gwu.edu> Date: Thu, 30 May 2002 18:04:07 -0400 From: "David G. Boney" Organization: The George Washington University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: rpsec@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [RPSEC] Routing Security Bibliography Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Hi, I am currently writing a lierature review paper on routing security. I have a partial bibliography posted at http://student.seas.gwu.edu/~dboney/routingsecurity.html . Please let me know of any additional works that should be cited. It may not be current for recent publications. -- Sincerely, David G. Boney Graduate Research Assistant Department of Electrical and Computer Engineering The George Washington University Phillips Hall, Suite 607 801 22nd Street, N.W. Washington, DC 20052 http://student.seas.gwu.edu/~dboney mailto:dboney@gwu.edu Department Phone (202) 994-6083 Department Fax (202) 994-0227 "I don't get up until noon, I only work a couple of hours a day, and I spend the rest of my time reading. I guess my calling in life is to be a professor." _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 30 22:05:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24189 for ; Thu, 30 May 2002 22:05:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18398; Thu, 30 May 2002 22:05:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07502 for ; Thu, 30 May 2002 17:56:44 -0400 (EDT) Received: from sushi.toad.net (sushi.toad.net [162.33.130.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20725 for ; Thu, 30 May 2002 17:56:19 -0400 (EDT) Received: from gwu.edu (dboney-01.dslbr.toad.net [162.33.159.86]) by sushi.toad.net (8.11.6/8.11.6) with ESMTP id g4ULuiq26680 for ; Thu, 30 May 2002 17:56:44 -0400 Message-ID: <3CF6A01B.5050801@gwu.edu> Date: Thu, 30 May 2002 17:56:43 -0400 From: "David G. Boney" Organization: The George Washington University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: rpsec@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [RPSEC] MPLS Security Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Hi, Would MPLS security be within the bounds of this group? -- Sincerely, David G. Boney Graduate Research Assistant Department of Electrical and Computer Engineering The George Washington University Phillips Hall, Suite 607 801 22nd Street, N.W. Washington, DC 20052 http://student.seas.gwu.edu/~dboney mailto:dboney@gwu.edu Department Phone (202) 994-6083 Department Fax (202) 994-0227 "I don't get up until noon, I only work a couple of hours a day, and I spend the rest of my time reading. I guess my calling in life is to be a professor." _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Thu May 30 22:36:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24847 for ; Thu, 30 May 2002 22:36:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19558; Thu, 30 May 2002 22:32:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19524 for ; Thu, 30 May 2002 22:32:03 -0400 (EDT) Received: from ims21.stu.nus.edu.sg (nusnet-14-26.dynip.nus.edu.sg [137.132.14.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24616 for ; Thu, 30 May 2002 22:31:37 -0400 (EDT) Received: from mbxsrv26.stu.nus.edu.sg ([137.132.14.236]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 10:31:59 +0800 content-class: urn:content-classes:message Subject: RE: [RPSEC] MPLS Security Date: Fri, 31 May 2002 10:31:59 +0800 Message-ID: <6330DC96389A924A804F52FA3848930E5B3E6B@MBXSRV26.stu.nus.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: [RPSEC] MPLS Security Thread-Index: AcIIR6qJHmiDtCuURoG8+UB0bKpvkwAA0a0g From: "Marwaha Shivanajay" To: X-OriginalArrivalTime: 31 May 2002 02:31:59.0831 (UTC) FILETIME=[5732C670:01C2084B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA19525 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit We may also inlcude ad hoc network routing security. Regards, Shivanajay -~-~-~-~-~-~-~-~-~-~-~-~ Research Scholar, Dept. of Electrical and Comp. Eng. National University of Singapore Singapore. -~-~-~-~-~-~-~-~-~-~-~-~ -----Original Message----- From: David G. Boney [mailto:dboney@gwu.edu] Sent: Friday, May 31, 2002 5:57 AM To: rpsec@ietf.org Subject: [RPSEC] MPLS Security Hi, Would MPLS security be within the bounds of this group? -- Sincerely, David G. Boney Graduate Research Assistant Department of Electrical and Computer Engineering The George Washington University Phillips Hall, Suite 607 801 22nd Street, N.W. Washington, DC 20052 http://student.seas.gwu.edu/~dboney mailto:dboney@gwu.edu Department Phone (202) 994-6083 Department Fax (202) 994-0227 "I don't get up until noon, I only work a couple of hours a day, and I spend the rest of my time reading. I guess my calling in life is to be a professor." _______________________________________________ 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