From exim@www1.ietf.org Mon Dec 1 03:22:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01519 for ; Mon, 1 Dec 2003 03:22:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQjK1-0008GH-U6 for rpsec-archive@odin.ietf.org; Mon, 01 Dec 2003 03:22:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB18MLYI031751 for rpsec-archive@odin.ietf.org; Mon, 1 Dec 2003 03:22:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQjK1-0008G2-FG for rpsec-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 03:22:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01454 for ; Mon, 1 Dec 2003 03:22:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQjJz-0005Qz-00 for rpsec-web-archive@ietf.org; Mon, 01 Dec 2003 03:22:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQjJy-0005Qv-00 for rpsec-web-archive@ietf.org; Mon, 01 Dec 2003 03:22:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQjJl-0008Ck-GG; Mon, 01 Dec 2003 03:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQjIj-0008Ap-Fz for rpsec@optimus.ietf.org; Mon, 01 Dec 2003 03:21:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01352 for ; Mon, 1 Dec 2003 03:20:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQjAH-0005Ck-00 for rpsec@ietf.org; Mon, 01 Dec 2003 03:12:17 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AQjAH-0005CP-00 for rpsec@ietf.org; Mon, 01 Dec 2003 03:12:17 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 4979C34554 for ; Mon, 1 Dec 2003 09:09:55 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 34BA03F423 for ; Mon, 1 Dec 2003 09:09:55 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003120109094118171 for ; Mon, 01 Dec 2003 09:09:41 +0100 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 1677E3F423 for ; Mon, 1 Dec 2003 09:09:55 +0100 (CET) Received: from jjp by localhost with local id 1AQj7n-0002Cj-00 for ; Mon, 01 Dec 2003 09:09:43 +0100 Date: Mon, 1 Dec 2003 09:09:43 +0100 From: Jean-Jacques Puig To: rpsec@ietf.org Message-ID: <20031201080943.GA7879@ivan.int-evry.fr> Mail-Followup-To: rpsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [RPSEC] draft-puig-rpsec-generic-requirements-01 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Hi ! During the meeting, we asked for a consensus call on this draft as whether it should be accepted as a WG item. Though the sense of the room on this question was Yes, it was decided that the question would be taken on the list for confirmation. In order to go farther, we need this confirmation before submitting to IDs. So: Dear RPSEC WG members, do you confirm this draft should be accepted as a WG item ? -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Dec 10 00:09:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02406 for ; Wed, 10 Dec 2003 00:09:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATwb1-00010x-UF for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 00:09:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA59Bi7003893 for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 00:09:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATwb1-00010i-PI for rpsec-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 00:09:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02402 for ; Wed, 10 Dec 2003 00:08:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATwaz-0002gy-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 00:09:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATway-0002gu-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 00:09:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATwar-0000zS-1X; Wed, 10 Dec 2003 00:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATwad-0000zB-Mr for rpsec@optimus.ietf.org; Wed, 10 Dec 2003 00:08:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02394 for ; Wed, 10 Dec 2003 00:08:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATwab-0002gQ-00 for rpsec@ietf.org; Wed, 10 Dec 2003 00:08:45 -0500 Received: from machine77.level3.com ([209.244.4.106] helo=scanner1.l3.com) by ietf-mx with esmtp (Exim 4.12) id 1ATwaa-0002fu-00 for rpsec@ietf.org; Wed, 10 Dec 2003 00:08:44 -0500 Received: from scanner1.l3.com (localhost [127.0.0.1]) by localhost.l3.com (Postfix) with ESMTP id A6B6578B51E for ; Wed, 10 Dec 2003 05:08:15 +0000 (GMT) Received: from buzz.idc1.level3.com (qfe0.buzz.idc1.oss.level3.com [10.1.116.4]) by scanner1.l3.com (Postfix) with ESMTP id 6669778B499 for ; Wed, 10 Dec 2003 05:08:15 +0000 (GMT) Received: from localhost (ttauber@localhost) by buzz.idc1.level3.com (8.8.8p2+Sun/8.8.8) with ESMTP id FAA26502 for ; Wed, 10 Dec 2003 05:08:15 GMT X-Authentication-Warning: buzz.idc1.level3.com: ttauber owned process doing -bs Date: Wed, 10 Dec 2003 05:08:14 +0000 (GMT) From: Tony Tauber X-X-Sender: ttauber@buzz.idc1.level3.com To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Consensus calls Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Folks, At the meeting in Minneapolis, the sense of the room was that there was positive support for these proposals: 1) Should draft-puig-rpsec-generic-requirements-01.txt be accepted as a WG work item? 2) Should the RPSEC charter be amended to allow for the acceptance of protocol-specific work? (Removing the sentence below should do that.) ++> It is also a non-goal at this point to produce new or change the ++> current security mechanisms in the existing routing protocols. 3) Should draft-convery-bgpattack-01.txt be accepted as a WG work item? 4) Should draft-jones-OSPF-vuln-01.txt be accepted as a WG work item? Please respond with your opinions. (See meeting minutes at http://ietf.org/proceedings/03nov/minutes/rpsec.htm for more details if desired.) Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Dec 10 13:39:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08604 for ; Wed, 10 Dec 2003 13:39:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU91V-0006I2-E1 for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 13:25:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAIPLZ3024178 for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 13:25:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU91V-0006Ht-9t for rpsec-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 13:25:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08207 for ; Wed, 10 Dec 2003 13:25:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU91R-0005HW-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 13:25:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU91R-0005HT-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 13:25:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU91D-0006AF-Co; Wed, 10 Dec 2003 13:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU90h-00065s-J0 for rpsec@optimus.ietf.org; Wed, 10 Dec 2003 13:24:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08145 for ; Wed, 10 Dec 2003 13:24:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU8tw-00055S-00 for rpsec@ietf.org; Wed, 10 Dec 2003 13:17:32 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AU8tv-00053A-00 for rpsec@ietf.org; Wed, 10 Dec 2003 13:17:31 -0500 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBAIGoH04393; Wed, 10 Dec 2003 13:16:50 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WTQNF7BY; Wed, 10 Dec 2003 13:16:49 -0500 Received: from nortelnetworks.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y2KC75SQ; Wed, 10 Dec 2003 13:16:49 -0500 Message-ID: <3FD76311.5030009@nortelnetworks.com> Date: Wed, 10 Dec 2003 13:16:49 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Tauber CC: rpsec@ietf.org Subject: Re: [RPSEC] Consensus calls References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I am just curious about item 2 below. Do you mean just protocol specific threats and requirements, or solutions as well? Lakshminath Tony Tauber wrote: >Folks, > >At the meeting in Minneapolis, the sense of the room was that there >was positive support for these proposals: > >1) Should draft-puig-rpsec-generic-requirements-01.txt be accepted as > a WG work item? > >2) Should the RPSEC charter be amended to allow for the acceptance of > protocol-specific work? (Removing the sentence below should do that.) > > ++> It is also a non-goal at this point to produce new or change the > ++> current security mechanisms in the existing routing protocols. > >3) Should draft-convery-bgpattack-01.txt be accepted as a WG work item? > >4) Should draft-jones-OSPF-vuln-01.txt be accepted as a WG work item? > >Please respond with your opinions. > >(See meeting minutes at http://ietf.org/proceedings/03nov/minutes/rpsec.htm >for more details if desired.) > >Thanks, > >Tony > >_______________________________________________ >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 exim@www1.ietf.org Wed Dec 10 14:01:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08601 for ; Wed, 10 Dec 2003 13:39:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU964-0006RB-QW for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 13:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAIU4Xa024739 for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 13:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU964-0006Qw-Lv for rpsec-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 13:30:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08301 for ; Wed, 10 Dec 2003 13:30:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU962-0005LC-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 13:30:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU962-0005L9-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 13:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU961-0006Od-MN; Wed, 10 Dec 2003 13:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU956-0006O2-T0 for rpsec@optimus.ietf.org; Wed, 10 Dec 2003 13:29:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08287 for ; Wed, 10 Dec 2003 13:29:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU954-0005Kj-00 for rpsec@ietf.org; Wed, 10 Dec 2003 13:29:02 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AU954-0005KQ-00 for rpsec@ietf.org; Wed, 10 Dec 2003 13:29:02 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBAISOH05936; Wed, 10 Dec 2003 13:28:25 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Dec 2003 13:28:25 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75407DCFB6C@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Tony Tauber Cc: rpsec@ietf.org Subject: RE: [RPSEC] Consensus calls Date: Wed, 10 Dec 2003 13:28:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BF4B.64148B4A" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3BF4B.64148B4A Content-Type: text/plain Hi, Same here, I think you need to be specific to what protocols are in scope. Abbie > -----Original Message----- > From: Dondeti, Lakshminath [BL60:1A14:EXCH] > Sent: Wednesday, December 10, 2003 1:17 PM > To: Tony Tauber > Cc: rpsec@ietf.org > Subject: Re: [RPSEC] Consensus calls > > > Hi, > > I am just curious about item 2 below. Do you mean just protocol > specific threats and requirements, or solutions as well? > > Lakshminath > > Tony Tauber wrote: > > >Folks, > > > >At the meeting in Minneapolis, the sense of the room was > that there was > >positive support for these proposals: > > > >1) Should draft-puig-rpsec-generic-requirements-01.txt be accepted as > > a WG work item? > > > >2) Should the RPSEC charter be amended to allow for the acceptance of > > protocol-specific work? (Removing the sentence below should do > >that.) > > > > ++> It is also a non-goal at this point to produce new or > change the > > ++> current security mechanisms in the existing routing protocols. > > > >3) Should draft-convery-bgpattack-01.txt be accepted as a WG > work item? > > > >4) Should draft-jones-OSPF-vuln-01.txt be accepted as a WG work item? > > > >Please respond with your opinions. > > > >(See meeting minutes at > >http://ietf.org/proceedings/03nov/minutes/rpsec.htm > >for more details if desired.) > > > >Thanks, > > > >Tony > > > >_______________________________________________ > >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 > ------_=_NextPart_001_01C3BF4B.64148B4A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [RPSEC] Consensus calls

Hi,

Same here, I think you need to be specific to what = protocols are in scope.

Abbie


> -----Original Message-----
> From: Dondeti, Lakshminath [BL60:1A14:EXCH] =
> Sent: Wednesday, December 10, 2003 1:17 = PM
> To: Tony Tauber
> Cc: rpsec@ietf.org
> Subject: Re: [RPSEC] Consensus calls
>
>
> Hi,
>
> I am just curious about item 2 below.  Do = you mean just protocol
> specific threats and requirements, or solutions = as well?
>
> Lakshminath
>
> Tony Tauber wrote:
>
> >Folks,
> >
> >At the meeting in Minneapolis, the sense of = the room was
> that there was
> >positive support for these = proposals:
> >
> >1) Should = draft-puig-rpsec-generic-requirements-01.txt be accepted as
> >   a WG work item?
> >
> >2) Should the RPSEC charter be amended to = allow for the acceptance of
> >   protocol-specific work?  = (Removing the sentence below should do
> >that.)
> >
> >   ++> It is also a non-goal = at this point to produce new or
> change the
> >   ++> current security = mechanisms in the existing routing protocols.
> >
> >3) Should draft-convery-bgpattack-01.txt be = accepted as a WG
> work item?
> >
> >4) Should draft-jones-OSPF-vuln-01.txt be = accepted as a WG work item?
> >
> >Please respond with your opinions.
> >
> >(See meeting minutes at
> >http://ietf.org/proceedings/03nov/minutes/rpsec.htm
> >for more details if desired.)
> >
> >Thanks,
> >
> >Tony
> >
> = >_______________________________________________
> >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
>

------_=_NextPart_001_01C3BF4B.64148B4A-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Dec 10 22:12:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02322 for ; Wed, 10 Dec 2003 22:12:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUHFJ-0005a9-D2 for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 22:12:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB3C9rr021451 for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 22:12:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUHFJ-0005Zu-8E for rpsec-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 22:12:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02308 for ; Wed, 10 Dec 2003 22:12:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUHFF-00011a-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 22:12:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUHFF-00011X-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 22:12:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUHFA-0005YU-SJ; Wed, 10 Dec 2003 22:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUHEx-0005Y1-CS for rpsec@optimus.ietf.org; Wed, 10 Dec 2003 22:11:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02295 for ; Wed, 10 Dec 2003 22:11:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUHEp-000117-00 for rpsec@ietf.org; Wed, 10 Dec 2003 22:11:39 -0500 Received: from kc-msxproto1.kc.umkc.edu ([134.193.143.167]) by ietf-mx with esmtp (Exim 4.12) id 1AUHEp-000112-00 for rpsec@ietf.org; Wed, 10 Dec 2003 22:11:39 -0500 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Wed, 10 Dec 2003 21:11:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] Consensus calls Date: Wed, 10 Dec 2003 21:08:59 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011081D9@KC-MAIL4.kc.umkc.edu> Thread-Topic: [RPSEC] Consensus calls Thread-Index: AcO/k8D6dUf7NhIBSXqrFI+G5OYgHQAAF4s9 From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: X-OriginalArrivalTime: 11 Dec 2003 03:11:40.0316 (UTC) FILETIME=[7EFE35C0:01C3BF94] Content-Transfer-Encoding: quoted-printable Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > 1) Should > draft-puig-rpsec-generic-requirements-01.txt be > accepted as a WG work item? yes. The draft may be incomplete. But, we should remember it is work-in-progress. It is hard to get generic requirements draft complete at first shot. > 2) Should the RPSEC charter be amended to allow for > the acceptance of protocol-specific work?=20 yes. I strongly support for protocol-specific requirements=20 work. It can be integrated or can provide specific input=20 to the generic requirements document at a later stage. =20 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Dec 10 23:49:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04971 for ; Wed, 10 Dec 2003 23:49:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIl7-00007Z-MX for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 23:49:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB4n5Q5000459 for rpsec-archive@odin.ietf.org; Wed, 10 Dec 2003 23:49:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIl7-00007K-HX for rpsec-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 23:49:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04932 for ; Wed, 10 Dec 2003 23:49:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUIl4-0002eZ-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 23:49:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUIl4-0002eW-00 for rpsec-web-archive@ietf.org; Wed, 10 Dec 2003 23:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIl3-00005Y-FK; Wed, 10 Dec 2003 23:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIkE-0008WP-21 for rpsec@optimus.ietf.org; Wed, 10 Dec 2003 23:48:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04900 for ; Wed, 10 Dec 2003 23:48:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUIkB-0002ds-00 for rpsec@ietf.org; Wed, 10 Dec 2003 23:48:07 -0500 Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx with esmtp (Exim 4.12) id 1AUIkA-0002dp-00 for rpsec@ietf.org; Wed, 10 Dec 2003 23:48:06 -0500 Received: from [192.168.1.39] (unknown [151.118.13.197]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 72DD894277; Wed, 10 Dec 2003 21:48:02 -0700 (MST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2A2286BB-2B95-11D8-989B-000393D54EA6@tcb.net> Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org From: Danny McPherson Subject: Re: [RPSEC] Consensus calls Date: Wed, 10 Dec 2003 21:47:46 -0700 To: Stephen Kent X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > No. This document is a hodge podge. It mixes the authors's solution > ideas with requirements statements. It is very uneven in its > treatment of topics, and has numerous errors, e.g., characterizing > anti-replay as a crypto mechanism. It is not a generic requirements > document, as the title suggests. Then provide some input to the authors. Accepting it as a starting point at least gets us moving forward (although I am impressed you presumably took a moment to actually look at the document) -- as opposed to simply continuing with fumbling over two solutions to problems we've yet to define. I find the lack of interest/input and sentiment such as this very annoying. >> 4) Should draft-jones-OSPF-vuln-01.txt be accepted as a WG work item? > > no, see my response to #2 above. So I'm confused. What is it you believe we should be doing AND how would you go about accomplishing it? -danny _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 11 06:53:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26321 for ; Thu, 11 Dec 2003 06:53:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPNZ-0008Aj-1N for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 06:53:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBBrDGr031407 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 06:53:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPNY-0008AU-RR for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 06:53:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26312 for ; Thu, 11 Dec 2003 06:53:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPNT-0000zj-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 06:53:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUPNT-0000zf-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 06:53:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPNN-00089I-8K; Thu, 11 Dec 2003 06:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPN4-00088I-Tf for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 06:52:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26301 for ; Thu, 11 Dec 2003 06:52:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPN0-0000zL-00 for rpsec@ietf.org; Thu, 11 Dec 2003 06:52:38 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AUPMz-0000zA-00 for rpsec@ietf.org; Thu, 11 Dec 2003 06:52:37 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 11 Dec 2003 11:53:24 +0000 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBBBq6DM013272; Thu, 11 Dec 2003 06:52:07 -0500 (EST) Received: from dhcp-64-102-48-212.cisco.com (dhcp-64-102-48-212.cisco.com [64.102.48.212]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA24254; Thu, 11 Dec 2003 06:52:06 -0500 (EST) Date: Thu, 11 Dec 2003 06:52:08 -0500 (EST) From: Russ White Reply-To: Russ White To: "Dondeti, Lakshminath" cc: Tony Tauber , rpsec@ietf.org Subject: Re: [RPSEC] Consensus calls In-Reply-To: <3FD76311.5030009@nortelnetworks.com> Message-ID: References: <3FD76311.5030009@nortelnetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > I am just curious about item 2 below. Do you mean just protocol specific > threats and requirements, or solutions as well? RPsec would take on requirements work, not solution work, with this change. In other words, RPsec could provide the requirements docs that other working groups would use to build solutions in their specific protocols. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 11 06:57:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26411 for ; Thu, 11 Dec 2003 06:57:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPRG-0008I7-LH for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 06:57:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBBv2Fk031865 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 06:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPRG-0008Hs-GD for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 06:57:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26399 for ; Thu, 11 Dec 2003 06:56:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPRB-000130-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 06:56:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUPRB-00012x-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 06:56:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPRF-0008Fh-4H; Thu, 11 Dec 2003 06:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPRC-0008FQ-Gg for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 06:56:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26393 for ; Thu, 11 Dec 2003 06:56:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPR7-00012o-00 for rpsec@ietf.org; Thu, 11 Dec 2003 06:56:53 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AUPR7-00012d-00 for rpsec@ietf.org; Thu, 11 Dec 2003 06:56:53 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id E144E340F7 for ; Thu, 11 Dec 2003 12:53:01 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id D34103F48D for ; Thu, 11 Dec 2003 12:53:01 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003121112522810765 for ; Thu, 11 Dec 2003 12:52:28 +0100 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id B35023F48D for ; Thu, 11 Dec 2003 12:53:01 +0100 (CET) Received: from jjp by localhost with local id 1AUPNJ-0008Cy-00 for ; Thu, 11 Dec 2003 12:52:57 +0100 Date: Thu, 11 Dec 2003 12:52:57 +0100 From: Jean-Jacques Puig To: rpsec@ietf.org Subject: Re: [RPSEC] Consensus calls Message-ID: <20031211115257.GJ17183@ivan.int-evry.fr> Mail-Followup-To: rpsec@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Wed, Dec 10, 2003 at 02:01:29PM -0500, Stephen Kent wrote: > At 5:08 +0000 12/10/03, Tony Tauber wrote: > >Folks, > > > >At the meeting in Minneapolis, the sense of the room was that there > >was positive support for these proposals: > > > >1) Should draft-puig-rpsec-generic-requirements-01.txt be accepted as > > a WG work item? > > No. This document is a hodge podge. It mixes the authors's solution > ideas with requirements statements. True. The purpose of the current state of the document is to provide input for discussion within the WG. Such a document cannot be directly the reflect of a consensus that has not yet been discussed ! And setting generic requirements is certainly as much a matter of reaching to a consensus as of considering technical issues; may be even more. However, current state does not preclude this document from being relevant wrt WG charter. > It is very uneven in its > treatment of topics, and has numerous errors, e.g., characterizing > anti-replay as a crypto mechanism. Right. We had major TOC changes on this document, so one may consider some parts are messy. However, we made these changes according to overall feedback we received and I think this was the good way to go. Also, we will certainly welcome your feedback on the different points you raise, as we value your skills. Regarding anti-replay, I confess that I have a natural tendency to bundle it with integrity and authentication, as anti-replay alone is usually worthless; this is a pragmatic point of view rather than a functional classification. If you think this distinction is important, we will arrange sections differently. However, I think that, *currently*, features usefulness should be valued and discussed much more than the accuracy of their classification. > It is not a generic requirements > document, as the title suggests. This is also a *draft*, a work in progress. If it is irrelevant with the topics addressed by the WG, then it will get rejected sooner or later and this will be perfectly normal. But better than just waiting for this, you also have the power to influence its content and to guide it with your views on the topic through your comments. Whether this doc moves to a wg item or not, I will soon start successive calls for feedback on the different parts. We have to move forward. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 11 07:05:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26618 for ; Thu, 11 Dec 2003 07:05:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPYm-0008Vj-AB for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 07:04:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBC4m0X032709 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 07:04:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPYm-0008VU-6k for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 07:04:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26602 for ; Thu, 11 Dec 2003 07:04:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPYh-00019Z-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 07:04:43 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUPYg-00019W-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 07:04:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPY1-0008UH-EQ; Thu, 11 Dec 2003 07:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPXO-0008TH-On for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 07:03:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26592 for ; Thu, 11 Dec 2003 07:03:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPXJ-00019A-00 for rpsec@ietf.org; Thu, 11 Dec 2003 07:03:17 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AUPXJ-00018X-00 for rpsec@ietf.org; Thu, 11 Dec 2003 07:03:17 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBBC1q506282; Thu, 11 Dec 2003 07:01:52 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Dec 2003 07:01:53 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75407DCFF7A@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Russ White , "Lakshminath Dondeti" Cc: Tony Tauber , rpsec@ietf.org Subject: RE: [RPSEC] Consensus calls Date: Thu, 11 Dec 2003 07:01:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BFDE.90171986" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3BFDE.90171986 Content-Type: text/plain Russ, Somehow, may be requirements should be done in the same working groups that the protocol belongs to. Form what your are saying to happen, it means that this WG should have the expertize in the specific protocol that is being addressed and on top of that the security experts. It might be easier to just add the security experts to the original "owner" group. This is just my two cents. Abbie > -----Original Message----- > From: Russ White [mailto:ruwhite@cisco.com] > Sent: Thursday, December 11, 2003 6:52 AM > To: Dondeti, Lakshminath [BL60:1A14:EXCH] > Cc: Tony Tauber; rpsec@ietf.org > Subject: Re: [RPSEC] Consensus calls > > > > > I am just curious about item 2 below. Do you mean just protocol > > specific threats and requirements, or solutions as well? > > RPsec would take on requirements work, not solution work, > with this change. In other words, RPsec could provide the > requirements docs that other working groups would use to > build solutions in their specific protocols. > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > ------_=_NextPart_001_01C3BFDE.90171986 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [RPSEC] Consensus calls

Russ,

Somehow, may be requirements should be done in the = same working groups that the protocol belongs to.

Form what your are saying to happen, it means that = this WG should have the expertize in the specific protocol that is = being addressed and on top of that the security experts. It might be = easier to just add the security experts to the original = "owner" group.

This is just my two cents.

Abbie

> -----Original Message-----
> From: Russ White [mailto:ruwhite@cisco.com]
> Sent: Thursday, December 11, 2003 6:52 = AM
> To: Dondeti, Lakshminath = [BL60:1A14:EXCH]
> Cc: Tony Tauber; rpsec@ietf.org
> Subject: Re: [RPSEC] Consensus calls
>
>
>
> > I am just curious about item 2 = below.  Do you mean just protocol
> > specific threats and requirements, or = solutions as well?
>
> RPsec would take on requirements work, not = solution work,
> with this change. In other words, RPsec could = provide the
> requirements docs that other working groups = would use to
> build solutions in their specific = protocols.
>
> :-)
>
> Russ
>
> __________________________________
> riw@cisco.com CCIE <>< Grace = Alone
>
>
> = _______________________________________________
> RPSEC mailing list
> RPSEC@ietf.org
> https://www1.ietf.org/mailman/listinfo/rpsec
>

------_=_NextPart_001_01C3BFDE.90171986-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 11 07:12:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26851 for ; Thu, 11 Dec 2003 07:12:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPfl-0000aq-Nj for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 07:12:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBCC169002274 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 07:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPfl-0000ab-KC for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 07:12:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26830 for ; Thu, 11 Dec 2003 07:11:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPfi-0001KW-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 07:11:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUPfi-0001KT-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 07:11:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPfl-0000YN-D5; Thu, 11 Dec 2003 07:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPfT-0000XW-Gf for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 07:11:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26809 for ; Thu, 11 Dec 2003 07:11:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPfO-0001Js-00 for rpsec@ietf.org; Thu, 11 Dec 2003 07:11:38 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AUPfO-0001JZ-00 for rpsec@ietf.org; Thu, 11 Dec 2003 07:11:38 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 11 Dec 2003 12:12:26 +0000 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBBCB7xg013129; Thu, 11 Dec 2003 07:11:07 -0500 (EST) Received: from dhcp-64-102-48-212.cisco.com (dhcp-64-102-48-212.cisco.com [64.102.48.212]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA24586; Thu, 11 Dec 2003 07:11:06 -0500 (EST) Date: Thu, 11 Dec 2003 07:11:08 -0500 (EST) From: Russ White Reply-To: Russ White To: Abbie Barbir cc: Lakshminath Dondeti , Tony Tauber , rpsec@ietf.org Subject: RE: [RPSEC] Consensus calls In-Reply-To: <87609AFB433BD5118D5E0002A52CD75407DCFF7A@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75407DCFF7A@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > Somehow, may be requirements should be done in the same working groups > that the protocol belongs to. > > Form what your are saying to happen, it means that this WG should have > the expertize in the specific protocol that is being addressed and on top > of that the security experts. It might be easier to just add the security > experts to the original "owner" group. And if the protocol specific requirements are done in the protocol working groups, then the protocol working groups will either need to attract or build the security expertise this working group already has access to. It makes more sense to me to build the requirements, at least, where we have the security expertise, and then to hand those off to the protocol working groups for action. There is also some efficiency gained in "centeralizing" the work on requirements documents, and other advantages. BTW, this isn't a "non thought out" decision. It's been discussed for some time among the working group chairs and AD's within routing for at least three IETF's. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 11 07:19:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27117 for ; Thu, 11 Dec 2003 07:19:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPmZ-00014V-Eg for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 07:19:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBCJ3fw004113 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 07:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPmZ-00014G-Ae for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 07:19:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27098 for ; Thu, 11 Dec 2003 07:19:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPmY-0001WQ-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 07:19:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUPmY-0001WN-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 07:19:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPmX-000131-DT; Thu, 11 Dec 2003 07:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUPmN-00012m-Fx for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 07:18:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27092 for ; Thu, 11 Dec 2003 07:18:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUPmM-0001WE-00 for rpsec@ietf.org; Thu, 11 Dec 2003 07:18:50 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AUPmM-0001VK-00 for rpsec@ietf.org; Thu, 11 Dec 2003 07:18:50 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBBCI0I00792; Thu, 11 Dec 2003 07:18:00 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Dec 2003 07:18:01 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75407E2F761@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Russ White Cc: "Lakshminath Dondeti" , Tony Tauber , rpsec@ietf.org Subject: RE: [RPSEC] Consensus calls Date: Thu, 11 Dec 2003 07:17:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BFE0.D128050A" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3BFE0.D128050A Content-Type: text/plain Russ, There are two sides to the coin. Abbie > -----Original Message----- > From: Russ White [mailto:ruwhite@cisco.com] > Sent: Thursday, December 11, 2003 7:11 AM > To: Barbir, Abbie [CAR:1A11:EXCH] > Cc: Dondeti, Lakshminath [BL60:1A14:EXCH]; Tony Tauber; rpsec@ietf.org > Subject: RE: [RPSEC] Consensus calls > > > > > Somehow, may be requirements should be done in the same > working groups > > that the protocol belongs to. > > > > Form what your are saying to happen, it means that this WG > should have > > the expertize in the specific protocol that is being > addressed and on > > top of that the security experts. It might be easier to > just add the > > security experts to the original "owner" group. > > And if the protocol specific requirements are done in the > protocol working groups, then the protocol working groups > will either need to attract or build the security expertise > this working group already has access to. It makes more sense > to me to build the requirements, at least, where we have the > security expertise, and then to hand those off to the > protocol working groups for action. > > There is also some efficiency gained in "centeralizing" the > work on requirements documents, and other advantages. > > BTW, this isn't a "non thought out" decision. It's been > discussed for some time among the working group chairs and > AD's within routing for at least three IETF's. > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > ------_=_NextPart_001_01C3BFE0.D128050A Content-Type: text/html RE: [RPSEC] Consensus calls

Russ,

There are two sides to the coin.

Abbie

> -----Original Message-----
> From: Russ White [mailto:ruwhite@cisco.com]
> Sent: Thursday, December 11, 2003 7:11 AM
> To: Barbir, Abbie [CAR:1A11:EXCH]
> Cc: Dondeti, Lakshminath [BL60:1A14:EXCH]; Tony Tauber; rpsec@ietf.org
> Subject: RE: [RPSEC] Consensus calls
>
>
>
> > Somehow, may be requirements should be done in the same
> working groups
> > that the protocol belongs to.
> >
> > Form what your are saying to happen, it means that this WG
> should have
> > the expertize in the specific protocol that is being
> addressed and on
> > top of that the security experts. It might be easier to
> just add the
> > security experts to the original "owner" group.
>
> And if the protocol specific requirements are done in the
> protocol working groups, then the protocol working groups
> will either need to attract or build the security expertise
> this working group already has access to. It makes more sense
> to me to build the requirements, at least, where we have the
> security expertise, and then to hand those off to the
> protocol working groups for action.
>
> There is also some efficiency gained in "centeralizing" the
> work on requirements documents, and other advantages.
>
> BTW, this isn't a "non thought out" decision. It's been
> discussed for some time among the working group chairs and
> AD's within routing for at least three IETF's.
>
> :-)
>
> Russ
>
> __________________________________
> riw@cisco.com CCIE <>< Grace Alone
>
>

------_=_NextPart_001_01C3BFE0.D128050A-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 11 08:03:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28679 for ; Thu, 11 Dec 2003 08:03:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUQTB-0002eh-4z for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 08:03:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBD358Z010204 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 08:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUQTB-0002eV-0b for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 08:03:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28663 for ; Thu, 11 Dec 2003 08:03:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUQTA-0002gu-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 08:03:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUQT9-0002gr-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 08:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUQT6-0002d5-UK; Thu, 11 Dec 2003 08:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUQSx-0002cg-JH for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 08:02:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28653 for ; Thu, 11 Dec 2003 08:02:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUQSw-0002gP-00 for rpsec@ietf.org; Thu, 11 Dec 2003 08:02:50 -0500 Received: from colossus.systems.pipex.net ([62.241.160.73]) by ietf-mx with esmtp (Exim 4.12) id 1AUQSv-0002fp-00 for rpsec@ietf.org; Thu, 11 Dec 2003 08:02:49 -0500 Received: from tom3 (1Cust191.tnt29.lnd3.gbr.da.uu.net [62.188.120.191]) by colossus.systems.pipex.net (Postfix) with SMTP id 1EC7316000184; Thu, 11 Dec 2003 13:02:18 +0000 (GMT) Message-ID: <004801c3bfe7$04f93f60$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Tony Tauber" , Subject: Re: [RPSEC] Consensus calls Date: Thu, 11 Dec 2003 12:47:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Inline -----Original Message----- From: Tony Tauber To: rpsec@ietf.org Date: 10 December 2003 05:09 Subject: [RPSEC] Consensus calls Yes, I believe that protocol specific work does belong in RPSEC. The work spans two distinct areas, routing and security, and so there is not one clear, right answer. But on balance I see the security considerations as the harder to deal with, the one where greater specialist expertise is needed, that the security group is more likely to have the necessary routing skills than the routing group will have adequate security skills. So do the work in RPSEC. >2) Should the RPSEC charter be amended to allow for the acceptance of > protocol-specific work? (Removing the sentence below should do that.) > > ++> It is also a non-goal at this point to produce new or change the > ++> current security mechanisms in the existing routing protocols. > >3) Should draft-convery-bgpattack-01.txt be accepted as a WG work item? > >4) Should draft-jones-OSPF-vuln-01.txt be accepted as a WG work item? > >(See meeting minutes at http://ietf.org/proceedings/03nov/minutes/rpsec.htm >for more details if desired.) > >Thanks, > >Tony Tom Petch, Network Consultant nwnetworks@dial.pipex.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 11 09:33:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01992 for ; Thu, 11 Dec 2003 09:33:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURsO-0006GJ-NE for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 09:33:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBEXCgN024068 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 09:33:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURsO-0006G7-Iy for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 09:33:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01971 for ; Thu, 11 Dec 2003 09:33:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AURsM-0004vY-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 09:33:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AURsL-0004vV-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 09:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURsD-0006Ey-HG; Thu, 11 Dec 2003 09:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURro-0006EU-4l for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 09:32:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01963 for ; Thu, 11 Dec 2003 09:32:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AURrm-0004vL-00 for rpsec@ietf.org; Thu, 11 Dec 2003 09:32:34 -0500 Received: from machine77.level3.com ([209.244.4.106] helo=scanner1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 1AURrl-0004v2-00 for rpsec@ietf.org; Thu, 11 Dec 2003 09:32:34 -0500 Received: from scanner1.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 8E92A78B15B; Thu, 11 Dec 2003 14:32:02 +0000 (GMT) Received: from buzz.idc1.level3.com (qfe0.buzz.idc1.oss.level3.com [10.1.116.4]) by scanner1.level3.com (Postfix) with ESMTP id 4084178B14C; Thu, 11 Dec 2003 14:32:02 +0000 (GMT) Received: from localhost (ttauber@localhost) by buzz.idc1.level3.com (8.8.8p2+Sun/8.8.8) with ESMTP id OAA04718; Thu, 11 Dec 2003 14:32:01 GMT X-Authentication-Warning: buzz.idc1.level3.com: ttauber owned process doing -bs Date: Thu, 11 Dec 2003 14:32:01 +0000 (GMT) From: Tony Tauber X-X-Sender: ttauber@buzz.idc1.level3.com To: Russ White Cc: Abbie Barbir , Lakshminath Dondeti , rpsec@ietf.org Subject: RE: [RPSEC] Consensus calls In-Reply-To: Message-ID: References: <87609AFB433BD5118D5E0002A52CD75407DCFF7A@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Thu, 11 Dec 2003, Russ White wrote: > > Somehow, may be requirements should be done in the same working > > groups that the protocol belongs to. > > > > Form what your are saying to happen, it means that this WG should > > have the expertize in the specific protocol that is being > > addressed and on top of that the security experts. It might be > > easier to just add the security experts to the original "owner" > > group. If the security in established RPs is wanting, it's because their "owner" groups have failed to add it. Why? Probably because "the world has changed" to the point where security is more of a concern than before; and/or because the security awareness wasn't in those groups. How might we "just add the security experts" to other groups? Also see Russ's "efficiency" below. > And if the protocol specific requirements are done in the protocol > working groups, then the protocol working groups will either need to > attract or build the security expertise this working group already > has access to. It makes more sense to me to build the requirements, > at least, where we have the security expertise, and then to hand > those off to the protocol working groups for action. > > There is also some efficiency gained in "centeralizing" the work on > requirements documents, and other advantages. > > BTW, this isn't a "non thought out" decision. It's been discussed > for some time among the working group chairs and AD's within routing > for at least three IETF's. Whatever people think of how effective RPSEC is now or may be in the future, the guiding philosophy behind its establishment is as Russ outlined above. Part of the hope is, I believe, through "cross-training" more security expertise will diffuse into the protocol-specific groups and RPSEC will no longer be necessary. Also, don't forget "operations" as the third leg of this stool besides "security" and "routing". To paraphrase Radia, perfectly good security mechanisms can be misused through improper implementation _or_ deployment. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 11 09:41:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02251 for ; Thu, 11 Dec 2003 09:41:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURzz-0006yC-GX for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 09:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBEf3Dq026786 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 09:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURzz-0006xx-Cj for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 09:41:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02224 for ; Thu, 11 Dec 2003 09:40:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AURzx-00058B-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 09:41:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AURzw-000588-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 09:41:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURzx-0006vn-Gv; Thu, 11 Dec 2003 09:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURzW-0006uY-U3 for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 09:40:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02211 for ; Thu, 11 Dec 2003 09:40:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AURzV-00057f-00 for rpsec@ietf.org; Thu, 11 Dec 2003 09:40:33 -0500 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=tm3.ca.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 1AURzU-00057c-00 for rpsec@ietf.org; Thu, 11 Dec 2003 09:40:32 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by tm3.ca.alcatel.com (8.12.10/8.12.10) with ESMTP id hBBEePVB023570 for ; Thu, 11 Dec 2003 09:40:25 -0500 (EST) Message-ID: <3FD881D8.8050307@alcatel.com> Date: Thu, 11 Dec 2003 09:40:24 -0500 From: Emanuele Jones Organization: Alcatel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rpsec@ietf.org Subject: Re: [RPSEC] Consensus calls References: <5EF7D95E17BDAD4A968C812E5ABC390B011081D9@KC-MAIL4.kc.umkc.edu> In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B011081D9@KC-MAIL4.kc.umkc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I strongly agree with Ayyasamy and on top of that if one were to search for a definitive analysis on routing protocol threats and attacks today there is no clear authoritative place. So, it would be nice, and make sense, that IETF would provide a security analysis for the routing protocols it owns, so that people could find this information fast and be confident that these documents have been reviewed and approved by IETF. In the end, I am simply hoping that this dispute between central solution (RPSec) and individual WGs does not end up delaying (or canceling) any work for routing protocol specific analysis. In that respect I think this matter should be addressed in RPSec given the current state of things. For example what WG should take care of RIP security analysis? How are we going to guarantee a consistency across these documents if the are done in separate WGs? Just some thoughts, Emanuele Ayyasamy, Senthilkumar (UMKC-Student) wrote: >>1) Should >>draft-puig-rpsec-generic-requirements-01.txt be >>accepted as a WG work item? >> >> > >yes. The draft may be incomplete. But, we should >remember it is work-in-progress. It is hard to get >generic requirements draft complete at first shot. > > > > >>2) Should the RPSEC charter be amended to allow for >>the acceptance of protocol-specific work? >> >> > >yes. I strongly support for protocol-specific requirements >work. It can be integrated or can provide specific input >to the generic requirements document at a later stage. > > > >_______________________________________________ >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 exim@www1.ietf.org Thu Dec 11 10:57:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07837 for ; Thu, 11 Dec 2003 10:57:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTBj-0002R5-DN for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 10:57:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBFvF8T009357 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 10:57:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTBj-0002Qq-9s for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 10:57:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07819 for ; Thu, 11 Dec 2003 10:57:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUTBg-0007IR-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 10:57:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUTBg-0007IO-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 10:57:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTBV-0002OK-Pf; Thu, 11 Dec 2003 10:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTBL-0002Nv-6l for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 10:56:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07807 for ; Thu, 11 Dec 2003 10:56:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUTBI-0007Hx-00 for rpsec@ietf.org; Thu, 11 Dec 2003 10:56:48 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AUTBH-0007Hg-00 for rpsec@ietf.org; Thu, 11 Dec 2003 10:56:47 -0500 Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hBBFuGxA009596 for ; Thu, 11 Dec 2003 07:56:16 -0800 (PST) Received: from bur-mail2.east.sun.com (bur-mail2 [129.148.13.31]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HPQ00KMNMXSQE@bur-mail2.east.sun.com> for rpsec@ietf.org; Thu, 11 Dec 2003 10:56:16 -0500 (EST) Received: from [129.147.60.148] by bur-mail2.east.sun.com (mshttpd); Thu, 11 Dec 2003 07:56:16 -0800 Date: Thu, 11 Dec 2003 07:56:16 -0800 From: Radia Perlman Subject: Re: RE: [RPSEC] Consensus calls To: rpsec@ietf.org Message-id: <45a19454a6.454a645a19@bur-mail2.east.sun.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7bit Content-disposition: inline X-Accept-Language: en Priority: normal Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > How might we "just add the security experts" to other groups? This gives me a chance to rant about one of my pet issues. :-) If we want more cross-collaboration (and we do!), we need to make it easy for someone to come up to speed on what's going on in a group. It isn't reasonable to expect someone (especially someone who is doing us a favor by agreeing to help us) to have to read years of email archives, or get bogged down in details of what is, without any hints written down of why things are the way they are, or learn obscure jargon, or slog through specs that people admit are incomprehensible. Some ideas are: having companion tutorial documents which skip the details that aren't relevant to conceptual understanding, and which also document the arguments (on both sides) of issues that were controversial and all sorts of folklore that would not usually get written down because "everyone knows it by now", an official person charged with periodically summarizing email threads (perhaps a person appointed by the WG chair for each specific issue), perhaps at the area meeting having a summary, not just of which names of documents are in which stage in the official process, but a summary of what the group is about, someone from the group willing to sit down one-on-one with someone wanting to come up to speed (I find this particularly helpful when trying to understand another area). I'm certainly not implying that the Routing area is any more obscure than any other area, by the way. And most of the above ideas are being done sometimes. But I don't think it hurts to keep reminding people about it. :-) Radia _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 11 11:35:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08806 for ; Thu, 11 Dec 2003 11:35:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTmP-0003u5-J6 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 11:35:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBGZ9kt014999 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 11:35:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTmP-0003tq-Fd for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 11:35:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08794 for ; Thu, 11 Dec 2003 11:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUTmO-00008Q-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 11:35:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUTmO-00008N-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 11:35:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTmI-0003sV-Ck; Thu, 11 Dec 2003 11:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTlg-0003rT-EJ for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 11:34:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08781 for ; Thu, 11 Dec 2003 11:34:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUTlf-00007p-00 for rpsec@ietf.org; Thu, 11 Dec 2003 11:34:23 -0500 Received: from machine77.level3.com ([209.244.4.106] helo=scanner1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 1AUTle-00007M-00 for rpsec@ietf.org; Thu, 11 Dec 2003 11:34:23 -0500 Received: from scanner1.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id C5E1778B284; Thu, 11 Dec 2003 16:33:51 +0000 (GMT) Received: from buzz.idc1.level3.com (qfe0.buzz.idc1.oss.level3.com [10.1.116.4]) by scanner1.level3.com (Postfix) with ESMTP id 8132978B191; Thu, 11 Dec 2003 16:33:51 +0000 (GMT) Received: from localhost (ttauber@localhost) by buzz.idc1.level3.com (8.8.8p2+Sun/8.8.8) with ESMTP id QAA18935; Thu, 11 Dec 2003 16:33:51 GMT X-Authentication-Warning: buzz.idc1.level3.com: ttauber owned process doing -bs Date: Thu, 11 Dec 2003 16:33:50 +0000 (GMT) From: Tony Tauber X-X-Sender: ttauber@buzz.idc1.level3.com To: Radia Perlman Cc: rpsec@ietf.org Subject: Re: RE: [RPSEC] Consensus calls In-Reply-To: <45a19454a6.454a645a19@bur-mail2.east.sun.com> Message-ID: References: <45a19454a6.454a645a19@bur-mail2.east.sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , OK, really a tangent, but... On Thu, 11 Dec 2003, Radia Perlman wrote: > > How might we "just add the security experts" to other groups? > > This gives me a chance to rant about one of my pet issues. :-) > > If we want more cross-collaboration (and we do!), we need to make it > easy for someone to come up to speed on what's going on in a group. > It isn't reasonable to expect someone (especially someone who is > doing us a favor by agreeing to help us) to have to read years of > email archives, or get bogged down in details of what is, without > any hints written down of why things are the way they are, or learn > obscure jargon, or slog through specs that people admit are > incomprehensible. I agree. In an effort to get up to speed in this way about different things, one often find the only alternative to dry specifications is either journalism (trade rags) or vendor whitepapers (marketing). It'd be nice to think some alternative is possible, to be sure. > Some ideas are: having companion tutorial documents which skip the > details that aren't relevant to conceptual understanding, and which > also document the arguments (on both sides) of issues that were > controversial and all sorts of folklore that would not usually get > written down because "everyone knows it by now", an official person Documenting the unspoken political undercurrents, now that's the hard part! Tony > charged with periodically summarizing email threads (perhaps a > person appointed by the WG chair for each specific issue), perhaps > at the area meeting having a summary, not just of which names of > documents are in which stage in the official process, but a summary > of what the group is about, someone from the group willing to sit > down one-on-one with someone wanting to come up to speed (I find > this particularly helpful when trying to understand another area). > > I'm certainly not implying that the Routing area is any more obscure > than any other area, by the way. And most of the above ideas are > being done sometimes. But I don't think it hurts to keep reminding > people about it. :-) > > Radia _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 11 11:44:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09080 for ; Thu, 11 Dec 2003 11:44:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTv2-0004Rs-3Q for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 11:44:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBGi4we017094 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 11:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTv1-0004Qg-TP for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 11:44:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09059 for ; Thu, 11 Dec 2003 11:44:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUTv0-0000Pn-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 11:44:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUTv0-0000Pk-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 11:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTuz-0004PX-1x; Thu, 11 Dec 2003 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUTug-0004PA-0p for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 11:43:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09052 for ; Thu, 11 Dec 2003 11:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUTue-0000Pc-00 for rpsec@ietf.org; Thu, 11 Dec 2003 11:43:40 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AUTue-0000PW-00 for rpsec@ietf.org; Thu, 11 Dec 2003 11:43:40 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 5855A3438B for ; Thu, 11 Dec 2003 17:35:11 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 424F43F44D for ; Thu, 11 Dec 2003 17:35:11 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003121117343603661 for ; Thu, 11 Dec 2003 17:34:36 +0100 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 1FAA03F44D for ; Thu, 11 Dec 2003 17:35:11 +0100 (CET) Received: from jjp by localhost with local id 1AUTmM-0000NO-00 for ; Thu, 11 Dec 2003 17:35:06 +0100 Date: Thu, 11 Dec 2003 17:35:06 +0100 From: Jean-Jacques Puig To: rpsec@ietf.org Subject: Re: RE: [RPSEC] Consensus calls Message-ID: <20031211163506.GA31636@ivan.int-evry.fr> Mail-Followup-To: rpsec@ietf.org References: <45a19454a6.454a645a19@bur-mail2.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45a19454a6.454a645a19@bur-mail2.east.sun.com> Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Thu, Dec 11, 2003 at 07:56:16AM -0800, Radia Perlman wrote: > > How might we "just add the security experts" to other groups? > > This gives me a chance to rant about one of my pet issues. :-) > > If we want more cross-collaboration (and we do!), we need to make > it easy for someone to come up to speed on what's going on in a group. > It isn't reasonable to expect someone (especially someone who > is doing us a favor by agreeing to help us) to have to read years of > email archives, or get bogged down in details of what is, without > any hints written down of why things are the way they are, or learn > obscure jargon, or slog through specs that people admit are incomprehensible. > > Some ideas are: having companion tutorial documents which skip the > details that aren't relevant to conceptual understanding, and which > also document the arguments (on both sides) of issues that were > controversial and all sorts of folklore that would > not usually get written down because "everyone knows it by now", > an official person charged with periodically summarizing > email threads (perhaps a person appointed by the WG chair for each specific > issue), perhaps at the area meeting having a summary, not just of which > names of documents are in which stage in the official process, but a summary > of what the group is about, someone from the group willing to sit down > one-on-one with someone wanting to come up to speed (I find this particularly > helpful when trying to understand another area). Yeah. I found this quite appropriate with ikev2 and it certainly makes sense when a group eventually reach to a decision on an non-obvious topic. However, I would have expected such documents to be long life (for ikev2 rationale | tutorial), and to last even after the actual work is over: these also help in understanding choices that were done for the end doc. This information is still valuable. I support this approach. This is all the more important here because we may reach to conclusions some more focused WG would not have agreed on. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 11 12:36:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11469 for ; Thu, 11 Dec 2003 12:36:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUjP-0007Ub-LD for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 12:36:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBHa70E028795 for rpsec-archive@odin.ietf.org; Thu, 11 Dec 2003 12:36:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUjP-0007UM-GJ for rpsec-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 12:36:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11448 for ; Thu, 11 Dec 2003 12:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUUjN-0001tt-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 12:36:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUUjN-0001tq-00 for rpsec-web-archive@ietf.org; Thu, 11 Dec 2003 12:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUjJ-0007SC-Sm; Thu, 11 Dec 2003 12:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUiZ-0007RI-UQ for rpsec@optimus.ietf.org; Thu, 11 Dec 2003 12:35:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11412 for ; Thu, 11 Dec 2003 12:35:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUUiY-0001sc-00 for rpsec@ietf.org; Thu, 11 Dec 2003 12:35:14 -0500 Received: from kc-msxproto3.kc.umkc.edu ([134.193.143.160]) by ietf-mx with esmtp (Exim 4.12) id 1AUUiX-0001sZ-00 for rpsec@ietf.org; Thu, 11 Dec 2003 12:35:13 -0500 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Dec 2003 11:35:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] Consensus calls Date: Thu, 11 Dec 2003 11:33:11 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011081DA@KC-MAIL4.kc.umkc.edu> Thread-Topic: [RPSEC] Consensus calls Thread-Index: AcO/k8D6dUf7NhIBSXqrFI+G5OYgHQAeRiXk From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: Cc: X-OriginalArrivalTime: 11 Dec 2003 17:35:13.0361 (UTC) FILETIME=[21F97410:01C3C00D] Content-Transfer-Encoding: quoted-printable Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > If we want more cross-collaboration (and we do!), we need to make > it easy for someone to come up to speed on what's going on in a=20 > group > [...] > Some ideas are: having companion tutorial documents which skip=20 > the details that aren't relevant to conceptual understanding, =20 To support Radia's idea: =20 http://www.ietf.org/internet-drafts/draft-iab-model-00.txt _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Dec 17 12:35:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21879 for ; Wed, 17 Dec 2003 12:35:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWfZH-00064e-0o for rpsec-archive@odin.ietf.org; Wed, 17 Dec 2003 12:34:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHHYcCm023348 for rpsec-archive@odin.ietf.org; Wed, 17 Dec 2003 12:34:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWfZG-00064V-Rj for rpsec-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 12:34:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21852 for ; Wed, 17 Dec 2003 12:34:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWfZF-00009C-00 for rpsec-web-archive@ietf.org; Wed, 17 Dec 2003 12:34:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWfZ5-00008J-00 for rpsec-web-archive@ietf.org; Wed, 17 Dec 2003 12:34:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWfZ5-00007o-00 for rpsec-web-archive@ietf.org; Wed, 17 Dec 2003 12:34:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWfYf-00060O-Gx; Wed, 17 Dec 2003 12:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWfYa-000608-TL for rpsec@optimus.ietf.org; Wed, 17 Dec 2003 12:33:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21815 for ; Wed, 17 Dec 2003 12:33:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWfYZ-00006y-00 for rpsec@ietf.org; Wed, 17 Dec 2003 12:33:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWfYT-00006a-00 for rpsec@ietf.org; Wed, 17 Dec 2003 12:33:54 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AWfYS-00005e-00; Wed, 17 Dec 2003 12:33:48 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBHHX9A09220; Wed, 17 Dec 2003 12:33:10 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 12:33:10 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75407F0FC87@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "'internet-drafts@ietf.org'" Cc: "'Russ White'" , "Abbie Barbir" , "'Tony Tauber'" , "'rpsec@ietf.org'" Date: Wed, 17 Dec 2003 12:33:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3C4C3.D450E426" Subject: [RPSEC] Request To Publish: draft-ietf-rpsec-routing-threats-04 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_MESSAGE,LINES_OF_YELLING, SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 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_000_01C3C4C3.D450E426 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C4C3.D450E426" ------_=_NextPart_001_01C3C4C3.D450E426 Content-Type: text/plain Please publish the following draft-ietf-rpsec-routing-threats-04 as a WG Draft. Thanks Abbie ------_=_NextPart_001_01C3C4C3.D450E426 Content-Type: text/html Request To Publish: draft-ietf-rpsec-routing-threats-04

Please publish the following

draft-ietf-rpsec-routing-threats-04

as a WG Draft.

Thanks
Abbie

  ------_=_NextPart_001_01C3C4C3.D450E426-- ------_=_NextPart_000_01C3C4C3.D450E426 Content-Type: text/plain; name="draft-ietf-rpsec-routing-threats-04.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-rpsec-routing-threats-04.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: June 16, 2004 S. = Murphy Sparta, = Inc. Y. = Yang Cisco = Systems December 17, = 2003 Generic Threats to Routing Protocols draft-ietf-rpsec-routing-threats-04 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 16, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. Barbir, et al. Expires June 16, 2004 [Page = 1] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Routing Functions Overview . . . . . . . . . . . . . . . . . = 4 3. Generic Routing Protocol Threat Model . . . . . . . . . . . = 5 3.1 Threat Definitions . . . . . . . . . . . . . . . . . . . . . = 5 3.1.1 Threat Sources . . . . . . . . . . . . . . . . . . . . . . . = 6 3.1.2 Threat Consequences . . . . . . . . . . . . . . . . . . . . = 6 4. Generally Identifiable Routing Threats . . . . . . . . . . . = 11 4.1 Deliberate Exposure . . . . . . . . . . . . . . . . . . . . = 11 4.2 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . = 11 4.3 Traffic Analysis . . . . . . . . . . . . . . . . . . . . . . = 12 4.4 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . = 12 4.5 Falsification . . . . . . . . . . . . . . . . . . . . . . . = 13 4.5.1 Falsifications by Originators . . . . . . . . . . . . . . . = 13 4.5.2 Falsifications by Forwarders . . . . . . . . . . . . . . . . = 16 4.6 Interference . . . . . . . . . . . . . . . . . . . . . . . . = 17 4.7 Overload . . . . . . . . . . . . . . . . . . . . . . . . . . = 18 4.8 Byzantine Failures . . . . . . . . . . . . . . . . . . . . . = 18 5. Security Considerations . . . . . . . . . . . . . . . . . . = 19 Normative References . . . . . . . . . . . . . . . . . . . . = 20 Informative References . . . . . . . . . . . . . . . . . . . = 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . = 21 A. Additional Contributors . . . . . . . . . . . . . . . . . . = 22 B. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . = 23 Intellectual Property and Copyright Statements . . . . . . . = 24 Barbir, et al. Expires June 16, 2004 [Page = 2] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 1. Introduction Routing protocols are subject to threats and attacks that can harm individual users or the network operations as a whole. The document provides a summary of generic threats that affect routing protocols. In particular, this work identifies generic threats to routing protocols that include threat sources, threat actions, and threat consequences. A breakdown of routing functions that might be separately attacked is provided. This work should be considered as a precursor to developing a common set of security requirements for routing protocols. While it is well known that bad, incomplete, or poor implementations of routing protocols may, in themselves, lead to routing problems or failures, or may increase the risk of a network being attacked successfully, these issues are not considered here. This document only considers attacks against robust, well considered implementations of routing protocols, as outlined in OSPF [5], IS-IS [6], RIP [7] and BGP [8]. The document is organized as follows: Section 2 provides a review of routing functions. Section 3 defines threats. In section 4, a discussion on generally identifiable routing threat actions is provided. Section 5 addresses security considerations. Barbir, et al. Expires June 16, 2004 [Page = 3] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 2. Routing Functions Overview This section provides an overview of common functions that are = shared among various routing protocols. In general, routing protocols share the following functions: o Transport Subsystem: The routing protocol transmits messages to its neighbors using some underlying protocol. For example, OSPF uses IP, while other protocols may run over TCP. o Neighbor State Maintenance: Neighbor State Maintenance: Neighboring relationship formation is the first step for topology determination. For this reason, routing protocols may need to maintain state information. Each routing protocol may use a different mechanism for determining its neighbors in the routing topology. Some protocols have distinct exchanges through which they establish neighboring relationships, e.g., Hello exchanges = in OSPF. o Database Maintenance: Routing protocols exchange network topology and reachability information. The routers collect this = information in routing databases with varying detail. The maintenance of = these databases is a significant portion of the function of a routing protocol. A router's functions can be divided into control and data plane (protocol traffic vs. data traffic). In a similar fashion, a routing protocol has a control and a data plane. A routing protocol has a control plane that exchanges messages that are intended only for control of the protocol state. Routing protocol data plane uses messages to exchange information that is intended to be used in the forwarding function. For example, the information can be used to establish a forwarding table in each router or to return a description of the route to be used. Routing functions may affect the control and the data planes. However, there may be an emphasis on one of the planes as opposed to the other. For example, neighbor maintenance is likely to focus on the routing protocol control plane, while database maintenance may focus on the data plane. Barbir, et al. Expires June 16, 2004 [Page = 4] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 3. Generic Routing Protocol Threat Model The model developed in this section can be used to identify threats to any routing protocol. It examines attacks which can be launched against routing from subverted entities within the routing system = and from entities outside the routing system. Both of these types of entities are called unauthorized entities. Routing protocols are subject to threats at the control and data planes and at the functional level. At the control plane level, control and data plane are subject to attack. An attacker may be = able to break a neighboring (e.g., peering, adjacency) relationship. This type of attack can impact the network routing behavior in the affected routers and likely the surrounding neighborhood. An = attacker who is able to break a database exchange between two routers can = also affect routing behavior. In the routing protocol data plane, an attacker who is able to introduce bogus data can have a strong = effect on the behavior of routing in the neighborhood. At the routing function level, threats can affect the transport subsystem, where the routing protocol can be subject to attacks on its underlying protocol. At the neighbor state maintenance level, there are threats that can lead to attacks that can disrupt the neighboring relationship with widespread consequences. For example, in BGP, if a router receives a CEASE message, it can lead to = breaking its neighboring relationship to other routers. There are threats against the database maintenance functionality. = For example, the information in the database must be authentic and authorized. Threats that jeopardize this information can affect the routing functionality in the overall network. For example, if an = OSPF router sends LSAs with the wrong Advertising Router, the receivers will compute an SPF tree that is incorrect and might not forward the traffic. If a BGP router advertises a NLRI that it is not authorized to advertise, then receivers might forward that NLRI's traffic = toward that router and the traffic would not be deliverable. A PIM router might transmit a JOIN message to receive multicast data it would otherwise not receive. 3.1 Threat Definitions In this work, a threat is defined as a motivated, capable adversary. This characterization of threats clearly distinguishes threats from attacks. By modeling the motivations (attack goals) and capabilities of the adversaries who are threats, one can better understand what classes of attacks these threats may mount and thus what types of countermeasures will be required to deal with these attacks. In [1], a threat is defined as a potential for violation of security, which Barbir, et al. Expires June 16, 2004 [Page = 5] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 exists when there is a circumstance, capability, action, or event that could breach security and cause harm. Threats can be = categorized based on various rules, such as threat sources, threat actions, threat consequences, threat consequence zones, and threat = consequence periods. 3.1.1 Threat Sources There are many sources for threats that may affect routing = protocols. In some cases, unauthorized entities such as attackers may illegally participate in the routing operations. In other circumstances, there are threats to routing protocols from entities that are running incorrect code, or using invalid configurations. Threats can originate from outsiders or insiders. An insider is an authorized participant in the routing protocol. An outsider is any other host or network. A particular router determines if a host is = an outsider or an insider. In general, threats can be classified into the following categories based on their sources [2]: o Threats that result from subverted links: A link becomes = subverted when an attacker gains access to (or control) it through a physical medium. The attacker can then take control over the = link. This threat can result from the lack (or the use of weak) access control mechanisms as applied to physical mediums or channels. = The attacker may eavesdrop, replay, delay, or drop routing messages, or break routing sessions between authorized routers, without participating in the routing exchange. o Threats that result from subverted devices (e.g. routers): A subverted device (router) is an authorized router that may have been broken into by an attacker. The attacker can use the subverted device to inappropriately claim authority for some network resources, or violate routing protocols, such as advertising invalid routing information. 3.1.2 Threat Consequences A threat consequence is a security violation that results from a threat action [1]. The compromise to the behavior of the routing system can damage a particular network or host or can damage the operation of the network as a whole. There are four types of threat consequences: disclosure, deception, disruption, and usurpation [1]. Barbir, et al. Expires June 16, 2004 [Page = 6] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 o Disclosure: Disclosure of routing information happens when a router successfully accesses the information without being authorized. Subverted links can cause disclosure, if routing exchanges lack confidentiality. Subverted devices (routers), can cause disclosure, as long as they are successfully involved in = the routing exchanges. Although inappropriate disclosure of routing information can pose a security threat or be part of a later, larger, or higher layer attack, confidentiality is not generally = a design goal of routing protocols. o Deception: This consequence happens when a legitimate router receives a forged routing message and believes it to be = authentic. Subverted links and/or subverted devices (routers)can cause this consequence if the receiving router lacks the ability to check routing message integrity or origin authentication. o Disruption: This consequence occurs when a legitimate router's operation is being interrupted or prevented. Subverted links can cause this by replaying, delaying, or dropping routing messages, or breaking routing sessions between legitimate routers. = Subverted devices (routers) can cause this consequence by sending false routing messages, interfering with normal routing exchanges, or flooding unnecessary messages. (DoS is a common threat action causing disruption.) o Usurpation: This consequence happens when an attacker gains control over a legitimate router's services/functions. Subverted links can cause this by delaying or dropping routing exchanges, = or replaying out-dated routing information. Subverted routers can cause this consequence by sending false routing information or interfering routing exchanges. Note: an attacker does not have to directly control a router to control its services. For example, in Figure 1, Network 1 is dual-homed through Router A and Router B, and Router A is preferred. However, Router B is compromised and advertises a better metric. Consequently, devices on the Internet choose the path through Router B to reach Network 1. In this way, Router B steals the data traffic and Router A surrenders its control of the services to Router B. = This depicted in Figure 1. Barbir, et al. Expires June 16, 2004 [Page = 7] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 +-------------+ +-------+ | Internet |---| Rtr A | +------+------+ +---+---+ | | | | | | | *-+-* +-------+ / \ | Rtr B |----------* N 1 * +-------+ \ / *---* Figure 1: Dual-homed Network Several threat consequences might be caused by a single threat action. In Figure 1, there exist at least two consequences: routers using Router B to reach Network 1 are deceived, while Router A is usurped. Within the context of the threat consequences described above, = damage that might result from attacks against the network as a whole may include: o Network congestion: more data traffic is forwarded through some portion of the network than would otherwise need to carry the traffic, o Blackhole: the consequence is that "packets go in, but go nowhere", o Looping: data traffic is forwarded along a route that loops, so that the data is never delivered (resulting in network congestion), o Partition: some portion of the network believes that it is partitioned from the rest of the network when it is not, o Churn: the forwarding in the network changes (unnecessarily) at a rapid pace, resulting in large variations in the data delivery patterns (and adversely affecting congestion control techniques), o Instability: the protocol becomes unstable so that convergence on a global forwarding state is not achieved, and o Overload: the protocol messages themselves become a significant portion of the traffic the network carries. Barbir, et al. Expires June 16, 2004 [Page = 8] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 The damage that might result from attacks against a particular host or network address may include: o Starvation: data traffic destined for the network or host is forwarded to a part of the network that cannot deliver it, o Eavesdrop: data traffic is forwarded through some router or network that would otherwise not see the traffic, affording an opportunity to see the data or at least the data delivery = pattern, o Cut: some portion of the network believes that it has no route to the host or network when it is in fact connected, o Delay: data traffic destined for the network or host is forwarded along a route that is in some way inferior to the route it would otherwise take, o Looping: data traffic for the network or host is forwarded along = a route that loops, so that the data is never delivered It is important to consider all compromises, because some security solutions can protect against one attack but not against others. It might be possible to design a security solution that protects = against an attack that eavesdropped on one destination's traffic without protecting against an attack that overwhelmed a router. Similarly, = it is possible to design a security solution that prevents a starvation attack against one host, but not against a network wide resources. The security requirements must be clear as to which compromises are being avoided and which compromises must be addressed by other = means (e.g., by administrative means outside the protocol). 3.1.2.1 Threat Consequence Zone A threat consequence zone covers the area within which the network operations have been affected by threat actions. Possible threat consequence zones can be classified as: a single link or router, multiple routers (within a single routing domain), a single routing domain, multiple routing domains, or the global Internet. The threat consequence zone varies based on the threat action and origin. Similar threat actions that happened at different locations may = cause totally different threat consequence. For example, when a = compromised link breaks the routing session between a distribution router and a stub router, only reachability to and from the network devices attached to the stub router will be impaired. In other words, the threat consequence zone is a single router. In another case, if the compromised router is located between a customer edge router and its corresponding provider edge router, such an action might cause the whole customer site to lose its connection. In this case, the threat Barbir, et al. Expires June 16, 2004 [Page = 9] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 consequence zone might be a single routing domain. 3.1.2.2 Threat Consequence Periods Threat consequence period is defined as a portion of time during which the network operations are been impacted by the threat consequences. The threat consequence period is influenced by, but = not totally dependent on the duration of the threat action. In some cases, the network operations will get back to normal as soon as the threat action has been stopped. In other cases, however, threat consequences may persist longer than the threat action. For example, in the original ARPANET link-state algorithm, some errors in a = router introduced three instances of an LSA. All of them flooded = throughout the network continuously, until the entire network was power cycled [3]. Barbir, et al. Expires June 16, 2004 [Page = 10] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 4. Generally Identifiable Routing Threats This section addresses generally identifiable and recognized threat actions against routing protocols. The threat actions are not necessarily specific to individual protocols but may be present in one or more of the common routing protocols in use today. 4.1 Deliberate Exposure Deliberate Exposure occurs when an attacker takes control of a = router and intentionally releases routing information directly to devices that, otherwise, should not receive the exposed information. In some cases, the receiving devices (e.g. routers) may not be authorized to access the leaked routing information. Deliberate exposure is always a threat action; however, the exposure of routing information may = not be. The consequence of deliberate exposure is the disclosure of routing information. The threat consequence zone of deliberate exposure depends on the routing information that the attackers have exposed. The more knowledge they have exposed, the bigger the threat consequence zone. The threat consequence period of deliberate exposure might be longer than the duration of the action itself. The routing information exposed will not be out-dated until there is a topology change of = the exposed network. 4.2 Sniffing Sniffing is an action whereby attackers monitor and/or record the routing exchanges between authorized routers. Attackers can use subverted links to sniff for routing information. Attackers can also sniff data plane information (however, this is out of scope of the current work). The consequence of sniffing is disclosure of routing information. The threat consequence zone of sniffing depends on the attacker's location, the routing protocol type, and the routing information = that has been recorded. For example, if the subverted link is in an OSPF totally stubby area, the threat consequence zone should be limited = to the whole area. An attacker that is sniffing a subverted link in an EBGP session can gain knowledge of multiple routing domains. The threat consequence period might be longer than the duration of the action. If an attacker stops sniffing a subverted link their Barbir, et al. Expires June 16, 2004 [Page = 11] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 acquired knowledge will not be out-dated until there is a topology change of the affected network. 4.3 Traffic Analysis Traffic analysis is an action whereby attackers gain routing information by analyzing the characteristics of the data traffic on = a subverted link. Traffic analysis threats can affect any data that is sent over a communication link. This threat is not peculiar to routing protocols and is included here for completeness. The consequence of data traffic analysis is the disclosure of = routing information. For example, the source and destination IP addresses of the data traffic, and the type, magnitude, and volume of traffic can be disclosed. The threat consequence zone of the traffic analysis depends on the attacker's location and what data traffic has passed through. A subverted link at the network core should be able to disclose more information than its counterpart at the edge. The threat consequence period might be longer than the duration of the traffic analysis. After the attacker stops traffic analysis, its knowledge will not be out-dated until there is a topology change of the disclosed network. 4.4 Spoofing Spoofing occurs when an illegitimate device assumes the identity of = a legitimate one. Spoofing in and of itself is often not the true attack. Spoofing is special in that it can be used to carry out = other threat actions causing other threat consequences. An attacker can = use spoofing as a means for launching other types of attacks. For example, if an attacker succeeds in spoofing the identity of a router, the attacker can act as a masquerading router. In other situations, the spoofing router can be used to send out unrealistic routing information that might cause the disruption of network services. There are a few cases where spoofing can be an attack in and of itself. For example, messages from an attacker which spoof the identity of a legitimate router may cause a neighbor relationship to form and deny the formation of the relationship with the legitimate router. The consequences of spoofing are: o The disclosure of routing information: The spoofing router will = be Barbir, et al. Expires June 16, 2004 [Page = 12] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 able to gain access to the routing information. o The deception of peer relationship: The authorized routers, which exchange routing messages with the spoofing router, do not = realize they are neighboring with a router that is faking another = router's identity. The threat consequence zone covers: o The consequence zone of the fake peer relationship will be = limited to those routers trusting the attacker's claimed identity. o The consequence zone of the disclosed routing information depends on the attacker's location, the routing protocol type, and the routing information that has been exchanged between the attacker and its deceived neighbors. Note: This section focus on addressing spoofing as a threat on its own. However, spoofing creates conditions for other threats. Other consequences are considered falsifications and are treated in the next section. 4.5 Falsification Falsification is an intentional action whereby false routing information is sent by a subverted router. To falsify the routing information, an attacker has to be either the originator or a forwarder of the routing information. It cannot be a receiver-only. False routing information describes the network in an unrealistic fashion, whether or not intended by the authoritative network administrator. 4.5.1 Falsifications by Originators An originator of routing information can launch the falsifications that are described in the next sections. 4.5.1.1 Overclaiming Overclaiming occurs when a subverted router advertises its control = of some network resources, while in reality it does not, or the advertisement is not authorized. This is given in Figure 2 and = Figure 3. Barbir, et al. Expires June 16, 2004 [Page = 13] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 +-------------+ +-------+ +-------+ | Internet |---| Rtr B |---| Rtr A | +------+------+ +-------+ +---+---+ | . | | | . | *-+-* +-------+ / \ | Rtr C |------------------* N 1 * +-------+ \ / *---* Figure 2: Overclaiming-1 +-------------+ +-------+ +-------+ | Internet |---| Rtr B |---| Rtr A | +------+------+ +-------+ +-------+ | | | | *---* +-------+ / \ | Rtr C |------------------* N 1 * +-------+ \ / *---* Figure 3: Overclaiming-2 The above figures provide examples of overclaiming. Router A, the attacker, is connected to the Internet through Router B. Router C is authorized to advertise its link to Network 1. In Figure 2, Router A controls a link to Network 1, but is not authorized to advertise it. In Figure 3, Router A does not control such a link. But in either case, Router A advertises the link to the Internet, through Router = B. Compromised routers, unauthorized routers, and masquerading routers can overclaim network resources. The consequence of overclaiming includes: o Usurpation of the overclaimed network resources. In Figure 2 and Figure 3, usurpation of Network 1 can occur when Router B (or other routers on the Internet, (not shown in the figures)) believes that Router A provides the best path to reach the = Network 1. As a result, routers forward data traffic, destined to Network Barbir, et al. Expires June 16, 2004 [Page = 14] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 1 to Router A. The best result is that the data traffic uses an unauthorized path, as in Figure 2. The worst case is that the = data never reaches the destination Network 1, as in Figure 3. The ultimate consequence is Router A gaining control over Network 1's services, by controlling the data traffic. o Usurpation of the legitimate advertising routers. In Figure 2 and Figure 3 Router C is the legitimate advertiser of Network 1. By overclaiming, Router A also controls (partially or totally) the services/functions provided by the Router C. (This is NOT a disruption, because Router C is operating in a way intended by = the authoritative network administrator.) o Deception of other routers. In Figure 2 and Figure 3, Router B, = or other routers on the Internet, might be deceived to believe the path through Router A is the best. o Disruption of data planes on some routers. This might happen to routers that are on the path that is used by other routers to = each the overclaimed network resources through the attacker. In Figure 2 and Figure 3, when other routers on the Internet are deceived, they will forward the data traffic to Router B, which might be overloaded. The threat consequence zone varies based on the consequence: o Where usurpation is concerned, the consequence zone covers the network resources that are overclaimed by the attacker (Network 1 in Figure 2 and 3), and the routers that are authorized to advertise the network resources but lose the competition against the attacker(Router C in Figure 2 and Figure 3). o Where deception is concerned, the consequence zone covers the routers that do believe the attacker's advertisement and use the attacker to reach the claimed networks (Router B and other deceived routers on the Internet in Figure 2 and Figure 3). o Where disruption is concerned, the consequence zone includes the routers that are on the path of misdirected data traffic (Router = B in Figure 2 and Figure 3). The threat consequence will cease when the attacker stops overclaiming, and will totally disappear when the routing tables are converged. As a result the consequence period is longer than the duration of the overclaiming. Barbir, et al. Expires June 16, 2004 [Page = 15] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 4.5.1.2 Misclaiming A misclaiming threat is defined as an action where an attacker is advertising its authorized control of some network resources in a = way that is not intended by the authoritative network administrator. An attacker can eulogize or disparage when advertising these network resources. Subverted routers, unauthorized routers, and masquerading routers can misclaim network resources. The threat consequences of misclaiming are similar to the consequences of overclaiming. The consequence zone and period are also similar to those of overclaiming. 4.5.2 Falsifications by Forwarders When a legitimate router forwards routing information, it must or must not modify the routing information, depending on the routing information and the routing protocol type. For example, in RIP, the forwarder must modify the routing information by increasing the hop count by 1. On the other hand, the forwarder must not modify the = type 1 LSA in OSPF. In general, forwarders in distance vector routing protocols are authorized to and must modify the routing information, while most forwarders in link state routing protocols are not authorized to and must not modify most routing information. As a forwarder authorized to modify routing message, an attacker might not forward necessary routing information to other authorized routers. 4.5.2.1 Misstatement This is defined as an action whereby the attacker describes route attributes in an incorrect manner. For example, in RIP, the attacker might increase the path cost by two hops instead of one. In BGP, the attacker might delete some AS numbers from the AS PATH. Where forwarding routing information should not be modified, an attacker can launch the following falsifications: o Deletion: Attacker deletes valid data in the routing message. o Insertion: Attacker inserts false data in the routing message. o Substitution: Attacker replaces valid data in the routing message with false data. Barbir, et al. Expires June 16, 2004 [Page = 16] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 o Replaying: Attacker replays out-dated data in the routing = message. All types of attackers (compromised links, compromised routers, unauthorized routers, and masquerading routers) can falsify the routing information when they forward the routing messages. The threat consequences of these falsifications by forwarders are similar to those caused by originators: usurpation of some network resources and related routers; deception of routers using false paths; and disruption of data planes of routers on the false paths. The threat consequence zone and period are also similar. 4.6 Interference Interference is a threat action where an attacker uses a subverted link or router to inhibit the exchanges by legitimate routers. The attacker can do this by adding noise, or by not forwarding packets, or by replaying out-dated packets, or by delaying responses, or by denial of receipts, or by breaking synchronization. Subverted, unauthorized and masquerading routers can slow down their routing exchanges or induce flapping in the routing sessions of legitimate neighboring routers. The consequence of interference is the disruption of routing operations. The consequence zone of interference varies based on the source of the threats: o When a subverted link is used to launch the action, the threat consequence zone covers routers that are using the link to exchange the routing information. An attack on a link can cause consequences at the neighbor maintenance level that may lead to changes in the database. In this case, the consequences can be felt network-wide. o When subverted routers, unauthorized routers, or masquerading routers are the attackers, the threat consequence zone covers routers with which the attackers are exchanging routing information. The threat consequences might disappear as soon as the interference is stopped, or might not totally disappear until the networks have converged. Therefore, the consequence period is equal or longer than the duration of the interference. Barbir, et al. Expires June 16, 2004 [Page = 17] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 4.7 Overload Overload is defined as a threat action whereby attackers place = excess burden on legitimate routers. For example, it is possible for an attacker to overload the control plane. In this regard, it is possible for a compromised router to trigger creation of an = excessive amount of state that routers within the network are not able to handle. In a similar fashion, it is possible for an attacker to overload the data plane. Since the data plane is involved in routing exchanges, overload of the data plane can also influence the routing operations. This section combines overload of the control plane and the data plane i.e., the routing protocol messages and the data traffic, not the control and data plane of the routing protocol itself as discussed in section 2.1). The routing protocol design might have a chance to limit control plane traffic. However, the routing protocol cannot limit the data traffic. Thus, an attacker can affect the behavior of the entire routing system. 4.8 Byzantine Failures As described in [4], "A node with a Byzantine failure may corrupt messages, forge messages, delay messages, or send conflicting messages to different nodes". These faults may arise from routers which have been subverted by an attacker or which have faulty hardware or software. In any case, they represent a threat to = correct operation of routing and routing protocols. The ability of the network to function in the face of such defects = is described as Byzantine robustness and would fall into the scope of a requirements document for routing protocol security which may build from the base established in this document. Barbir, et al. Expires June 16, 2004 [Page = 18] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 5. Security Considerations This entire document is security related. Specifically the document addresses security of routing protocols as associated with threats = to those protocols. In a larger context, this work builds upon the recognition of the IETF community that signaling and control/ management planes of networked devices need strengthening. Routing protocols can be considered part of that signaling and control = plane. However, to date, routing protocols have largely remained = unprotected and open to malicious attacks. This document discusses inter- and intra-domain routing protocol threats that are currently known and lays the foundation for other documents that will discuss security requirements for routing protocols. This document is protocol independent. Barbir, et al. Expires June 16, 2004 [Page = 19] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 Normative References [1] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000. [2] Smith, B et al., "Securing Distance-Vector Routing Protocols", Symposium on Network and Distributed System Security , = February 1997. [3] Rosen, E., "Vulnerabilities of Network Control Protocols: An Example, Computer Communication Review", , July 1981. [4] Perlman, R, "Network Layer Protocols with Byzantine = Robustness", , August 1988 . [5] Moy, J, "OSPF Version 2", RFC 2328, April 1998. [6] Shen, N. et. al., "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 2763 , February 2000. [7] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721 , November 1994. Barbir, et al. Expires June 16, 2004 [Page = 20] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 Informative References [8] Kent, S. et al., "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications , April 2000. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: EMail: abbieb@nortelnetworks.com Sandy Murphy Sparta, Inc. 7075 Samuel Morse Drive Columbia, MD USA Phone: 410-872-1515 x206 EMail: sandy@tislabs.com Yi Yang Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA Phone: EMail: yiya@cisco.com Barbir, et al. Expires June 16, 2004 [Page = 21] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 Appendix A. Additional Contributors This draft would not have been possible save for the excellent efforts and team work characteristics of those listed here. o Dennis Beard- Nortel Networks o Ayman Musharbash - Nortel Networks o Jean-Jacques Puig, int-evry, France o Paul Knight - Nortel Networks o Elwyn Davies - Nortel Networks o Ameya Dilip Pandit - Graduate student - University of Missouri o Senthilkumar Ayyasamy - Graduate student - University of Missouri o Stephen Kent- BBN o Tim Gage - CISCO o James Ng - CISCO o Alvaro Retana - CISCO Barbir, et al. Expires June 16, 2004 [Page = 22] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 Appendix B. Acronyms AS - Autonomous system. Set of routers under a single technical administration. Each AS normally uses a single interior gateway protocol (IGP) and metrics to propagate routing information within the set of routers. Also called routing domain. AS-Path - In BGP, the route to a destination. The path consists of the AS numbers of all routers a packet must go through to reach a destination. BGP - Border Gateway Protocol. Exterior gateway protocol used to exchange routing information among routers in different autonomous systems. LSA - Link-State Announcement NLRI - Network layer reachability information. Information that is carried in BGP packets and is used by MBGP. OSPF - Open Shortest Path First. A link-state IGP that makes routing decisions based on the shortest-path-first (SPF) algorithm (also referred to as the Dijkstra algorithm). Barbir, et al. Expires June 16, 2004 [Page = 23] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances = of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification = can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir, et al. Expires June 16, 2004 [Page = 24] =0C Internet-Draft Generic Threats to Routing Protocols December = 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir, et al. Expires June 16, 2004 [Page = 25] =0C ------_=_NextPart_000_01C3C4C3.D450E426-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 18 15:32:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15485 for ; Thu, 18 Dec 2003 15:32:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4on-0006dO-Mt for rpsec-archive@odin.ietf.org; Thu, 18 Dec 2003 15:32:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIKWLYc025501 for rpsec-archive@odin.ietf.org; Thu, 18 Dec 2003 15:32:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4on-0006dE-Ix for rpsec-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 15:32:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15433 for ; Thu, 18 Dec 2003 15:32:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX4om-00063S-00 for rpsec-web-archive@ietf.org; Thu, 18 Dec 2003 15:32:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX4ol-00063K-00 for rpsec-web-archive@ietf.org; Thu, 18 Dec 2003 15:32:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX4ok-00063H-00 for rpsec-web-archive@ietf.org; Thu, 18 Dec 2003 15:32:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4oU-0006W3-4S; Thu, 18 Dec 2003 15:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX4no-0006NA-OQ for rpsec@optimus.ietf.org; Thu, 18 Dec 2003 15:31:20 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15258; Thu, 18 Dec 2003 15:31:18 -0500 (EST) Message-Id: <200312182031.PAA15258@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rpsec@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 18 Dec 2003 15:31:18 -0500 Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-routing-threats-04.txt Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF. Title : Generic Threats to Routing Protocols Author(s) : A. Barbir, S. Murphy, Y. Yang Filename : draft-ietf-rpsec-routing-threats-04.txt Pages : 25 Date : 2003-12-18 Routing protocols are subject to attacks that can harm individual users or the network operations as a whole. This document provides a description and a summary of generic threats that affects routing protocols in general. The work describes threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rpsec-routing-threats-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rpsec-routing-threats-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-18142900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-routing-threats-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-routing-threats-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-18142900.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Dec 18 16:59:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23851 for ; Thu, 18 Dec 2003 16:59:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6Aj-0002lv-Rz for rpsec-archive@odin.ietf.org; Thu, 18 Dec 2003 16:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBILx5KS010649 for rpsec-archive@odin.ietf.org; Thu, 18 Dec 2003 16:59:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6Aj-0002lg-Na for rpsec-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 16:59:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23826 for ; Thu, 18 Dec 2003 16:59:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6Ah-00056E-00 for rpsec-web-archive@ietf.org; Thu, 18 Dec 2003 16:59:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6Ag-000567-00 for rpsec-web-archive@ietf.org; Thu, 18 Dec 2003 16:59:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX6Ag-000564-00 for rpsec-web-archive@ietf.org; Thu, 18 Dec 2003 16:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6Ae-0002kY-TY; Thu, 18 Dec 2003 16:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6Ac-0002kE-MK for rpsec@optimus.ietf.org; Thu, 18 Dec 2003 16:58:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23819 for ; Thu, 18 Dec 2003 16:58:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6Aa-00055Y-00 for rpsec@ietf.org; Thu, 18 Dec 2003 16:58:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6AY-00055O-00 for rpsec@ietf.org; Thu, 18 Dec 2003 16:58:55 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AX6AY-00055D-00 for rpsec@ietf.org; Thu, 18 Dec 2003 16:58:54 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AX6AY-0002k9-Hy for rpsec@ietf.org; Thu, 18 Dec 2003 21:58:54 +0000 Date: Thu, 18 Dec 2003 13:57:14 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <40162413117.20031218135714@psg.com> To: rpsec@ietf.org In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [RPSEC] Fwd: Last Call: 'Operational Security Requirements for IP Network Infrastructure' to BCP Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,RCVD_NUMERIC_HELO, SUBJ_HAS_SPACES autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Might of interest to the participants in this WG. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: The IESG To: Cc: Date: Wednesday, December 17, 2003, 11:52:51 AM Subject: Last Call: 'Operational Security Requirements for IP Network Infrastructure' to BCP ===8<==============Original message text=============== The IESG has received a request from an individual submitter to consider the following document: - 'Operational Security Requirements for IP Network Infrastructure ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-01-14. The file can be obtained via http://www.ietf.org/internet-drafts/draft-jones-opsec-03.txt ===8<===========End of original message text=========== _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Dec 22 10:06:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19563 for ; Mon, 22 Dec 2003 10:06:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRdP-00046N-CH for rpsec-archive@odin.ietf.org; Mon, 22 Dec 2003 10:06:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMF6Fcj015763 for rpsec-archive@odin.ietf.org; Mon, 22 Dec 2003 10:06:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRdP-00046A-7O for rpsec-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 10:06:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19483 for ; Mon, 22 Dec 2003 10:06:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYRdN-0005wx-00 for rpsec-web-archive@ietf.org; Mon, 22 Dec 2003 10:06:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYRdL-0005wp-00 for rpsec-web-archive@ietf.org; Mon, 22 Dec 2003 10:06:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYRdL-0005wm-00 for rpsec-web-archive@ietf.org; Mon, 22 Dec 2003 10:06:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRdC-00044t-EO; Mon, 22 Dec 2003 10:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRcw-00044E-AL for rpsec@optimus.ietf.org; Mon, 22 Dec 2003 10:05:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19430 for ; Mon, 22 Dec 2003 10:05:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYRcu-0005wI-00 for rpsec@ietf.org; Mon, 22 Dec 2003 10:05:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYRct-0005wB-00 for rpsec@ietf.org; Mon, 22 Dec 2003 10:05:43 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AYRcs-0005ux-00 for rpsec@ietf.org; Mon, 22 Dec 2003 10:05:42 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBMF5Al24148; Mon, 22 Dec 2003 10:05:10 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Dec 2003 10:05:11 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75407F7AE35@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: rpsec@ietf.org Cc: Tony Tauber , riw@cisco.com Date: Mon, 22 Dec 2003 10:05:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C89C.FDB9A000" Subject: [RPSEC] Summary of editorial changes to draft-ietf-rpsec-routing-threats -04 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 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_01C3C89C.FDB9A000 Content-Type: text/plain All, This is a list of changes that were done to the -03 version of the document to make align with the IESG Feedback. 1. Aligned definition of threat with RFC 2828 2. Fixed Blachole definition/consequence 3. In section 2 , fixed who maintain the state in a routing protocol. 4. Done editorial changes to Section 3.1.2 to fix Disruption. 5. Done editorial changes to 4.1 Deliberate Exposure with the references to other routers 6. Improved section 4.2 Sniffing 7. In section 4.5.1.2 Misclaiming added a forward reference to the next section to clarify other consequence of Misclaiming. 8. Various editorial fixes and spelling. In summary, there were only editorial changes to the document with no major changes to content. PS: We need to re-forward the -04 version to IESG ASAP. So please recomment on the draft by no Later than January 7th. Abbie Barbir Nortel Networks ------_=_NextPart_001_01C3C89C.FDB9A000 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Summary of editorial changes to = draft-ietf-rpsec-routing-threats-04

All,

This is a list of changes that were done to the -03 = version of the document to make align with the IESG Feedback.


1. Aligned definition of threat with RFC 2828
2. Fixed Blachole definition/consequence
3. In section 2 , fixed who maintain the state in a = routing protocol.
4. Done editorial changes to Section 3.1.2 to fix = Disruption.
5. Done editorial changes to 4.1 Deliberate Exposure = with the references to other routers
6. Improved section 4.2 Sniffing
7. In section 4.5.1.2 Misclaiming added a forward = reference to the next section to clarify other consequence of = Misclaiming.

8. Various editorial fixes and spelling.


In summary, there were only editorial changes to the = document with no major changes to content.

PS: We need to re-forward the -04 version to IESG = ASAP.

So please recomment on the draft by no Later than = January 7th.


Abbie Barbir
Nortel Networks

------_=_NextPart_001_01C3C89C.FDB9A000-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Dec 22 14:56:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03110 for ; Mon, 22 Dec 2003 14:56:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYWA4-0006pg-Oi for rpsec-archive@odin.ietf.org; Mon, 22 Dec 2003 14:56:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMJuGrh026260 for rpsec-archive@odin.ietf.org; Mon, 22 Dec 2003 14:56:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYWA4-0006pT-LW for rpsec-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 14:56:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03027 for ; Mon, 22 Dec 2003 14:56:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYWA1-0000jr-00 for rpsec-web-archive@ietf.org; Mon, 22 Dec 2003 14:56:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYW9z-0000jW-00 for rpsec-web-archive@ietf.org; Mon, 22 Dec 2003 14:56:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYW9z-0000jR-00 for rpsec-web-archive@ietf.org; Mon, 22 Dec 2003 14:56:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW9p-0006nc-BN; Mon, 22 Dec 2003 14:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYW8n-0006m7-S3 for rpsec@optimus.ietf.org; Mon, 22 Dec 2003 14:55:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02851 for ; Mon, 22 Dec 2003 14:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYW8g-0000dx-00 for rpsec@ietf.org; Mon, 22 Dec 2003 14:54:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYW8A-0000dJ-00 for rpsec@ietf.org; Mon, 22 Dec 2003 14:54:19 -0500 Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AYW8A-0000bw-00 for rpsec@ietf.org; Mon, 22 Dec 2003 14:54:18 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 795AC2D496F; Mon, 22 Dec 2003 14:53:33 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 84021-01-42; Mon, 22 Dec 2003 14:53:32 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8CBC12D4969; Mon, 22 Dec 2003 14:53:32 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id hBMJrWf11247; Mon, 22 Dec 2003 14:53:32 -0500 (EST) Date: Mon, 22 Dec 2003 14:53:32 -0500 From: Jeffrey Haas To: Tony Tauber Cc: rpsec@ietf.org Subject: Re: [RPSEC] Consensus calls Message-ID: <20031222145332.G12249@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tony.tauber@level3.com on Wed, Dec 10, 2003 at 05:08:14AM +0000 X-Virus-Scanned: by amavisd-new at nexthop.com Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Wed, Dec 10, 2003 at 05:08:14AM +0000, Tony Tauber wrote: > 2) Should the RPSEC charter be amended to allow for the acceptance of > protocol-specific work? (Removing the sentence below should do that.) > > ++> It is also a non-goal at this point to produce new or change the > ++> current security mechanisms in the existing routing protocols. To echo several other people here, letting RPSEC help produce requirements as well as analyses of existing protocols will allow the group to not only produce good requirements, but also suggest to other working groups on how to improve their protocols. However, I think that once things have gotten beyond analysis and requirements that details should fall back to the individual protocol WGs. A relationship similar to the OPS group MIB-doctors would probably be appropriate. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec