From exim@www1.ietf.org Wed Aug 6 10:24:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18448 for ; Wed, 6 Aug 2003 10:24:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPD3-0007kt-RR for rpsec-archive@odin.ietf.org; Wed, 06 Aug 2003 10:24:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76EOD4Q029810 for rpsec-archive@odin.ietf.org; Wed, 6 Aug 2003 10:24:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPD3-0007kj-KG for rpsec-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 10:24:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18430 for ; Wed, 6 Aug 2003 10:24:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPD1-0003Bz-00 for rpsec-web-archive@ietf.org; Wed, 06 Aug 2003 10:24:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kPD0-0003Bv-00 for rpsec-web-archive@ietf.org; Wed, 06 Aug 2003 10:24:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPCr-0007j4-CU; Wed, 06 Aug 2003 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPCl-0007iX-VK for rpsec@optimus.ietf.org; Wed, 06 Aug 2003 10:23:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18417 for ; Wed, 6 Aug 2003 10:23:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPCg-0003Bf-00 for rpsec@ietf.org; Wed, 06 Aug 2003 10:23:50 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 19kPCf-0003BQ-00 for rpsec@ietf.org; Wed, 06 Aug 2003 10:23:49 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 5FD2833DE9 for ; Wed, 6 Aug 2003 16:23:18 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id BA5A23F42B for ; Wed, 6 Aug 2003 16:27:40 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003080616231904716 for ; Wed, 06 Aug 2003 16:23:19 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 95D123F42B for ; Wed, 6 Aug 2003 16:27:40 +0200 (CEST) Received: from jjp by localhost with local id 19kPBF-0004XZ-00 for ; Wed, 06 Aug 2003 16:22:21 +0200 Date: Wed, 6 Aug 2003 16:22:21 +0200 From: Jean-Jacques Puig To: Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming Message-ID: <20030806142221.GB11726@ivan.int-evry.fr> Mail-Followup-To: Routing Protocols Security Working Group 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: , Hi ! ('made a cut and paste from 'Threats Draft Issues: Where we Stand?' so that to keep separate threads on specific issues) On Sun, Jul 13, 2003 at 09:57:39PM -0400, Russ White wrote: > > Did we come to some concensus on whether or not underclaiming is a > legitimate threat? I know there was a lengthy discussion on this, but I > don't recall any sort of final concensus around the question. On Fri, Jul 25, 2003 at 10:40:57PM -0400, Russ White wrote: > > We've had some discussion over some of the issues on the threats draft I > had recorded from various places; below is a summary of what I have so far. > We need to get this cleaned up and finished up, so we can move on to > other > work in the near future. > > ... > > Issue 3: Issue 3: Section 4.5, Is underclaiming a threat to routing > systems? > > Status: I seem to remember Sandy and some others arguing against > underclaiming being a threat, while I and others argue for it being a > threat. The reasoning on one side appears to be that you can't force a > router to advertise anything (?), while on the other side the claim is that > this doesn't matter, forcinf information can still cause misrouting to > occur, and thus it's a threat. It seems we need some closure on this > one. After a second reading of the ML mails, WG minutes and drafts on this topic, current positions are the following (please correct me if I'm wrong): For considering underclaiming as a valid attack: Yi, Birger, Russ, Jean-Jacques (and possibly Tony ?). Against considering underclaiming as a valid attack: Sandy, Radia, Curtis (and possibly Stephen ?). Current input regarding this issue is mainly draft-beard-rpsec-routing-threats-01, though further elements were mentioned on the mailing list. Discussion: From RFC 2828: A threat (action ?) can be either "intentional" or "accidental". According to this, if underclaiming is not a valid attack, it may still be an accidental threat action, and as such, can be documented in the threats document (according to current approach of threats definition sect 3.1). There have been input that this attack was against an individual network element ? Does anyone want to develop on this ? I think the router may not be affected by it's own underclaiming, but so is the network it should have advertised; thus a possible target of the attack is a network. Is it an attack against the routing system ? The routing db is affected by underclaiming. If farther on the paths routers make *legitimate* underclaiming of the prefix, only a part of the routing db may be affected. Most consequences already listed in the draft may happen. *Incorrect* distributed routing db is, IMHO, the manifestation of that a threat action against routing occured. How can a routing protocol be protected against such an attack ? The same way such a protocol can check authority for prefix advertisement through an appropriate distributed db (e.g. http://www.isi.edu/~bmanning/inet98.html ). Such a db may announce policies related to routing, and systems REQUIRED (by agreement) to advertise a prefix. This may not be sufficient for forcing the path, yet it allows detection of an incorrect behavior by non subverted devices. Besides, threats are not defined by the existence of a solution to them. Sometimes, when robustness cannot be achieved, detection can and is of great interest to limit the consequence zone. Is it too early for a consensus on this ? Comments are welcome ! -- 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 Aug 6 13:35:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25946 for ; Wed, 6 Aug 2003 13:35:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSBn-0008Lm-W6 for rpsec-archive@odin.ietf.org; Wed, 06 Aug 2003 13:35:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76HZ7qp032092 for rpsec-archive@odin.ietf.org; Wed, 6 Aug 2003 13:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSBn-0008LX-Ss for rpsec-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13:35:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25915 for ; Wed, 6 Aug 2003 13:35:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSBl-0004yk-00 for rpsec-web-archive@ietf.org; Wed, 06 Aug 2003 13:35:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kSBl-0004yh-00 for rpsec-web-archive@ietf.org; Wed, 06 Aug 2003 13:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSBh-0008KN-Q6; Wed, 06 Aug 2003 13:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSBb-0008K7-7M for rpsec@optimus.ietf.org; Wed, 06 Aug 2003 13:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25908 for ; Wed, 6 Aug 2003 13:34:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSBZ-0004ye-00 for rpsec@ietf.org; Wed, 06 Aug 2003 13:34:53 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 19kSBY-0004yQ-00 for rpsec@ietf.org; Wed, 06 Aug 2003 13:34:52 -0400 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 h76HYL327762 for ; Wed, 6 Aug 2003 13:34:21 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Aug 2003 13:34:22 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Routing Protocols Security Working Group Subject: RE: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming Date: Wed, 6 Aug 2003 13:34:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35C40.F7F858FA" 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_01C35C40.F7F858FA Content-Type: text/plain Hi, please provide feedback ASAP so we can incorportae in the next vrsion of the draft, that should be comming in the next two weeks. abbie > -----Original Message----- > From: Jean-Jacques Puig [mailto:Jean-Jacques.Puig@int-evry.fr] > Sent: Wednesday, August 06, 2003 10:22 AM > To: Routing Protocols Security Working Group > Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming > > > Hi ! > > ('made a cut and paste from 'Threats Draft Issues: > Where we Stand?' > so that to keep separate threads on specific issues) > > On Sun, Jul 13, 2003 at 09:57:39PM -0400, Russ White wrote: > > > > Did we come to some concensus on whether or not underclaiming is a > > legitimate threat? I know there was a lengthy discussion on > this, but > > I don't recall any sort of final concensus around the question. > > On Fri, Jul 25, 2003 at 10:40:57PM -0400, Russ White wrote: > > > > We've had some discussion over some of the issues on the > threats draft > > I had recorded from various places; below is a summary of > what I have > > so far. We need to get this cleaned up and finished up, so > we can move > > on to other work in the near future. > > > > ... > > > > Issue 3: Issue 3: Section 4.5, Is underclaiming a threat to routing > > systems? > > > > Status: I seem to remember Sandy and some others arguing against > > underclaiming being a threat, while I and others argue for > it being a > > threat. The reasoning on one side appears to be that you > can't force a > > router to advertise anything (?), while on the other side > the claim is > > that this doesn't matter, forcinf information can still cause > > misrouting to occur, and thus it's a threat. It seems we need some > > closure on this one. > > After a second reading of the ML mails, WG minutes and drafts > on this topic, current positions are the following (please > correct me if I'm > wrong): > > For considering underclaiming as a valid attack: Yi, Birger, > Russ, Jean-Jacques (and possibly Tony ?). > > Against considering underclaiming as a valid attack: Sandy, > Radia, Curtis (and possibly Stephen ?). > > Current input regarding this issue is mainly > draft-beard-rpsec-routing-threats-01, though further elements > were mentioned on the mailing list. > > Discussion: > > From RFC 2828: A threat (action ?) can be either > "intentional" or > "accidental". > According to this, if underclaiming is not a valid > attack, it may > still be an accidental threat action, and as such, can be > documented in the threats document (according to > current approach of > threats definition sect 3.1). > > There have been input that this attack was against an individual > network element ? Does anyone want to develop on this ? > > I think the router may not be affected by it's own > underclaiming, > but so is the network it should have advertised; thus a possible > target of the attack is a network. > > Is it an attack against the routing system ? The routing db is > affected by underclaiming. If farther on the paths routers make > *legitimate* underclaiming of the prefix, only a part of the > routing db may be affected. Most consequences already > listed in the > draft may happen. *Incorrect* distributed routing db > is, IMHO, the > manifestation of that a threat action against routing occured. > > How can a routing protocol be protected against such an > attack ? The > same way such a protocol can check authority for prefix > advertisement through an appropriate distributed db (e.g. > http://www.isi.edu/~bmanning/inet98.html ). Such a db > may announce > policies related to routing, and systems REQUIRED (by > agreement) to > advertise a prefix. This may not be sufficient for > forcing the path, > yet it allows detection of an incorrect behavior by non > subverted > devices. Besides, threats are not defined by the existence of a > solution to them. Sometimes, when robustness cannot be achieved, > detection can and is of great interest to limit the consequence > zone. > > Is it too early for a consensus on this ? > > Comments are welcome ! > > -- > Jean-Jacques Puig > > [homepage] http://www-lor.int-evry.fr/~puig/ > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > ------_=_NextPart_001_01C35C40.F7F858FA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [RPSEC] Threats Draft Issue 3: Section 4.5 = Underclaiming

Hi,
please provide feedback ASAP so we can incorportae = in the next vrsion of the draft, that should be comming in the next two = weeks.

abbie


> -----Original Message-----
> From: Jean-Jacques Puig [mailto:Jean-Jacques.Puig@i= nt-evry.fr]
> Sent: Wednesday, August 06, 2003 10:22 = AM
> To: Routing Protocols Security Working = Group
> Subject: Re: [RPSEC] Threats Draft Issue 3: = Section 4.5 Underclaiming
>
>
> Hi !
>
>       ('made a cut and = paste from 'Threats Draft Issues:
> Where we Stand?'
>       so that to keep = separate threads on specific issues)
>
> On Sun, Jul 13, 2003 at 09:57:39PM -0400, Russ = White wrote:
> >
> > Did we come to some concensus on whether = or not underclaiming is a
> > legitimate threat? I know there was a = lengthy discussion on
> this, but
> > I don't recall any sort of final concensus = around the question.
>
> On Fri, Jul 25, 2003 at 10:40:57PM -0400, Russ = White wrote:
> >
> > We've had some discussion over some of the = issues on the
> threats draft
> > I had recorded from various places; below = is a summary of
> what I have
> > so far. We need to get this cleaned up and = finished up, so
> we can move
> > on to other work in the near = future.
> >
> > ...
> >
> > Issue 3: Issue 3: Section 4.5, Is = underclaiming a threat to routing
> > systems?
> >
> > Status: I seem to remember Sandy and some = others arguing against
> > underclaiming being a threat, while I and = others argue for
> it being a
> > threat. The reasoning on one side appears = to be that you
> can't force a
> > router to advertise anything (?), while on = the other side
> the claim is
> > that this doesn't matter, forcinf = information can still cause
> > misrouting to occur, and thus it's a = threat. It seems we need some
> > closure on this one.
>
> After a second reading of the ML mails, WG = minutes and drafts
> on this topic, current positions are the = following (please
> correct me if I'm
> wrong):
>
> For considering underclaiming as a valid = attack: Yi, Birger,
> Russ, Jean-Jacques  (and possibly Tony = ?).
>
> Against considering underclaiming as a valid = attack: Sandy,
> Radia, Curtis (and possibly Stephen ?).
>
> Current input regarding this issue is mainly =
> draft-beard-rpsec-routing-threats-01, though = further elements
> were mentioned on the mailing list.
>
> Discussion:
>
>       From RFC 2828: A = threat (action ?) can be either
> "intentional" or
>       = "accidental".
>       According to = this, if underclaiming is not a valid
> attack, it may
>       still be an = accidental threat action, and as such, can be
>       documented in = the threats document (according to
> current approach of
>       threats = definition sect 3.1).
>
>       There have been = input that this attack was against an individual
>       network element = ? Does anyone want to develop on this ?
>      
>       I think the = router may not be affected by it's own
> underclaiming,
>       but so is the = network it should have advertised; thus a possible
>       target of the = attack is a network.
>
>       Is it an attack = against the routing system ? The routing db is
>       affected by = underclaiming. If farther on the paths routers make
>       *legitimate* = underclaiming of the prefix, only a part of the
>       routing db may = be affected. Most consequences already
> listed in the
>       draft may = happen. *Incorrect* distributed routing db
> is, IMHO, the
>       manifestation of = that a threat action against routing occured.
>
>       How can a = routing protocol be protected against such an
> attack ? The
>       same way such a = protocol can check authority for prefix
>       advertisement = through an appropriate distributed db (e.g.
>       http://www.isi.edu/~bmanning/inet98.html ). Such = a db
> may announce
>       policies related = to routing, and systems REQUIRED (by
> agreement) to
>       advertise a = prefix. This may not be sufficient for
> forcing the path,
>       yet it allows = detection of an incorrect behavior by non
> subverted
>       devices. = Besides, threats are not defined by the existence of a
>       solution to = them. Sometimes, when robustness cannot be achieved,
>       detection can = and is of great interest to limit the consequence
>       zone.
>
>       Is it too early = for a consensus on this ?
>
>       Comments are = welcome !
>
> --
> Jean-Jacques Puig
>
> [homepage] http://www-lor.int-evry.fr/~puig/
>
> = _______________________________________________
> RPSEC mailing list
> RPSEC@ietf.org
> https://www1.ietf.org/mailman/listinfo/rpsec
>

------_=_NextPart_001_01C35C40.F7F858FA-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Aug 6 15:08:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00351 for ; Wed, 6 Aug 2003 15:08:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTdl-0004ug-Av for rpsec-archive@odin.ietf.org; Wed, 06 Aug 2003 15:08:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76J85xC018885 for rpsec-archive@odin.ietf.org; Wed, 6 Aug 2003 15:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTdl-0004uW-6L for rpsec-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 15:08:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00272 for ; Wed, 6 Aug 2003 15:08:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTdi-0005yk-00 for rpsec-web-archive@ietf.org; Wed, 06 Aug 2003 15:08:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kTdh-0005yh-00 for rpsec-web-archive@ietf.org; Wed, 06 Aug 2003 15:08:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTdh-0004sK-7j; Wed, 06 Aug 2003 15:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPri-0000sG-Jv for rpsec@optimus.ietf.org; Wed, 06 Aug 2003 11:06:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19570 for ; Wed, 6 Aug 2003 11:06:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPrg-0003Qg-00 for rpsec@ietf.org; Wed, 06 Aug 2003 11:06:12 -0400 Received: from kc-msxproto3.kc.umkc.edu ([134.193.143.160]) by ietf-mx with esmtp (Exim 4.12) id 19kPrf-0003Qd-00 for rpsec@ietf.org; Wed, 06 Aug 2003 11:06:11 -0400 Received: from KC-MAIL3.kc.umkc.edu ([134.193.143.110]) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Wed, 6 Aug 2003 10:06:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming Date: Wed, 6 Aug 2003 10:06:10 -0500 Message-ID: Thread-Topic: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming Thread-Index: AcNcJnK7GO9tvgQXRaezDoKHh9bz+QAA7ziw From: "Huang, Dijiang (UMKC-Student)" To: "Jean-Jacques Puig" , "Routing Protocols Security Working Group" X-OriginalArrivalTime: 06 Aug 2003 15:06:10.0713 (UTC) FILETIME=[45476890:01C35C2C] Content-Transfer-Encoding: base64 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: base64 Content-Transfer-Encoding: base64 DQogICAgICAgIFRoZXJlIGhhdmUgYmVlbiBpbnB1dCB0aGF0IHRoaXMgYXR0YWNrIHdhcyBhZ2Fp bnN0IGFuIGluZGl2aWR1YWwNCiAgICAgICAgbmV0d29yayBlbGVtZW50ID8gRG9lcyBhbnlvbmUg d2FudCB0byBkZXZlbG9wIG9uIHRoaXMgPw0KIA0KPiBVbmRlcmNsYWltaW5nIGNhbiB0YXJnZXQg YXQgYW4gaW5kaXZpZHVhbCBuZXR3b3JrIGVsZW1lbnQuIEl0IGRlcGVuZHMNCj4gb24gd2hhdCBy b3V0aW5nIHByb3RvY29sIGFuZCBmcmFtZXdvcmsgdXNlZC4gRm9yIGV4YW1wbGUsIHRoZSBwYXBl cg0KPiAiSW50ZXJuZXQgVHJhZmZpYyBFbmdpbmVlcmluZyBieSBPcHRpbWl6aW5nIE9TUEYgV2Vp Z2h0cyIgcHJvcG9zZWQNCj4gYSBzdGF0aWMgcm91dGluZyBzY2hlbWUuIEluIHRoZSBleGFtcGxl IHByZXNlbnRlZCBpbiB0aGUgcGFwZXIsIGlmIA0KPiBhbnkgcm91dGVyIG1hbGljaW91c2x5IHVu ZGVyY2xhaW1zIHRoZSBsaW5rIGNvc3QsIGl0IG1pZ2h0IGFmZmVjdA0KPiB0aGUgcGFja2V0IGZv cndhcmRpbmcgYmVoaXZvdXMgb2Ygc29tZSBvdGhlciByb3V0ZXJzIG9yIG1heWJlIG9uZS4gDQo+ IFRoZSBjb25zZXF1ZW5jZSBpcyB0byBjb21wcm9taXNlIHRoZSByb3V0aW5nIHN5c3RlbSAoY2F1 c2UgY29uZ2VzdGlvbiwgZXRjLikuDQo+IFRoZSBhY3VyYWN5IG9mIHByb3BhZ2VkIGxpbmsgY29z dCBpcyBleHRyZW1lbHkgaW1wb3J0YW50IGZvciB0aGlzDQo+IHR5cGUgb2Ygcm91dGluZyBzY2hl bWUsIGNhdXNlIGl0IGNhbiBjaGFuZ2UgdGhlIGRlc2lnbiBnb2FsIG9mIA0KPiB0aGUgcm91dGlu ZyBzY2htZS4gDQogDQo= _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Aug 11 09:47:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15844 for ; Mon, 11 Aug 2003 09:47:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mD15-0003hU-Aj for rpsec-archive@odin.ietf.org; Mon, 11 Aug 2003 09:47:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BDlJ7L014220 for rpsec-archive@odin.ietf.org; Mon, 11 Aug 2003 09:47:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mD15-0003hH-7a for rpsec-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 09:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15810 for ; Mon, 11 Aug 2003 09:47:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mD13-0005zG-00 for rpsec-web-archive@ietf.org; Mon, 11 Aug 2003 09:47:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mD12-0005zC-00 for rpsec-web-archive@ietf.org; Mon, 11 Aug 2003 09:47:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mD0n-0003fC-NE; Mon, 11 Aug 2003 09:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mD0j-0003f1-K0 for rpsec@optimus.ietf.org; Mon, 11 Aug 2003 09:46:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15794 for ; Mon, 11 Aug 2003 09:46:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mD0e-0005yz-00 for rpsec@ietf.org; Mon, 11 Aug 2003 09:46:52 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mD0e-0005yt-00 for rpsec@ietf.org; Mon, 11 Aug 2003 09:46:52 -0400 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 h7BDkJXw009770; Mon, 11 Aug 2003 09:46:19 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn1-66.cisco.com [10.82.224.66]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA02175; Mon, 11 Aug 2003 09:46:18 -0400 (EDT) Date: Mon, 11 Aug 2003 09:46:22 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: Abbie Barbir cc: Routing Protocols Security Working Group Subject: RE: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming In-Reply-To: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , I'm still of the belief that it is a valid threat, though it's hard to define, and impossible to defend against. :-) Russ On Wed, 6 Aug 2003, Abbie Barbir wrote: > Hi, > please provide feedback ASAP so we can incorportae in the next vrsion of the > draft, that should be comming in the next two weeks. > > abbie > > > > -----Original Message----- > > From: Jean-Jacques Puig [mailto:Jean-Jacques.Puig@int-evry.fr] > > Sent: Wednesday, August 06, 2003 10:22 AM > > To: Routing Protocols Security Working Group > > Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming > > > > > > Hi ! > > > > ('made a cut and paste from 'Threats Draft Issues: > > Where we Stand?' > > so that to keep separate threads on specific issues) > > > > On Sun, Jul 13, 2003 at 09:57:39PM -0400, Russ White wrote: > > > > > > Did we come to some concensus on whether or not underclaiming is a > > > legitimate threat? I know there was a lengthy discussion on > > this, but > > > I don't recall any sort of final concensus around the question. > > > > On Fri, Jul 25, 2003 at 10:40:57PM -0400, Russ White wrote: > > > > > > We've had some discussion over some of the issues on the > > threats draft > > > I had recorded from various places; below is a summary of > > what I have > > > so far. We need to get this cleaned up and finished up, so > > we can move > > > on to other work in the near future. > > > > > > ... > > > > > > Issue 3: Issue 3: Section 4.5, Is underclaiming a threat to routing > > > systems? > > > > > > Status: I seem to remember Sandy and some others arguing against > > > underclaiming being a threat, while I and others argue for > > it being a > > > threat. The reasoning on one side appears to be that you > > can't force a > > > router to advertise anything (?), while on the other side > > the claim is > > > that this doesn't matter, forcinf information can still cause > > > misrouting to occur, and thus it's a threat. It seems we need some > > > closure on this one. > > > > After a second reading of the ML mails, WG minutes and drafts > > on this topic, current positions are the following (please > > correct me if I'm > > wrong): > > > > For considering underclaiming as a valid attack: Yi, Birger, > > Russ, Jean-Jacques (and possibly Tony ?). > > > > Against considering underclaiming as a valid attack: Sandy, > > Radia, Curtis (and possibly Stephen ?). > > > > Current input regarding this issue is mainly > > draft-beard-rpsec-routing-threats-01, though further elements > > were mentioned on the mailing list. > > > > Discussion: > > > > From RFC 2828: A threat (action ?) can be either > > "intentional" or > > "accidental". > > According to this, if underclaiming is not a valid > > attack, it may > > still be an accidental threat action, and as such, can be > > documented in the threats document (according to > > current approach of > > threats definition sect 3.1). > > > > There have been input that this attack was against an individual > > network element ? Does anyone want to develop on this ? > > > > I think the router may not be affected by it's own > > underclaiming, > > but so is the network it should have advertised; thus a possible > > target of the attack is a network. > > > > Is it an attack against the routing system ? The routing db is > > affected by underclaiming. If farther on the paths routers make > > *legitimate* underclaiming of the prefix, only a part of the > > routing db may be affected. Most consequences already > > listed in the > > draft may happen. *Incorrect* distributed routing db > > is, IMHO, the > > manifestation of that a threat action against routing occured. > > > > How can a routing protocol be protected against such an > > attack ? The > > same way such a protocol can check authority for prefix > > advertisement through an appropriate distributed db (e.g. > > http://www.isi.edu/~bmanning/inet98.html ). Such a db > > may announce > > policies related to routing, and systems REQUIRED (by > > agreement) to > > advertise a prefix. This may not be sufficient for > > forcing the path, > > yet it allows detection of an incorrect behavior by non > > subverted > > devices. Besides, threats are not defined by the existence of a > > solution to them. Sometimes, when robustness cannot be achieved, > > detection can and is of great interest to limit the consequence > > zone. > > > > Is it too early for a consensus on this ? > > > > Comments are welcome ! > > > > -- > > Jean-Jacques Puig > > > > [homepage] http://www-lor.int-evry.fr/~puig/ > > > > _______________________________________________ > > RPSEC mailing list > > RPSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/rpsec > > > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Aug 11 16:37:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05357 for ; Mon, 11 Aug 2003 16:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mJPe-0003CM-VD for rpsec-archive@odin.ietf.org; Mon, 11 Aug 2003 16:37:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BKb6V3012288 for rpsec-archive@odin.ietf.org; Mon, 11 Aug 2003 16:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mJPe-0003C7-PZ for rpsec-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 16:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05342 for ; Mon, 11 Aug 2003 16:37:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mJPc-0002DZ-00 for rpsec-web-archive@ietf.org; Mon, 11 Aug 2003 16:37:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mJPc-0002DW-00 for rpsec-web-archive@ietf.org; Mon, 11 Aug 2003 16:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mJPa-00039h-0I; Mon, 11 Aug 2003 16:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mJOb-00038g-Np for rpsec@optimus.ietf.org; Mon, 11 Aug 2003 16:36:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05288 for ; Mon, 11 Aug 2003 16:35:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mJOZ-0002CS-00 for rpsec@ietf.org; Mon, 11 Aug 2003 16:35:59 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 19mJOZ-0002CA-00 for rpsec@ietf.org; Mon, 11 Aug 2003 16:35:59 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h7BKZL1J007261; Mon, 11 Aug 2003 16:35:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20030806142221.GB11726@ivan.int-evry.fr> References: <20030806142221.GB11726@ivan.int-evry.fr> Date: Mon, 11 Aug 2003 16:30:42 -0400 To: Jean-Jacques Puig From: Stephen Kent Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming Cc: Routing Protocols Security Working Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Add my vote to the notion that under-claiming ought not be classified as an attack. I think we discussed scenarios in which such action might be justifiable, e.g., as a result of contractual issues now visible to external parties, and thus this is better left out of the list. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Aug 11 17:31:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07236 for ; Mon, 11 Aug 2003 17:31:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mKFs-0005rV-5m for rpsec-archive@odin.ietf.org; Mon, 11 Aug 2003 17:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BLV4ro022530 for rpsec-archive@odin.ietf.org; Mon, 11 Aug 2003 17:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mKFs-0005rJ-2q for rpsec-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 17:31:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07211 for ; Mon, 11 Aug 2003 17:30:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mKFp-0002ao-00 for rpsec-web-archive@ietf.org; Mon, 11 Aug 2003 17:31:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mKFp-0002al-00 for rpsec-web-archive@ietf.org; Mon, 11 Aug 2003 17:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mKFq-0005qC-11; Mon, 11 Aug 2003 17:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mKFo-0005pb-El for rpsec@optimus.ietf.org; Mon, 11 Aug 2003 17:31:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07207 for ; Mon, 11 Aug 2003 17:30:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mKFm-0002ai-00 for rpsec@ietf.org; Mon, 11 Aug 2003 17:30:58 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 19mKFl-0002aU-00 for rpsec@ietf.org; Mon, 11 Aug 2003 17:30:57 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h7BLUPa03705; Mon, 11 Aug 2003 17:30:25 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Mon, 11 Aug 2003 17:30:25 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Jean-Jacques Puig cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming In-Reply-To: <20030806142221.GB11726@ivan.int-evry.fr> Message-ID: References: <20030806142221.GB11726@ivan.int-evry.fr> 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 the topic of "underclaiming", the numerical vote is virtually a tie so let's take out our pragmatic razor. Even those who think that there may be some place where such a thing may be classified as a threat, no one can make any sort of practical sense of what might be gained from doing so. Given that, let's remove it from the document to keep from creating confusion and dilution. I don't subscribe to some argument for cryogenically capturing these things for some future generation to solve. Problems with this approach? Thanks, Tony > > Issue 3: Issue 3: Section 4.5, Is underclaiming a threat to routing > > systems? > > > > Status: I seem to remember Sandy and some others arguing against > > underclaiming being a threat, while I and others argue for it > > being a threat. The reasoning on one side appears to be that you > > can't force a router to advertise anything (?), while on the other > > side the claim is that this doesn't matter, forcinf information > > can still cause misrouting to occur, and thus it's a threat. It > > seems we need some closure on this one. > > After a second reading of the ML mails, WG minutes and drafts on > this topic, current positions are the following (please correct me > if I'm wrong): > > For considering underclaiming as a valid attack: Yi, Birger, Russ, > Jean-Jacques (and possibly Tony ?). > > Against considering underclaiming as a valid attack: Sandy, Radia, > Curtis (and possibly Stephen ?). > > Current input regarding this issue is mainly > draft-beard-rpsec-routing-threats-01, though further elements were > mentioned on the mailing list. > > Discussion: > > From RFC 2828: A threat (action ?) can be either "intentional" or > "accidental". > According to this, if underclaiming is not a valid attack, it may > still be an accidental threat action, and as such, can be > documented in the threats document (according to current approach of > threats definition sect 3.1). > > There have been input that this attack was against an individual > network element ? Does anyone want to develop on this ? > > I think the router may not be affected by it's own underclaiming, > but so is the network it should have advertised; thus a possible > target of the attack is a network. > > Is it an attack against the routing system ? The routing db is > affected by underclaiming. If farther on the paths routers make > *legitimate* underclaiming of the prefix, only a part of the > routing db may be affected. Most consequences already listed in the > draft may happen. *Incorrect* distributed routing db is, IMHO, the > manifestation of that a threat action against routing occured. > > How can a routing protocol be protected against such an attack ? The > same way such a protocol can check authority for prefix > advertisement through an appropriate distributed db (e.g. > http://www.isi.edu/~bmanning/inet98.html ). Such a db may announce > policies related to routing, and systems REQUIRED (by agreement) to > advertise a prefix. This may not be sufficient for forcing the path, > yet it allows detection of an incorrect behavior by non subverted > devices. Besides, threats are not defined by the existence of a > solution to them. Sometimes, when robustness cannot be achieved, > detection can and is of great interest to limit the consequence > zone. > > Is it too early for a consensus on this ? > > Comments are welcome ! > > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Aug 12 06:43:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07967 for ; Tue, 12 Aug 2003 06:43:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mWcO-0006Aa-U1 for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 06:43:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CAh8k8023712 for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 06:43:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mWcO-0006AN-JQ for rpsec-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 06:43:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07958 for ; Tue, 12 Aug 2003 06:43:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mWcK-00070k-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 06:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mWcJ-00070h-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 06:43:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mWcG-00069G-V2; Tue, 12 Aug 2003 06:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mWbz-00068x-Ls for rpsec@optimus.ietf.org; Tue, 12 Aug 2003 06:42:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07950 for ; Tue, 12 Aug 2003 06:42:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mWbv-00070Y-00 for rpsec@ietf.org; Tue, 12 Aug 2003 06:42:39 -0400 Received: from host19.ipowerweb.com ([12.129.211.119]) by ietf-mx with esmtp (Exim 4.12) id 19mWbu-00070E-00 for rpsec@ietf.org; Tue, 12 Aug 2003 06:42:38 -0400 Received: from h00a0ccd1a9ec.ne.client2.attbi.com ([24.128.205.220] helo=GraIyMage.com) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 19mWav-0005kD-00; Tue, 12 Aug 2003 03:41:37 -0700 Message-ID: <3F38C357.E4AF5FFF@GraIyMage.com> Date: Tue, 12 Aug 2003 06:37:11 -0400 From: Eric Gray Reply-To: ewgray@graiymage.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Russ White CC: Abbie Barbir , Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - graiymage.com Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Russ, As I understand it, the premise is that 'underclaiming' is a problem if it results from subversion of a router. In this case, isn't the threat really the subversion of the router? Lots of things can be done with subverted routers... -- Eric Gray Russ White wrote: > I'm still of the belief that it is a valid threat, though it's hard to > define, and impossible to defend against. > > :-) > > Russ > > On Wed, 6 Aug 2003, Abbie Barbir wrote: > > > Hi, > > please provide feedback ASAP so we can incorportae in the next vrsion of the > > draft, that should be comming in the next two weeks. > > > > abbie > > > > > > > -----Original Message----- > > > From: Jean-Jacques Puig [mailto:Jean-Jacques.Puig@int-evry.fr] > > > Sent: Wednesday, August 06, 2003 10:22 AM > > > To: Routing Protocols Security Working Group > > > Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming > > > > > > > > > Hi ! > > > > > > ('made a cut and paste from 'Threats Draft Issues: > > > Where we Stand?' > > > so that to keep separate threads on specific issues) > > > > > > On Sun, Jul 13, 2003 at 09:57:39PM -0400, Russ White wrote: > > > > > > > > Did we come to some concensus on whether or not underclaiming is a > > > > legitimate threat? I know there was a lengthy discussion on > > > this, but > > > > I don't recall any sort of final concensus around the question. > > > > > > On Fri, Jul 25, 2003 at 10:40:57PM -0400, Russ White wrote: > > > > > > > > We've had some discussion over some of the issues on the > > > threats draft > > > > I had recorded from various places; below is a summary of > > > what I have > > > > so far. We need to get this cleaned up and finished up, so > > > we can move > > > > on to other work in the near future. > > > > > > > > ... > > > > > > > > Issue 3: Issue 3: Section 4.5, Is underclaiming a threat to routing > > > > systems? > > > > > > > > Status: I seem to remember Sandy and some others arguing against > > > > underclaiming being a threat, while I and others argue for > > > it being a > > > > threat. The reasoning on one side appears to be that you > > > can't force a > > > > router to advertise anything (?), while on the other side > > > the claim is > > > > that this doesn't matter, forcinf information can still cause > > > > misrouting to occur, and thus it's a threat. It seems we need some > > > > closure on this one. > > > > > > After a second reading of the ML mails, WG minutes and drafts > > > on this topic, current positions are the following (please > > > correct me if I'm > > > wrong): > > > > > > For considering underclaiming as a valid attack: Yi, Birger, > > > Russ, Jean-Jacques (and possibly Tony ?). > > > > > > Against considering underclaiming as a valid attack: Sandy, > > > Radia, Curtis (and possibly Stephen ?). > > > > > > Current input regarding this issue is mainly > > > draft-beard-rpsec-routing-threats-01, though further elements > > > were mentioned on the mailing list. > > > > > > Discussion: > > > > > > From RFC 2828: A threat (action ?) can be either > > > "intentional" or > > > "accidental". > > > According to this, if underclaiming is not a valid > > > attack, it may > > > still be an accidental threat action, and as such, can be > > > documented in the threats document (according to > > > current approach of > > > threats definition sect 3.1). > > > > > > There have been input that this attack was against an individual > > > network element ? Does anyone want to develop on this ? > > > > > > I think the router may not be affected by it's own > > > underclaiming, > > > but so is the network it should have advertised; thus a possible > > > target of the attack is a network. > > > > > > Is it an attack against the routing system ? The routing db is > > > affected by underclaiming. If farther on the paths routers make > > > *legitimate* underclaiming of the prefix, only a part of the > > > routing db may be affected. Most consequences already > > > listed in the > > > draft may happen. *Incorrect* distributed routing db > > > is, IMHO, the > > > manifestation of that a threat action against routing occured. > > > > > > How can a routing protocol be protected against such an > > > attack ? The > > > same way such a protocol can check authority for prefix > > > advertisement through an appropriate distributed db (e.g. > > > http://www.isi.edu/~bmanning/inet98.html ). Such a db > > > may announce > > > policies related to routing, and systems REQUIRED (by > > > agreement) to > > > advertise a prefix. This may not be sufficient for > > > forcing the path, > > > yet it allows detection of an incorrect behavior by non > > > subverted > > > devices. Besides, threats are not defined by the existence of a > > > solution to them. Sometimes, when robustness cannot be achieved, > > > detection can and is of great interest to limit the consequence > > > zone. > > > > > > Is it too early for a consensus on this ? > > > > > > Comments are welcome ! > > > > > > -- > > > Jean-Jacques Puig > > > > > > [homepage] http://www-lor.int-evry.fr/~puig/ > > > > > > _______________________________________________ > > > RPSEC mailing list > > > RPSEC@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > > > > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Aug 12 06:57:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08227 for ; Tue, 12 Aug 2003 06:57:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mWpr-0006SU-9T for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 06:57:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CAv3vP024822 for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 06:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mWpr-0006SH-54 for rpsec-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 06:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08223 for ; Tue, 12 Aug 2003 06:56:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mWpm-00075j-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 06:56:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mWpm-00075g-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 06:56:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mWpp-0006QJ-Gn; Tue, 12 Aug 2003 06:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mWpR-0006Q5-6t for rpsec@optimus.ietf.org; Tue, 12 Aug 2003 06:56:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08220 for ; Tue, 12 Aug 2003 06:56:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mWpM-00075d-00 for rpsec@ietf.org; Tue, 12 Aug 2003 06:56:32 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mWpM-00075a-00 for rpsec@ietf.org; Tue, 12 Aug 2003 06:56:32 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2003 03:56:03 -0700 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 h7CAu1xc009721; Tue, 12 Aug 2003 06:56:01 -0400 (EDT) Received: from dhcp-64-102-60-237.cisco.com (dhcp-64-102-60-237.cisco.com [64.102.60.237]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA01836; Tue, 12 Aug 2003 06:56:01 -0400 (EDT) Date: Tue, 12 Aug 2003 06:57:14 -0400 (EDT) From: Russ White Reply-To: Russ White To: Eric Gray cc: Abbie Barbir , Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming In-Reply-To: <3F38C357.E4AF5FFF@GraIyMage.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.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: , Is that true? With RIP, at least, you can force underclaiming by just being on the wire, and having direct control of the network hardware, I'd guess. Just collide with anything that comes out looking like a RIP update, no? That would cause your peers to think you couldn't reach anything. Of course, the rest of the routing protocols have reliable delivery, so this isn't theorectically possible. On the other side of the issue, if we are going to state that any attack which can only be accomplished through some other attack is really only the "lower level" attack, then we should probably scrub about half of this doc out, right? Again, it comes down to where you draw the line, I think (?). :-) Russ On Tue, 12 Aug 2003, Eric Gray wrote: > Russ, > > As I understand it, the premise is that 'underclaiming' is a problem if > it results from subversion of a router. In this case, isn't the threat really > the subversion of the router? Lots of things can be done with subverted > routers... > > -- > Eric Gray > > Russ White wrote: > > > I'm still of the belief that it is a valid threat, though it's hard to > > define, and impossible to defend against. > > > > :-) > > > > Russ > > > > On Wed, 6 Aug 2003, Abbie Barbir wrote: > > > > > Hi, > > > please provide feedback ASAP so we can incorportae in the next vrsion of the > > > draft, that should be comming in the next two weeks. > > > > > > abbie > > > > > > > > > > -----Original Message----- > > > > From: Jean-Jacques Puig [mailto:Jean-Jacques.Puig@int-evry.fr] > > > > Sent: Wednesday, August 06, 2003 10:22 AM > > > > To: Routing Protocols Security Working Group > > > > Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming > > > > > > > > > > > > Hi ! > > > > > > > > ('made a cut and paste from 'Threats Draft Issues: > > > > Where we Stand?' > > > > so that to keep separate threads on specific issues) > > > > > > > > On Sun, Jul 13, 2003 at 09:57:39PM -0400, Russ White wrote: > > > > > > > > > > Did we come to some concensus on whether or not underclaiming is a > > > > > legitimate threat? I know there was a lengthy discussion on > > > > this, but > > > > > I don't recall any sort of final concensus around the question. > > > > > > > > On Fri, Jul 25, 2003 at 10:40:57PM -0400, Russ White wrote: > > > > > > > > > > We've had some discussion over some of the issues on the > > > > threats draft > > > > > I had recorded from various places; below is a summary of > > > > what I have > > > > > so far. We need to get this cleaned up and finished up, so > > > > we can move > > > > > on to other work in the near future. > > > > > > > > > > ... > > > > > > > > > > Issue 3: Issue 3: Section 4.5, Is underclaiming a threat to routing > > > > > systems? > > > > > > > > > > Status: I seem to remember Sandy and some others arguing against > > > > > underclaiming being a threat, while I and others argue for > > > > it being a > > > > > threat. The reasoning on one side appears to be that you > > > > can't force a > > > > > router to advertise anything (?), while on the other side > > > > the claim is > > > > > that this doesn't matter, forcinf information can still cause > > > > > misrouting to occur, and thus it's a threat. It seems we need some > > > > > closure on this one. > > > > > > > > After a second reading of the ML mails, WG minutes and drafts > > > > on this topic, current positions are the following (please > > > > correct me if I'm > > > > wrong): > > > > > > > > For considering underclaiming as a valid attack: Yi, Birger, > > > > Russ, Jean-Jacques (and possibly Tony ?). > > > > > > > > Against considering underclaiming as a valid attack: Sandy, > > > > Radia, Curtis (and possibly Stephen ?). > > > > > > > > Current input regarding this issue is mainly > > > > draft-beard-rpsec-routing-threats-01, though further elements > > > > were mentioned on the mailing list. > > > > > > > > Discussion: > > > > > > > > From RFC 2828: A threat (action ?) can be either > > > > "intentional" or > > > > "accidental". > > > > According to this, if underclaiming is not a valid > > > > attack, it may > > > > still be an accidental threat action, and as such, can be > > > > documented in the threats document (according to > > > > current approach of > > > > threats definition sect 3.1). > > > > > > > > There have been input that this attack was against an individual > > > > network element ? Does anyone want to develop on this ? > > > > > > > > I think the router may not be affected by it's own > > > > underclaiming, > > > > but so is the network it should have advertised; thus a possible > > > > target of the attack is a network. > > > > > > > > Is it an attack against the routing system ? The routing db is > > > > affected by underclaiming. If farther on the paths routers make > > > > *legitimate* underclaiming of the prefix, only a part of the > > > > routing db may be affected. Most consequences already > > > > listed in the > > > > draft may happen. *Incorrect* distributed routing db > > > > is, IMHO, the > > > > manifestation of that a threat action against routing occured. > > > > > > > > How can a routing protocol be protected against such an > > > > attack ? The > > > > same way such a protocol can check authority for prefix > > > > advertisement through an appropriate distributed db (e.g. > > > > http://www.isi.edu/~bmanning/inet98.html ). Such a db > > > > may announce > > > > policies related to routing, and systems REQUIRED (by > > > > agreement) to > > > > advertise a prefix. This may not be sufficient for > > > > forcing the path, > > > > yet it allows detection of an incorrect behavior by non > > > > subverted > > > > devices. Besides, threats are not defined by the existence of a > > > > solution to them. Sometimes, when robustness cannot be achieved, > > > > detection can and is of great interest to limit the consequence > > > > zone. > > > > > > > > Is it too early for a consensus on this ? > > > > > > > > Comments are welcome ! > > > > > > > > -- > > > > Jean-Jacques Puig > > > > > > > > [homepage] http://www-lor.int-evry.fr/~puig/ > > > > > > > > _______________________________________________ > > > > RPSEC mailing list > > > > RPSEC@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > > > > > > > > > __________________________________ > > riw@cisco.com CCIE <>< Grace Alone > > > > _______________________________________________ > > RPSEC mailing list > > RPSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/rpsec > > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Aug 12 09:39:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12935 for ; Tue, 12 Aug 2003 09:39:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZMf-00035T-NI for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 09:39:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CDd55w011866 for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 09:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZMf-00035J-HU for rpsec-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 09:39:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12898 for ; Tue, 12 Aug 2003 09:39:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZMd-0000TG-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 09:39:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mZMd-0000TD-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 09:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZMa-000349-LC; Tue, 12 Aug 2003 09:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZMH-00032O-Uc for rpsec@optimus.ietf.org; Tue, 12 Aug 2003 09:38:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12879 for ; Tue, 12 Aug 2003 09:38:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZMG-0000Sy-00 for rpsec@ietf.org; Tue, 12 Aug 2003 09:38:40 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 19mZMF-0000Sj-00 for rpsec@ietf.org; Tue, 12 Aug 2003 09:38:39 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h7CDbt1J004561; Tue, 12 Aug 2003 09:37:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> Date: Tue, 12 Aug 2003 09:35:56 -0400 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming Cc: Eric Gray , Abbie Barbir , Routing Protocols Security Working Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 6:57 -0400 8/12/03, Russ White wrote: >Is that true? With RIP, at least, you can force underclaiming by just being >on the wire, and having direct control of the network hardware, I'd guess. >Just collide with anything that comes out looking like a RIP update, no? >That would cause your peers to think you couldn't reach anything. The attack you describe is an active wiretapping problem. I think we need to maintain a clear separation here. I assumed that any reference to underclaiming was in the context of an authenticated, integrity-protected communication by a legitimate router. > >Of course, the rest of the routing protocols have reliable delivery, so >this isn't theorectically possible. > >On the other side of the issue, if we are going to state that any attack >which can only be accomplished through some other attack is really only the >"lower level" attack, then we should probably scrub about half of this doc >out, right? That would be my suggestion. This document seems to be very sloppy in this regard. One wants a clear taxonomy of problems, and citing one problem which is the result of any number of other precursor attacks is just confusing. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Aug 12 09:44:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13119 for ; Tue, 12 Aug 2003 09:44:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZRU-0003Ff-W1 for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 09:44:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CDi40D012493 for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 09:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZRU-0003FQ-Go for rpsec-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 09:44:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13095 for ; Tue, 12 Aug 2003 09:43:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZRS-0000Uv-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 09:44:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mZRR-0000Us-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 09:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZRR-0003Cl-GK; Tue, 12 Aug 2003 09:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZQg-0003CP-En for rpsec@optimus.ietf.org; Tue, 12 Aug 2003 09:43:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13048 for ; Tue, 12 Aug 2003 09:43:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZQe-0000Ui-00 for rpsec@ietf.org; Tue, 12 Aug 2003 09:43:12 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19mZQd-0000Uf-00 for rpsec@ietf.org; Tue, 12 Aug 2003 09:43:12 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2003 06:42:41 -0700 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 h7CDgcxc021376; Tue, 12 Aug 2003 09:42:38 -0400 (EDT) Received: from dhcp-64-102-60-237.cisco.com (dhcp-64-102-60-237.cisco.com [64.102.60.237]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA07843; Tue, 12 Aug 2003 09:42:38 -0400 (EDT) Date: Tue, 12 Aug 2003 09:43:52 -0400 (EDT) From: Russ White Reply-To: Russ White To: Stephen Kent cc: Eric Gray , Abbie Barbir , Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming In-Reply-To: Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.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: , > >Is that true? With RIP, at least, you can force underclaiming by just being > >on the wire, and having direct control of the network hardware, I'd guess. > >Just collide with anything that comes out looking like a RIP update, no? > >That would cause your peers to think you couldn't reach anything. > > The attack you describe is an active wiretapping problem. I think we need > to maintain a clear separation here. I assumed that any reference to > underclaiming was in the context of an authenticated, integrity-protected > communication by a legitimate router. But then you're presupposing a solution to the threat, and saying it's not a threat if there's a solution that people should be running, correct? In that case, there are no threats, right? :-) > >Of course, the rest of the routing protocols have reliable delivery, so > >this isn't theorectically possible. > > > >On the other side of the issue, if we are going to state that any attack > >which can only be accomplished through some other attack is really only the > >"lower level" attack, then we should probably scrub about half of this doc > >out, right? > > That would be my suggestion. This document seems to be very sloppy in > this regard. One wants a clear taxonomy of problems, and citing one > problem which is the result of any number of other precursor attacks is > just confusing. Okay, there seems to be some tension between the concept of providing a "complete reference," and a "set of specific threats at the lowest level." Is there any attack on a routing protocol that cannot be reduced to: -- access to the physical media -- access to the physical device ? It doesn't seem like it--they can all be reduced to one of these two. :-) 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 Tue Aug 12 10:19:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15568 for ; Tue, 12 Aug 2003 10:19:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZzU-0004e0-Tj for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 10:19:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CEJCoe017794 for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 10:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZzU-0004bc-LZ for rpsec-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 10:19:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15502 for ; Tue, 12 Aug 2003 10:19:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZzS-0000n5-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 10:19:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mZzR-0000n1-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 10:19:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZzJ-0004YQ-CW; Tue, 12 Aug 2003 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mZyx-0004UI-4t for rpsec@optimus.ietf.org; Tue, 12 Aug 2003 10:18:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15425 for ; Tue, 12 Aug 2003 10:18:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZyu-0000mW-00 for rpsec@ietf.org; Tue, 12 Aug 2003 10:18:36 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 19mZyt-0000m7-00 for rpsec@ietf.org; Tue, 12 Aug 2003 10:18:35 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h7CEHu1J007377; Tue, 12 Aug 2003 10:17:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> Date: Tue, 12 Aug 2003 10:13:28 -0400 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming Cc: Routing Protocols Security Working Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 9:43 -0400 8/12/03, Russ White wrote: > > >Is that true? With RIP, at least, you can force underclaiming by >just being >> >on the wire, and having direct control of the network hardware, I'd guess. >> >Just collide with anything that comes out looking like a RIP update, no? >> >That would cause your peers to think you couldn't reach anything. >> >> The attack you describe is an active wiretapping problem. I think we need >> to maintain a clear separation here. I assumed that any reference to >> underclaiming was in the context of an authenticated, integrity-protected >> communication by a legitimate router. > >But then you're presupposing a solution to the threat, and saying it's not >a threat if there's a solution that people should be running, correct? In >that case, there are no threats, right? :-) First, the term threat is being misused here, still, but I've given up on trying to fix that, after submitting my grief threat analysis note to the group some time ago. A useful taxonomy distinguishes attacks at low levels, and includes discussion of how combinations of attacks, or different attack paths, can result in problems at higher levels, as a way of showig the reader how to put the pieces together. > > >Of course, the rest of the routing protocols have reliable delivery, so >> >this isn't theorectically possible. >> > >> >On the other side of the issue, if we are going to state that any attack >> >which can only be accomplished through some other attack is really only the >> >"lower level" attack, then we should probably scrub about half of this doc >> >out, right? >> >> That would be my suggestion. This document seems to be very sloppy in >> this regard. One wants a clear taxonomy of problems, and citing one >> problem which is the result of any number of other precursor attacks is >> just confusing. > >Okay, there seems to be some tension between the concept of providing a >"complete reference," and a "set of specific threats at the lowest level." >Is there any attack on a routing protocol that cannot be reduced to: > >-- access to the physical media >-- access to the physical device > >? It doesn't seem like it--they can all be reduced to one of these two. This is not a useful basis for the discussion, especially when one thinks harder about the meaning of "access." I do not mean to suggest that there is only one way to provide the taxonomy. But any approach should give the reader as sense of completeness, relative to the approach selected. In this context one might discuss passive and active attacks against transmission media, attacks against routers, attacks against the computers used to manage the routers, and operational problems resulting from human actions. In the attacks against the routers or the management computers, one could distinguish attacks effected via communication paths from attacks that require physical access to the components. One could also look at the problems from the traditional security discipline perspective: personnel, procedural, physical, communications and computer security. You could adopt the approach we did for analyzing BGP security, i.e., consider correct operation to be the base definition, then examines the means by which correct operation can be subverted. All of these are valid starting points, but whichever way this analysis is done, one has to avoid drifting into an ad hoc listing. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Aug 12 10:25:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15950 for ; Tue, 12 Aug 2003 10:25:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ma59-0004vE-OA for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 10:25:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CEP3SM018920 for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 10:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ma59-0004v5-KF for rpsec-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 10:25:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15926 for ; Tue, 12 Aug 2003 10:24:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ma57-0000r5-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 10:25:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ma56-0000r2-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 10:25:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ma57-0004t7-Pg; Tue, 12 Aug 2003 10:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ma4t-0004sN-QU for rpsec@optimus.ietf.org; Tue, 12 Aug 2003 10:24:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15919 for ; Tue, 12 Aug 2003 10:24:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ma4r-0000qy-00 for rpsec@ietf.org; Tue, 12 Aug 2003 10:24:45 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ma4q-0000ql-00 for rpsec@ietf.org; Tue, 12 Aug 2003 10:24:45 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 12 Aug 2003 07:30:23 -0700 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 h7CEOBXw028539; Tue, 12 Aug 2003 10:24:12 -0400 (EDT) Received: from dhcp-64-102-60-237.cisco.com (dhcp-64-102-60-237.cisco.com [64.102.60.237]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA11132; Tue, 12 Aug 2003 10:24:11 -0400 (EDT) Date: Tue, 12 Aug 2003 10:25:25 -0400 (EDT) From: Russ White Reply-To: Russ White To: Stephen Kent cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming In-Reply-To: Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.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: , > All of these are valid starting points, but whichever way this analysis > is done, one has to avoid drifting into an ad hoc listing. Okay, if you could remake this draft, rather than giving us a general feeling of what is wrong with it, how about taking one specific section, and telling us what you would take out, vs what you would leave in, add, etc (?). I suppose my question to the list is: Would this be a useful excercise for everyone to understand, so we could read through this in a "more standard" way? 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 Tue Aug 12 12:38:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20966 for ; Tue, 12 Aug 2003 12:38:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcA0-00022K-Gq for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 12:38:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CGcC20007822 for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 12:38:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcA0-000225-CJ for rpsec-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 12:38:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20959 for ; Tue, 12 Aug 2003 12:38:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mc9y-00028K-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 12:38:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mc9x-00028G-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 12:38:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mc9p-0001zW-0Q; Tue, 12 Aug 2003 12:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mc9f-0001yV-4U for rpsec@optimus.ietf.org; Tue, 12 Aug 2003 12:37:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20949 for ; Tue, 12 Aug 2003 12:37:45 -0400 (EDT) From: sanjay.ramaswamy@ndsu.nodak.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mc9d-000281-00 for rpsec@ietf.org; Tue, 12 Aug 2003 12:37:49 -0400 Received: from smtp1.ndsu.nodak.edu ([134.129.111.146]) by ietf-mx with esmtp (Exim 4.12) id 19mc9c-00027y-00 for rpsec@ietf.org; Tue, 12 Aug 2003 12:37:48 -0400 Received: from ndsu.nodak.edu (webmail1.ndsu.NoDak.edu [134.129.111.141]) by smtp1.ndsu.NoDak.edu (8.11.7/8.11.6) with SMTP id h7CGbhk28378; Tue, 12 Aug 2003 11:37:43 -0500 Received: from 134.129.110.160 (SquirrelMail authenticated user sanjay.ramaswamy) by webmail.ndsu.nodak.edu with HTTP; Tue, 12 Aug 2003 11:37:44 -0500 (CDT) Message-ID: <1187.134.129.110.160.1060706264.squirrel@webmail.ndsu.nodak.edu> Date: Tue, 12 Aug 2003 11:37:44 -0500 (CDT) Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming To: In-Reply-To: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> X-Priority: 3 Importance: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > I suppose my question to the list is: Would this be a useful excercise > for everyone to understand, so we could read through this in a "more > standard" way? > > Russ Yes please. That would surely help us all. Sanjay _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Aug 12 12:59:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21508 for ; Tue, 12 Aug 2003 12:59:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcUC-0002kj-9G for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 12:59:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CGx4jM010575 for rpsec-archive@odin.ietf.org; Tue, 12 Aug 2003 12:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcUC-0002kU-5j for rpsec-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 12:59:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21486 for ; Tue, 12 Aug 2003 12:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcUA-0002Er-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 12:59:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mcU9-0002Eo-00 for rpsec-web-archive@ietf.org; Tue, 12 Aug 2003 12:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcU9-0002jN-I0; Tue, 12 Aug 2003 12:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mcTg-0002j8-Jv for rpsec@optimus.ietf.org; Tue, 12 Aug 2003 12:58:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21477 for ; Tue, 12 Aug 2003 12:58:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mcTe-0002EZ-00 for rpsec@ietf.org; Tue, 12 Aug 2003 12:58:30 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 19mcTe-0002EA-00 for rpsec@ietf.org; Tue, 12 Aug 2003 12:58:30 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h7CGvp1J018038; Tue, 12 Aug 2003 12:57:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <1187.134.129.110.160.1060706264.squirrel@webmail.ndsu.nodak.edu> References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> <1187.134.129.110.160.1060706264.squirrel@webmail.ndsu.nodak.edu> Date: Tue, 12 Aug 2003 12:56:11 -0400 To: sanjay.ramaswamy@ndsu.nodak.edu From: Stephen Kent Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming Cc: , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 11:37 -0500 8/12/03, sanjay.ramaswamy@ndsu.nodak.edu wrote: > > I suppose my question to the list is: Would this be a useful excercise >> for everyone to understand, so we could read through this in a "more >> standard" way? >> >> Russ > > >Yes please. That would surely help us all. > >Sanjay Sure, just send time & money :-) Remember, BBN is a contract R&D company, not a vendor. We bill clients for our time. I am happy to spend some time trying to help here, but I have no current client who I can bill for an extended amount of work on this topic. Since my last contribution to the efforts of this WG, a concrete example of how to perform a threat analysis for routing, seems to have gotten nowhere, it's very hard to justify the expenditure of more hours on rewriting parts of this document. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Aug 13 12:21:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24977 for ; Wed, 13 Aug 2003 12:21:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myNE-0007U8-WC for rpsec-archive@odin.ietf.org; Wed, 13 Aug 2003 12:21:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DGLKUS028768 for rpsec-archive@odin.ietf.org; Wed, 13 Aug 2003 12:21:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myNE-0007Tv-S0 for rpsec-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 12:21:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24956 for ; Wed, 13 Aug 2003 12:21:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myND-0002xm-00 for rpsec-web-archive@ietf.org; Wed, 13 Aug 2003 12:21:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19myNC-0002xi-00 for rpsec-web-archive@ietf.org; Wed, 13 Aug 2003 12:21:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myMv-0007Sd-0c; Wed, 13 Aug 2003 12:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19myMs-0007SH-UW for rpsec@optimus.ietf.org; Wed, 13 Aug 2003 12:20:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24946 for ; Wed, 13 Aug 2003 12:20:53 -0400 (EDT) From: sanjay.ramaswamy@ndsu.nodak.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myMr-0002xY-00 for rpsec@ietf.org; Wed, 13 Aug 2003 12:20:57 -0400 Received: from smtp1.ndsu.nodak.edu ([134.129.111.146]) by ietf-mx with esmtp (Exim 4.12) id 19myMq-0002xU-00 for rpsec@ietf.org; Wed, 13 Aug 2003 12:20:56 -0400 Received: from ndsu.nodak.edu (webmail1.ndsu.NoDak.edu [134.129.111.141]) by smtp1.ndsu.NoDak.edu (8.11.7/8.11.6) with SMTP id h7DGKnk12828; Wed, 13 Aug 2003 11:20:49 -0500 Received: from 134.129.110.182 (SquirrelMail authenticated user sanjay.ramaswamy) by webmail.ndsu.nodak.edu with HTTP; Wed, 13 Aug 2003 11:20:49 -0500 (CDT) Message-ID: <1195.134.129.110.182.1060791649.squirrel@webmail.ndsu.nodak.edu> Date: Wed, 13 Aug 2003 11:20:49 -0500 (CDT) Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming To: In-Reply-To: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> <1187.134.129.110.160.1060706264.squirrel@webmail.ndsu.nodak.edu> X-Priority: 3 Importance: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Looks like I added more fuel to the fire. I had missed a couple of earlier mails and mistook the list Russ was talking, to a summary list one Jean had a couple of days back. I have mailed Steve personally, and please disregard my previous mail. Sanjay > At 11:37 -0500 8/12/03, sanjay.ramaswamy@ndsu.nodak.edu wrote: >> > I suppose my question to the list is: Would this be a useful >> excercise >>> for everyone to understand, so we could read through this in a "more >>> standard" way? >>> >>> Russ >> >> >>Yes please. That would surely help us all. >> >>Sanjay > > Sure, just send time & money :-) > > Remember, BBN is a contract R&D company, not a vendor. We bill > clients for our time. I am happy to spend some time trying to help > here, but I have no current client who I can bill for an extended > amount of work on this topic. Since my last contribution to the > efforts of this WG, a concrete example of how to perform a threat > analysis for routing, seems to have gotten nowhere, it's very hard to > justify the expenditure of more hours on rewriting parts of this > document. > > Steve > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Aug 13 19:08:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10607 for ; Wed, 13 Aug 2003 19:08:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4is-0007tp-58 for rpsec-archive@odin.ietf.org; Wed, 13 Aug 2003 19:08:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DN86qK030361 for rpsec-archive@odin.ietf.org; Wed, 13 Aug 2003 19:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4is-0007tc-21 for rpsec-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 19:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10598 for ; Wed, 13 Aug 2003 19:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n4io-0005uC-00 for rpsec-web-archive@ietf.org; Wed, 13 Aug 2003 19:08:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n4io-0005u9-00 for rpsec-web-archive@ietf.org; Wed, 13 Aug 2003 19:08:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4in-0007ro-N5; Wed, 13 Aug 2003 19:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n4i8-0007ee-7A for rpsec@optimus.ietf.org; Wed, 13 Aug 2003 19:07:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10584 for ; Wed, 13 Aug 2003 19:07:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n4i4-0005u3-00 for rpsec@ietf.org; Wed, 13 Aug 2003 19:07:17 -0400 Received: from host19.ipowerweb.com ([12.129.211.119]) by ietf-mx with esmtp (Exim 4.12) id 19n4i4-0005tn-00 for rpsec@ietf.org; Wed, 13 Aug 2003 19:07:16 -0400 Received: from [65.211.67.100] (helo=GraIyMage.com) by host19.ipowerweb.com with asmtp (Exim 3.36 #1) id 19n4gm-0007nb-00; Wed, 13 Aug 2003 16:05:56 -0700 Message-ID: <3F3AC34B.BD8E680@GraIyMage.com> Date: Wed, 13 Aug 2003 19:01:31 -0400 From: Eric Gray Reply-To: ewgray@graiymage.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Russ White CC: Stephen Kent , Abbie Barbir , Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host19.ipowerweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - graiymage.com Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Russ, It comes down to what you were saying earlier - we have to draw a line somewhere. For example, we know that active wire tapping and router subversion are problems, because - if they're allowed to happen, a lot of other things can be done as well. Do we need to list all of those other things as separate threats? If we head down that road, we end inevitably in a rat hole, so the answer should be - no. I believe the answer is that we do not need to list these as separate threats when it is well known that several effectively unanswerable attacks are possible if a certain type of exposure is allowed to occur. In such a case, it should be sufficient to state a few such attacks as existence proof, possibly assert that others (perhaps many others) exist and leave it at that. In these cases, the secondary risks are not so much separate threats as validation of the initial exposure. -- Eric Russ White wrote: > > >Is that true? With RIP, at least, you can force underclaiming by just being > > >on the wire, and having direct control of the network hardware, I'd guess. > > >Just collide with anything that comes out looking like a RIP update, no? > > >That would cause your peers to think you couldn't reach anything. > > > > The attack you describe is an active wiretapping problem. I think we need > > to maintain a clear separation here. I assumed that any reference to > > underclaiming was in the context of an authenticated, integrity-protected > > communication by a legitimate router. > > But then you're presupposing a solution to the threat, and saying it's not > a threat if there's a solution that people should be running, correct? In > that case, there are no threats, right? :-) > > > >Of course, the rest of the routing protocols have reliable delivery, so > > >this isn't theorectically possible. > > > > > >On the other side of the issue, if we are going to state that any attack > > >which can only be accomplished through some other attack is really only the > > >"lower level" attack, then we should probably scrub about half of this doc > > >out, right? > > > > That would be my suggestion. This document seems to be very sloppy in > > this regard. One wants a clear taxonomy of problems, and citing one > > problem which is the result of any number of other precursor attacks is > > just confusing. > > Okay, there seems to be some tension between the concept of providing a > "complete reference," and a "set of specific threats at the lowest level." > Is there any attack on a routing protocol that cannot be reduced to: > > -- access to the physical media > -- access to the physical device > > ? It doesn't seem like it--they can all be reduced to one of these two. > > :-) > > 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 Wed Aug 13 21:03:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13337 for ; Wed, 13 Aug 2003 21:03:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n6W8-0005P7-AG for rpsec-archive@odin.ietf.org; Wed, 13 Aug 2003 21:03:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7E134vN020767 for rpsec-archive@odin.ietf.org; Wed, 13 Aug 2003 21:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n6W8-0005Os-6m for rpsec-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 21:03:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13333 for ; Wed, 13 Aug 2003 21:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n6W5-0006eI-00 for rpsec-web-archive@ietf.org; Wed, 13 Aug 2003 21:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n6W5-0006eF-00 for rpsec-web-archive@ietf.org; Wed, 13 Aug 2003 21:03:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n6W5-0005Nk-5o; Wed, 13 Aug 2003 21:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n6Vq-0005NZ-Eh for rpsec@optimus.ietf.org; Wed, 13 Aug 2003 21:02:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13330 for ; Wed, 13 Aug 2003 21:02:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n6Vo-0006eB-00 for rpsec@ietf.org; Wed, 13 Aug 2003 21:02:44 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19n6Vn-0006e2-00 for rpsec@ietf.org; Wed, 13 Aug 2003 21:02:43 -0400 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 h7E12Axc016593; Wed, 13 Aug 2003 21:02:11 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn2-730.cisco.com [10.82.242.218]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA28545; Wed, 13 Aug 2003 21:02:10 -0400 (EDT) Date: Wed, 13 Aug 2003 21:02:00 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: Eric Gray cc: Stephen Kent , Abbie Barbir , Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming In-Reply-To: <3F3AC34B.BD8E680@GraIyMage.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> <3F3AC34B.BD8E680@GraIyMage.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > It comes down to what you were saying earlier - we have to draw a > line somewhere. For example, we know that active wire tapping and router > subversion are problems, because - if they're allowed to happen, a lot of > other things can be done as well. > > Do we need to list all of those other things as separate threats? If > we head down that road, we end inevitably in a rat hole, so the answer > should be - no. > > I believe the answer is that we do not need to list these as separate > threats when it is well known that several effectively unanswerable > attacks are possible if a certain type of exposure is allowed to occur. > In such a case, it should be sufficient to state a few such attacks as > existence proof, possibly assert that others (perhaps many others) exist > and leave it at that. In these cases, the secondary risks are not so much > separate threats as validation of the initial exposure. Okay, which attacks within the current document would you say fall within the bounds of one of these two attacks, and which do not? :-) 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 Aug 14 14:25:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21079 for ; Thu, 14 Aug 2003 14:25:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nMml-0001Tf-Rn for rpsec-archive@odin.ietf.org; Thu, 14 Aug 2003 14:25:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EIPJPj005676 for rpsec-archive@odin.ietf.org; Thu, 14 Aug 2003 14:25:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nMml-0001TT-JF for rpsec-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 14:25:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21070 for ; Thu, 14 Aug 2003 14:25:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nMmi-0004y0-00 for rpsec-web-archive@ietf.org; Thu, 14 Aug 2003 14:25:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nMmi-0004xw-00 for rpsec-web-archive@ietf.org; Thu, 14 Aug 2003 14:25:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nMmT-0001RD-2V; Thu, 14 Aug 2003 14:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nMll-0001Qo-GG for rpsec@optimus.ietf.org; Thu, 14 Aug 2003 14:24:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21052 for ; Thu, 14 Aug 2003 14:24:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nMli-0004xk-00 for rpsec@ietf.org; Thu, 14 Aug 2003 14:24:15 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 19nMli-0004xe-00 for rpsec@ietf.org; Thu, 14 Aug 2003 14:24:14 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h7EINFU06798; Thu, 14 Aug 2003 14:23:15 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Thu, 14 Aug 2003 14:23:15 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Russ White cc: Eric Gray , Stephen Kent , Abbie Barbir , Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming In-Reply-To: Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> <3F3AC34B.BD8E680@GraIyMage.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Wed, 13 Aug 2003, Russ White wrote: > > It comes down to what you were saying earlier - we have to > > draw a line somewhere. For example, we know that active wire > > tapping and router subversion are problems, because - if > > they're allowed to happen, a lot of other things can be done > > as well. > > > > Do we need to list all of those other things as separate > > threats? If we head down that road, we end inevitably in a rat > > hole, so the answer should be - no. > > > > I believe the answer is that we do not need to list these as > > separate threats when it is well known that several > > effectively unanswerable attacks are possible if a certain > > type of exposure is allowed to occur. In such a case, it > > should be sufficient to state a few such attacks as existence > > proof, possibly assert that others (perhaps many others) exist > > and leave it at that. In these cases, the secondary risks are > > not so much separate threats as validation of the initial > > exposure. > > Okay, which attacks within the current document would you say fall > within the bounds of one of these two attacks, and which do not? > > Russ So, we've got these (from the table of contents): 4. Generally Identifiable Routing Threats 4.1 Deliberate Exposure 4.2 Sniffing 4.3 Traffic Analysis 4.4 Spoofing 4.5 Falsification 4.5.1 Falsifications by Originators 4.5.2 Falsifications by Forwarders 4.6 Interference 4.7 Overload 4.8 Byzantine Failures 4.9 Discarding of Control Packets 4.10 Network Mapping Threats 4.11 DoS and DDoS Attacks Seems like most of these can be effected by compromised routers. A number (eg. sniffing, spoofing, interference, traffic analysis, discarding) can also arise from compromised links. Given that the signalling is in-band with user traffic, there's another avenue which is spoofing, DoS, Overload by use of spoofing routing packets. Remember that the goal with this exercise is to derive a security requirements document for routing protocols. I think Steve Kent gave the insight that it's possible to apply mechanisms to counteract the threat of subverted routers and links (possibly operators, even.) Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Aug 14 16:10:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25329 for ; Thu, 14 Aug 2003 16:10:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOQ8-0006H6-9Z for rpsec-archive@odin.ietf.org; Thu, 14 Aug 2003 16:10:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EKA4WK024114 for rpsec-archive@odin.ietf.org; Thu, 14 Aug 2003 16:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOQ8-0006Gr-4B for rpsec-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 16:10:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25304 for ; Thu, 14 Aug 2003 16:09:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nOQ6-0005dU-00 for rpsec-web-archive@ietf.org; Thu, 14 Aug 2003 16:10:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nOQ5-0005dR-00 for rpsec-web-archive@ietf.org; Thu, 14 Aug 2003 16:10:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOQ5-0006F7-52; Thu, 14 Aug 2003 16:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nOPU-0006Ee-56 for rpsec@optimus.ietf.org; Thu, 14 Aug 2003 16:09:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25286 for ; Thu, 14 Aug 2003 16:09:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nOPS-0005dI-00 for rpsec@ietf.org; Thu, 14 Aug 2003 16:09:22 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 19nOPR-0005dE-00 for rpsec@ietf.org; Thu, 14 Aug 2003 16:09:22 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h7EK8j506926; Thu, 14 Aug 2003 16:08:45 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Thu, 14 Aug 2003 16:08:44 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Abbie Barbir cc: Routing Protocols Security Working Group Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Threats Draft TBD sections 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 Abbie and others, It looks like a few sections have "TBD" (To Be Determined) or some other text indicating they need more definition from the group. (Perhaps Abbie already has what he feels he needs?) The sections in question are: 4.5.1.2 Underclaiming TBD: Need to agree on the title and if it is a threat or not? 4.8 Byzantine Failures Definition is needed. It is not clear how to valid that a Byzantine failure has occurred NOTE: More work is needed 4.9 Discarding of Control Packets TBD: Not clear from the list the needed text here. 4.10 Network Mapping Threats TBD 4.11 DoS and DDoS Attacks TBD: Information to be collected from the list. What's the sense now for these? Can we fill in or remove them for the next revision (which ought to be coming very soon)? Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Aug 15 10:59:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29801 for ; Fri, 15 Aug 2003 10:59:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ng2W-0006Yu-6x for rpsec-archive@odin.ietf.org; Fri, 15 Aug 2003 10:58:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FEwqwL025220 for rpsec-archive@odin.ietf.org; Fri, 15 Aug 2003 10:58:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ng2W-0006Yh-3p for rpsec-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 10:58:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29789 for ; Fri, 15 Aug 2003 10:58:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ng2T-00030o-00 for rpsec-web-archive@ietf.org; Fri, 15 Aug 2003 10:58:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ng2T-00030l-00 for rpsec-web-archive@ietf.org; Fri, 15 Aug 2003 10:58:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ng1h-0006UH-21; Fri, 15 Aug 2003 10:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ng0s-0006P4-SY for rpsec@optimus.ietf.org; Fri, 15 Aug 2003 10:57:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29742 for ; Fri, 15 Aug 2003 10:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ng0q-00030H-00 for rpsec@ietf.org; Fri, 15 Aug 2003 10:57:08 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 19ng0p-0002zs-00 for rpsec@ietf.org; Fri, 15 Aug 2003 10:57:07 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h7FEuWU07920; Fri, 15 Aug 2003 10:56:32 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Fri, 15 Aug 2003 10:56:31 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Abbie Barbir cc: rpsec@ietf.org In-Reply-To: <87609AFB433BD5118D5E0002A52CD754069B1A28@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD754069B1A28@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] RE: Threats Draft TBD sections Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Fri, 15 Aug 2003, Abbie Barbir wrote: > Tony, > > 4.10 may require more info > the rest should be fine > > Abbie OK, that's "Network Mapping Threats". I went back to the archive to find the thread on this section and it seems that there was some agreement that the information derived from network mapping wasn't actually a threat to the operation of the routing protocol but might end up as a precursor to some other attack (on routing protocols or something else). Given this, I think we could say so in the document and leave it at that. Does anyone want to weigh in here? Tony > > -----Original Message----- > > From: Tony Tauber [mailto:tony.tauber@level3.com] > > Sent: Thursday, August 14, 2003 4:09 PM > > To: Barbir, Abbie [CAR:1A11:EXCH] > > Cc: Routing Protocols Security Working Group > > Subject: Threats Draft TBD sections > > > > > > Hi Abbie and others, > > > > It looks like a few sections have "TBD" (To Be Determined) or > > some other text indicating they need more definition from the > > group. (Perhaps Abbie already has what he feels he needs?) > > > > The sections in question are: > > > > 4.5.1.2 Underclaiming > > TBD: Need to agree on the title and if it is a threat or not? > > > > 4.8 Byzantine Failures > > Definition is needed. > > > > It is not clear how to valid that a Byzantine failure has occurred > > > > NOTE: More work is needed > > > > 4.9 Discarding of Control Packets > > TBD: Not clear from the list the needed text here. > > > > 4.10 Network Mapping Threats > > TBD > > > > 4.11 DoS and DDoS Attacks > > TBD: Information to be collected from the list. > > > > What's the sense now for these? Can we fill in or remove > > them for the next revision (which ought to be coming very soon)? > > > > Tony > > > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Aug 15 13:38:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06107 for ; Fri, 15 Aug 2003 13:38:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niWJ-0007VM-3s for rpsec-archive@odin.ietf.org; Fri, 15 Aug 2003 13:37:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FHbln0028847 for rpsec-archive@odin.ietf.org; Fri, 15 Aug 2003 13:37:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niWI-0007Uk-Vv for rpsec-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 13:37:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06095 for ; Fri, 15 Aug 2003 13:37:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niWG-0004a2-00 for rpsec-web-archive@ietf.org; Fri, 15 Aug 2003 13:37:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19niWG-0004Zz-00 for rpsec-web-archive@ietf.org; Fri, 15 Aug 2003 13:37:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niVZ-0007EL-MY; Fri, 15 Aug 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niVF-0007DN-W2 for rpsec@optimus.ietf.org; Fri, 15 Aug 2003 13:36:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06058 for ; Fri, 15 Aug 2003 13:36:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niVD-0004ZM-00 for rpsec@ietf.org; Fri, 15 Aug 2003 13:36:39 -0400 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 19niVD-0004Z8-00 for rpsec@ietf.org; Fri, 15 Aug 2003 13:36:39 -0400 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.8p1/8.12.8) with ESMTP id h7FHZcwA020447; Fri, 15 Aug 2003 12:35:38 -0500 (CDT) Message-ID: <3F3D19E9.B9EBA385@alcatel.com> Date: Fri, 15 Aug 2003 12:35:37 -0500 From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Russ White CC: Eric Gray , Stephen Kent , Abbie Barbir , Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> <3F3AC34B.BD8E680@GraIyMage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It may just be sufficient to document the symptoms of attacks on routing, instead of the different ways the attacks my be carried out. For example, active wire tapping my trigger the same effect or symptoms as another attack method say X. But all we care about are the symptoms. For example, does it cause routing information corruption, or processing resource starvation, or,.. Alex. Russ White wrote: > > It comes down to what you were saying earlier - we have to draw a > > line somewhere. For example, we know that active wire tapping and router > > subversion are problems, because - if they're allowed to happen, a lot of > > other things can be done as well. > > > > Do we need to list all of those other things as separate threats? If > > we head down that road, we end inevitably in a rat hole, so the answer > > should be - no. > > > > I believe the answer is that we do not need to list these as separate > > threats when it is well known that several effectively unanswerable > > attacks are possible if a certain type of exposure is allowed to occur. > > In such a case, it should be sufficient to state a few such attacks as > > existence proof, possibly assert that others (perhaps many others) exist > > and leave it at that. In these cases, the secondary risks are not so much > > separate threats as validation of the initial exposure. > > Okay, which attacks within the current document would you say fall within > the bounds of one of these two attacks, and which do not? > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Aug 15 16:21:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12021 for ; Fri, 15 Aug 2003 16:21:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl47-0000Xr-TA for rpsec-archive@odin.ietf.org; Fri, 15 Aug 2003 16:20:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FKKpDA002092 for rpsec-archive@odin.ietf.org; Fri, 15 Aug 2003 16:20:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl47-0000Xf-O4 for rpsec-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 16:20:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12017 for ; Fri, 15 Aug 2003 16:20:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl45-0005ic-00 for rpsec-web-archive@ietf.org; Fri, 15 Aug 2003 16:20:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nl45-0005iY-00 for rpsec-web-archive@ietf.org; Fri, 15 Aug 2003 16:20:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl3J-0000TO-IK; Fri, 15 Aug 2003 16:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl2n-0000Si-Ps for rpsec@optimus.ietf.org; Fri, 15 Aug 2003 16:19:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11983 for ; Fri, 15 Aug 2003 16:19:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl2m-0005hw-00 for rpsec@ietf.org; Fri, 15 Aug 2003 16:19:28 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19nl2l-0005hk-00 for rpsec@ietf.org; Fri, 15 Aug 2003 16:19:27 -0400 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 h7FKIruH029582; Fri, 15 Aug 2003 16:18:53 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn2-577.cisco.com [10.82.242.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA21557; Fri, 15 Aug 2003 16:18:52 -0400 (EDT) Date: Fri, 15 Aug 2003 16:18:42 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: Tony Tauber cc: Eric Gray , Stephen Kent , Abbie Barbir , Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming In-Reply-To: Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> <3F3AC34B.BD8E680@GraIyMage.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > > Okay, which attacks within the current document would you say fall > > within the bounds of one of these two attacks, and which do not? > > So, we've got these (from the table of contents): > > 4. Generally Identifiable Routing Threats > 4.1 Deliberate Exposure > 4.2 Sniffing > 4.3 Traffic Analysis > 4.4 Spoofing > 4.5 Falsification > 4.5.1 Falsifications by Originators > 4.5.2 Falsifications by Forwarders > 4.6 Interference > 4.7 Overload > 4.8 Byzantine Failures > 4.9 Discarding of Control Packets > 4.10 Network Mapping Threats > 4.11 DoS and DDoS Attacks Yep, these seem like the right areas that would be implemented through comprosing a router or link. > Seems like most of these can be effected by compromised routers. A number > (eg. sniffing, spoofing, interference, traffic analysis, discarding) can > also arise from compromised links. Given that the signalling is in-band > with user traffic, there's another avenue which is spoofing, DoS, > Overload by use of spoofing routing packets. > > Remember that the goal with this exercise is to derive a security > requirements document for routing protocols. I think Steve Kent gave the > insight that it's possible to apply mechanisms to counteract the threat > of subverted routers and links (possibly operators, even.) So, we could _theoretically_ replace all of these sections with a single section stating that a compromised router or link could cuase "bad things," that we don't need to specify what these "bad things" could be. In the requirements doc this would be paralleled by a statement about protecting routers and links from being compromised. Thoughts? :-) 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 Fri Aug 15 16:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12267 for ; Fri, 15 Aug 2003 16:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl99-00017R-Ku for rpsec-archive@odin.ietf.org; Fri, 15 Aug 2003 16:26:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FKQ37e004297 for rpsec-archive@odin.ietf.org; Fri, 15 Aug 2003 16:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl99-00017E-Hy for rpsec-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 16:26:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12237 for ; Fri, 15 Aug 2003 16:25:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl97-0005mP-00 for rpsec-web-archive@ietf.org; Fri, 15 Aug 2003 16:26:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nl97-0005mL-00 for rpsec-web-archive@ietf.org; Fri, 15 Aug 2003 16:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl97-00014y-1X; Fri, 15 Aug 2003 16:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nl90-00011H-P3 for rpsec@optimus.ietf.org; Fri, 15 Aug 2003 16:25:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12220 for ; Fri, 15 Aug 2003 16:25:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nl8y-0005m5-00 for rpsec@ietf.org; Fri, 15 Aug 2003 16:25:52 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19nl8y-0005m2-00 for rpsec@ietf.org; Fri, 15 Aug 2003 16:25:52 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19nl8x-0000Pc-Ld for rpsec@ietf.org; Fri, 15 Aug 2003 20:25:51 +0000 Date: Fri, 15 Aug 2003 13:25:27 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1323562913.20030815132527@psg.com> To: rpsec@ietf.org In-Reply-To: <96615458792.20030814180213@psg.com> References: <96615458792.20030814180213@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [RPSEC] Fwd: Last Call on draft-gill-gtsh-00.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit FYI below. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: routing-discussion@ietf.org Cc: Date: Thursday, August 14, 2003, 6:02:13 PM Subject: Last Call on draft-gill-gtsh-00.txt ===8<==============Original message text=============== Folks- The IESG received a request to progress draft-gill-gtsh-00.txt as an individual contribution towards the EXPERIMENTAL RFC status. The concept described in the document (as well as the original document known as draft-gill-btsh) has been widely discussed in the community, and I would like to start a 4-week Last Call on the Routing Area mailing list to encourage review and gauge the consensus on the document before taking it to the IESG. Please read the document and indicate if you support it going forward (do send a message if you support). The last call ends on September 12th, 2003. This message will be forwarded as an FYI to certain individual WGs. However, please send your comments to routing-discussion@ietf.org -- Alex Zinin IETF Routing Area Co-Director http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion ===8<===========End of original message text=========== _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Aug 15 16:38:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12935 for ; Fri, 15 Aug 2003 16:38:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlKn-0002ID-Fa for rpsec-archive@odin.ietf.org; Fri, 15 Aug 2003 16:38:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FKc5EO008813 for rpsec-archive@odin.ietf.org; Fri, 15 Aug 2003 16:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlKn-0002I4-C9 for rpsec-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 16:38:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12905 for ; Fri, 15 Aug 2003 16:38:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlKl-0005xK-00 for rpsec-web-archive@ietf.org; Fri, 15 Aug 2003 16:38:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nlKk-0005xH-00 for rpsec-web-archive@ietf.org; Fri, 15 Aug 2003 16:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlKi-0002FF-VG; Fri, 15 Aug 2003 16:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlJp-0001ur-Rj for rpsec@optimus.ietf.org; Fri, 15 Aug 2003 16:37:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12845 for ; Fri, 15 Aug 2003 16:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlJn-0005w6-00 for rpsec@ietf.org; Fri, 15 Aug 2003 16:37:04 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 19nlJm-0005vA-00 for rpsec@ietf.org; Fri, 15 Aug 2003 16:37:02 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h7FKZxx08440; Fri, 15 Aug 2003 16:35:59 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Fri, 15 Aug 2003 16:35:58 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Russ White cc: Eric Gray , Stephen Kent , Abbie Barbir , Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming In-Reply-To: Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> <3F3AC34B.BD8E680@GraIyMage.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Fri, 15 Aug 2003, Russ White wrote: > Date: Fri, 15 Aug 2003 16:18:42 -0400 (Eastern Daylight Time) > From: Russ White > > > Okay, which attacks within the current document would you say fall > > > within the bounds of one of these two attacks, and which do not? > > > > So, we've got these (from the table of contents): > > > > 4. Generally Identifiable Routing Threats > > 4.1 Deliberate Exposure > > 4.2 Sniffing > > 4.3 Traffic Analysis > > 4.4 Spoofing > > 4.5 Falsification > > 4.5.1 Falsifications by Originators > > 4.5.2 Falsifications by Forwarders > > 4.6 Interference > > 4.7 Overload > > 4.8 Byzantine Failures > > 4.9 Discarding of Control Packets > > 4.10 Network Mapping Threats > > 4.11 DoS and DDoS Attacks > > So, we could _theoretically_ replace all of these sections with a > single section stating that a compromised router or link could cuase > "bad things," that we don't need to specify what these "bad things" > could be. In the requirements doc this would be paralleled by a > statement about protecting routers and links from being compromised. > > Thoughts? No. Compromising a router or link does not comprise an attack on the routing protocol. Moreover, since one can't fix those things within a routing protocol, we might as well pack up and go home. The mitigtions that can be implemented in routing protocols are to address what can be put in so that the protocols can function even in the face of these attacks (hopefully). For instance, some cryptographic enhancements might mitigate some attacks that can carried out through a compromised link (eg. spoofing, sniffing) but not others (eg. discarding of control packets, traffic analysis). I believe that the so/s BGP enhancements are designed to mitigate, among other things, compromised routers (ie. someone with control of a router announcing a prefix they're not authorized to). Does that sound right? Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Aug 18 07:54:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16783 for ; Mon, 18 Aug 2003 07:54:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oiaS-0002p9-7l for rpsec-archive@odin.ietf.org; Mon, 18 Aug 2003 07:54:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IBsC2s010849 for rpsec-archive@odin.ietf.org; Mon, 18 Aug 2003 07:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oiaS-0002ou-3M for rpsec-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 07:54:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16779 for ; Mon, 18 Aug 2003 07:54:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oiaR-0006gq-00 for rpsec-web-archive@ietf.org; Mon, 18 Aug 2003 07:54:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oiaQ-0006gm-00 for rpsec-web-archive@ietf.org; Mon, 18 Aug 2003 07:54:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oiaG-0002nl-Rp; Mon, 18 Aug 2003 07:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oiZW-0002lN-Ku for rpsec@optimus.ietf.org; Mon, 18 Aug 2003 07:53:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16771 for ; Mon, 18 Aug 2003 07:53:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oiZV-0006gi-00 for rpsec@ietf.org; Mon, 18 Aug 2003 07:53:13 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19oiZV-0006gQ-00 for rpsec@ietf.org; Mon, 18 Aug 2003 07:53:13 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2003 04:52:42 -0700 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 h7IBqdYY010189; Mon, 18 Aug 2003 07:52:39 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn2-391.cisco.com [10.82.241.135]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA29638; Mon, 18 Aug 2003 07:52:38 -0400 (EDT) Date: Mon, 18 Aug 2003 07:52:29 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: Tony Tauber cc: Abbie Barbir , rpsec@ietf.org Subject: Re: [RPSEC] RE: Threats Draft TBD sections In-Reply-To: Message-ID: References: <87609AFB433BD5118D5E0002A52CD754069B1A28@zcard0k6.ca.nortel.com> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > OK, that's "Network Mapping Threats". > > I went back to the archive to find the thread on this section and it > seems that there was some agreement that the information derived from > network mapping wasn't actually a threat to the operation of the routing > protocol but might end up as a precursor to some other attack (on routing > protocols or something else). > > Given this, I think we could say so in the document and leave it at that. Agreed--this sounds fine. :-) 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 Tue Aug 19 12:22:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21221 for ; Tue, 19 Aug 2003 12:22:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9FI-0004ys-VV for rpsec-archive@odin.ietf.org; Tue, 19 Aug 2003 12:22:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JGM8f6019142 for rpsec-archive@odin.ietf.org; Tue, 19 Aug 2003 12:22:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9FI-0004yf-SB for rpsec-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 12:22:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21203 for ; Tue, 19 Aug 2003 12:22:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9FH-00030r-00 for rpsec-web-archive@ietf.org; Tue, 19 Aug 2003 12:22:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p9FG-00030n-00 for rpsec-web-archive@ietf.org; Tue, 19 Aug 2003 12:22:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9FA-0004xL-UH; Tue, 19 Aug 2003 12:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9F6-0004x4-4F for rpsec@optimus.ietf.org; Tue, 19 Aug 2003 12:21:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21186 for ; Tue, 19 Aug 2003 12:21:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9F4-00030N-00 for rpsec@ietf.org; Tue, 19 Aug 2003 12:21:54 -0400 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 19p9F3-000306-00 for rpsec@ietf.org; Tue, 19 Aug 2003 12:21:53 -0400 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 894EE340D0 for ; Tue, 19 Aug 2003 18:20:23 +0200 (CEST) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 3C7673F449 for ; Tue, 19 Aug 2003 18:22:39 +0200 (CEST) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003081918202732356 for ; Tue, 19 Aug 2003 18:20:27 +0200 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 16C823F44A for ; Tue, 19 Aug 2003 18:22:39 +0200 (CEST) Received: from jjp by localhost with local id 19p9Bq-00044n-00 for ; Tue, 19 Aug 2003 18:18:34 +0200 Date: Tue, 19 Aug 2003 18:18:34 +0200 From: Jean-Jacques Puig To: Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming Message-ID: <20030819161834.GB24261@ivan.int-evry.fr> Mail-Followup-To: Routing Protocols Security Working Group References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F38C357.E4AF5FFF@GraIyMage.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: , Hi ! (I have to split here in the tree because later in the thread it may be difficult to understand what I'm talking about) On Tue, Aug 12, 2003 at 06:37:11AM -0400, Eric Gray wrote: > Russ, > > As I understand it, the premise is that 'underclaiming' is a problem if > it results from subversion of a router. In this case, isn't the threat really > the subversion of the router? Lots of things can be done with subverted > routers... As states Russ later in the thread, the underclaiming may be done on the wire; or a 'subverted link'. I fear that in the following part of the discussion, threat sources and threat attacks are mistaken. The current draft list subverted links and devices as threat *sources*, whereas the question was whether underclaiming is a valid threat *action* (attack). This approach to threat definition may not be perfect, but it looks coherent here. The subvertion of the router / the link is required, but is not sufficient to provide a complete description and is not the real attack against routing operations. > > -- > Eric Gray > > Russ White wrote: > > > I'm still of the belief that it is a valid threat, though it's hard to > > define, and impossible to defend against. > > > > :-) > > > > Russ -- 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 Aug 20 06:39:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03097 for ; Wed, 20 Aug 2003 06:39:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQN0-0006AZ-PE for rpsec-archive@odin.ietf.org; Wed, 20 Aug 2003 06:39:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KAdE5J023716 for rpsec-archive@odin.ietf.org; Wed, 20 Aug 2003 06:39:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQN0-0006AR-Iq for rpsec-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 06:39:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03063 for ; Wed, 20 Aug 2003 06:39:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pQMw-00078q-00 for rpsec-web-archive@ietf.org; Wed, 20 Aug 2003 06:39:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pQMv-00078l-00 for rpsec-web-archive@ietf.org; Wed, 20 Aug 2003 06:39:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQMn-000695-To; Wed, 20 Aug 2003 06:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQMl-00068f-1z for rpsec@optimus.ietf.org; Wed, 20 Aug 2003 06:38:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03050 for ; Wed, 20 Aug 2003 06:38:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pQMh-00078U-00 for rpsec@ietf.org; Wed, 20 Aug 2003 06:38:55 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19pQMg-000784-00 for rpsec@ietf.org; Wed, 20 Aug 2003 06:38:54 -0400 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 h7KAcN4w009621; Wed, 20 Aug 2003 06:38:24 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn1-76.cisco.com [10.82.224.76]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA29623; Wed, 20 Aug 2003 06:38:23 -0400 (EDT) Date: Wed, 20 Aug 2003 06:38:13 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: Jean-Jacques Puig cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft Issue 3: Section 4.5 Underclaiming In-Reply-To: <20030819161834.GB24261@ivan.int-evry.fr> Message-ID: References: <87609AFB433BD5118D5E0002A52CD7540686F36E@zcard0k6.ca.nortel.com> <3F38C357.E4AF5FFF@GraIyMage.com> <20030819161834.GB24261@ivan.int-evry.fr> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > I fear that in the following part of the discussion, threat sources and > threat attacks are mistaken. The current draft list subverted links and > devices as threat *sources*, whereas the question was whether > underclaiming is a valid threat *action* (attack). This approach to > threat definition may not be perfect, but it looks coherent here. The > subvertion of the router / the link is required, but is not sufficient to > provide a complete description and is not the real attack against routing > operations. I think it's probably useful to maintain the distinction between threat sources and threat actions (what I would consider just a threat, although I suppose it's better to have some qualifier on the word). This way we can state that a link can be subverted, and then what actions an attacker could take based on that subversion, right? Otherwise, most all attacks are going to come down to just a couple of threat sources, and the draft will lose most of its usefulness in helping people understand what sorts of attacks could take place. I'll agree, on the other side, that we shouldn't try to catalogue every possible threat action in the world, but some examples to set the reader's mind to thinking are good, at least. :-) 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 Wed Aug 20 06:44:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03264 for ; Wed, 20 Aug 2003 06:44:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQRf-0006LD-Hf for rpsec-archive@odin.ietf.org; Wed, 20 Aug 2003 06:44:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KAi3o0024371 for rpsec-archive@odin.ietf.org; Wed, 20 Aug 2003 06:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQRf-0006Kr-Eh for rpsec-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 06:44:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03235 for ; Wed, 20 Aug 2003 06:43:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pQRb-0007Co-00 for rpsec-web-archive@ietf.org; Wed, 20 Aug 2003 06:43:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pQRa-0007Cl-00 for rpsec-web-archive@ietf.org; Wed, 20 Aug 2003 06:43:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQRd-0006JN-DM; Wed, 20 Aug 2003 06:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQRY-0006Ik-NR for rpsec@optimus.ietf.org; Wed, 20 Aug 2003 06:43:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03228 for ; Wed, 20 Aug 2003 06:43:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pQRU-0007Cc-00 for rpsec@ietf.org; Wed, 20 Aug 2003 06:43:52 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19pQRU-0007CA-00 for rpsec@ietf.org; Wed, 20 Aug 2003 06:43:52 -0400 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 h7KAhL4w013010; Wed, 20 Aug 2003 06:43:22 -0400 (EDT) Received: from russpc.whitehouse.intra (rtp-vpn1-76.cisco.com [10.82.224.76]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id GAA29730; Wed, 20 Aug 2003 06:43:21 -0400 (EDT) Date: Wed, 20 Aug 2003 06:43:10 -0400 (Eastern Daylight Time) From: Russ White Reply-To: Russ White To: Tony Tauber cc: Abbie Barbir , Routing Protocols Security Working Group Subject: Re: [RPSEC] Threats Draft TBD sections In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > It looks like a few sections have "TBD" (To Be Determined) or some other > text indicating they need more definition from the group. (Perhaps Abbie > already has what he feels he needs?) > > The sections in question are: > > 4.5.1.2 Underclaiming > TBD: Need to agree on the title and if it is a threat or not? I'm okay with dropping this section, if it's the feeling of the list that we should. I think it is a threat, but that it's hard to define, and it's hard to/impossible to defend against. > 4.8 Byzantine Failures > Definition is needed. > > It is not clear how to valid that a Byzantine failure has occurred Agreed. We should state what a Byzantine failure is, and then point to other parts of the doc that talk about them in more detail. It might be better if it's actually a definition, rather than a separate section, as it is now. > 4.9 Discarding of Control Packets > TBD: Not clear from the list the needed text here. I'm not certain we should include this? > 4.10 Network Mapping Threats > TBD I think this could be worth mentioning, but not as a threat source or attack. It's only a possible precursor to a real attack. In fact, should we just leave it out of this doc, and let someone come along and follow this up with some other doc that defines, and explains in more detail, network mapping, in case someone is interested in doing so? It would help move this doc along, and since it pretty much falls outside the scope of the doc, it might be more useful that way. > 4.11 DoS and DDoS Attacks > TBD: Information to be collected from the list. I'm not certain we should include these at all, other than as possible attacks against peering relationships between routers? I'd probably pull them, myself (?). :-) 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 Fri Aug 22 10:54:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00943 for ; Fri, 22 Aug 2003 10:54:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qDIq-0006oj-AS for rpsec-archive@odin.ietf.org; Fri, 22 Aug 2003 10:54:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MEsClW026201 for rpsec-archive@odin.ietf.org; Fri, 22 Aug 2003 10:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qDIq-0006oW-4f for rpsec-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 10:54:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00914 for ; Fri, 22 Aug 2003 10:54:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qDIn-0005Tf-00 for rpsec-web-archive@ietf.org; Fri, 22 Aug 2003 10:54:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19qDIn-0005Ta-00 for rpsec-web-archive@ietf.org; Fri, 22 Aug 2003 10:54:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qDIf-0006n6-Ks; Fri, 22 Aug 2003 10:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qDIT-0006mc-VS for rpsec@optimus.ietf.org; Fri, 22 Aug 2003 10:53:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00882 for ; Fri, 22 Aug 2003 10:53:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qDIR-0005T6-00 for rpsec@ietf.org; Fri, 22 Aug 2003 10:53:47 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 19qDIQ-0005Sy-00 for rpsec@ietf.org; Fri, 22 Aug 2003 10:53:46 -0400 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 h7MEpmK02447; Fri, 22 Aug 2003 10:51:49 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Aug 2003 10:51:49 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406A39252@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: alex.audu@alcatel.com, Stephen Kent Cc: Russ White , Tony Tauber , Routing Protocols Security Working Group Subject: RE: [RPSEC] Threats Draft Issue 7: Ownership as a Term Date: Fri, 22 Aug 2003 10:51:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C368BC.EA8FE006" 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_01C368BC.EA8FE006 Content-Type: text/plain Hi, Those that could live with the owner, can you please provide a definition so I can use it in the draft. Thanks Abbie > -----Original Message----- > From: Alex Audu [mailto:alex.audu@alcatel.com] > Sent: Monday, July 21, 2003 10:37 AM > To: Stephen Kent > Cc: Russ White; Tony Tauber; Routing Protocols Security Working Group > Subject: Re: [RPSEC] Threats Draft Issue 7: Ownership as a Term > > > I'd go with "owner" too. > > Cheers, > Alex. > > Stephen Kent wrote: > > > At 12:54 -0400 7/15/03, Russ White wrote: > > >So, we have: > > > > > >-- use "own," with a definition to explain what we really mean > > >-- use 'authorized," which may entail some rewording/feel awkward? > > >-- use "holder,' which may also be awkward > > > > > >Any other suggestions? Should we take a humm on one of these three? > > > > > >:-) > > > > > >Russ > > > > > > > I can live with holder, aqlthough I prefer owner. > > > > steve > > > > _______________________________________________ > > RPSEC mailing list > > RPSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/rpsec > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > ------_=_NextPart_001_01C368BC.EA8FE006 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [RPSEC] Threats Draft Issue 7: Ownership as a Term

Hi,

Those that could live with the owner,
can you please provide a definition so I can use it = in the draft.

Thanks
Abbie


> -----Original Message-----
> From: Alex Audu [mailto:alex.audu@alcatel.com] =
> Sent: Monday, July 21, 2003 10:37 AM
> To: Stephen Kent
> Cc: Russ White; Tony Tauber; Routing Protocols = Security Working Group
> Subject: Re: [RPSEC] Threats Draft Issue 7: = Ownership as a Term
>
>
> I'd go with "owner" too.
>
> Cheers,
> Alex.
>
> Stephen Kent wrote:
>
> > At 12:54 -0400 7/15/03, Russ White = wrote:
> > >So, we have:
> > >
> > >-- use "own," with a = definition to explain what we really mean
> > >-- use 'authorized," which may = entail some rewording/feel awkward?
> > >-- use "holder,' which may also = be awkward
> > >
> > >Any other suggestions? Should we take = a humm on one of these three?
> > >
> > >:-)
> > >
> > >Russ
> > >
> >
> > I can live with holder, aqlthough I prefer = owner.
> >
> > steve
> >
> > = _______________________________________________
> > RPSEC mailing list
> > RPSEC@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rpsec
>
>
> = _______________________________________________
> RPSEC mailing list
> RPSEC@ietf.org
> https://www1.ietf.org/mailman/listinfo/rpsec
>

------_=_NextPart_001_01C368BC.EA8FE006-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Aug 22 14:55:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13344 for ; Fri, 22 Aug 2003 14:55:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qH44-00032K-M1 for rpsec-archive@odin.ietf.org; Fri, 22 Aug 2003 14:55:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MItC2M011666 for rpsec-archive@odin.ietf.org; Fri, 22 Aug 2003 14:55:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qH44-000325-HF for rpsec-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 14:55:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13329 for ; Fri, 22 Aug 2003 14:55:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qH41-0000Z7-00 for rpsec-web-archive@ietf.org; Fri, 22 Aug 2003 14:55:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19qH41-0000Z4-00 for rpsec-web-archive@ietf.org; Fri, 22 Aug 2003 14:55:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qH3u-00030U-QQ; Fri, 22 Aug 2003 14:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qH2x-0002xS-Af for rpsec@optimus.ietf.org; Fri, 22 Aug 2003 14:54:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13273 for ; Fri, 22 Aug 2003 14:53:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qH2u-0000YO-00 for rpsec@ietf.org; Fri, 22 Aug 2003 14:54:00 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 19qH2t-0000Xn-00 for rpsec@ietf.org; Fri, 22 Aug 2003 14:53:59 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h7MIqW1J001545; Fri, 22 Aug 2003 14:52:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <87609AFB433BD5118D5E0002A52CD75406A39252@zcard0k6.ca.nortel.com> References: <87609AFB433BD5118D5E0002A52CD75406A39252@zcard0k6.ca.nortel.com> Date: Fri, 22 Aug 2003 14:51:19 -0400 To: "Abbie Barbir" From: Stephen Kent Subject: RE: [RPSEC] Threats Draft Issue 7: Ownership as a Term Cc: alex.audu@alcatel.com, Russ White , Tony Tauber , Routing Protocols Security Working Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 10:51 -0400 8/22/03, Abbie Barbir wrote: >Hi, > >Those that could live with the owner, >can you please provide a definition so I can use it in the draft. > >Thanks >Abbie Here's some text: The "owner" of an address prefix or an AS number is an organization that has been granted the right to use that prefix or number. Each Regional Internet Rggistry (RIR) acquires prefixes and AS numbers from the IANA, and further distributes (delegates use of) them to organizations such as ISPs and multi-homed subscribers. For address prefixes, delegation typically involves assigning a subset of a prefix to an organization, which may, in turn, further delegate subsets to other organizations, e.g., subscribers or downstream providers. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Aug 28 05:57:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23577 for ; Thu, 28 Aug 2003 05:57:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sJJX-0002UB-MM for rpsec-archive@odin.ietf.org; Thu, 28 Aug 2003 05:43:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S9hZNm009551 for rpsec-archive@odin.ietf.org; Thu, 28 Aug 2003 05:43:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sJCF-00022t-QH for rpsec-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 05:36:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21717 for ; Thu, 28 Aug 2003 05:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sJCA-0000ph-00 for rpsec-web-archive@ietf.org; Thu, 28 Aug 2003 05:35:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sJC9-0000pa-00 for rpsec-web-archive@ietf.org; Thu, 28 Aug 2003 05:35:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sEJK-0001Oo-Em; Thu, 28 Aug 2003 00:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sEG0-0001IQ-LT for rpsec@optimus.ietf.org; Thu, 28 Aug 2003 00:19:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13693 for ; Thu, 28 Aug 2003 00:19:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sEFw-00020w-00 for rpsec@ietf.org; Thu, 28 Aug 2003 00:19:32 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 19sEFv-000209-00 for rpsec@ietf.org; Thu, 28 Aug 2003 00:19:31 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h7S4J1820910 for ; Thu, 28 Aug 2003 00:19:01 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Wed, 27 Aug 2003 09:21:45 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="----_=_NextPart_000_01C36BBC.66F4AA80" Content-ID: ReSent-Date: Thu, 28 Aug 2003 00:18:50 -0400 (EDT) ReSent-From: Tony Tauber ReSent-To: rpsec@ietf.org ReSent-Subject: WG Last Call on Threats Doc ReSent-Message-ID: Subject: [RPSEC] WG Last Call on Threats Doc Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , ------_=_NextPart_000_01C36BBC.66F4AA80 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: > On Mon, 25 Aug 2003, abbie barbir wrote: > > > Attached is the -02 version, please review. > > I do not have access through work today. > > Can you please fwd to the rpsec list and the > > ietf-drafts. > > > > Thanks > > > > Abbie Folks, With this posting, we're starting a Working Group Last Call for the Generic Routing Protocol Threats document. I know it's far from perfect, but let's hope it's useful enough to serve as a background analysis and to get us into the Generic Requirements document. Please review and send comments by Sun. September 7th. Thanks, Tony ------_=_NextPart_000_01C36BBC.66F4AA80 Content-Type: TEXT/PLAIN; NAME="draft-ietf-rpsec-routing-threats-02.txt" Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="draft-ietf-rpsec-routing-threats-02.txt" Content-Transfer-Encoding: QUOTED-PRINTABLE Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: February 24, 2004 S. = Murphy Network Associates, = Inc Y. = Yang Cisco = Systems August 26, = 2003 Generic Threats to Routing Protocols draft-ietf-rpsec-routing-threats-02 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 February 24, 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 affects 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 February 24, 2004 [Page = 1] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Routing Functions Overview . . . . . . . . . . . . . . . . . = 4 2.1 Routing Protocol Control and Data Planes . . . . . . . . . . = 4 3. Generic Routing Protocol Threat Model . . . . . . . . . . . = 5 3.1 Threat Definitions . . . . . . . . . . . . . . . . . . . . . = 5 3.1.1 Threat Sources . . . . . . . . . . . . . . . . . . . . . . . = 6 3.1.2 Threat Consequences . . . . . . . . . . . . . . . . . . . . = 7 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 . . . . . . . . . . . . . . . . . . = 20 Normative References . . . . . . . . . . . . . . . . . . . . = 21 Informative References . . . . . . . . . . . . . . . . . . . = 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . = 22 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = 24 B. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . = 25 Intellectual Property and Copyright Statements . . . . . . . = 26 Barbir, et al. Expires February 24, 2004 [Page = 2] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 affects 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 documents takes a general threats to routing functions. In this work, the "owner" of an address prefix or an AS [17] number is an organization that has been granted the right to use that prefix or number. Each Regional Internet Rggistry (RIR) acquires prefixes and AS numbers from IANA, and further distributes (delegates use of) = them to organizations such as ISPs and multi-homed subscribers. For address prefixes, delegation typically involves assigning a subset = of a prefix to an organization, which may, in turn, further delegate subsets to other organizations, e.g., subscribers or downstream providers. 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 [6], IS-IS [10] , RIP [11] and BGP [17]. The security requirements derived from this analysis are intended to be used as guidance to those who are designing and modifying routing protocols. They may also be used by routing protocol implementers to increase the robustness of their implementations. 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 February 24, 2004 [Page = 3] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 common functions: o Transport Subsystem: The routing protocol transmits messages to its neighbors using some underlying protocol. For example, OSPF uses IP, while AODV uses a broadcast link. Other protocols may = run over TCP. o Neighbor State Maintenance: neighboring relationship formation is the first step for topology determination. For this reason, routing protocols may need to maintain the state of their neighbors. Each routing protocol may use a different mechanism for determining its neighbors in the routing topology. Some protocols have distinct exchange through which they establish neighboring relationships, e.g., Hello exchanges in OSPF. o Database Maintenance: Routing protocols exchange network topology and reach-ability 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. 2.1 Routing Protocol Control and Data Planes 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 February 24, 2004 [Page = 4] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 treats 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 neighbor (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, if the DR election is disrupted in an OSPF network, an unauthorized router could be chosen as designated router. This might allow unauthorized access to routing information. In BGP, if a router receives a CEASE message, it can break the neighboring relationship and cause any related topology information to be flushed. 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 LSA's with the wrong Advertising Router, the receivers will compute a 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 Threat is defined in [1] as a potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm. A threat presents itself when an attacker has the ability to take advantage of an Barbir, et al. Expires February 24, 2004 [Page = 5] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 existing security weakness. 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 form outsiders or insiders. An insider is an authorized participant in the routing protocol. An outsider is any other host or network. A host is determined to be an outsider or an insider from the point of view of a particular router. Even an authorized protocol speaker can be an outsider to a particular = router if the router does not consider the speaker to be a legitimate peer (as could conceivably happen on a multi-access link). In general, threats can be classified into the following categories based on their sources [2]: o Threats that result from subverted links: A link become subverted when an attacker gain access (or control) to 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 routing software bugs, hardware defects, incorrect or unintended configurations. Devices can be susceptible to such threats due to the lack mechanisms to verify system integrity (For example, the router is working correctly as been intended by the authoritative network administrator), or such mechanisms can be circumvented. Such threats may enable attackers to inappropriately claim authority for some network resources, or violate routing protocols, such as advertising invalid routing information. For example, an OSPF router will form a peering relationship with = any attached device which appears to be running OSPF, unless MD5 authentication (or some other means) is used to prevent the neighboring relationship from forming. Furthermore, MANET protocols Barbir, et al. Expires February 24, 2004 [Page = 6] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 frequently speak over the broadcast link. 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]. 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 false routing message and believes it to be true. Subverted links and/or subverted device (routers)can cause this consequence if the receiving router lacks ability to check routing message integrity, routing message origin, authentication or peer router authentication. o Disruption: This consequence occurs when a legitimate router's operation is being interrupted or prevented. Subvert links can cause this by replaying, delaying, or dropping routing messages, or breaking routing sessions between legitimate routers. = Subverted devices (router) can cause this consequence by sending false routing messages, interfering 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, interfering routing exchanges, or system integrity. 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. Barbir, et al. Expires February 24, 2004 [Page = 7] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 However, Router B is compromised and advertises a lower 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. +-------------+ +-------+ | Internet |---| Rtr A | +------+------+ +---+---+ | | | | | | | *-+-* +-------+ / \ | Rtr B |----------* N 1 * +-------+ \ / *---* Figure 1: 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: large amounts of traffic are directed to be forwarded through one router that cannot handle the increased level of traffic and drops many/most/all packets, 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 Barbir, et al. Expires February 24, 2004 [Page = 8] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 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. 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. Barbir, et al. Expires February 24, 2004 [Page = 9] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Similar threat actions that happened at different locations may = cause totally different threat consequence zones. For example, when a compromised link breaks the routing session between a distribution router and a stub router, only reach ability from and to the network devices attached on the stub router will be impaired. In other = words, the threat consequence zone is a single router. Nonetheless, 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 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 have 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 appear longer than threat action. For example, in the original ARPANET link-state algorithm, some errors in a router might introduce three instances of an LSA, and all of them would be flooded throughout the network forever, until the entire network was power cycled [3]. Barbir, et al. Expires February 24, 2004 [Page = 10] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 4. Generally Identifiable Routing Threats This section addresses generally identifiable and recognized threat action against routing protocols. The threats 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 other routers. In some cases, the receiving 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. 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 acquired knowledge will not be out-dated until there is a topology change of the affected network. Barbir, et al. Expires February 24, 2004 [Page = 11] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 4.3 Traffic Analysis Traffic analysis is 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 in the clear 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 address of the data traffic, the type, magnitude, and volume of traffic is 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 to spoof the identity of a router, the subverted router can act as masquerading router. In other situation, the spoofed router can be used to send out unrealistic routing information that might cause disruption of network services. There are a few cases where spoofing can be an attack. For example, if a router establishes a neighbor/peering relationship, spoofing = the identity of a legitimate router and by that action was able to prevent the legitimate router from establishing a relationship; that would be an attack, denying service to the good router. As a second example, if a router is doing auditing, then the ability to spoof an identity of a router would be an attack, since the audit data would be false. The consequences of spoofing are: o The disclosure of routing information: The spoofed router will be able to gain access to the routing information. Barbir, et al. Expires February 24, 2004 [Page = 12] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 o The deception of peer relationship: The authorized routers, = which exchange routing messages with the spoofed router, do not realize they are neighboring with a router that is faking another = router's identity. The threat consequence zone includes: The consequence zone of the disclosed routing information depends on what routing information has been exchanged between the = spoofed router and its neighbors. The threat consequence zone covers: o The consequence zone of the fake peer relationship will be = limited to those routers mistrusting the attacker's 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. 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. False routing information describes the network in an unrealistic view, whether or not = intended by the authoritative network administrator. 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. 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 Over-claiming 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 February 24, 2004 [Page = 13] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 with 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, it will cause a usurpation of Network 1 when Router B = or other routers on the Internet (not shown in the figures) believe that Router A provides the best path to reach the Network 1. = They, the routers, thereby forward the data traffic, destined to = Network Barbir, et al. Expires February 24, 2004 [Page = 14] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 1, to Router A. The best result is the data traffic uses an unauthorized path Figure 2, and the worst case is the data never reach the destination Network 1 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 on routers that are on the path, which is used by other routers to reach 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 not believe the attacker's advertisement and use the attacker to reach the claimed subnets (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. 4.5.1.2 Misclaiming Barbir, et al. Expires February 24, 2004 [Page = 15] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 A Misclaiming threat is defined as an attacker action 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 overclaimin. Eulogizing the network resources might cause the same consequences made by 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 = does not forward necessary routing information to other authorized routers. Unauthorized aggregation (summarization) is special type of understatements. 4.5.2.1 Misstatement This is defined as an action whereby the attacker describes route attributes in a wrong way. For example, in RIP, the attacker increases the path cost by two hops instead of one. Another example is, in BGP, the attacker deletes some AS numbers from the AS PATH. When forwarding routing information that 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 February 24, 2004 [Page = 16] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 area and period are also similar. 4.6 Interference Interference is a threat action where an attackers 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, and breaking synchronization. Subverted, unauthorized and masquerading routers can slowdown their routing exchanges or create flapping 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. 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. o 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 February 24, 2004 [Page = 17] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 4.7 Overload Overload is defined as a threat action whereby attackers place = excess burden on legitimate routers. Attackers can overload the data plane or control plane. Because data plane is involved in routing exchanges, overload of data plane will 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 effect the behavior of the entire routing system. Examples include the ability of an attacker to break the transport protocol connection (e.g., = TCP RST). 4.8 Byzantine Failures Within this work, Byzantine failure is an event resulting from a legitimate router or several legitimate routers running as subverted devices. Whether the subvertion results from an accidental behavior or from a malign attack may be considered for providing solutions in some cases (currently, the accidental origin of the threat is much more probable than the malign origin), yet in both cases it is assumed that the misbehaving routers are still considered as authenticated devices (according to the situation; therefore, misbehavior of insider(s) in a protocol is often regarded as a Byzantine failure). This is opposed to the fail-stop model, in which a system halt on the occurrence of a failure. The Byzantine failure event may involve many combinations of threat actions, threat consequences, threat zone and threat periods = possibly resulting from subverted devices. The Byzantine failure is specific in the sense that it is the distributed nature of the threat that is under consideration. Because Byzantine devices are, at least at the beginning of the problem, undetectable, only source and destination devices are to be trusted (though they may also be subverted). Because this threat results from a combination of incorrect behaviors, it may be difficult to tell apart which devices are subverted, or even to = state that the system is under the occurrence of such a failure. [Byzantine failure is often a threat to a distributed algorithm termination, to the agreement of non-subverted nodes, and to the validity of the conclusion agreed upon; here, ] Destination Barbir, et al. Expires February 24, 2004 [Page = 18] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 reachability and integrity of the information transmitted are the main system features jeopardized by the failure, according to the source and destination point of view. Route attributes (cost, hops, confidentiality...) may also be affected and result in a degradation of the service provided by the forwarding function. Barbir, et al. Expires February 24, 2004 [Page = 19] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 5. Security Considerations This entire informational draft RFC is security related. = Specifically it 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 as we know them today and lays the foundation for a future draft which fully discusses security requirements for routing protocols. Barbir, et al. Expires February 24, 2004 [Page = 20] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Normative References [1] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000. [2] Smith, R 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] Murphy, S et al., "OSPF with Digital Signatures", RFC 2154 , June 1997. [6] Moy, J, "OSPF Version 2", RFC 2328 , April 1998. [7] Mittal, V et al., "Sensor-Based Intrusion Detection for Intra-Domain istance-Vector Routing", Proceedings of the ACM Conference on Computer and Communication Security (CCS'02), Washington, DC , November 2002. [8] Cheung, S. et. al., "Protecting Routing Infrastructures from Denial of Service using co-operative intrusion detection", In Proceedings of the 1995 IEEE Symposium on Security and = Privacy , May 1995. [9] Bradley, K. et. al., "A distributed Network Monitoring approach", Published , November 2001. [10] Shen, N. et. al., "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 2763 , February 2000. [11] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721 , November 1994. Barbir, et al. Expires February 24, 2004 [Page = 21] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Informative References [12] Vetter, W. et al., "Experimental Study of Insider Attacks in = a Link State Routing Protocol", 5th IEEE International Conference on Network Protocols, Atlanta, GA , 1997. [13] "Internet Group Management Protocol", RFC 3376 , October = 2002. [14] Estrin, D. et al., "Independent Multicast-Sparse Mode = (PIM-SM): Protocol pecification", RFC 2362 , June 1998 . [15] Ballardie, A. et al., "Multicast-Specific Security Threats and Counter-Measures", "Symposium on network and Distributed System Security" , February 1995. [16] Smith, A. et al., "Securing the Border Gateway Routing Protocol", Proc. Global Internet'96 , November 1996. [17] Kent, S. et al., "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in = Communications , April 2000. Authors' Addresses Abbie Barbir (Editor) Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: EMail: abbieb@nortelnetworks.com Sandy Murphy Network Associates, Inc 3060 Washington Rd. Glenwood, MD 21738 USA Phone: 443-259-2303 EMail: sandy@tislabs.com Barbir, et al. Expires February 24, 2004 [Page = 22] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Yi Yang Cisco Systems 7025 Kit Creek Road RTP, NC 27709 Canada Phone: EMail: yiya@cisco.com Barbir, et al. Expires February 24, 2004 [Page = 23] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Appendix A. Acknowledgements 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 Barbir, et al. Expires February 24, 2004 [Page = 24] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Appendix B. Acronyms AODV - Ad-hoc On-demand Distance Vector routing protocol 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. eBGP - External BGP. BGP configuration in which sessions are established between routers in different ASs. iBGP - Internal BGP. BGP configuration in which sessions are established between routers in the same ASs. LSRP - Link-State Routing Protocol LSA - Link-State Announcement M-OSPF - Multicast Open Shortest Path First 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 February 24, 2004 [Page = 25] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 February 24, 2004 [Page = 26] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 February 24, 2004 [Page = 27] =0C ------_=_NextPart_000_01C36BBC.66F4AA80 Content-Type: APPLICATION/OCTET-STREAM; NAME="draft-ietf-rpsec-routing-threats-02.htm" Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="draft-ietf-rpsec-routing-threats-02.htm" Content-Transfer-Encoding: QUOTED-PRINTABLE =0A= =0A= Generic Threats to Routing = Protocols=0A= =0A= =0A= =0A= =0A= =0A=
 TOC 
=0A=
=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
Network Working GroupA. Barbir
Internet-DraftNortel = Networks
Expires: February 24, 2004S. Murphy
 Network = Associates, Inc
 Y. = Yang
 Cisco = Systems
 August 26, = 2003
=0A=

Generic Threats to = Routing Protocols
=0A=

draft-ietf-rpsec-routing-threats-02
=0A= =0A=

Status of this Memo

=0A=

=0A= This document is an Internet-Draft and is in full conformance with all = provisions of Section 10 of RFC2026.

=0A=

=0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups.=0A= Note that other groups may also distribute working documents as=0A= Internet-Drafts.

=0A=

=0A= Internet-Drafts are draft documents valid for a maximum of six = months=0A= and may be updated, replaced, or obsoleted by other documents at any = time.=0A= It is inappropriate to use Internet-Drafts as reference material or to = cite=0A= them other than as "work in progress."

=0A=

=0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/= ietf/1id-abstracts.txt.

=0A=

=0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html= .

=0A=

=0A= This Internet-Draft will expire on February 24, 2004.

=0A= =0A=

Copyright Notice

=0A=

=0A= Copyright (C) The Internet Society (2003). All Rights Reserved.

=0A= =0A=

Abstract

=0A= =0A=

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 affects 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.=0A=


=0A=

Table of Contents

=0A=

=0A= 1. =0A= Introduction
=0A= 2. =0A= Routing Functions Overview
=0A= 2.1 =0A= Routing Protocol Control and Data Planes
=0A= 3. =0A= Generic Routing Protocol Threat Model
=0A= 3.1 =0A= Threat Definitions
=0A= 3.1.1 =0A= Threat Sources
=0A= 3.1.2 =0A= Threat Consequences
=0A= 4. =0A= Generally Identifiable Routing Threats
=0A= 4.1 =0A= Deliberate Exposure
=0A= 4.2 =0A= Sniffing
=0A= 4.3 =0A= Traffic Analysis
=0A= 4.4 =0A= Spoofing
=0A= 4.5 =0A= Falsification
=0A= 4.5.1 =0A= Falsifications by Originators
=0A= 4.5.2 =0A= Falsifications by Forwarders
=0A= 4.6 =0A= Interference
=0A= 4.7 =0A= Overload
=0A= 4.8 =0A= Byzantine Failures
=0A= 5. =0A= Security Considerations
=0A= § =0A= Normative References
=0A= § =0A= Informative References
=0A= § =0A= Authors' Addresses
=0A= A. =0A= Acknowledgements
=0A= B. =0A= Acronyms
=0A= § =0A= Intellectual Property and Copyright Statements
=0A=

=0A=
=0A= =0A=
=0A=
 TOC 
=0A=

1. Introduction

=0A= =0A=

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 affects 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.=0A=

=0A=

This documents takes a general threats to routing functions. In this = work, the "owner" of an address prefix or an AS [17] number is an organization =0A= that has been granted the right to use that prefix or number. Each = Regional Internet Rggistry (RIR) acquires prefixes and AS numbers from = IANA, and further distributes (delegates use of) them to =0A= organizations such as ISPs and multi-homed subscribers. For address = prefixes, delegation typically involves assigning a subset of a prefix = to an organization, which may, in turn, further delegate =0A= subsets to other organizations, e.g., subscribers or downstream = providers.=0A= =0A= =0A=

=0A=

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 [6], IS-IS [10] , RIP [11] and BGP [17].=0A= =0A=

=0A=

The security requirements derived from this analysis are intended to = be used as guidance to those who are designing and modifying routing = protocols. They may also be used by routing protocol implementers to = increase the robustness of their implementations.=0A= =0A=

=0A=

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.=0A=

=0A=
=0A=
 TOC 
=0A=

2. Routing Functions = Overview

=0A= =0A=

This section provides an overview of common functions that are = shared among various routing protocols. In general, routing protocols = share the following common functions:=0A=

=0A=
    =0A=
  • Transport Subsystem: The routing protocol transmits messages to=0A= its neighbors using some underlying protocol. For example, OSPF = uses IP, while AODV uses a broadcast link. Other protocols may run over = TCP. =0A= =0A= =0A=
    • =0A=
  • Neighbor State Maintenance: neighboring relationship formation is = the first step for topology determination. For this reason, routing = protocols may need to maintain the state of their neighbors. Each = routing protocol may use a different mechanism for determining its = neighbors in the routing topology. Some protocols have distinct = exchange through which they establish neighboring relationships, e.g., = Hello exchanges in OSPF. =0A= =0A=
    • =0A=
  • Database Maintenance: Routing protocols exchange network = topology=0A= and reach-ability information. The routers collect this=0A= information in routing databases with varying detail. The=0A= maintenance of these databases is a significant portion of the = function of a routing protocol. =0A= =0A= =0A=
    • =0A=
=0A= =0A=

2.1 Routing Protocol Control and Data = Planes

=0A= =0A=

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. =0A= =0A=

=0A=

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. =0A=

=0A=

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.=0A= =0A=

=0A=
=0A=
 TOC 
=0A=

3. Generic Routing Protocol = Threat Model

=0A= =0A=

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.=0A= =0A=

=0A=

Routing protocols are subject to treats 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 neighbor (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. =0A= =0A=

=0A=

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, if the DR = election is disrupted in an OSPF network, an unauthorized router could = be chosen as designated router. This might allow unauthorized access = to routing information. In BGP, if a router receives a CEASE message, = it can break the neighboring relationship and cause any related = topology information to be flushed.=0A= =0A=

=0A=

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 LSA's with the wrong Advertising Router, the receivers = will compute a 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=0A= =0A=

=0A=

3.1 Threat Definitions

=0A= =0A=

Threat is defined in [1] as a potential for = violation of security, which exists when there is a circumstance, = capability, action, or event that could breach security and cause harm. = A threat presents itself when an attacker has the ability to take = advantage of an existing security weakness. Threats can be categorized = based on various rules, such as threat sources, threat actions, threat = consequences, threat consequence zones, and threat consequence = periods.=0A= =0A=

=0A=

3.1.1 Threat Sources

=0A= =0A=

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. =0A= =0A=

=0A=

Threats can originate form outsiders or insiders. An insider is an = authorized participant in the routing protocol. An outsider is any = other host or network. A host is determined to be an outsider or an = insider from the point of view of a particular router. Even an = authorized protocol speaker can be an outsider to a particular router = if the router does not consider the speaker to be a legitimate peer (as = could conceivably happen on a multi-access link).=0A= =0A=

=0A=

In general, threats can be classified into the following categories = based on their sources [2]:=0A=

=0A=
    =0A=
  • Threats that result from subverted links: A link become subverted = when an attacker gain access (or control) to 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.=0A=
    • =0A=
  • Threats that result from subverted devices (e.g. routers): A = subverted device (router) is an authorized router that may have routing = software bugs, hardware defects, incorrect or unintended = configurations. Devices can be susceptible to such threats due to the = lack mechanisms to verify system integrity (For example, the router is = working correctly as been intended by the authoritative network = administrator), or such mechanisms can be circumvented. Such threats = may enable attackers to inappropriately claim authority for some = network resources, or violate routing protocols, such as advertising = invalid routing information.=0A=
    • =0A=
=0A= =0A=

For example, an OSPF router will form a peering relationship with = any attached device which appears to be running OSPF, unless MD5 = authentication (or some other means) is used to prevent the neighboring = relationship from forming. Furthermore, MANET protocols frequently = speak over the broadcast link. =0A= =0A=

=0A=

3.1.2 Threat Consequences

=0A= =0A=

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=0A= the operation of the network as a whole.=0A= =0A= =0A=

=0A=

There are four types of threat consequences: disclosure, deception, = disruption,=0A= and usurpation [1].=0A= =0A=

=0A=
    =0A=
  • Disclosure: Disclosure of routing information happens when a=0A= router successfully accesses the information without being=0A= authorized. Subverted links can cause disclosure, if routing=0A= exchanges lack confidentiality. Subverted devices (routers),=0A= can cause disclosure, as long as they are successfully=0A= involved in the routing exchanges. Although inappropriate=0A= disclosure of routing information can pose a security threat or = be=0A= part of a later, larger, or higher layer attack, = confidentiality=0A= is not generally a design goal of routing protocols.=0A= =0A=
    • =0A=
  • Deception: This consequence happens when a legitimate router=0A= receives a false routing message and believes it to be true. = Subverted links and/or subverted device (routers)can cause this = consequence if the receiving router lacks ability to check routing = message integrity, routing message origin, authentication or peer = router authentication.=0A= =0A=
    • =0A=
  • Disruption: This consequence occurs when a legitimate router's=0A= operation is being interrupted or prevented. Subvert links can=0A= cause this by replaying, delaying, or dropping routing = messages,=0A= or breaking routing sessions between legitimate routers.=0A= Subverted devices (router) can cause this consequence by=0A= sending false routing messages, interfering normal routing=0A= exchanges, or flooding unnecessary messages. (DoS is a common=0A= threat action causing disruption.)=0A=
    • =0A=
  • Usurpation: This consequence happens when an attacker gains=0A= control over a legitimate router's services/functions. = Subverted=0A= links can cause this by delaying or dropping routing exchanges, = or=0A= replaying out-dated routing information. Subverted routers can = cause this=0A= consequence by sending false routing information, interfering=0A= routing exchanges, or system integrity.=0A=
    • =0A=
=0A= =0A=

Note: an attacker does not have to directly control a router to=0A= control its services. For example, in Figure = 1, Network 1 is=0A= dual-homed through Router A and Router B, and Router A is = preferred.=0A= However, Router B is compromised and advertises a lower metric.=0A= Consequently, devices on the Internet choose the path through = Router=0A= B to reach Network 1. In this way, Router B steals the data = traffic=0A= and Router A surrenders its control of the services to Router B. = This=0A= depicted in =0A= Figure 1.=0A= =0A= =0A= =0A=


=0A= =0A= 
=0A=
=0A=
   +-------------+   +-------+=0A=
   |  Internet   |---| Rtr A |=0A=
   +------+------+   +---+---+=0A=
          |              |=0A=
          |              |=0A=
          |              |=0A=
          |            *-+-*=0A=
   +-------+           /     \=0A=
   | Rtr B |----------*  N 1  *=0A=
   +-------+           \     /=0A=
                        *---*=0A=
=0A=
=0A=
=0A= =0A=

=0A=

 Network 
=0A= =0A=

Several threat consequences might be caused by a single threat=0A= action. In Figure 1, there exist at least two = consequences:=0A= routers using Router B to reach Network 1 are deceived, while = Router=0A= A is usurped. =0A=

=0A=

Within the context of the threat consequences described above, = damage=0A= that might result from attacks against the network as a whole may=0A= include:=0A=

=0A=
    =0A=
  • Network congestion: more data traffic is forwarded through some=0A= portion of the network than would otherwise need to carry the=0A= traffic,=0A= =0A=
    • =0A=
  • Blackhole: large amounts of traffic are directed to be forwarded=0A= through one router that cannot handle the increased level of=0A= traffic and drops many/most/all packets,=0A= =0A=
    • =0A=
  • Looping: data traffic is forwarded along a route that loops, so=0A= that the data is never delivered (resulting in network=0A= congestion),=0A= =0A=
    • =0A=
  • Partition: some portion of the network believes that it is=0A= partitioned from the rest of the network when it is not,=0A= =0A=
    • =0A=
  • Churn: the forwarding in the network changes (unnecessarily) at = a=0A= rapid pace, resulting in large variations in the data delivery=0A= patterns (and adversely affecting congestion control = techniques),=0A= =0A=
    • =0A=
  • Instability: the protocol becomes unstable so that convergence = on=0A= a global forwarding state is not achieved, and=0A= =0A=
    • =0A=
  • Overload: the protocol messages themselves become a significant=0A= portion of the traffic the network carries.=0A= =0A=
    • =0A=
=0A= =0A=

The damage that might result from attacks against a particular = host=0A= or network address may include:

=0A=
    =0A=
  • Starvation: data traffic destined for the network or host is=0A= forwarded to a part of the network that cannot deliver it, =0A= =0A=
    • =0A=
  • Eavesdrop: data traffic is forwarded through some router or=0A= network that would otherwise not see the traffic, affording an=0A= opportunity to see the data or at least the data delivery = pattern,=0A= =0A=
    • =0A=
  • Cut: some portion of the network believes that it has no route = to=0A= the host or network when it is in fact connected,=0A= =0A=
    • =0A=
  • Delay: data traffic destined for the network or host is = forwarded=0A= along a route that is in some way inferior to the route it = would=0A= otherwise take,=0A= =0A=
    • =0A=
  • Looping: data traffic for the network or host is forwarded along = a=0A= route that loops, so that the data is never delivered=0A=
    • =0A=
=0A= =0A=

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).=0A= =0A=

=0A=

3.1.2.1 Threat Consequence Zone

=0A= =0A=

A threat consequence zone covers the area within which the = network=0A= operations have been affected by threat actions. Possible=0A= threat consequence zones can be classified as: a single link or=0A= router, multiple routers (within a single routing domain), a = single=0A= routing domain, multiple routing domains, or the global Internet. = The=0A= threat consequence zone varies based on the threat action and = origin.=0A= Similar threat actions that happened at different locations may = cause=0A= totally different threat consequence zones. For example, when a=0A= compromised link breaks the routing session between a = distribution=0A= router and a stub router, only reach ability from and to the = network=0A= devices attached on the stub router will be impaired. In other = words,=0A= the threat consequence zone is a single router. Nonetheless, if = the=0A= compromised router is located between a customer edge router and = its=0A= corresponding provider edge router, such an action might cause = the=0A= whole customer site to lose its connection. In this case, the = threat=0A= consequence zone might be a single routing domain.=0A= =0A=

=0A=

3.1.2.2 Threat Consequence Periods

=0A= =0A=

Threat consequence period is defined as a portion of time during=0A= which the network operations have been impacted by the threat=0A= consequences. The threat consequence period is influenced by, but = not=0A= totally dependent on the duration of the threat action. In some=0A= cases, the network operations will get back to normal as soon as = the=0A= threat action has been stopped. In other cases, however, threat=0A= consequences may appear longer than threat action. For example, = in=0A= the original ARPANET link-state algorithm, some errors in a = router=0A= might introduce three instances of an LSA, and all of them would = be=0A= flooded throughout the network forever, until the entire network = was=0A= power cycled [3]. =0A= =0A=

=0A=
=0A=
 TOC 
=0A=

4. Generally Identifiable = Routing Threats

=0A= =0A=

This section addresses generally identifiable and recognized threat = action against routing protocols. The threats are not necessarily = specific to individual protocols but may be present in one or more of = the common routing protocols in use today.=0A= =0A=

=0A=

4.1 Deliberate Exposure

=0A= =0A=

Deliberate Exposure occurs when an attacker takes control of a = router and intentionally releases routing information directly to other = routers. In some cases, the receiving 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. = =0A=

=0A=

The consequence of deliberate exposure is the disclosure of = routing=0A= information.=0A= =0A=

=0A=

The threat consequence zone of deliberate exposure depends on the=0A= routing information that the attackers have exposed. The more=0A= knowledge they have exposed, the bigger the threat consequence = zone.=0A= =0A=

=0A=

The threat consequence period of deliberate exposure might be = longer=0A= than the duration of the action itself. The routing information=0A= exposed will not be out-dated until there is a topology change of = the=0A= exposed network.=0A= =0A=

=0A=

4.2 Sniffing

=0A= =0A=

Sniffing is an action whereby attackers monitor and/or record the=0A= routing exchanges between authorized routers. Attackers can use = subverted links to=0A= sniff for routing information. =0A=

=0A=

The consequence of sniffing is disclosure of routing information. = =0A= =0A=

=0A=

The threat consequence zone of sniffing depends on the attacker's = location, the routing protocol type, and the routing=0A= information that has been recorded. For example, if the subverted = link=0A= is in an OSPF totally stubby area, the threat consequence=0A= zone should be limited to the whole area. An attacker that is sniffing = a subverted link in an EBGP session =0A= can gain knowledge of multiple routing domains.=0A= =0A=

=0A=

The threat consequence period might be longer than the duration = of=0A= the action. If an attacker stops sniffing a subverted link their = acquired knowledge=0A= will not be out-dated until there is a topology change of the = affected network.=0A=

=0A=

4.3 Traffic Analysis

=0A= =0A=

Traffic analysis is 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 in the clear over a communication link. This threat is not = peculiar to routing protocols and is included here for completeness.=0A=

=0A=

The consequence of data traffic analysis is the disclosure of = routing=0A= information. For example, the source and destination IP address = of=0A= the data traffic, the type, magnitude, and volume of traffic is=0A= disclosed.=0A= =0A=

=0A=

The threat consequence zone of the traffic analysis depends on = the=0A= attacker's location and what data traffic has passed=0A= through. A subverted link at the network core should be able to=0A= disclose more information than its counterpart at the edge.=0A= =0A=

=0A=

The threat consequence period might be longer than the duration = of=0A= the traffic analysis. After the attacker stops traffic analysis, = its=0A= knowledge will not be out-dated until there is a topology change = of=0A= the disclosed network.=0A= =0A=

=0A=

4.4 Spoofing

=0A= =0A=

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 to spoof the identity of a router, the = subverted router can act as masquerading router. In other situation, = the spoofed router can be used to send out unrealistic routing = information that might cause disruption of network services. =0A=

=0A=

=0A= There are a few cases where spoofing can be an attack. For example, if = a router establishes a neighbor/peering relationship, spoofing the = identity of a legitimate router and by that action was able to prevent = the legitimate router from establishing a relationship; that would be = an attack, denying service to the good router. As a second example, if = a router is doing auditing, then the ability to spoof an identity of a = router would be an attack, since the audit data would be false.=0A= =0A=

=0A=

The consequences of spoofing are:=0A=

=0A=
    =0A=
  • The disclosure of routing information: The spoofed router will be = able to gain access to the routing information. =0A=
    • =0A=
  • The deception of peer relationship: The authorized routers, which = exchange routing messages with the spoofed router, do not realize they = are neighboring with a router that is faking another router's identity. = =0A=
    • =0A=
=0A= =0A=

The threat consequence zone includes:=0A=

=0A=
=0A=
  • The consequence zone of the disclosed routing information depends = on what routing information has been exchanged between the spoofed = router and its neighbors.=0A=
    • =0A=
    =0A= =0A=

    The threat consequence zone covers:=0A=

    =0A=
      =0A=
    • The consequence zone of the fake peer relationship will be limited = to those routers mistrusting the attacker's identity.=0A=
      • =0A=
    • 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.=0A=
      • =0A=
    =0A= =0A=

    4.5 Falsification

    =0A= =0A=

    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. False routing information describes the = network in an unrealistic view, whether or not intended by the = authoritative network administrator.=0A=

    =0A=

    To falsify the routing information, an attacker has to be either = the=0A= originator or a forwarder of the routing information. It cannot be = a=0A= receiver-only.=0A= =0A=

    =0A=

    4.5.1 Falsifications by Originators

    =0A= =0A=

    An originator of routing information can launch the falsifications = that are described in the next sections.=0A=

    =0A=

    4.5.1.1 Overclaiming

    =0A= =0A=

    Over-claiming 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.=0A= =0A=


    =0A= =0A= 
    =0A=
=0A=
           +-------------+   +-------+   +-------+=0A=
           | Internet    |---| Rtr B |---| Rtr A |=0A=
           +------+------+   +-------+   +---+---+=0A=
                  |                          .=0A=
                  |                          |=0A=
                  |                          .=0A=
                  |                        *-+-*=0A=
              +-------+                   /     \=0A=
              | Rtr C |------------------*  N 1  *=0A=
              +-------+                   \     /=0A=
                                           *---*=0A=
=0A=
    =0A= =0A=

    =0A=

     Overclaiming-1 
    =0A=
    =0A= =0A= 
    =0A=
=0A=
     +-------------+   +-------+   +-------+=0A=
     |  Internet   |---| Rtr B |---| Rtr A |=0A=
     +------+------+   +-------+   +-------+=0A=
            |=0A=
            |=0A=
            |=0A=
            |                        *---*=0A=
        +-------+                   /     \ =0A=
        | Rtr C |------------------*  N 1  *=0A=
        +-------+                   \     /=0A=
                                     *---*=0A=
=0A=
    =0A= =0A=

    =0A=

     Overclaiming-2 
    =0A= =0A=

    The above figures provide examples of overclaiming. Router A, the = attacker, is connected with 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.=0A= =0A= =0A=

    =0A=

    Compromised routers, unauthorized routers, and masquerading routers = can overclaim network resources. The consequence of overclaiming = includes:=0A=

    =0A=
      =0A=
    • Usurpation of the overclaimed network resources. In Figure 2 and=0A= Figure 3, it will cause a usurpation of Network 1 = when Router B or other routers on the Internet (not shown in the = figures) believe that Router A provides the best path to reach the = Network 1. They, the routers, thereby forward the data traffic, = destined to Network 1, to Router A. The best result is the data traffic = uses an unauthorized path Figure 2, and the worst = case is the data never reach the destination Network 1 Figure 3. The ultimate consequence is Router A = gaining control over Network 1's services, by controlling the data = traffic.=0A= =0A=
      • =0A=
    • 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.)=0A=
      • =0A=
    • 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.=0A=
      • =0A=
    • Disruption of data planes on some routers. This might happen on = routers that are on the path, which is used by other routers to reach = 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. =0A=
      • =0A=
    =0A= =0A=

    The threat consequence zone varies based on the consequence:=0A=

    =0A=
      =0A=
    • 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).=0A=
      • =0A=
    • Where deception is concerned, the consequence zone covers the = routers that do not believe the attacker's advertisement and use the = attacker to reach the claimed subnets (Router B and other deceived = routers on the Internet in Figure 2 and Figure 3).=0A=
      • =0A=
    • 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).=0A=
      • =0A=
    =0A= =0A=

    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.=0A=

    =0A=

    4.5.1.2 Misclaiming

    =0A= =0A=

    A Misclaiming threat is defined as an attacker action advertising = its=0A= authorized control of some network resources in a way that is not=0A= intended by the authoritative network administrator. An attacker = can=0A= eulogize or disparage when advertising these network resources.=0A= Subverted routers, unauthorized routers, and masquerading routers=0A= can misclaim network resources.=0A= =0A=

    =0A=

    The threat consequences of Misclaiming are similar to the=0A= consequences of overclaimin. Eulogizing the network resources might = cause the same consequences made by=0A= overclaiming.=0A= =0A= =0A=

    =0A=

    The consequence zone and period are also similar to those of = overclaiming.=0A= =0A=

    =0A=

    4.5.2 Falsifications by Forwarders

    =0A= =0A=

    When a legitimate router forwards routing information, it must or=0A= must not modify the routing information, depending on the routing=0A= information and the routing protocol type. For example, in RIP, = the=0A= forwarder must modify the routing information by increasing the = hop=0A= count by 1. On the other hand, the forwarder must not modify the = type=0A= 1 LSA in OSPF. In general, forwarders in distance vector routing=0A= protocols are authorized to and must modify the routing = information,=0A= while most forwarders in link state routing protocols are not=0A= authorized to and must not modify most routing information.=0A= =0A=

    =0A=

    As a forwarder authorized to modify routing message, an attacker = does=0A= not forward necessary routing information to other authorized=0A= routers. Unauthorized aggregation (summarization) is special type = of=0A= understatements.=0A= =0A=

    =0A=

    =0A=

    =0A=

    4.5.2.1 Misstatement

    =0A= =0A=

    This is defined as an action whereby the attacker describes route = attributes in a wrong way. For example, in RIP, the attacker increases = the path cost by two hops instead of one. Another example is, in BGP, = the attacker deletes some AS numbers from the AS PATH. =0A=

    =0A=

    When forwarding routing information that should not be modified, an = attacker can launch the following falsifications:=0A=

    =0A=
      =0A=
    • Deletion: Attacker deletes valid data in the routing message.=0A=
      • =0A=
    • Insertion: Attacker inserts false data in the routing message.=0A=
      • =0A=
    • Substitution: Attacker replaces valid data in the routing message = with false data.=0A=
      • =0A=
    • Replaying: Attacker replays out-dated data in the routing = message.=0A=
      • =0A=
    =0A= =0A=

    All types of attackers (Compromised links, compromised routers, = unauthorized routers, and masquerading routers) can falsify the routing = information when they forward the routing messages.=0A=

    =0A=

    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 area and period are also similar.=0A=

    =0A=

    =0A=

    =0A=

    4.6 Interference

    =0A= =0A=

    Interference is a threat action where an attackers 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, and breaking synchronization.=0A=

    =0A=

    Subverted, unauthorized and masquerading routers can slowdown their = routing exchanges or create flapping routing sessions of legitimate = neighboring routers. =0A=

    =0A=

    The consequence of interference is the disruption of routing = operations. =0A=

    =0A=

    The consequence zone of interference varies based on the source of = the threats: =0A=

    =0A=
      =0A=
    • 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. =0A=
      • =0A=
    • 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.=0A=
      • =0A=
    • 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.=0A=
      • =0A=
    =0A= =0A=

    =0A=

    =0A=

    =0A=

    =0A=

    4.7 Overload

    =0A= =0A=

    Overload is defined as a threat action whereby attackers place = excess=0A= burden on legitimate routers. Attackers can overload the data plane = or=0A= control plane. Because data plane is involved in routing = exchanges,=0A= overload of data plane will also influence the routing = operations.=0A= =0A=

    =0A=

    This section combines overload of the control plane and the data = plane=0A= (i.e., the routing protocol messages and the data traffic, not the = control and=0A= data plane of the routing protocol itself as discussed in section=0A= 2.1). The routing protocol design might have a chance to limit control = plane=0A= traffic. However, the routing protocol cannot limit the data traffic. = Thus, an attacker can effect the behavior of the entire routing = system.=0A= Examples include the ability of an attacker to break the transport = protocol connection (e.g., TCP RST). =0A= =0A= =0A=

    =0A=

    4.8 Byzantine Failures

    =0A= =0A=

    =0A= =0A= Within this work, Byzantine failure is an event resulting from a=0A= legitimate router or several legitimate routers running as = subverted=0A= devices. Whether the subvertion results from an accidental behavior = or=0A= from a malign attack may be considered for providing solutions in = some=0A= cases (currently, the accidental origin of the threat is much more=0A= probable than the malign origin), yet in both cases it is assumed = that=0A= the misbehaving routers are still considered as authenticated = devices=0A= (according to the situation; therefore, misbehavior of insider(s) in = a=0A= protocol is often regarded as a Byzantine failure). This is opposed = to=0A= the fail-stop model, in which a system halt on the occurrence of a=0A= failure. =0A= =0A= =0A=

    =0A=

    =0A= =0A= The Byzantine failure event may involve many combinations of = threat=0A= actions, threat consequences, threat zone and threat periods = possibly=0A= resulting from subverted devices.=0A= =0A= =0A=

    =0A=

    =0A= =0A= The Byzantine failure is specific in the sense that it is the = distributed=0A= nature of the threat that is under consideration. Because = Byzantine=0A= devices are, at least at the beginning of the problem, undetectable, = only=0A= source and destination devices are to be trusted (though they may = also be=0A= subverted). Because this threat results from a combination of = incorrect=0A= behaviors, it may be difficult to tell apart which devices are = subverted,=0A= or even to state that the system is under the occurrence of such a=0A= failure.=0A= =0A= =0A=

    =0A=

    =0A= =0A= [Byzantine failure is often a threat to a distributed algorithm=0A= termination, to the agreement of non-subverted nodes, and to the = validity=0A= of the conclusion agreed upon; here, ] Destination reachability = and=0A= integrity of the information transmitted are the main system = features=0A= jeopardized by the failure, according to the source and destination = point=0A= of view. Route attributes (cost, hops, confidentiality...) may also = be=0A= affected and result in a degradation of the service provided by = the=0A= forwarding function.=0A= =0A= =0A=

    =0A=
    =0A=
     TOC 
    =0A=

    5. Security = Considerations

    =0A= =0A=

    =0A= This entire informational draft RFC is security related. Specifically = it 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 as we know them today and lays the foundation = for a future draft which fully discusses security requirements for = routing protocols. =0A=

    =0A=
    =0A=
     TOC 
    =0A=

    Normative References

    =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
    [1]Shirey, R, "Internet Security = Glossary", RFC 2828 , May 2000.
    [2]Smith, R et al., "Securing Distance-Vector = Routing Protocols", Symposium on Network and Distributed System = Security=0A= , 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]Murphy, S et al., "OSPF with=0A= Digital Signatures", RFC 2154 , June 1997.
    [6]Moy, J, "OSPF Version 2", = RFC 2328 , April 1998.
    [7]Mittal, V et al., "Sensor-Based Intrusion = Detection for Intra-Domain istance-Vector Routing", Proceedings of the = ACM Conference =0A= on Computer and Communication Security (CCS'02), Washington, DC=0A= , November 2002.
    [8]Cheung, S. et. al., "Protecting Routing = Infrastructures from Denial of Service using co-operative intrusion = detection", In Proceedings of the 1995 IEEE Symposium on Security and = Privacy=0A= , May 1995.
    [9]Bradley, K. et. al., "A distributed Network = Monitoring approach", Published , November 2001.
    [10]Shen, N. et. al., "Dynamic Hostname = Exchange Mechanism for IS-IS", RFC 2763 , February = 2000.
    [11]Malkin, G., "RIP Version 2 Protocol = Analysis", RFC 1721 , November = 1994.
    =0A= =0A=
    =0A=
     TOC 
    =0A=

    Informative References

    =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
    [12]Vetter, W. et al., "Experimental Study of = Insider Attacks in a Link State Routing Protocol", 5th IEEE = International Conference on Network Protocols, Atlanta, GA=0A= , 1997.
    [13]"Internet Group = Management Protocol", RFC 3376 , October 2002.
    [14]Estrin, D. et al., "Independent = Multicast-Sparse Mode (PIM-SM): Protocol pecification", RFC 2362 , = June 1998 .
    [15]Ballardie, A. et al., "Multicast-Specific = Security Threats and Counter-Measures", "Symposium on network and = Distributed System Security"=0A= , February 1995.
    [16]Smith, A. et al., "Securing the Border = Gateway Routing Protocol", Proc. Global Internet'96 , November = 1996.
    [17]Kent, S. et al., "Secure Border Gateway = Protocol (Secure-BGP)", IEEE Journal on Selected Areas in = Communications , April 2000.
    =0A= =0A=
    =0A=
     TOC 
    =0A=

    Authors' Addresses

    =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
     Abbie Barbir (Editor)
     Nortel Networks
     3500 Carling Avenue
     Nepean, Ontario K2H 8E9
     Canada
    Phone: 
    EMail: abbieb@nortelnetworks.com<= /td>
      
     Sandy Murphy
     Network Associates, Inc
     3060 Washington Rd.
     Glenwood, MD 21738
     USA
    Phone: 443-259-2303
    EMail: sandy@tislabs.com
      
     Yi Yang
     Cisco Systems
     7025 Kit Creek Road
     RTP, NC 27709
     Canada
    Phone: 
    EMail: yiya@cisco.com
    =0A= =0A=
    =0A=
     TOC 
    =0A=

    Appendix A. Acknowledgements

    = =0A= =0A=

    This draft would not have been possible save for the excellent = efforts=0A= and team work characteristics of those listed here.=0A=

    =0A=
      =0A=
    • Dennis Beard- Nortel Networks=0A=
      • =0A=
    • Ayman Musharbash - Nortel Networks=0A=
      • =0A=
    • Jean-Jacques Puig, int-evry, France =0A=
      • =0A=
    • Paul Knight - Nortel Networks=0A=
      • =0A=
    • Elwyn Davies - Nortel Networks=0A=
      • =0A=
    • Ameya Dilip Pandit - Graduate student - University of Missouri=0A=
      • =0A=
    • Senthilkumar Ayyasamy - Graduate student - University of = Missouri=0A=
      • =0A=
    =0A= =0A=

    =0A=

    =0A=
    =0A=
     TOC 
    =0A=

    Appendix B. Acronyms

    =0A= =0A=

    AODV - Ad-hoc On-demand Distance Vector routing protocol=0A= =0A=

    =0A=

    AS - Autonomous system. Set of routers under a single technical=0A= administration. Each AS normally uses a single interior gateway=0A= protocol (IGP) and metrics to propagate routing information=0A= within the set of routers. Also called routing domain.=0A= =0A=

    =0A=

    AS-Path - In BGP, the route to a destination. The path consists=0A= of the AS numbers of all routers a packet must go through to reach = a=0A= destination.=0A= =0A=

    =0A=

    BGP - Border Gateway Protocol. Exterior gateway protocol used to=0A= exchange routing information among routers in different autonomous=0A= systems.=0A= =0A= =0A=

    =0A=

    eBGP - External BGP. BGP configuration in which sessions are=0A= established between routers in different ASs.=0A= =0A=

    =0A=

    iBGP - Internal BGP. BGP configuration in which sessions are=0A= established between routers in the same ASs.=0A= =0A= =0A=

    =0A=

    LSRP - Link-State Routing Protocol=0A= =0A= =0A=

    =0A=

    LSA - Link-State Announcement=0A= =0A=

    =0A=

    M-OSPF - Multicast Open Shortest Path First=0A= =0A= =0A=

    =0A=

    NLRI - Network layer reachability information. Information that=0A= is carried in BGP packets and is used by MBGP.=0A= =0A=

    =0A=

    OSPF - Open Shortest Path First. A link-state IGP that makes=0A= routing decisions based on the shortest-path-first (SPF) algorithm =0A= (also referred to as the Dijkstra algorithm).=0A= =0A= =0A= =0A=


    =0A=
     TOC 
    =0A=

    Intellectual Property Statement

    =0A=

    =0A= The IETF takes no position regarding the validity or scope of=0A= any intellectual property or other rights that might be claimed=0A= to pertain to the implementation or use of the technology=0A= described in this document or the extent to which any license=0A= under such rights might or might not be available; neither does=0A= it represent that it has made any effort to identify any such=0A= rights. Information on the IETF's procedures with respect to=0A= rights in standards-track and standards-related documentation=0A= can be found in BCP-11. Copies of claims of rights made=0A= available for publication and any assurances of licenses to=0A= be made available, or the result of an attempt made=0A= to obtain a general license or permission for the use of such=0A= proprietary rights by implementors or users of this=0A= specification can be obtained from the IETF Secretariat.

    =0A=

    =0A= The IETF invites any interested party to bring to its=0A= attention any copyrights, patents or patent applications, or=0A= other proprietary rights which may cover technology that may be=0A= required to practice this standard. Please address the=0A= information to the IETF Executive Director.

    =0A=

    Full Copyright Statement

    =0A=

    =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.

    =0A=

    =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it=0A= or assist in its implementation may be prepared, copied, published = and=0A= distributed, in whole or in part, without restriction of any kind,=0A= provided that the above copyright notice and this paragraph are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by removing=0A= the copyright notice or references to the Internet Society or other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other than=0A= English.

    =0A=

    =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assignees.

    =0A=

    =0A= This document and the information contained herein is provided on an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

    =0A=

    Acknowledgment

    =0A=

    =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.

    =0A= =0A= =0A= ------_=_NextPart_000_01C36BBC.66F4AA80-- ------_=_NextPart_000_01C36BBC.66F4AA80-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Aug 28 08:41:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08943 for ; Thu, 28 Aug 2003 08:41:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKIg-0007Ts-QB for rpsec-archive@odin.ietf.org; Thu, 28 Aug 2003 06:46:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SAkkB5028750 for rpsec-archive@odin.ietf.org; Thu, 28 Aug 2003 06:46:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sJvH-0005BQ-8M for rpsec-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 06:22:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26088 for ; Thu, 28 Aug 2003 06:22:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sJvC-00021P-00 for rpsec-web-archive@ietf.org; Thu, 28 Aug 2003 06:22:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sJvB-00021M-00 for rpsec-web-archive@ietf.org; Thu, 28 Aug 2003 06:22:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sFMB-0004nb-K3; Thu, 28 Aug 2003 01:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDPp-0006HH-Su for rpsec@optimus.ietf.org; Wed, 27 Aug 2003 23:25:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09028 for ; Wed, 27 Aug 2003 23:25:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sDPn-0000mO-00 for rpsec@ietf.org; Wed, 27 Aug 2003 23:25:39 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 19sDPl-0000ld-00 for rpsec@ietf.org; Wed, 27 Aug 2003 23:25:37 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h7S3OxE20814 for ; Wed, 27 Aug 2003 23:24:59 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Wed, 27 Aug 2003 09:21:45 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="----_=_NextPart_000_01C36BBC.66F4AA80" Content-ID: ReSent-Date: Wed, 27 Aug 2003 23:24:47 -0400 (EDT) ReSent-From: Tony Tauber ReSent-To: rpsec@ietf.org ReSent-Subject: WG Last Call on Threats Doc ReSent-Message-ID: Subject: [RPSEC] WG Last Call on Threats Doc Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , ------_=_NextPart_000_01C36BBC.66F4AA80 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: > On Mon, 25 Aug 2003, abbie barbir wrote: > > > Attached is the -02 version, please review. > > I do not have access through work today. > > Can you please fwd to the rpsec list and the > > ietf-drafts. > > > > Thanks > > > > Abbie Folks, With this posting, we're starting a Working Group Last Call for the Generic Routing Protocol Threats document. I know it's far from perfect, but let's hope it's useful enough to serve as a background analysis and to get us into the Generic Requirements document. Please review and send comments by Sun. September 7th. Thanks, Tony ------_=_NextPart_000_01C36BBC.66F4AA80 Content-Type: TEXT/PLAIN; NAME="draft-ietf-rpsec-routing-threats-02.txt" Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="draft-ietf-rpsec-routing-threats-02.txt" Content-Transfer-Encoding: QUOTED-PRINTABLE Network Working Group A. = Barbir Internet-Draft Nortel = Networks Expires: February 24, 2004 S. = Murphy Network Associates, = Inc Y. = Yang Cisco = Systems August 26, = 2003 Generic Threats to Routing Protocols draft-ietf-rpsec-routing-threats-02 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 February 24, 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 affects 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 February 24, 2004 [Page = 1] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Routing Functions Overview . . . . . . . . . . . . . . . . . = 4 2.1 Routing Protocol Control and Data Planes . . . . . . . . . . = 4 3. Generic Routing Protocol Threat Model . . . . . . . . . . . = 5 3.1 Threat Definitions . . . . . . . . . . . . . . . . . . . . . = 5 3.1.1 Threat Sources . . . . . . . . . . . . . . . . . . . . . . . = 6 3.1.2 Threat Consequences . . . . . . . . . . . . . . . . . . . . = 7 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 . . . . . . . . . . . . . . . . . . = 20 Normative References . . . . . . . . . . . . . . . . . . . . = 21 Informative References . . . . . . . . . . . . . . . . . . . = 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . = 22 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = 24 B. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . = 25 Intellectual Property and Copyright Statements . . . . . . . = 26 Barbir, et al. Expires February 24, 2004 [Page = 2] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 affects 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 documents takes a general threats to routing functions. In this work, the "owner" of an address prefix or an AS [17] number is an organization that has been granted the right to use that prefix or number. Each Regional Internet Rggistry (RIR) acquires prefixes and AS numbers from IANA, and further distributes (delegates use of) = them to organizations such as ISPs and multi-homed subscribers. For address prefixes, delegation typically involves assigning a subset = of a prefix to an organization, which may, in turn, further delegate subsets to other organizations, e.g., subscribers or downstream providers. 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 [6], IS-IS [10] , RIP [11] and BGP [17]. The security requirements derived from this analysis are intended to be used as guidance to those who are designing and modifying routing protocols. They may also be used by routing protocol implementers to increase the robustness of their implementations. 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 February 24, 2004 [Page = 3] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 common functions: o Transport Subsystem: The routing protocol transmits messages to its neighbors using some underlying protocol. For example, OSPF uses IP, while AODV uses a broadcast link. Other protocols may = run over TCP. o Neighbor State Maintenance: neighboring relationship formation is the first step for topology determination. For this reason, routing protocols may need to maintain the state of their neighbors. Each routing protocol may use a different mechanism for determining its neighbors in the routing topology. Some protocols have distinct exchange through which they establish neighboring relationships, e.g., Hello exchanges in OSPF. o Database Maintenance: Routing protocols exchange network topology and reach-ability 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. 2.1 Routing Protocol Control and Data Planes 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 February 24, 2004 [Page = 4] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 treats 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 neighbor (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, if the DR election is disrupted in an OSPF network, an unauthorized router could be chosen as designated router. This might allow unauthorized access to routing information. In BGP, if a router receives a CEASE message, it can break the neighboring relationship and cause any related topology information to be flushed. 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 LSA's with the wrong Advertising Router, the receivers will compute a 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 Threat is defined in [1] as a potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm. A threat presents itself when an attacker has the ability to take advantage of an Barbir, et al. Expires February 24, 2004 [Page = 5] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 existing security weakness. 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 form outsiders or insiders. An insider is an authorized participant in the routing protocol. An outsider is any other host or network. A host is determined to be an outsider or an insider from the point of view of a particular router. Even an authorized protocol speaker can be an outsider to a particular = router if the router does not consider the speaker to be a legitimate peer (as could conceivably happen on a multi-access link). In general, threats can be classified into the following categories based on their sources [2]: o Threats that result from subverted links: A link become subverted when an attacker gain access (or control) to 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 routing software bugs, hardware defects, incorrect or unintended configurations. Devices can be susceptible to such threats due to the lack mechanisms to verify system integrity (For example, the router is working correctly as been intended by the authoritative network administrator), or such mechanisms can be circumvented. Such threats may enable attackers to inappropriately claim authority for some network resources, or violate routing protocols, such as advertising invalid routing information. For example, an OSPF router will form a peering relationship with = any attached device which appears to be running OSPF, unless MD5 authentication (or some other means) is used to prevent the neighboring relationship from forming. Furthermore, MANET protocols Barbir, et al. Expires February 24, 2004 [Page = 6] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 frequently speak over the broadcast link. 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]. 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 false routing message and believes it to be true. Subverted links and/or subverted device (routers)can cause this consequence if the receiving router lacks ability to check routing message integrity, routing message origin, authentication or peer router authentication. o Disruption: This consequence occurs when a legitimate router's operation is being interrupted or prevented. Subvert links can cause this by replaying, delaying, or dropping routing messages, or breaking routing sessions between legitimate routers. = Subverted devices (router) can cause this consequence by sending false routing messages, interfering 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, interfering routing exchanges, or system integrity. 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. Barbir, et al. Expires February 24, 2004 [Page = 7] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 However, Router B is compromised and advertises a lower 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. +-------------+ +-------+ | Internet |---| Rtr A | +------+------+ +---+---+ | | | | | | | *-+-* +-------+ / \ | Rtr B |----------* N 1 * +-------+ \ / *---* Figure 1: 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: large amounts of traffic are directed to be forwarded through one router that cannot handle the increased level of traffic and drops many/most/all packets, 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 Barbir, et al. Expires February 24, 2004 [Page = 8] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 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. 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. Barbir, et al. Expires February 24, 2004 [Page = 9] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Similar threat actions that happened at different locations may = cause totally different threat consequence zones. For example, when a compromised link breaks the routing session between a distribution router and a stub router, only reach ability from and to the network devices attached on the stub router will be impaired. In other = words, the threat consequence zone is a single router. Nonetheless, 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 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 have 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 appear longer than threat action. For example, in the original ARPANET link-state algorithm, some errors in a router might introduce three instances of an LSA, and all of them would be flooded throughout the network forever, until the entire network was power cycled [3]. Barbir, et al. Expires February 24, 2004 [Page = 10] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 4. Generally Identifiable Routing Threats This section addresses generally identifiable and recognized threat action against routing protocols. The threats 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 other routers. In some cases, the receiving 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. 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 acquired knowledge will not be out-dated until there is a topology change of the affected network. Barbir, et al. Expires February 24, 2004 [Page = 11] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 4.3 Traffic Analysis Traffic analysis is 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 in the clear 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 address of the data traffic, the type, magnitude, and volume of traffic is 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 to spoof the identity of a router, the subverted router can act as masquerading router. In other situation, the spoofed router can be used to send out unrealistic routing information that might cause disruption of network services. There are a few cases where spoofing can be an attack. For example, if a router establishes a neighbor/peering relationship, spoofing = the identity of a legitimate router and by that action was able to prevent the legitimate router from establishing a relationship; that would be an attack, denying service to the good router. As a second example, if a router is doing auditing, then the ability to spoof an identity of a router would be an attack, since the audit data would be false. The consequences of spoofing are: o The disclosure of routing information: The spoofed router will be able to gain access to the routing information. Barbir, et al. Expires February 24, 2004 [Page = 12] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 o The deception of peer relationship: The authorized routers, = which exchange routing messages with the spoofed router, do not realize they are neighboring with a router that is faking another = router's identity. The threat consequence zone includes: The consequence zone of the disclosed routing information depends on what routing information has been exchanged between the = spoofed router and its neighbors. The threat consequence zone covers: o The consequence zone of the fake peer relationship will be = limited to those routers mistrusting the attacker's 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. 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. False routing information describes the network in an unrealistic view, whether or not = intended by the authoritative network administrator. 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. 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 Over-claiming 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 February 24, 2004 [Page = 13] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 with 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, it will cause a usurpation of Network 1 when Router B = or other routers on the Internet (not shown in the figures) believe that Router A provides the best path to reach the Network 1. = They, the routers, thereby forward the data traffic, destined to = Network Barbir, et al. Expires February 24, 2004 [Page = 14] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 1, to Router A. The best result is the data traffic uses an unauthorized path Figure 2, and the worst case is the data never reach the destination Network 1 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 on routers that are on the path, which is used by other routers to reach 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 not believe the attacker's advertisement and use the attacker to reach the claimed subnets (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. 4.5.1.2 Misclaiming Barbir, et al. Expires February 24, 2004 [Page = 15] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 A Misclaiming threat is defined as an attacker action 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 overclaimin. Eulogizing the network resources might cause the same consequences made by 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 = does not forward necessary routing information to other authorized routers. Unauthorized aggregation (summarization) is special type of understatements. 4.5.2.1 Misstatement This is defined as an action whereby the attacker describes route attributes in a wrong way. For example, in RIP, the attacker increases the path cost by two hops instead of one. Another example is, in BGP, the attacker deletes some AS numbers from the AS PATH. When forwarding routing information that 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 February 24, 2004 [Page = 16] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 area and period are also similar. 4.6 Interference Interference is a threat action where an attackers 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, and breaking synchronization. Subverted, unauthorized and masquerading routers can slowdown their routing exchanges or create flapping 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. 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. o 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 February 24, 2004 [Page = 17] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 4.7 Overload Overload is defined as a threat action whereby attackers place = excess burden on legitimate routers. Attackers can overload the data plane or control plane. Because data plane is involved in routing exchanges, overload of data plane will 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 effect the behavior of the entire routing system. Examples include the ability of an attacker to break the transport protocol connection (e.g., = TCP RST). 4.8 Byzantine Failures Within this work, Byzantine failure is an event resulting from a legitimate router or several legitimate routers running as subverted devices. Whether the subvertion results from an accidental behavior or from a malign attack may be considered for providing solutions in some cases (currently, the accidental origin of the threat is much more probable than the malign origin), yet in both cases it is assumed that the misbehaving routers are still considered as authenticated devices (according to the situation; therefore, misbehavior of insider(s) in a protocol is often regarded as a Byzantine failure). This is opposed to the fail-stop model, in which a system halt on the occurrence of a failure. The Byzantine failure event may involve many combinations of threat actions, threat consequences, threat zone and threat periods = possibly resulting from subverted devices. The Byzantine failure is specific in the sense that it is the distributed nature of the threat that is under consideration. Because Byzantine devices are, at least at the beginning of the problem, undetectable, only source and destination devices are to be trusted (though they may also be subverted). Because this threat results from a combination of incorrect behaviors, it may be difficult to tell apart which devices are subverted, or even to = state that the system is under the occurrence of such a failure. [Byzantine failure is often a threat to a distributed algorithm termination, to the agreement of non-subverted nodes, and to the validity of the conclusion agreed upon; here, ] Destination Barbir, et al. Expires February 24, 2004 [Page = 18] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 reachability and integrity of the information transmitted are the main system features jeopardized by the failure, according to the source and destination point of view. Route attributes (cost, hops, confidentiality...) may also be affected and result in a degradation of the service provided by the forwarding function. Barbir, et al. Expires February 24, 2004 [Page = 19] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 5. Security Considerations This entire informational draft RFC is security related. = Specifically it 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 as we know them today and lays the foundation for a future draft which fully discusses security requirements for routing protocols. Barbir, et al. Expires February 24, 2004 [Page = 20] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Normative References [1] Shirey, R, "Internet Security Glossary", RFC 2828 , May 2000. [2] Smith, R 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] Murphy, S et al., "OSPF with Digital Signatures", RFC 2154 , June 1997. [6] Moy, J, "OSPF Version 2", RFC 2328 , April 1998. [7] Mittal, V et al., "Sensor-Based Intrusion Detection for Intra-Domain istance-Vector Routing", Proceedings of the ACM Conference on Computer and Communication Security (CCS'02), Washington, DC , November 2002. [8] Cheung, S. et. al., "Protecting Routing Infrastructures from Denial of Service using co-operative intrusion detection", In Proceedings of the 1995 IEEE Symposium on Security and = Privacy , May 1995. [9] Bradley, K. et. al., "A distributed Network Monitoring approach", Published , November 2001. [10] Shen, N. et. al., "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 2763 , February 2000. [11] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721 , November 1994. Barbir, et al. Expires February 24, 2004 [Page = 21] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Informative References [12] Vetter, W. et al., "Experimental Study of Insider Attacks in = a Link State Routing Protocol", 5th IEEE International Conference on Network Protocols, Atlanta, GA , 1997. [13] "Internet Group Management Protocol", RFC 3376 , October = 2002. [14] Estrin, D. et al., "Independent Multicast-Sparse Mode = (PIM-SM): Protocol pecification", RFC 2362 , June 1998 . [15] Ballardie, A. et al., "Multicast-Specific Security Threats and Counter-Measures", "Symposium on network and Distributed System Security" , February 1995. [16] Smith, A. et al., "Securing the Border Gateway Routing Protocol", Proc. Global Internet'96 , November 1996. [17] Kent, S. et al., "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in = Communications , April 2000. Authors' Addresses Abbie Barbir (Editor) Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: EMail: abbieb@nortelnetworks.com Sandy Murphy Network Associates, Inc 3060 Washington Rd. Glenwood, MD 21738 USA Phone: 443-259-2303 EMail: sandy@tislabs.com Barbir, et al. Expires February 24, 2004 [Page = 22] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Yi Yang Cisco Systems 7025 Kit Creek Road RTP, NC 27709 Canada Phone: EMail: yiya@cisco.com Barbir, et al. Expires February 24, 2004 [Page = 23] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Appendix A. Acknowledgements 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 Barbir, et al. Expires February 24, 2004 [Page = 24] =0C Internet-Draft Generic Threats to Routing Protocols August = 2003 Appendix B. Acronyms AODV - Ad-hoc On-demand Distance Vector routing protocol 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. eBGP - External BGP. BGP configuration in which sessions are established between routers in different ASs. iBGP - Internal BGP. BGP configuration in which sessions are established between routers in the same ASs. LSRP - Link-State Routing Protocol LSA - Link-State Announcement M-OSPF - Multicast Open Shortest Path First 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 February 24, 2004 [Page = 25] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 February 24, 2004 [Page = 26] =0C Internet-Draft Generic Threats to Routing Protocols August = 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 February 24, 2004 [Page = 27] =0C ------_=_NextPart_000_01C36BBC.66F4AA80 Content-Type: APPLICATION/OCTET-STREAM; NAME="draft-ietf-rpsec-routing-threats-02.htm" Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="draft-ietf-rpsec-routing-threats-02.htm" Content-Transfer-Encoding: QUOTED-PRINTABLE =0A= =0A= Generic Threats to Routing = Protocols=0A= =0A= =0A= =0A= =0A= =0A=
     TOC 
    =0A=
    =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
    Network Working GroupA. Barbir
    Internet-DraftNortel = Networks
    Expires: February 24, 2004S. Murphy
     Network = Associates, Inc
     Y. = Yang
     Cisco = Systems
     August 26, = 2003
    =0A=

    Generic Threats to = Routing Protocols
    =0A=

    draft-ietf-rpsec-routing-threats-02
    =0A= =0A=

    Status of this Memo

    =0A=

    =0A= This document is an Internet-Draft and is in full conformance with all = provisions of Section 10 of RFC2026.

    =0A=

    =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups.=0A= Note that other groups may also distribute working documents as=0A= Internet-Drafts.

    =0A=

    =0A= Internet-Drafts are draft documents valid for a maximum of six = months=0A= and may be updated, replaced, or obsoleted by other documents at any = time.=0A= It is inappropriate to use Internet-Drafts as reference material or to = cite=0A= them other than as "work in progress."

    =0A=

    =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/= ietf/1id-abstracts.txt.

    =0A=

    =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html= .

    =0A=

    =0A= This Internet-Draft will expire on February 24, 2004.

    =0A= =0A=

    Copyright Notice

    =0A=

    =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.

    =0A= =0A=

    Abstract

    =0A= =0A=

    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 affects 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.=0A=


    =0A=

    Table of Contents

    =0A=

    =0A= 1. =0A= Introduction
    =0A= 2. =0A= Routing Functions Overview
    =0A= 2.1 =0A= Routing Protocol Control and Data Planes
    =0A= 3. =0A= Generic Routing Protocol Threat Model
    =0A= 3.1 =0A= Threat Definitions
    =0A= 3.1.1 =0A= Threat Sources
    =0A= 3.1.2 =0A= Threat Consequences
    =0A= 4. =0A= Generally Identifiable Routing Threats
    =0A= 4.1 =0A= Deliberate Exposure
    =0A= 4.2 =0A= Sniffing
    =0A= 4.3 =0A= Traffic Analysis
    =0A= 4.4 =0A= Spoofing
    =0A= 4.5 =0A= Falsification
    =0A= 4.5.1 =0A= Falsifications by Originators
    =0A= 4.5.2 =0A= Falsifications by Forwarders
    =0A= 4.6 =0A= Interference
    =0A= 4.7 =0A= Overload
    =0A= 4.8 =0A= Byzantine Failures
    =0A= 5. =0A= Security Considerations
    =0A= § =0A= Normative References
    =0A= § =0A= Informative References
    =0A= § =0A= Authors' Addresses
    =0A= A. =0A= Acknowledgements
    =0A= B. =0A= Acronyms
    =0A= § =0A= Intellectual Property and Copyright Statements
    =0A=

    =0A=
    =0A= =0A=
    =0A=
     TOC 
    =0A=

    1. Introduction

    =0A= =0A=

    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 affects 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.=0A=

    =0A=

    This documents takes a general threats to routing functions. In this = work, the "owner" of an address prefix or an AS [17] number is an organization =0A= that has been granted the right to use that prefix or number. Each = Regional Internet Rggistry (RIR) acquires prefixes and AS numbers from = IANA, and further distributes (delegates use of) them to =0A= organizations such as ISPs and multi-homed subscribers. For address = prefixes, delegation typically involves assigning a subset of a prefix = to an organization, which may, in turn, further delegate =0A= subsets to other organizations, e.g., subscribers or downstream = providers.=0A= =0A= =0A=

    =0A=

    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 [6], IS-IS [10] , RIP [11] and BGP [17].=0A= =0A=

    =0A=

    The security requirements derived from this analysis are intended to = be used as guidance to those who are designing and modifying routing = protocols. They may also be used by routing protocol implementers to = increase the robustness of their implementations.=0A= =0A=

    =0A=

    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.=0A=

    =0A=
    =0A=
     TOC 
    =0A=

    2. Routing Functions = Overview

    =0A= =0A=

    This section provides an overview of common functions that are = shared among various routing protocols. In general, routing protocols = share the following common functions:=0A=

    =0A=
      =0A=
    • Transport Subsystem: The routing protocol transmits messages to=0A= its neighbors using some underlying protocol. For example, OSPF = uses IP, while AODV uses a broadcast link. Other protocols may run over = TCP. =0A= =0A= =0A=
      • =0A=
    • Neighbor State Maintenance: neighboring relationship formation is = the first step for topology determination. For this reason, routing = protocols may need to maintain the state of their neighbors. Each = routing protocol may use a different mechanism for determining its = neighbors in the routing topology. Some protocols have distinct = exchange through which they establish neighboring relationships, e.g., = Hello exchanges in OSPF. =0A= =0A=
      • =0A=
    • Database Maintenance: Routing protocols exchange network = topology=0A= and reach-ability information. The routers collect this=0A= information in routing databases with varying detail. The=0A= maintenance of these databases is a significant portion of the = function of a routing protocol. =0A= =0A= =0A=
      • =0A=
    =0A= =0A=

    2.1 Routing Protocol Control and Data = Planes

    =0A= =0A=

    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. =0A= =0A=

    =0A=

    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. =0A=

    =0A=

    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.=0A= =0A=

    =0A=
    =0A=
     TOC 
    =0A=

    3. Generic Routing Protocol = Threat Model

    =0A= =0A=

    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.=0A= =0A=

    =0A=

    Routing protocols are subject to treats 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 neighbor (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. =0A= =0A=

    =0A=

    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, if the DR = election is disrupted in an OSPF network, an unauthorized router could = be chosen as designated router. This might allow unauthorized access = to routing information. In BGP, if a router receives a CEASE message, = it can break the neighboring relationship and cause any related = topology information to be flushed.=0A= =0A=

    =0A=

    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 LSA's with the wrong Advertising Router, the receivers = will compute a 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=0A= =0A=

    =0A=

    3.1 Threat Definitions

    =0A= =0A=

    Threat is defined in [1] as a potential for = violation of security, which exists when there is a circumstance, = capability, action, or event that could breach security and cause harm. = A threat presents itself when an attacker has the ability to take = advantage of an existing security weakness. Threats can be categorized = based on various rules, such as threat sources, threat actions, threat = consequences, threat consequence zones, and threat consequence = periods.=0A= =0A=

    =0A=

    3.1.1 Threat Sources

    =0A= =0A=

    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. =0A= =0A=

    =0A=

    Threats can originate form outsiders or insiders. An insider is an = authorized participant in the routing protocol. An outsider is any = other host or network. A host is determined to be an outsider or an = insider from the point of view of a particular router. Even an = authorized protocol speaker can be an outsider to a particular router = if the router does not consider the speaker to be a legitimate peer (as = could conceivably happen on a multi-access link).=0A= =0A=

    =0A=

    In general, threats can be classified into the following categories = based on their sources [2]:=0A=

    =0A=
      =0A=
    • Threats that result from subverted links: A link become subverted = when an attacker gain access (or control) to 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.=0A=
      • =0A=
    • Threats that result from subverted devices (e.g. routers): A = subverted device (router) is an authorized router that may have routing = software bugs, hardware defects, incorrect or unintended = configurations. Devices can be susceptible to such threats due to the = lack mechanisms to verify system integrity (For example, the router is = working correctly as been intended by the authoritative network = administrator), or such mechanisms can be circumvented. Such threats = may enable attackers to inappropriately claim authority for some = network resources, or violate routing protocols, such as advertising = invalid routing information.=0A=
      • =0A=
    =0A= =0A=

    For example, an OSPF router will form a peering relationship with = any attached device which appears to be running OSPF, unless MD5 = authentication (or some other means) is used to prevent the neighboring = relationship from forming. Furthermore, MANET protocols frequently = speak over the broadcast link. =0A= =0A=

    =0A=

    3.1.2 Threat Consequences

    =0A= =0A=

    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=0A= the operation of the network as a whole.=0A= =0A= =0A=

    =0A=

    There are four types of threat consequences: disclosure, deception, = disruption,=0A= and usurpation [1].=0A= =0A=

    =0A=
      =0A=
    • Disclosure: Disclosure of routing information happens when a=0A= router successfully accesses the information without being=0A= authorized. Subverted links can cause disclosure, if routing=0A= exchanges lack confidentiality. Subverted devices (routers),=0A= can cause disclosure, as long as they are successfully=0A= involved in the routing exchanges. Although inappropriate=0A= disclosure of routing information can pose a security threat or = be=0A= part of a later, larger, or higher layer attack, = confidentiality=0A= is not generally a design goal of routing protocols.=0A= =0A=
      • =0A=
    • Deception: This consequence happens when a legitimate router=0A= receives a false routing message and believes it to be true. = Subverted links and/or subverted device (routers)can cause this = consequence if the receiving router lacks ability to check routing = message integrity, routing message origin, authentication or peer = router authentication.=0A= =0A=
      • =0A=
    • Disruption: This consequence occurs when a legitimate router's=0A= operation is being interrupted or prevented. Subvert links can=0A= cause this by replaying, delaying, or dropping routing = messages,=0A= or breaking routing sessions between legitimate routers.=0A= Subverted devices (router) can cause this consequence by=0A= sending false routing messages, interfering normal routing=0A= exchanges, or flooding unnecessary messages. (DoS is a common=0A= threat action causing disruption.)=0A=
      • =0A=
    • Usurpation: This consequence happens when an attacker gains=0A= control over a legitimate router's services/functions. = Subverted=0A= links can cause this by delaying or dropping routing exchanges, = or=0A= replaying out-dated routing information. Subverted routers can = cause this=0A= consequence by sending false routing information, interfering=0A= routing exchanges, or system integrity.=0A=
      • =0A=
    =0A= =0A=

    Note: an attacker does not have to directly control a router to=0A= control its services. For example, in Figure = 1, Network 1 is=0A= dual-homed through Router A and Router B, and Router A is = preferred.=0A= However, Router B is compromised and advertises a lower metric.=0A= Consequently, devices on the Internet choose the path through = Router=0A= B to reach Network 1. In this way, Router B steals the data = traffic=0A= and Router A surrenders its control of the services to Router B. = This=0A= depicted in =0A= Figure 1.=0A= =0A= =0A= =0A=


    =0A= =0A= 
    =0A=
=0A=
   +-------------+   +-------+=0A=
   |  Internet   |---| Rtr A |=0A=
   +------+------+   +---+---+=0A=
          |              |=0A=
          |              |=0A=
          |              |=0A=
          |            *-+-*=0A=
   +-------+           /     \=0A=
   | Rtr B |----------*  N 1  *=0A=
   +-------+           \     /=0A=
                        *---*=0A=
=0A=
=0A=
    =0A= =0A=

    =0A=

     Network 
    =0A= =0A=

    Several threat consequences might be caused by a single threat=0A= action. In Figure 1, there exist at least two = consequences:=0A= routers using Router B to reach Network 1 are deceived, while = Router=0A= A is usurped. =0A=

    =0A=

    Within the context of the threat consequences described above, = damage=0A= that might result from attacks against the network as a whole may=0A= include:=0A=

    =0A=
      =0A=
    • Network congestion: more data traffic is forwarded through some=0A= portion of the network than would otherwise need to carry the=0A= traffic,=0A= =0A=
      • =0A=
    • Blackhole: large amounts of traffic are directed to be forwarded=0A= through one router that cannot handle the increased level of=0A= traffic and drops many/most/all packets,=0A= =0A=
      • =0A=
    • Looping: data traffic is forwarded along a route that loops, so=0A= that the data is never delivered (resulting in network=0A= congestion),=0A= =0A=
      • =0A=
    • Partition: some portion of the network believes that it is=0A= partitioned from the rest of the network when it is not,=0A= =0A=
      • =0A=
    • Churn: the forwarding in the network changes (unnecessarily) at = a=0A= rapid pace, resulting in large variations in the data delivery=0A= patterns (and adversely affecting congestion control = techniques),=0A= =0A=
      • =0A=
    • Instability: the protocol becomes unstable so that convergence = on=0A= a global forwarding state is not achieved, and=0A= =0A=
      • =0A=
    • Overload: the protocol messages themselves become a significant=0A= portion of the traffic the network carries.=0A= =0A=
      • =0A=
    =0A= =0A=

    The damage that might result from attacks against a particular = host=0A= or network address may include:

    =0A=
      =0A=
    • Starvation: data traffic destined for the network or host is=0A= forwarded to a part of the network that cannot deliver it, =0A= =0A=
      • =0A=
    • Eavesdrop: data traffic is forwarded through some router or=0A= network that would otherwise not see the traffic, affording an=0A= opportunity to see the data or at least the data delivery = pattern,=0A= =0A=
      • =0A=
    • Cut: some portion of the network believes that it has no route = to=0A= the host or network when it is in fact connected,=0A= =0A=
      • =0A=
    • Delay: data traffic destined for the network or host is = forwarded=0A= along a route that is in some way inferior to the route it = would=0A= otherwise take,=0A= =0A=
      • =0A=
    • Looping: data traffic for the network or host is forwarded along = a=0A= route that loops, so that the data is never delivered=0A=
      • =0A=
    =0A= =0A=

    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).=0A= =0A=

    =0A=

    3.1.2.1 Threat Consequence Zone

    =0A= =0A=

    A threat consequence zone covers the area within which the = network=0A= operations have been affected by threat actions. Possible=0A= threat consequence zones can be classified as: a single link or=0A= router, multiple routers (within a single routing domain), a = single=0A= routing domain, multiple routing domains, or the global Internet. = The=0A= threat consequence zone varies based on the threat action and = origin.=0A= Similar threat actions that happened at different locations may = cause=0A= totally different threat consequence zones. For example, when a=0A= compromised link breaks the routing session between a = distribution=0A= router and a stub router, only reach ability from and to the = network=0A= devices attached on the stub router will be impaired. In other = words,=0A= the threat consequence zone is a single router. Nonetheless, if = the=0A= compromised router is located between a customer edge router and = its=0A= corresponding provider edge router, such an action might cause = the=0A= whole customer site to lose its connection. In this case, the = threat=0A= consequence zone might be a single routing domain.=0A= =0A=

    =0A=

    3.1.2.2 Threat Consequence Periods

    =0A= =0A=

    Threat consequence period is defined as a portion of time during=0A= which the network operations have been impacted by the threat=0A= consequences. The threat consequence period is influenced by, but = not=0A= totally dependent on the duration of the threat action. In some=0A= cases, the network operations will get back to normal as soon as = the=0A= threat action has been stopped. In other cases, however, threat=0A= consequences may appear longer than threat action. For example, = in=0A= the original ARPANET link-state algorithm, some errors in a = router=0A= might introduce three instances of an LSA, and all of them would = be=0A= flooded throughout the network forever, until the entire network = was=0A= power cycled [3]. =0A= =0A=

    =0A=
    =0A=
     TOC 
    =0A=

    4. Generally Identifiable = Routing Threats

    =0A= =0A=

    This section addresses generally identifiable and recognized threat = action against routing protocols. The threats are not necessarily = specific to individual protocols but may be present in one or more of = the common routing protocols in use today.=0A= =0A=

    =0A=

    4.1 Deliberate Exposure

    =0A= =0A=

    Deliberate Exposure occurs when an attacker takes control of a = router and intentionally releases routing information directly to other = routers. In some cases, the receiving 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. = =0A=

    =0A=

    The consequence of deliberate exposure is the disclosure of = routing=0A= information.=0A= =0A=

    =0A=

    The threat consequence zone of deliberate exposure depends on the=0A= routing information that the attackers have exposed. The more=0A= knowledge they have exposed, the bigger the threat consequence = zone.=0A= =0A=

    =0A=

    The threat consequence period of deliberate exposure might be = longer=0A= than the duration of the action itself. The routing information=0A= exposed will not be out-dated until there is a topology change of = the=0A= exposed network.=0A= =0A=

    =0A=

    4.2 Sniffing

    =0A= =0A=

    Sniffing is an action whereby attackers monitor and/or record the=0A= routing exchanges between authorized routers. Attackers can use = subverted links to=0A= sniff for routing information. =0A=

    =0A=

    The consequence of sniffing is disclosure of routing information. = =0A= =0A=

    =0A=

    The threat consequence zone of sniffing depends on the attacker's = location, the routing protocol type, and the routing=0A= information that has been recorded. For example, if the subverted = link=0A= is in an OSPF totally stubby area, the threat consequence=0A= zone should be limited to the whole area. An attacker that is sniffing = a subverted link in an EBGP session =0A= can gain knowledge of multiple routing domains.=0A= =0A=

    =0A=

    The threat consequence period might be longer than the duration = of=0A= the action. If an attacker stops sniffing a subverted link their = acquired knowledge=0A= will not be out-dated until there is a topology change of the = affected network.=0A=

    =0A=

    4.3 Traffic Analysis

    =0A= =0A=

    Traffic analysis is 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 in the clear over a communication link. This threat is not = peculiar to routing protocols and is included here for completeness.=0A=

    =0A=

    The consequence of data traffic analysis is the disclosure of = routing=0A= information. For example, the source and destination IP address = of=0A= the data traffic, the type, magnitude, and volume of traffic is=0A= disclosed.=0A= =0A=

    =0A=

    The threat consequence zone of the traffic analysis depends on = the=0A= attacker's location and what data traffic has passed=0A= through. A subverted link at the network core should be able to=0A= disclose more information than its counterpart at the edge.=0A= =0A=

    =0A=

    The threat consequence period might be longer than the duration = of=0A= the traffic analysis. After the attacker stops traffic analysis, = its=0A= knowledge will not be out-dated until there is a topology change = of=0A= the disclosed network.=0A= =0A=

    =0A=

    4.4 Spoofing

    =0A= =0A=

    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 to spoof the identity of a router, the = subverted router can act as masquerading router. In other situation, = the spoofed router can be used to send out unrealistic routing = information that might cause disruption of network services. =0A=

    =0A=

    =0A= There are a few cases where spoofing can be an attack. For example, if = a router establishes a neighbor/peering relationship, spoofing the = identity of a legitimate router and by that action was able to prevent = the legitimate router from establishing a relationship; that would be = an attack, denying service to the good router. As a second example, if = a router is doing auditing, then the ability to spoof an identity of a = router would be an attack, since the audit data would be false.=0A= =0A=

    =0A=

    The consequences of spoofing are:=0A=

    =0A=
      =0A=
    • The disclosure of routing information: The spoofed router will be = able to gain access to the routing information. =0A=
      • =0A=
    • The deception of peer relationship: The authorized routers, which = exchange routing messages with the spoofed router, do not realize they = are neighboring with a router that is faking another router's identity. = =0A=
      • =0A=
    =0A= =0A=

    The threat consequence zone includes:=0A=

    =0A=
    =0A=
  • The consequence zone of the disclosed routing information depends = on what routing information has been exchanged between the spoofed = router and its neighbors.=0A=
    • =0A=
    =0A= =0A=

    The threat consequence zone covers:=0A=

    =0A=
      =0A=
    • The consequence zone of the fake peer relationship will be limited = to those routers mistrusting the attacker's identity.=0A=
      • =0A=
    • 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.=0A=
      • =0A=
    =0A= =0A=

    4.5 Falsification

    =0A= =0A=

    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. False routing information describes the = network in an unrealistic view, whether or not intended by the = authoritative network administrator.=0A=

    =0A=

    To falsify the routing information, an attacker has to be either = the=0A= originator or a forwarder of the routing information. It cannot be = a=0A= receiver-only.=0A= =0A=

    =0A=

    4.5.1 Falsifications by Originators

    =0A= =0A=

    An originator of routing information can launch the falsifications = that are described in the next sections.=0A=

    =0A=

    4.5.1.1 Overclaiming

    =0A= =0A=

    Over-claiming 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.=0A= =0A=


    =0A= =0A= 
    =0A=
=0A=
           +-------------+   +-------+   +-------+=0A=
           | Internet    |---| Rtr B |---| Rtr A |=0A=
           +------+------+   +-------+   +---+---+=0A=
                  |                          .=0A=
                  |                          |=0A=
                  |                          .=0A=
                  |                        *-+-*=0A=
              +-------+                   /     \=0A=
              | Rtr C |------------------*  N 1  *=0A=
              +-------+                   \     /=0A=
                                           *---*=0A=
=0A=
    =0A= =0A=

    =0A=

     Overclaiming-1 
    =0A=
    =0A= =0A= 
    =0A=
=0A=
     +-------------+   +-------+   +-------+=0A=
     |  Internet   |---| Rtr B |---| Rtr A |=0A=
     +------+------+   +-------+   +-------+=0A=
            |=0A=
            |=0A=
            |=0A=
            |                        *---*=0A=
        +-------+                   /     \ =0A=
        | Rtr C |------------------*  N 1  *=0A=
        +-------+                   \     /=0A=
                                     *---*=0A=
=0A=
    =0A= =0A=

    =0A=

     Overclaiming-2 
    =0A= =0A=

    The above figures provide examples of overclaiming. Router A, the = attacker, is connected with 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.=0A= =0A= =0A=

    =0A=

    Compromised routers, unauthorized routers, and masquerading routers = can overclaim network resources. The consequence of overclaiming = includes:=0A=

    =0A=
      =0A=
    • Usurpation of the overclaimed network resources. In Figure 2 and=0A= Figure 3, it will cause a usurpation of Network 1 = when Router B or other routers on the Internet (not shown in the = figures) believe that Router A provides the best path to reach the = Network 1. They, the routers, thereby forward the data traffic, = destined to Network 1, to Router A. The best result is the data traffic = uses an unauthorized path Figure 2, and the worst = case is the data never reach the destination Network 1 Figure 3. The ultimate consequence is Router A = gaining control over Network 1's services, by controlling the data = traffic.=0A= =0A=
      • =0A=
    • 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.)=0A=
      • =0A=
    • 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.=0A=
      • =0A=
    • Disruption of data planes on some routers. This might happen on = routers that are on the path, which is used by other routers to reach = 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. =0A=
      • =0A=
    =0A= =0A=

    The threat consequence zone varies based on the consequence:=0A=

    =0A=
      =0A=
    • 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).=0A=
      • =0A=
    • Where deception is concerned, the consequence zone covers the = routers that do not believe the attacker's advertisement and use the = attacker to reach the claimed subnets (Router B and other deceived = routers on the Internet in Figure 2 and Figure 3).=0A=
      • =0A=
    • 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).=0A=
      • =0A=
    =0A= =0A=

    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.=0A=

    =0A=

    4.5.1.2 Misclaiming

    =0A= =0A=

    A Misclaiming threat is defined as an attacker action advertising = its=0A= authorized control of some network resources in a way that is not=0A= intended by the authoritative network administrator. An attacker = can=0A= eulogize or disparage when advertising these network resources.=0A= Subverted routers, unauthorized routers, and masquerading routers=0A= can misclaim network resources.=0A= =0A=

    =0A=

    The threat consequences of Misclaiming are similar to the=0A= consequences of overclaimin. Eulogizing the network resources might = cause the same consequences made by=0A= overclaiming.=0A= =0A= =0A=

    =0A=

    The consequence zone and period are also similar to those of = overclaiming.=0A= =0A=

    =0A=

    4.5.2 Falsifications by Forwarders

    =0A= =0A=

    When a legitimate router forwards routing information, it must or=0A= must not modify the routing information, depending on the routing=0A= information and the routing protocol type. For example, in RIP, = the=0A= forwarder must modify the routing information by increasing the = hop=0A= count by 1. On the other hand, the forwarder must not modify the = type=0A= 1 LSA in OSPF. In general, forwarders in distance vector routing=0A= protocols are authorized to and must modify the routing = information,=0A= while most forwarders in link state routing protocols are not=0A= authorized to and must not modify most routing information.=0A= =0A=

    =0A=

    As a forwarder authorized to modify routing message, an attacker = does=0A= not forward necessary routing information to other authorized=0A= routers. Unauthorized aggregation (summarization) is special type = of=0A= understatements.=0A= =0A=

    =0A=

    =0A=

    =0A=

    4.5.2.1 Misstatement

    =0A= =0A=

    This is defined as an action whereby the attacker describes route = attributes in a wrong way. For example, in RIP, the attacker increases = the path cost by two hops instead of one. Another example is, in BGP, = the attacker deletes some AS numbers from the AS PATH. =0A=

    =0A=

    When forwarding routing information that should not be modified, an = attacker can launch the following falsifications:=0A=

    =0A=
      =0A=
    • Deletion: Attacker deletes valid data in the routing message.=0A=
      • =0A=
    • Insertion: Attacker inserts false data in the routing message.=0A=
      • =0A=
    • Substitution: Attacker replaces valid data in the routing message = with false data.=0A=
      • =0A=
    • Replaying: Attacker replays out-dated data in the routing = message.=0A=
      • =0A=
    =0A= =0A=

    All types of attackers (Compromised links, compromised routers, = unauthorized routers, and masquerading routers) can falsify the routing = information when they forward the routing messages.=0A=

    =0A=

    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 area and period are also similar.=0A=

    =0A=

    =0A=

    =0A=

    4.6 Interference

    =0A= =0A=

    Interference is a threat action where an attackers 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, and breaking synchronization.=0A=

    =0A=

    Subverted, unauthorized and masquerading routers can slowdown their = routing exchanges or create flapping routing sessions of legitimate = neighboring routers. =0A=

    =0A=

    The consequence of interference is the disruption of routing = operations. =0A=

    =0A=

    The consequence zone of interference varies based on the source of = the threats: =0A=

    =0A=
      =0A=
    • 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. =0A=
      • =0A=
    • 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.=0A=
      • =0A=
    • 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.=0A=
      • =0A=
    =0A= =0A=

    =0A=

    =0A=

    =0A=

    =0A=

    4.7 Overload

    =0A= =0A=

    Overload is defined as a threat action whereby attackers place = excess=0A= burden on legitimate routers. Attackers can overload the data plane = or=0A= control plane. Because data plane is involved in routing = exchanges,=0A= overload of data plane will also influence the routing = operations.=0A= =0A=

    =0A=

    This section combines overload of the control plane and the data = plane=0A= (i.e., the routing protocol messages and the data traffic, not the = control and=0A= data plane of the routing protocol itself as discussed in section=0A= 2.1). The routing protocol design might have a chance to limit control = plane=0A= traffic. However, the routing protocol cannot limit the data traffic. = Thus, an attacker can effect the behavior of the entire routing = system.=0A= Examples include the ability of an attacker to break the transport = protocol connection (e.g., TCP RST). =0A= =0A= =0A=

    =0A=

    4.8 Byzantine Failures

    =0A= =0A=

    =0A= =0A= Within this work, Byzantine failure is an event resulting from a=0A= legitimate router or several legitimate routers running as = subverted=0A= devices. Whether the subvertion results from an accidental behavior = or=0A= from a malign attack may be considered for providing solutions in = some=0A= cases (currently, the accidental origin of the threat is much more=0A= probable than the malign origin), yet in both cases it is assumed = that=0A= the misbehaving routers are still considered as authenticated = devices=0A= (according to the situation; therefore, misbehavior of insider(s) in = a=0A= protocol is often regarded as a Byzantine failure). This is opposed = to=0A= the fail-stop model, in which a system halt on the occurrence of a=0A= failure. =0A= =0A= =0A=

    =0A=

    =0A= =0A= The Byzantine failure event may involve many combinations of = threat=0A= actions, threat consequences, threat zone and threat periods = possibly=0A= resulting from subverted devices.=0A= =0A= =0A=

    =0A=

    =0A= =0A= The Byzantine failure is specific in the sense that it is the = distributed=0A= nature of the threat that is under consideration. Because = Byzantine=0A= devices are, at least at the beginning of the problem, undetectable, = only=0A= source and destination devices are to be trusted (though they may = also be=0A= subverted). Because this threat results from a combination of = incorrect=0A= behaviors, it may be difficult to tell apart which devices are = subverted,=0A= or even to state that the system is under the occurrence of such a=0A= failure.=0A= =0A= =0A=

    =0A=

    =0A= =0A= [Byzantine failure is often a threat to a distributed algorithm=0A= termination, to the agreement of non-subverted nodes, and to the = validity=0A= of the conclusion agreed upon; here, ] Destination reachability = and=0A= integrity of the information transmitted are the main system = features=0A= jeopardized by the failure, according to the source and destination = point=0A= of view. Route attributes (cost, hops, confidentiality...) may also = be=0A= affected and result in a degradation of the service provided by = the=0A= forwarding function.=0A= =0A= =0A=

    =0A=
    =0A=
     TOC 
    =0A=

    5. Security = Considerations

    =0A= =0A=

    =0A= This entire informational draft RFC is security related. Specifically = it 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 as we know them today and lays the foundation = for a future draft which fully discusses security requirements for = routing protocols. =0A=

    =0A=
    =0A=
     TOC 
    =0A=

    Normative References

    =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
    [1]Shirey, R, "Internet Security = Glossary", RFC 2828 , May 2000.
    [2]Smith, R et al., "Securing Distance-Vector = Routing Protocols", Symposium on Network and Distributed System = Security=0A= , 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]Murphy, S et al., "OSPF with=0A= Digital Signatures", RFC 2154 , June 1997.
    [6]Moy, J, "OSPF Version 2", = RFC 2328 , April 1998.
    [7]Mittal, V et al., "Sensor-Based Intrusion = Detection for Intra-Domain istance-Vector Routing", Proceedings of the = ACM Conference =0A= on Computer and Communication Security (CCS'02), Washington, DC=0A= , November 2002.
    [8]Cheung, S. et. al., "Protecting Routing = Infrastructures from Denial of Service using co-operative intrusion = detection", In Proceedings of the 1995 IEEE Symposium on Security and = Privacy=0A= , May 1995.
    [9]Bradley, K. et. al., "A distributed Network = Monitoring approach", Published , November 2001.
    [10]Shen, N. et. al., "Dynamic Hostname = Exchange Mechanism for IS-IS", RFC 2763 , February = 2000.
    [11]Malkin, G., "RIP Version 2 Protocol = Analysis", RFC 1721 , November = 1994.
    =0A= =0A=
    =0A=
     TOC 
    =0A=

    Informative References

    =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
    [12]Vetter, W. et al., "Experimental Study of = Insider Attacks in a Link State Routing Protocol", 5th IEEE = International Conference on Network Protocols, Atlanta, GA=0A= , 1997.
    [13]"Internet Group = Management Protocol", RFC 3376 , October 2002.
    [14]Estrin, D. et al., "Independent = Multicast-Sparse Mode (PIM-SM): Protocol pecification", RFC 2362 , = June 1998 .
    [15]Ballardie, A. et al., "Multicast-Specific = Security Threats and Counter-Measures", "Symposium on network and = Distributed System Security"=0A= , February 1995.
    [16]Smith, A. et al., "Securing the Border = Gateway Routing Protocol", Proc. Global Internet'96 , November = 1996.
    [17]Kent, S. et al., "Secure Border Gateway = Protocol (Secure-BGP)", IEEE Journal on Selected Areas in = Communications , April 2000.
    =0A= =0A=
    =0A=
     TOC 
    =0A=

    Authors' Addresses

    =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
     Abbie Barbir (Editor)
     Nortel Networks
     3500 Carling Avenue
     Nepean, Ontario K2H 8E9
     Canada
    Phone: 
    EMail: abbieb@nortelnetworks.com<= /td>
      
     Sandy Murphy
     Network Associates, Inc
     3060 Washington Rd.
     Glenwood, MD 21738
     USA
    Phone: 443-259-2303
    EMail: sandy@tislabs.com
      
     Yi Yang
     Cisco Systems
     7025 Kit Creek Road
     RTP, NC 27709
     Canada
    Phone: 
    EMail: yiya@cisco.com
    =0A= =0A=
    =0A=
     TOC 
    =0A=

    Appendix A. Acknowledgements

    = =0A= =0A=

    This draft would not have been possible save for the excellent = efforts=0A= and team work characteristics of those listed here.=0A=

    =0A=
      =0A=
    • Dennis Beard- Nortel Networks=0A=
      • =0A=
    • Ayman Musharbash - Nortel Networks=0A=
      • =0A=
    • Jean-Jacques Puig, int-evry, France =0A=
      • =0A=
    • Paul Knight - Nortel Networks=0A=
      • =0A=
    • Elwyn Davies - Nortel Networks=0A=
      • =0A=
    • Ameya Dilip Pandit - Graduate student - University of Missouri=0A=
      • =0A=
    • Senthilkumar Ayyasamy - Graduate student - University of = Missouri=0A=
      • =0A=
    =0A= =0A=

    =0A=

    =0A=
    =0A=
     TOC 
    =0A=

    Appendix B. Acronyms

    =0A= =0A=

    AODV - Ad-hoc On-demand Distance Vector routing protocol=0A= =0A=

    =0A=

    AS - Autonomous system. Set of routers under a single technical=0A= administration. Each AS normally uses a single interior gateway=0A= protocol (IGP) and metrics to propagate routing information=0A= within the set of routers. Also called routing domain.=0A= =0A=

    =0A=

    AS-Path - In BGP, the route to a destination. The path consists=0A= of the AS numbers of all routers a packet must go through to reach = a=0A= destination.=0A= =0A=

    =0A=

    BGP - Border Gateway Protocol. Exterior gateway protocol used to=0A= exchange routing information among routers in different autonomous=0A= systems.=0A= =0A= =0A=

    =0A=

    eBGP - External BGP. BGP configuration in which sessions are=0A= established between routers in different ASs.=0A= =0A=

    =0A=

    iBGP - Internal BGP. BGP configuration in which sessions are=0A= established between routers in the same ASs.=0A= =0A= =0A=

    =0A=

    LSRP - Link-State Routing Protocol=0A= =0A= =0A=

    =0A=

    LSA - Link-State Announcement=0A= =0A=

    =0A=

    M-OSPF - Multicast Open Shortest Path First=0A= =0A= =0A=

    =0A=

    NLRI - Network layer reachability information. Information that=0A= is carried in BGP packets and is used by MBGP.=0A= =0A=

    =0A=

    OSPF - Open Shortest Path First. A link-state IGP that makes=0A= routing decisions based on the shortest-path-first (SPF) algorithm =0A= (also referred to as the Dijkstra algorithm).=0A= =0A= =0A= =0A=


    =0A=
     TOC 
    =0A=

    Intellectual Property Statement

    =0A=

    =0A= The IETF takes no position regarding the validity or scope of=0A= any intellectual property or other rights that might be claimed=0A= to pertain to the implementation or use of the technology=0A= described in this document or the extent to which any license=0A= under such rights might or might not be available; neither does=0A= it represent that it has made any effort to identify any such=0A= rights. Information on the IETF's procedures with respect to=0A= rights in standards-track and standards-related documentation=0A= can be found in BCP-11. Copies of claims of rights made=0A= available for publication and any assurances of licenses to=0A= be made available, or the result of an attempt made=0A= to obtain a general license or permission for the use of such=0A= proprietary rights by implementors or users of this=0A= specification can be obtained from the IETF Secretariat.

    =0A=

    =0A= The IETF invites any interested party to bring to its=0A= attention any copyrights, patents or patent applications, or=0A= other proprietary rights which may cover technology that may be=0A= required to practice this standard. Please address the=0A= information to the IETF Executive Director.

    =0A=

    Full Copyright Statement

    =0A=

    =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.

    =0A=

    =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it=0A= or assist in its implementation may be prepared, copied, published = and=0A= distributed, in whole or in part, without restriction of any kind,=0A= provided that the above copyright notice and this paragraph are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by removing=0A= the copyright notice or references to the Internet Society or other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other than=0A= English.

    =0A=

    =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assignees.

    =0A=

    =0A= This document and the information contained herein is provided on an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

    =0A=

    Acknowledgment

    =0A=

    =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.

    =0A= =0A= =0A= ------_=_NextPart_000_01C36BBC.66F4AA80-- ------_=_NextPart_000_01C36BBC.66F4AA80-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Aug 28 22:52:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15225 for ; Thu, 28 Aug 2003 22:52:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sWra-0004Yk-1t for rpsec-archive@odin.ietf.org; Thu, 28 Aug 2003 20:11:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T0BbuT017514 for rpsec-archive@odin.ietf.org; Thu, 28 Aug 2003 20:11:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sVz2-00028M-Eq for rpsec-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 19:15:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28780 for ; Thu, 28 Aug 2003 19:15:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sVz0-00019q-00 for rpsec-web-archive@ietf.org; Thu, 28 Aug 2003 19:15:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sVz0-00019m-00 for rpsec-web-archive@ietf.org; Thu, 28 Aug 2003 19:15:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sT6k-0002Y4-1l; Thu, 28 Aug 2003 16:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSCo-0008JS-Jj for rpsec@optimus.ietf.org; Thu, 28 Aug 2003 15:13:14 -0400 Received: from mesa.bbnplanet.com (mesa.bbnplanet.com [171.78.172.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10576 for ; Thu, 28 Aug 2003 15:13:09 -0400 (EDT) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h7SJBvm21946; Thu, 28 Aug 2003 15:11:57 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Thu, 28 Aug 2003 15:11:57 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Sandy Murphy cc: rpsec@ietf.org Subject: Re: [RPSEC] WG Last Call on Threats Doc In-Reply-To: <200308281628.h7SGS4u4007666@filbert.tislabs.com> Message-ID: References: <200308281628.h7SGS4u4007666@filbert.tislabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Thu, 28 Aug 2003, Sandy Murphy wrote: > The latest version on the ietf web site is the -01, dated Apr. > > Is there a newer version incorporating the recent comments? > > --Sandy Yes, it was attached to my message but has also been submitted to be posted on the IETF website. Should be there soon. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Aug 29 19:35:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18426 for ; Fri, 29 Aug 2003 19:35:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ssDi-0008Qh-JK for rpsec-archive@odin.ietf.org; Fri, 29 Aug 2003 18:59:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7TMxr37032383 for rpsec-archive@odin.ietf.org; Fri, 29 Aug 2003 18:59:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19spdx-0001vc-J4 for rpsec-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 16:14:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01202 for ; Fri, 29 Aug 2003 16:14:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19spdv-0005vS-00 for rpsec-web-archive@ietf.org; Fri, 29 Aug 2003 16:14:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19spdv-0005vP-00 for rpsec-web-archive@ietf.org; Fri, 29 Aug 2003 16:14:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19snw0-0005TU-Hq; Fri, 29 Aug 2003 14:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19slFi-0006Pb-OF for rpsec@optimus.ietf.org; Fri, 29 Aug 2003 11:33:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03622; Fri, 29 Aug 2003 11:33:23 -0400 (EDT) Message-Id: <200308291533.LAA03622@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: Fri, 29 Aug 2003 11:33:23 -0400 Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-routing-threats-02.txt Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. 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-02.txt Pages : 27 Date : 2003-8-29 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-02.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-02.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-02.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-8-29113829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-routing-threats-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-routing-threats-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-29113829.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec