From mailnull@www1.ietf.org  Fri Nov  1 09:58:10 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14635
	for <rpsec-archive@odin.ietf.org>; Fri, 1 Nov 2002 09:58:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA1F06L17495
	for rpsec-archive@odin.ietf.org; Fri, 1 Nov 2002 10:00:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1F06v17492
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 1 Nov 2002 10:00:06 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14572
	for <rpsec-web-archive@ietf.org>; Fri, 1 Nov 2002 09:57:37 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1ExLv17204;
	Fri, 1 Nov 2002 09:59:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1EwCv16788
	for <rpsec@optimus.ietf.org>; Fri, 1 Nov 2002 09:58:12 -0500
Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14439
	for <rpsec@ietf.org>; Fri, 1 Nov 2002 09:55:44 -0500 (EST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA1EvD829975;
	Fri, 1 Nov 2002 09:57:13 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKCMWJ8>; Fri, 1 Nov 2002 09:57:14 -0500
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6042F92A0@zcard0ke.ca.nortel.com>
From: "Dennis Beard" <beardd@nortelnetworks.com>
To: riw@cisco.com, sandy@tislabs.com, ttauber@genuity.net, zinin@psg.com,
        Yi Yang <yiya@cisco.com>
Cc: rpsec@ietf.org
Date: Fri, 1 Nov 2002 09:57:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C281B6.F48B1CC6"
Subject: [RPSEC] RE: routing threats I sent you Tuesday
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=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_01C281B6.F48B1CC6
Content-Type: text/plain

Hello,

Sandy is probably correct in her assessment that the Beard/Yang draft is
missing certain topics (or did Sandy mean we added new thoughts?).  The main
goal of this paper was to keep the WG milestone delivery schedule moving.  I
was quite sure that once the draft made the list, people of routing
expertise would come forward.  It should be an easier exercise to build upon
what is now issued, perhaps before Atlanta.  The main point of our efforts
is to fulfill the purpose of the WG charter, namely, to deliver security
requirements for routing protocols. And this is where strong WG chairs can
further that goal.  After Atlanta, Sandy's and other's opinions regarding
threats will be offered, noted, and incorporated.  Once those thoughts are
incorporated with the Beard/Yang topics, the chairs will need to "freeze"
the threats draft so that a requirements draft can begin to emerge.  I would
suggest that a requirements draft be set for first delivery to the WG by the
March 2003 meeting.  Let's not get caught in the IPsec WG IKE trap of
perpetual churn without definitive closure.
Consult-write-debate-rewrite-issue-move on to the next task.

Regards,

Dennis Beard

-----Original Message-----
From: sandy@tislabs.com [mailto:sandy@tislabs.com] 
Sent: Friday, November 01, 2002 5:30 AM
To: Gregory@netscreen.com; Beard, Dennis [CAR:0S03:EXCH]; riw@cisco.com;
sandy@tislabs.com; ttauber@genuity.net; zinin@psg.com
Subject: Re: routing threats I sent you Tuesday


So I just saw Dennis' routing threat draft.  Wow!  From a brief look
through, this has a lot of points that weren't covered before.  So now I
need to compare what I sent you and his draft, to see if there would be any
contribution in sending what I wrote to the list.  Would be interesting if
there's a different viewpoint.

--Sandy

------_=_NextPart_001_01C281B6.F48B1CC6
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: routing threats I sent you Tuesday</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello,</FONT>
</P>

<P><FONT SIZE=3D2>Sandy is probably correct in her assessment that the =
Beard/Yang draft is missing certain topics (or did Sandy mean we added =
new thoughts?).&nbsp; The main goal of this paper was to keep the WG =
milestone delivery schedule moving.&nbsp; I was quite sure that once =
the draft made the list, people of routing expertise would come =
forward.&nbsp; It should be an easier exercise to build upon what is =
now issued, perhaps before Atlanta.&nbsp; The main point of our efforts =
is to fulfill the purpose of the WG charter, namely, to deliver =
security requirements for routing protocols. And this is where strong =
WG chairs can further that goal.&nbsp; After Atlanta, Sandy's and =
other's opinions regarding threats will be offered, noted, and =
incorporated.&nbsp; Once those thoughts are incorporated with the =
Beard/Yang topics, the chairs will need to &quot;freeze&quot; the =
threats draft so that a requirements draft can begin to emerge.&nbsp; I =
would suggest that a requirements draft be set for first delivery to =
the WG by the March 2003 meeting.&nbsp; Let's not get caught in the =
IPsec WG IKE trap of perpetual churn without definitive closure.&nbsp; =
Consult-write-debate-rewrite-issue-move on to the next task.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Dennis Beard</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: sandy@tislabs.com [<A =
HREF=3D"mailto:sandy@tislabs.com">mailto:sandy@tislabs.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Friday, November 01, 2002 5:30 AM</FONT>
<BR><FONT SIZE=3D2>To: Gregory@netscreen.com; Beard, Dennis =
[CAR:0S03:EXCH]; riw@cisco.com; sandy@tislabs.com; ttauber@genuity.net; =
zinin@psg.com</FONT></P>

<P><FONT SIZE=3D2>Subject: Re: routing threats I sent you =
Tuesday</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>So I just saw Dennis' routing threat draft.&nbsp; =
Wow!&nbsp; From a brief look through, this has a lot of points that =
weren't covered before.&nbsp; So now I need to compare what I sent you =
and his draft, to see if there would be any contribution in sending =
what I wrote to the list.&nbsp; Would be interesting if there's a =
different viewpoint.</FONT></P>

<P><FONT SIZE=3D2>--Sandy</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C281B6.F48B1CC6--
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov  1 10:00:36 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14842
	for <rpsec-archive@odin.ietf.org>; Fri, 1 Nov 2002 10:00:36 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA1F2W218124
	for rpsec-archive@odin.ietf.org; Fri, 1 Nov 2002 10:02:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1F2Wv18121
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 1 Nov 2002 10:02:32 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14764
	for <rpsec-web-archive@ietf.org>; Fri, 1 Nov 2002 10:00:04 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1F21v18087;
	Fri, 1 Nov 2002 10:02:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1F1mv18069
	for <rpsec@optimus.ietf.org>; Fri, 1 Nov 2002 10:01:48 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14705
	for <rpsec@ietf.org>; Fri, 1 Nov 2002 09:59:21 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id KAA18246; Fri, 1 Nov 2002 10:01:47 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma018228; Fri, 1 Nov 02 10:00:52 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gA1F0nN01962;
	Fri, 1 Nov 2002 10:00:49 -0500 (EST)
Date: Fri, 1 Nov 2002 10:00:49 -0500 (EST)
Message-Id: <200211011500.gA1F0nN01962@raven.gw.tislabs.com>
To: beardd@nortelnetworks.com, riw@cisco.com, sandy@tislabs.com,
        ttauber@genuity.net, yiya@cisco.com, zinin@psg.com
Cc: rpsec@ietf.org
Subject: [RPSEC] RE: routing threats I sent you Tuesday
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>Sandy is probably correct in her assessment that the Beard/Yang draft is
>missing certain topics (or did Sandy mean we added new thoughts?).

Sandy meant it looked like you added a new breakdown of thoughts.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Sat Nov  2 07:58:58 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04060
	for <rpsec-archive@odin.ietf.org>; Sat, 2 Nov 2002 07:58:58 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA2D0sq29194
	for rpsec-archive@odin.ietf.org; Sat, 2 Nov 2002 08:00:54 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA2D0sv29191
	for <rpsec-web-archive@optimus.ietf.org>; Sat, 2 Nov 2002 08:00:54 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04052
	for <rpsec-web-archive@ietf.org>; Sat, 2 Nov 2002 07:58:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA2D0Hv29169;
	Sat, 2 Nov 2002 08:00:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1Ni4v13547
	for <rpsec@optimus.ietf.org>; Fri, 1 Nov 2002 18:44:04 -0500
Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08797
	for <rpsec@ietf.org>; Fri, 1 Nov 2002 18:41:32 -0500 (EST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA1NhagM025142;
	Fri, 1 Nov 2002 15:43:36 -0800 (PST)
Received: from nisser.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA1NhcnZ019128;
	Fri, 1 Nov 2002 15:43:38 -0800 (PST)
Received: from 171.71.119.97 (dhcp-171-71-119-97.cisco.com [171.71.119.97]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA12348; Fri, 1 Nov 2002 15:43:31 -0800 (PST)
Date: Fri,  1 Nov 2002 15:43:24 -0800
From: Sean Convery <sean@cisco.com>
To: rpsec@ietf.org
cc: riw@cisco.com, ttauber@genuity.net
X-Priority: 3
Message-ID: <r01050400-1021-BB6E141AEDF311D6A4E30003939CDD90@[171.71.119.97]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="5652839-0-3245154213=:9004"
Content-Transfer-Encoding: 7bit
X-Mailer: Mailsmith 1.5.4 (Blindsider)
Subject: [RPSEC] draft-convery-bgpattack-00
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

--5652839-0-3245154213=:9004
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit

All,

Sorry we couldn't get this in by the deadline.  We're planning to agenda
bash in Atlanta.  Text is attached and is available at:

http://trinux.sourceforge.net/draft-convery-bgpattack-00.txt

HTML format is available here:

http://trinux.sourceforge.net/draft-convery-bgpattack-00.html

Abstract:

This I-D presents all known attack vectors into or using BGP.  The
data is presented in "Attack Tree" format as published by Schneier
[1] and detailed by the CERT in "Attack Modeling for Information
Security and Survivability" [2].  Future security improvements to BGP
(whether best practices or enhancements to the protocol) should
consider the attacks outlined here when determining the relative
security improvements such changes provide.

Thanks,

Sean
--5652839-0-3245154213=:9004
Content-Type: application/octet-stream; Name="draft-convery-bgpattack-00.txt"; X-Mac-Type="00000000"; X-Mac-Creator="00000000"
Content-Disposition: attachment; Filename="draft-convery-bgpattack-00.txt"
Content-Transfer-Encoding: base64

CgpSb3V0aW5nIFByb3RvY29sIFNlY3VyaXR5ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFMuIENvbnZlcnkKUmVxdWlyZW1lbnRzIChycHNlYykg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBELiBD
b29rCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBNLiBGcmFuegpFeHBpcmVzOiBBcHJpbCAxLCAy
MDAzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Q2lzY28KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDAyCgoKICAgICAgICAgICAgIEFu
IEF0dGFjayBUcmVlIGZvciB0aGUgQm9yZGVyIEdhdGV3YXkgUHJvdG9jb2wKICAg
ICAgICAgICAgICAgICAgICAgICBkcmFmdC1jb252ZXJ5LWJncGF0dGFjay0wMAoK
U3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRl
cm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoCiAgIGFs
bCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4KCiAgIEludGVy
bmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0
IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFu
ZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBz
IG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu
ZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9j
dW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQg
bWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg
ZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0
byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBv
ciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i
CgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUg
YWNjZXNzZWQgYXQgaHR0cDovLwogICB3d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJz
dHJhY3RzLnR4dC4KCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRv
dyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5p
ZXRmLm9yZy9zaGFkb3cuaHRtbC4KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2ls
bCBleHBpcmUgb24gQXByaWwgMSwgMjAwMy4KCkNvcHlyaWdodCBOb3RpY2UKCiAg
IENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDIpLiAgQWxs
IFJpZ2h0cyBSZXNlcnZlZC4KCkFic3RyYWN0CgogICBUaGlzIEktRCBwcmVzZW50
cyBhbGwga25vd24gYXR0YWNrIHZlY3RvcnMgaW50byBvciB1c2luZyBCR1AuICBU
aGUKICAgZGF0YSBpcyBwcmVzZW50ZWQgaW4gIkF0dGFjayBUcmVlIiBmb3JtYXQg
YXMgcHVibGlzaGVkIGJ5IFNjaG5laWVyCiAgIFsxXSBhbmQgZGV0YWlsZWQgYnkg
dGhlIENFUlQgaW4gIkF0dGFjayBNb2RlbGluZyBmb3IgSW5mb3JtYXRpb24KICAg
U2VjdXJpdHkgYW5kIFN1cnZpdmFiaWxpdHkiIFsyXS4gIEZ1dHVyZSBzZWN1cml0
eSBpbXByb3ZlbWVudHMgdG8gQkdQCiAgICh3aGV0aGVyIGJlc3QgcHJhY3RpY2Vz
IG9yIGVuaGFuY2VtZW50cyB0byB0aGUgcHJvdG9jb2wpIHNob3VsZAogICBjb25z
aWRlciB0aGUgYXR0YWNrcyBvdXRsaW5lZCBoZXJlIHdoZW4gZGV0ZXJtaW5pbmcg
dGhlIHJlbGF0aXZlCiAgIHNlY3VyaXR5IGltcHJvdmVtZW50cyBzdWNoIGNoYW5n
ZXMgcHJvdmlkZS4KCgoKCgoKQ29udmVyeSwgZXQgYWwuICAgICAgICAgIEV4cGly
ZXMgQXByaWwgMSwgMjAwMyAgICAgICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50
ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIEJHUCBBdHRhY2sgVHJlZSAgICAgICAg
ICAgICAgICAgT2N0b2JlciAyMDAyCgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEu
ICAgIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAgMwogICAyLiAgICBCR1AgQXR0YWNrIFRyZWUgIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAg
Mi4xICAgQkdQIEF0b21pYyBHb2FscyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuICA2CiAgIDIuMS4xIENvbXByb21pc2UgTUQ1IEF1
dGhlbnRpY2F0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgog
ICAyLjEuMiBFc3RhYmxpc2ggVW5hdXRob3JpemVkIEJHUCBTZXNzaW9uIHdpdGgg
UGVlciAuIC4gLiAuIC4gLiAuIC4gIDgKICAgMi4xLjMgT3JpZ2luYXRlIFVuYXV0
aG9yaXplZCBQcmVmaXgvQXR0cmlidXRlIGludG8gUGVlciBSb3V0ZQogICAgICAg
ICBUYWJsZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gIDkKICAgMi4xLjQgQ2hhbmdlIFBhdGggUHJlZmVyZW5j
ZSBvZiBhIFByZWZpeCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgIDIu
MS41IENvbmR1Y3QgRGVuaWFsL0RlZ3JhZGF0aW9uIG9mIFNlcnZpY2UgQXR0YWNr
IEFnYWluc3QgQkdQCiAgICAgICAgIFByb2Nlc3MgIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAogICAyLjEuNiBS
ZXNldCBhIFNpbmdsZSBCR1AgU2Vzc2lvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gMTEKICAgMi4xLjcgU2VuZCBTcG9vZmVkIEJHUCBNZXNzYWdl
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgIDIuMiAg
IEF0dGFjayBTY2VuYXJpb3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAxMQogICAyLjIuMSBEaXNhYmxlIENyaXRpY2FsIFBvcnRp
b25zIG9mIHRoZSBJbnRlcm5ldCBieSBEaXNydXB0aW5nCiAgICAgICAgIEludGVy
bmV0IFJvdXRpbmcgVGFibGVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAxMwogICAyLjIuMiBGb3JjZSBhIE11bHRpLWhvbWVkIEFTIHRvIHVz
ZSBhbiBBdGVybmF0ZSBQYXRoIHRvL2Zyb20KICAgICAgICAgYW4gT3V0c2lkZSBO
ZXR3b3JrIEluc3RlYWQgb2YgdGhlIFByZWZlcnJlZCBQYXRoIC4gLiAuIC4gLiAu
IDE0CiAgIDIuMi4zIERpc2FibGUgYSBTaW5nbGUtaG9tZWQgQVMgIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAogICAyLjIuNCBEaXNhYmxlIGEg
TXVsdGktaG9tZWQgQVMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gMTUKICAgMi4yLjUgQmxhY2tob2xlIFRyYWZmaWMgIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1CiAgIDMuICAgIFRlc3Rpbmcg
Q29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAxNgogICAgICAgICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcKICAgICAgICAgQXV0aG9y
cycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIDE3CiAgIEEuICAgIFN1cHBvcnRpbmcgQXRvbWljIEdvYWxzICAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQogICBBLjEgICBDb21w
cm9taXNlIFJvdXRlciAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gMTkKICAgQS4yICAgRGVuaWFsIG9mIFNlcnZpY2UgKERvUykgUm91
dGVyIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwCiAgIEEuMyAgIElu
dGVyY2VwdCBvciBNb2RpZnkgRGF0YSBUaHJvdWdoIE1hbi1pbi10aGUtTWlkZGxl
CiAgICAgICAgIChNSVRNKSBBdHRhY2sgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQogICBBLjQgICBUQ1AgU2VxdWVuY2Ug
TnVtYmVyIEF0dGFjayAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
MjEKICAgQS41ICAgU25pZmYgVHJhZmZpYyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyCiAgICAgICAgIEZ1bGwgQ29weXJp
Z2h0IFN0YXRlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAyMwoKCgoKCgoKCgoKCgoKCgoKCgpDb252ZXJ5LCBldCBhbC4gICAgICAgICAg
RXhwaXJlcyBBcHJpbCAxLCAyMDAzICAgICAgICAgICAgICAgICAgW1BhZ2UgMl0K
DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQkdQIEF0dGFjayBUcmVlICAg
ICAgICAgICAgICAgICBPY3RvYmVyIDIwMDIKCgoxLiBJbnRyb2R1Y3Rpb24KCiAg
IEJHUCBhbmQgb3RoZXIgaW5mcmFzdHJ1Y3R1cmUgcHJvdG9jb2xzIHN1Y2ggYXMg
RE5TIGhhdmUgcmVjZWl2ZWQKICAgc2lnbmlmaWNhbnQgY3JpdGljYWwgYXR0ZW50
aW9uIGFzIHRoZSBvdmVyYWxsIGF3YXJlbmVzcyBvZiBJbnRlcm5ldAogICBzZWN1
cml0eSBoYXMgaW5jcmVhc2VkLiAgQWx0aG91Z2ggQkdQIHRocmVhdCBtb2RlbHMg
aGF2ZSBiZWVuCiAgIHB1Ymxpc2hlZCBbM10gdGhhdCBpZGVudGlmeSBpbmhlcmVu
dCB2dWxuZXJhYmlsaXRpZXMgaW4gdGhlIHByb3RvY29sLAogICBub25lIGhhdmUg
Y29uc2lkZXJlZCB0aGUgZnVsbCByYW5nZSBvZiBvcHRpb25zIGF2YWlsYWJsZSB0
byB0aGUKICAgYWR2ZXJzYXJ5IG9yIHRoZWlyIHJlbGF0aXZlIGRpZmZpY3VsdHku
CgogICBUaGUgdXNlIG9mIGF0dGFjayB0cmVlcyBmb2N1c2VzIGFuYWx5c2lzIG9u
IG1lYXN1cmFibGUgZ29hbHMgdGhhdCBjYW4KICAgdWx0aW1hdGVseSBiZSB0cmFu
c2xhdGVkIGludG8gc3BlY2lmaWMgdGVzdHMgYWdhaW5zdCBwb3B1bGFyCiAgIGlt
cGxlbWVudGF0aW9ucy4gIFRoaXMgYW5hbHlzaXMgdGVjaG5pcXVlIGFsc28gZW5j
b3VyYWdlcyBhCiAgIHN0cnVjdHVyZWQgZWxhYm9yYXRpb24gb2YgZXZlbnRzIHRo
YXQgbXVzdCBvY2N1ciBmb3IgYSBzdWNjZXNzZnVsCiAgIGludHJ1c2lvbi4gIFNp
bmNlIGVhY2ggbm9kZSAoYW4gYXR0YWNrZXIgZ29hbCkgbWF5IGJlIGRlY29tcG9z
ZWQgaW50bwogICBzdWJvcmRpbmF0ZSBub2RlcyAoc3ViLWdvYWxzLCBvciBtZWFu
cyBvZiBhY2hpZXZpbmcgdGhlIHBhcmVudCBnb2FsKSwKICAgYXR0YWNrIHRyZWVz
IGFsbG93IHNlY3VyaXR5IGFuYWx5c2lzIHRvIGJlIGNvbmR1Y3RlZCBhdCBtdWx0
aXBsZQogICBsYXllcnMgb2YgYWJzdHJhY3Rpb24uICBUaGlzIGFsbG93cyBjb21t
b24gYXR0YWNrcyB0byBiZSByZWZlcmVuY2VkCiAgIGFzIHJldXNhYmxlIG1vZHVs
ZXMgdGhhdCBhcHBseSB0byBjb21tb24gbmV0d29yayBzY2VuYXJpb3MuCgogICBB
bHRob3VnaCBhIGNvbXByZWhlbnNpdmUgZGlzY3Vzc2lvbiBvZiBhdHRhY2sgdHJl
ZXMgaXMgb3V0c2lkZSB0aGUKICAgc2NvcGUgb2YgdGhpcyBJLUQsIGl0IGlzIHVz
ZWZ1bCB0byBwcm92aWRlIGEgZ2VuZXJhbCBvdmVydmlldyBvZgogICB0aGVpciBm
dW5jdGlvbiBhbmQgdmFsdWUuICBUaGUgY2xlYXJlc3Qgd2F5IHRvIGRlbW9uc3Ry
YXRlIHRoaXMgaXMKICAgdGhyb3VnaCBleGFtcGxlcywgYXMgaWxsdXN0cmF0ZWQg
aW4gWzFdLiAgQ29uc2lkZXIgYW4gaW5kaXZpZHVhbAogICB0cnlpbmcgdG8gZ2Fp
biB1bmF1dGhvcml6ZWQgcGh5c2ljYWwgYWNjZXNzIHRvIGEgYnVpbGRpbmcuICBB
biBhdHRhY2sKICAgdHJlZSBmb3Igc3VjaCBhbiBhY3QgbWlnaHQgbG9vayBsaWtl
IHRoaXM6CgogICBHb2FsOiBHYWluIHVuYXV0aG9yaXplZCBwaHlzaWNhbCBhY2Nl
c3MgdG8gYnVpbGRpbmcKCiAgIEF0dGFjazoKICAgT1IgIDEuIFVubG9jayBkb29y
IHdpdGgga2V5CiAgICAgICAyLiBQaWNrIGxvY2sKICAgICAgIDMuIEJyZWFrIHdp
bmRvdwogICAgICAgNC4gRm9sbG93IGF1dGhvcml6ZWQgaW5kaXZpZHVhbCBpbnRv
IGJ1aWxkaW5nCgogICBUaGlzIHNpbXBsZSB0cmVlIHNob3VsZCBiZSByZWFkIGFz
IGZvbGxvd3M6IHRvIGdhaW4gdW5hdXRob3JpemVkCiAgIHBoeXNpY2FsIGFjY2Vz
cyB0byBhIGJ1aWxkaW5nLCB0aGUgYWR2ZXJzYXJ5IG11c3QgdW5sb2NrIHRoZSBk
b29yCiAgIHdpdGggYSBrZXksIHBpY2sgdGhlIGxvY2ssIGJyZWFrIGEgd2luZG93
LCBvciBmb2xsb3cgYW4gYXV0aG9yaXplZAogICBpbmRpdmlkdWFsIGludG8gdGhl
IGJ1aWxkaW5nLiAgVGhlICJPUiIgb3BlcmF0b3IgZGVmaW5lcyB0aGF0IG9ubHkK
ICAgb25lIGlzIHJlcXVpcmVkLiAgSW4gdGhlIHNhbWUgdHJlZSwgcmVwbGFjaW5n
IHRoZSAiT1IiIHdpdGggIkFORCIKICAgd291bGQgcmVxdWlyZSB0aGF0IGFsbCBz
dWJvcmRpbmF0ZSBnb2FscyBiZSBhY2hpZXZlZCB0byByZWFsaXplIHRoZQogICBw
YXJlbnQgZ29hbC4gIEF0dGFjayB0cmVlcyBhdCB0aGlzIGxldmVsIG9mIGRldGFp
bCBhcmUgb2YgbGltaXRlZAogICB1c2UuICBUaGVpciB0cnVlIHZhbHVlIGNvbWVz
IGluIHVuZGVyc3RhbmRpbmcgaG93IGFuIGFkdmVyc2FyeSBjYW4KICAgZXhlY3V0
ZSBvbmUgb2YgdGhlIGxpc3RlZCBzdWJvcmRpbmF0ZSBnb2Fscy4gIFRoaXMgcmVx
dWlyZXMgdGhlCiAgIGZvbGxvd2luZywgbW9yZSBkZXRhaWxlZCwgYXR0YWNrIHRy
ZWU6CgoKCgoKCgpDb252ZXJ5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJp
bCAxLCAyMDAzICAgICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1E
cmFmdCAgICAgICAgICAgICAgQkdQIEF0dGFjayBUcmVlICAgICAgICAgICAgICAg
ICBPY3RvYmVyIDIwMDIKCgogICBHb2FsOiBHYWluIHVuYXV0aG9yaXplZCBwaHlz
aWNhbCBhY2Nlc3MgdG8gYnVpbGRpbmcKCiAgIEF0dGFjazoKICAgT1IgIDEuIFVu
bG9jayBkb29yIHdpdGgga2V5CiAgICAgICBPUiAgMS4gU3RlYWwgS2V5CiAgICAg
ICAgICAgMi4gU29jaWFsIEVuZ2luZWVyaW5nCiAgICAgICAgICAgT1IgIDEuIEJv
cnJvdyBrZXkKICAgICAgICAgICAgICAgMi4gQ29udmluY2UgbG9ja3NtaXRoIHRv
IHVubG9jayBkb29yCiAgICAgICAyLiBQaWNrIGxvY2sKICAgICAgIDMuIEJyZWFr
IHdpbmRvdwogICAgICAgNC4gRm9sbG93IGF1dGhvcml6ZWQgaW5kaXZpZHVhbCBp
bnRvIGJ1aWxkaW5nCiAgICAgICBPUiAgMS4gQWN0IGxpa2UgeW91IGJlbG9uZyBh
bmQgZm9sbG93IHNvbWVvbmUgZWxzZQogICAgICAgICAgIDIuIEJlZnJpZW5kIHNv
bWVvbmUgYXV0aG9yaXplZCBvdXRzaWRlIGEgYnVpbGRpbmcKICAgICAgICAgICAz
LiBBcHBlYXIgaW4gbmVlZCBvZiBhc3Npc3RhbmNlIChzdWNoIGFzIGNhcnJ5aW5n
IGEgbGFyZ2UgYm94KQogICAgICAgQU5EIDQuIFdlYXIgYXBwcm9wcmlhdGUgY2xv
dGhpbmcgZm9yIHRoZSBsb2NhdGlvbgoKICAgTm93IHRoZSB2YXJpb3VzIHN1YiBu
b2RlcyBvZiB0aGUgdHJlZSBhcmUgYmV0dGVyIGRlZmluZWQuICBJbiBvcmRlcgog
ICB0byAidW5sb2NrIGRvb3Igd2l0aCBrZXkiIHlvdSBuZWVkIHRvIGVpdGhlciBz
dGVhbCB0aGUga2V5IG9yIHBlcmZvcm0KICAgc29tZSB0eXBlIG9mIHNvY2lhbCBl
bmdpbmVlcmluZy4gIFN1YiBnb2FsIDQgKEZvbGxvdyBhdXRob3JpemVkCiAgIGlu
ZGl2aWR1YWwgaW50byBidWlsZGluZykgaWxsdXN0cmF0ZXMgdGhlIHVzZSBvZiAi
T1IiIGFuZCAiQU5EIiBhdAogICB0aGUgc2FtZSBsZXZlbCBvZiB0aGUgdHJlZS4g
IFRoaXMgc2hvdWxkIGJlIHJlYWQgYXMgZm9sbG93czogSW4gb3JkZXIKICAgdG8g
Zm9sbG93IGFuIGluZGl2aWR1YWwgaW50byB0aGUgYnVpbGRpbmcgdGhlIGFkdmVy
c2FyeSBuZWVkcyB0byBkbwogICBvbmUgb2YgdGhlIGZpcnN0IDMgbGlzdGVkIGl0
ZW1zLCBhbmQgd2VhciBhcHByb3ByaWF0ZSBjbG90aGluZyBmb3IKICAgdGhlIGxv
Y2F0aW9uLgoKICAgVGhlIHVzZSBvZiBhdHRhY2sgdHJlZXMgYWxzbyBhbGxvd3Mg
Y29tcGFyaXNvbiBiZXR3ZWVuIHRlY2huaWNhbCBhbmQKICAgbm9uLXRlY2huaWNh
bCBtZWFucyBvZiBhdHRhY2ssIGFuZCBsZWFkcyB0byBhIG1vcmUgY29tcHJlaGVu
c2l2ZQogICBhbmFseXNpcyBvZiB0aHJlYXRzIGFuZCB2dWxuZXJhYmlsaXRpZXMu
ICBFdmVuIHdpdGhvdXQgZXh0ZW5zaXZlCiAgIGVsYWJvcmF0aW9uLCB3ZSBsZWFy
biBpbiB0aGlzIHRyZWUgdGhhdCBmb2xsb3dpbmcgc29tZW9uZSBpbnRvIGEKICAg
YnVpbGRpbmcgaXMgcHJvYmFibHkgdGhlIGVhc2llc3Qgd2F5IG9mIGdhaW5pbmcg
ZW50cmFuY2Ugd2l0aCB0aGUKICAgbG93ZXN0IGFtb3VudCBvZiBjb3N0IG9yIHJp
c2sgdG8gdGhlIGFkdmVyc2FyeS4gIFRoaXMgY2xhc3Mgb2YKICAgYXR0YWNrcyBj
b2xsZWN0aXZlbHkga25vd24gYXMgInNvY2lhbCBlbmdpbmVlcmluZyIgaXMgbGlz
dGVkIGJ1dCBub3QKICAgZWxhYm9yYXRlZCB0aHJvdWdob3V0IHRoaXMgSS1ELiAg
SW4gbWFueSBjYXNlcyBzb2NpYWwgZW5naW5lZXJpbmcgaXMKICAgdGhlIGVhc2ll
c3QgZm9ybSBvZiBhdHRhY2sgYW5kIGNvdWxkIHJlc3VsdCBpbiB0aGUgZ3JlYXRl
c3QgZGFtYWdlLgoKICAgVGhpcyBJLUQgaWxsdXN0cmF0ZXMgYSBzaW1wbGUgQkdQ
IGF0dGFjayB0cmVlOiBzdWJzZXF1ZW50IGFuYWx5c2lzCiAgIHNob3VsZCBhc3Np
Z24gYXR0cmlidXRlcyAoYW5kIHBvc3NpYmx5IHZhbHVlcykgdG8gZWFjaCBub2Rl
IG9mIHRoZQogICB0cmVlLiAgVGhpcyBhbGxvd3MgbW9yZSBxdWFudGl0YXRpdmUg
bWV0aG9kcyB0byBiZSB1c2VkIGluIGFuYWx5emluZwogICB0aGUgYXR0YWNrIHRy
ZWUgZGF0YS4gIFRoZXNlIGF0dHJpYnV0ZXMgY291bGQgaW5jbHVkZToKCiAgIG8g
IEltcGFjdCBvZiB0aGUgYXR0YWNrCgogICBvICBFYXNlIG9mIGF0dGFjayBleGVj
dXRpb24KCiAgIG8gIENvc3Qgb2YgdGhlIGF0dGFjawoKICAgbyAgUHJlc2VuY2Ug
b2YgY291bnRlcm1lYXN1cmVzIChzdWNoIGFzIGJlc3QgcHJhY3RpY2VzKQoKCgoK
Q29udmVyeSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMSwgMjAwMyAg
ICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg
ICAgICAgIEJHUCBBdHRhY2sgVHJlZSAgICAgICAgICAgICAgICAgT2N0b2JlciAy
MDAyCgoKICAgbyAgQWNjZXNzL3RydXN0IHJlcXVpcmVtZW50cyB0byBjb25kdWN0
IGF0dGFjawoKICAgQW5hbHlzaXMgb2YgdGhpcyBkYXRhIHdpbGwgeWllbGQgdGhl
IHN1YnNldCBvZiBhdHRhY2tzIHRoYXQgcmVzdWx0IGluCiAgIHRoZSBtb3N0IGRh
bWFnZSwgYXJlIHRoZSBlYXNpZXN0IHRvIGxhdW5jaCwgdGhlIGxlYXN0IGNvc3Rs
eSwgaGF2ZQogICB0aGUgbGVhc3QgYWNjZXNzIHJlcXVpcmVtZW50cywgYW5kIGFy
ZSB1bmxpa2VseSB0byBiZSBtaXRpZ2F0ZWQgYnkKICAgY3VycmVudCBiZXN0IHBy
YWN0aWNlcy4gIEFkZHJlc3NpbmcgdGhlc2UgYXR0YWNrcyBzaG91bGQgYmUgdGhl
CiAgIGluaXRpYWwgZm9jdXMgb2YgYW55IGltcHJvdmVtZW50cyB0byBCR1Agb3Ig
cmVsZXZhbnQgYmVzdCBwcmFjdGljZXMuCgogICBDb21wdXRlciBzZWN1cml0eSB0
ZXJtcyB1c2VkIGluIHRoaXMgSS1EIGFyZSBpbiBhY2NvcmRhbmNlIHdpdGggUkZD
CiAgIDI4MjggWzRdLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK
CgoKCgoKCkNvbnZlcnksIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFwcmlsIDEs
IDIwMDMgICAgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0
ICAgICAgICAgICAgICBCR1AgQXR0YWNrIFRyZWUgICAgICAgICAgICAgICAgIE9j
dG9iZXIgMjAwMgoKCjIuIEJHUCBBdHRhY2sgVHJlZQoKICAgVGhpcyBJLUQgZGl2
aWRlcyB0aGUgYXR0YWNrIHRyZWUgaW50byB0aHJlZSBtYWluIHNlY3Rpb25zIHRv
IHJlZHVjZQogICByZWR1bmRhbmN5IGFuZCBwcm92aWRlIGdyZWF0ZXIgcG9ydGFi
aWxpdHkgaW50byBzdWJzZXF1ZW50IHRyZWVzCiAgIGRlZmluZWQgaW4gb3RoZXIg
SS1Ecy4gIFdoZW4gYW5vdGhlciBzZWN0aW9uIG9mIHRoaXMgSS1EIGlzCiAgIHJl
ZmVyZW5jZWQgd2l0aGluIGEgc3BlY2lmaWMgdHJlZSwgdGhlIHRyZWUgbG9jYXRl
ZCBhdCB0aGUgcmVmZXJlbmNlZAogICBzZWN0aW9uIHNob3VsZCBiZSBhdHRhY2hl
ZCBhdCB0aGUgcG9pbnQgdGhlIHJlZmVyZW5jZSBpcyBtYWRlLgoKICAgVGhlIGZp
cnN0IHNlY3Rpb24gZGV0YWlscyBCR1AgQXRvbWljIEdvYWxzIG9mIGFuIGFkdmVy
c2FyeSBhbmQgaXMKICAgZGV0YWlsZWQgaW4gU2VjdGlvbiAyLjEuICBCR1AgQXRv
bWljIEdvYWxzIGFyZSBkZWZpbmVkIGluIHRoaXMgSS1EIGFzCiAgIHRoZSBuYXJy
b3dlc3QgZm9ybSBvZiBhdHRhY2sgYnkgYW4gYWR2ZXJzYXJ5IHNwZWNpZmljYWxs
eSBkaXJlY3RlZAogICBhZ2FpbnN0IEJHUC4gIEJHUCBBdG9taWMgR29hbHMgY29u
c2lzdCBvZiB1bmlxdWUgYXR0YWNrIHRlY2huaXF1ZXMKICAgYW5kIFN1cHBvcnRp
bmcgQXRvbWljIEdvYWxzIGFzIGRldGFpbGVkIGluIEFwcGVuZGl4IEEuICBTdXBw
b3J0aW5nCiAgIEF0b21pYyBHb2FscyBhcmUgY29tbW9uIG5ldHdvcmsgYXR0YWNr
IG1ldGhvZHMgdXNlZCBpbiBtb3JlIHRoYW4gb25lCiAgIEJHUCBBdG9taWMgR29h
bC4gIFRoZSB0aGlyZCBtYWluIHNlY3Rpb24gb2YgdGhlIGRvY3VtZW50IGRldGFp
bHMKICAgaGlnaGVyIGxldmVsIGFkdmVyc2FyeSBnb2FscyB0aGF0IG1ha2UgdXNl
IG9mIEJHUCBBdG9taWMgR29hbHMgKGFuZAogICB0aGVyZWZvcmUgc3VwcG9ydGlu
ZyBhdG9taWMgZ29hbHMgYXMgd2VsbCkuICBUaGVzZSBnb2FscyBhcmUgcmVmZXJy
ZWQKICAgdG8gYXMgQXR0YWNrIFNjZW5hcmlvcyBhbmQgYXJlIGRldGFpbGVkIGlu
IFNlY3Rpb24gMi4yLgoKICAgSXQgaXMgd29ydGggbm90aW5nIHRoYXQgdGhlIGlu
Y2x1c2lvbiBvZiBhbiBhdHRhY2sgaW4gdGhpcyBhdHRhY2sKICAgdHJlZSBzYXlz
IG5vdGhpbmcgd2l0aCByZWdhcmQgdG8gdGhlIGxpa2VsaWhvb2Qgc3VjaCBhbiBh
dHRhY2sgd2lsbAogICBvY2N1ciBvciBldmVuIHRoZSByZWFzb25hYmxlIHBvc3Np
YmlsaXR5IGl0IGNvdWxkIG9jY3VyLiAgRnV0dXJlCiAgIHRlc3RpbmcgYW5kIGFu
YWx5c2lzLCBhcyBtZW50aW9uZWQgZWFybGllciwgaXMgcmVxdWlyZWQgdG8gYWNj
dXJhdGVseQogICBpbnRlcnByZXQgdGhlIGRhdGEgaW4gdGhpcyB0cmVlLgoKMi4x
IEJHUCBBdG9taWMgR29hbHMKCiAgIFRoZSBmb2xsb3dpbmcgYXRvbWljIGdvYWxz
IGFyZSBkZWZpbmVkIGFuZCB1c2VkIHRocm91Z2hvdXQgdGhlIGF0dGFjawogICB0
cmVlOgoKICAgbyAgQ29tcHJvbWlzZSBNRDUgYXV0aGVudGljYXRpb24KCiAgIG8g
IEVzdGFibGlzaCB1bmF1dGhvcml6ZWQgQkdQIHNlc3Npb24gd2l0aCBwZWVyCgog
ICBvICBPcmlnaW5hdGUgdW5hdXRob3JpemVkIHByZWZpeCBpbnRvIHBlZXIgcm91
dGUgdGFibGUKCiAgIG8gIENoYW5nZSBwYXRoIHByZWZlcmVuY2Ugb2YgYSBwcmVm
aXgKCiAgIG8gIENvbmR1Y3QgZGVuaWFsL2RlZ3JhZGF0aW9uIG9mIHNlcnZpY2Ug
YWdhaW5zdCBCR1AgcHJvY2VzcwoKICAgbyAgUmVzZXQgc2luZ2xlIEJHUCBzZXNz
aW9uCgogICBvICBTcG9vZiBhIEJHUCBtZXNzYWdlCgoKMi4xLjEgQ29tcHJvbWlz
ZSBNRDUgQXV0aGVudGljYXRpb24KCgoKCgpDb252ZXJ5LCBldCBhbC4gICAgICAg
ICAgRXhwaXJlcyBBcHJpbCAxLCAyMDAzICAgICAgICAgICAgICAgICAgW1BhZ2Ug
Nl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQkdQIEF0dGFjayBUcmVl
ICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDIKCgogICBUaGUgY29tbW9uLXNl
bnNlIHZpZXcgaXMgdGhhdCBtb3N0IGFkdmVyc2FyaWVzIHdpbGwgY2hvb3NlIHRo
ZSBwYXRoCiAgIG9mIGxlYXN0IHJlc2lzdGFuY2UsIHNvIHRoYXQgYWxsIGJ1dCB0
aGUgbW9zdCBzb3BoaXN0aWNhdGVkIHRocmVhdHMKICAgd291bGQgdGFyZ2V0IGEg
QkdQIHNwZWFrZXIgd2hvc2Ugc2Vzc2lvbnMgYXJlIG5vdCBwcm90ZWN0ZWQgYnkg
UkZDCiAgIDIzODUgWzVdIGF1dGhlbnRpY2F0aW9uLiAgTmV2ZXJ0aGVsZXNzLCBh
dHRlbXB0aW5nIGEgY29tcHJvbWlzZSBvZgogICBNRDUgYXV0aGVudGljYXRlZCBC
R1AgbWVzc2FnZXMgY291bGQgYmUgZG9uZSBhcyBmb2xsb3dzOgoKCiAgIEF0dGFj
azoKICAgT1IgIDEuIFVzZSBzb2NpYWwgZW5naW5lZXJpbmcgdG8gb2J0YWluIE1E
NSBwYXNzd29yZAogICAgICAgMi4gQ2FwdHVyZSBQYXNzd29yZAogICAgICAgT1Ig
IDEuIEtleXN0cm9rZSBsb2dnZXIKICAgICAgICAgICBBTkQgIDEuIENvbXByb21p
c2UvZ2FpbiBhY2Nlc3MgdG8gYWRtaW5pc3RyYXRpdmUgaG9zdAogICAgICAgICAg
ICAgICAgMi4gSW5zdGFsbCBob3N0aWxlIGFwcGxpY2F0aW9uIG9uIGFkbWluaXN0
cmF0aXZlIGhvc3QKICAgICAgICAgICAgICAgIDMuIE9ic2VydmUgTUQ1IHBhc3N3
b3JkIGFzIGl0IGlzIHR5cGVkL3ZpZXdlZCBvbiBzY3JlZW4KICAgICAgICAgICAy
LiBTbmlmZiBNRDUgcGFzc3dvcmQgZnJvbSBtYW5hZ2VtZW50IHRyYWZmaWMgKEFw
cGVuZGl4IEEuNCkKICAgICAgICAgICAzLiBDYXB0dXJlIHBhc3N3b3JkIGZyb20g
cm91dGVyIGNvbmZpZ3VyYXRpb24KICAgICAgICAgICBPUiAgIDEuIENvbXByb21p
c2UgbmV0d29yayBtYW5hZ2VtZW50IHNlcnZlcgogICAgICAgICAgICAgICAgT1Ig
IDEuIFZpZXcgdW5lbmNyeXB0ZWQgcm91dGVyIGNvbmZpZ3VyYXRpb24KICAgICAg
ICAgICAgICAgICAgICAyLiBEZWNyeXB0IGVuY3J5cHRlZCByb3V0ZXIgY29uZmln
dXJhdGlvbgogICAgICAgICAgICAgICAgMi4gQ29tcHJvbWlzZSByb3V0ZXIgKEFw
cGVuZGl4IEEuMSkKICAgICAgIDMuIEJydXRlLUZvcmNlIE1ENSBwYXNzd29yZAog
ICAgICAgT1IgIDEuIEFjdGl2ZSBhdHRhY2sgLSBhdHRlbXB0IHRvIGNvbm5lY3Qg
d2l0aAogICAgICAgICAgIE9SICAxLiBTZW5kIHRvIHBlZXIgdGhhdCBnZW5lcmF0
ZXMgaGFzaGVkIHJlc3BvbnNlCiAgICAgICAgICAgICAgIEFORCAgMS4gU2VuZCBz
ZWdtZW50IHdpdGggUkZDIDIzODUgb3B0aW9uIHRvIHJvdXRlcgogICAgICAgICAg
ICAgICAgICAgIDIuIE9ic2VydmUgcmVzcG9uc2UgZnJvbSByb3V0ZXIgdG8gZGV0
ZXJtaW5lIGlmIHlvdXIgaGFzaAogICAgICAgICAgICAgICAgICAgIHdhcyB2YWxp
ZAogICAgICAgICAgICAgICAgICAgIDMuIEdhaW4gcGh5c2ljYWwvbG9jYWwgYWNj
ZXNzIHRvIGxpbmsgYmV0d2VlbiBwZWVycwogICAgICAgICAgIDIuIFBhc3NpdmUg
QXR0YWNrCiAgICAgICAgICAgQU5EIDEuIE9idGFpbiBoYXNoZWQgcGFja2V0ICh0
byBmYWNpbGl0YXRlIG9mZmxpbmUgYXR0YWNrKQogICAgICAgICAgICAgICAyLiBV
c2UgUkZDIDIzODUgY3JhY2tpbmcgdG9vbCB0byBkaXNjb3ZlciBwYXNzd29yZAog
ICAgICAgNS4gRGlzY292ZXIgaW1wbGVtZW50YXRpb24gZmxhdyBpbiBSRkMgMjM4
NQogICAgICAgNi4gRGlzY292ZXIgbmV3IGF0dGFjayBhZ2FpbnN0IE1ENQogICAg
ICAgNy4gRXhwbG9pdCBoYXNoIGNvbGxpc2lvbiBhdHRhY2sgYWdhaW5zdCBNRDUK
CgogICBUbyB2YWxpZGF0ZSBvdXIgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIHJlbGF0
aXZlIGRpZmZpY3VsdHkgb2YKICAgYXR0YWNraW5nIFJGQzIzODUgYXV0aGVudGlj
YXRpb24sIHdlIG11c3QgaGF2ZSB0ZXN0IGRhdGEgdGhhdAogICBtZWFzdXJlcyB0
aGUgcmVsYXRpdmUgZWFzZS9kaWZmaWN1bHR5IG9mIHN1Y2ggYXR0YWNrcyAob3Ig
dGhlIHNpZGUKICAgZWZmZWN0cyBvZiB1bnN1Y2Nlc3NmdWwgYXR0YWNrcykgYWdh
aW5zdCBwb3B1bGFyIEJHUC9UQ1AKICAgaW1wbGVtZW50YXRpb25zLiAgV2hlbiBv
YnNlcnZpbmcgdGhlIHJlc3BvbnNlIGZyb20gYW4gUkZDIDIzODUKICAgYXV0aGVu
dGljYXRlZCBzZXNzaW9uLCBzbmlmZmluZyB3aWxsIGJlIG5lY2Vzc2FyeSBpZiB1
c2luZyBhIHNwb29mZWQKICAgU1lOLgoKCgoKCgoKCgpDb252ZXJ5LCBldCBhbC4g
ICAgICAgICAgRXhwaXJlcyBBcHJpbCAxLCAyMDAzICAgICAgICAgICAgICAgICAg
W1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQkdQIEF0dGFj
ayBUcmVlICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDIKCgoyLjEuMiBFc3Rh
Ymxpc2ggVW5hdXRob3JpemVkIEJHUCBTZXNzaW9uIHdpdGggUGVlcgoKICAgRXN0
YWJsaXNoaW5nIGFuIHVuYXV0aG9yaXplZCBCR1Agc2Vzc2lvbiB3aXRoIGEgcGVl
ciBpcyBkZWZpbmVkIGJ5CiAgIGFjaGlldmluZyBhIHBlZXJpbmcgYXJyYW5nZW1l
bnQgd2l0aG91dCB0aGUga25vd2xlZGdlIG9yIHBlcm1pc3Npb24KICAgb2YgYm90
aCBzaWRlcyBvZiB0aGUgc2Vzc2lvbi4gIFRoaXMgaW5jbHVkZXMgcGVlcmluZyBz
ZXNzaW9ucwogICBlc3RhYmxpc2hlZCBieSByb3V0ZXJzIGFuZC9vciBhbnkgb3Ro
ZXIgZGV2aWNlIGNhcGFibGUgb2YgYmVpbmcgYSBCR1AKICAgc3BlYWtlci4KCiAg
IEF0dGFjazoKICAgT1IgIDEuIEVzdGFibGlzaCBzZXNzaW9uIHdpdGggcGVybWlz
c2l2ZSByb3V0ZXIKICAgICAgIE9SICAxLiBGaW5kIGF2YWlsYWJsZSBsb2NhbCBC
R1Agc3BlYWtlcgogICAgICAgICAgIE9SICAxLiBQb3J0IFNjYW4KICAgICAgICAg
ICAgICAgMi4gU29jaWFsIEVuZ2luZWVyaW5nCiAgICAgICAgICAgMi4gRmluZCBh
dmFpbGFibGUgcmVtb3RlIChFQkdQLW11bHRpKSBzcGVha2VyCiAgICAgICAgICAg
T1IgIDEuIFBvcnQgU2NhbgogICAgICAgICAgICAgICAyLiBTb2NpYWwgRW5naW5l
ZXJpbmcKICAgICAgIEFORCAzLiBFc3RhYmxpc2ggcGVlcmluZyByZWxhdGlvbnNo
aXAgd2l0aCBkaXNjb3ZlcmVkIHJvdXRlcgogICAgICAgMi4gQ29tcHJvbWlzZSBy
b3V0ZXIgYW5kIHJlY29uZmlndXJlIHRvIGFsbG93IHBlZXJpbmcgc2Vzc2lvbgog
ICAgICAgQU5EIDEuIENvbXByb21pc2UgUm91dGVyIChBcHBlbmRpeCBBLjEpCiAg
ICAgICAgICAgMi4gQ29uZmlndXJlIHJvdXRlciB0byBhbGxvdyBwZWVyaW5nIGZy
b20gYXR0YWNraW5nIHJvdXRlcgogICAgICAgMy4gU2ltdWxhdGUgQkdQIFNlc3Np
b24gZnJvbSBub24tcm91dGVyCgogICBPbmNlIGEgcGVlcmluZyBzZXNzaW9uIGhh
cyBiZWVuIGVzdGFibGlzaGVkLCB0aGUgYWR2ZXJzYXJ5IGNhbiBtdWNoCiAgIG1v
cmUgZWFzaWx5IGxhdW5jaCBhdHRhY2tzIHRoYXQgbm90IG9ubHkgZWZmZWN0IHRo
ZSBwZWVyLCBidXQgdGhlCiAgIGVudGlyZSBuZXR3b3JrLgoKCgoKCgoKCgoKCgoK
CgoKCgoKCgoKCgoKCkNvbnZlcnksIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFw
cmlsIDEsIDIwMDMgICAgICAgICAgICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0
LURyYWZ0ICAgICAgICAgICAgICBCR1AgQXR0YWNrIFRyZWUgICAgICAgICAgICAg
ICAgIE9jdG9iZXIgMjAwMgoKCjIuMS4zIE9yaWdpbmF0ZSBVbmF1dGhvcml6ZWQg
UHJlZml4L0F0dHJpYnV0ZSBpbnRvIFBlZXIgUm91dGUgVGFibGUKCiAgIFRvIGFj
Y29tcGxpc2ggdGhpcyBnb2FsLCBhbiBhZHZlcnNhcnkgbXVzdCBpbnNlcnQgYSBu
ZXcgcHJlZml4IGludG8gYQogICBwZWVyJ3Mgcm91dGluZyB0YWJsZS4gIFRoaXMg
YXR0YWNrIGNhbiBiZSB1c2VkIHRvIGNoYW5nZSB0cmFmZmljCiAgIHBhdHRlcm5z
IGluIGEgbmV0d29yayBpbiB0aGUgY2FzZSB0aGF0IHRoZSBwcmVmaXggaXMgbW9y
ZSBzcGVjaWZpYwogICB0aGFuIHRoZSByb3V0ZSBwcmV2aW91c2x5IHVzZWQgdG8g
ZGlyZWN0IHRyYWZmaWMuICBUaGlzIGNhbiBsZWFkIHRvCiAgIHN0b2xlbiBvciBi
bGFja2hvbGVkIHRyYWZmaWMgYWNyb3NzIHRoZSBuZXR3b3JrLgoKICAgQXR0YWNr
OgogICBPUiAgMS4gU2VuZCBmcm9tIHZhbGlkIFJvdXRlcgogICAgICAgT1IgIDEu
IE1pc2NvbmZpZ3VyZWQKICAgICAgICAgICAyLiBDb21wcm9taXNlIHJvdXRlciAo
QXBwZW5kaXggQS4xKQogICAgICAgMi4gU2VuZCBmcm9tIEludmFsaWQgUm91dGVy
CiAgICAgICBBTkQgMS4gR2FnIHZhbGlkIHJvdXRlcgogICAgICAgICAgIE9SICAx
LiBLaWxsIFJvdXRlcgogICAgICAgICAgICAgICBPUiAgMS4gUG93ZXIgT2ZmL1Bo
eXNpY2FsIExheWVyCiAgICAgICAgICAgICAgICAgICAyLiBDcmFzaCBhbmQgcHJl
dmVudCByZWJvb3QKICAgICAgICAgICAgICAgICAgIDMuIENvbmR1Y3QgZGVuaWFs
IG9mIHNlcnZpY2UgYWdhaW5zdCByb3V0ZXIgKEFwcGVuZGl4IEEuMikKICAgCSAg
ICAgICAgMi4gU3RlYWwgSVAgQWRkcgogICAgICAgICAgICAgICBPUiAgMS4gQVJQ
IFNwb29mCiAgICAgICAgICAgICAgICAgICAyLiBTdGVhbCBNQUMKICAgICAgICAg
ICAyLiBJbnRyb2R1Y2Ugcm9ndWUgcm91dGVyIChBc3N1bWUgSVApCiAgICAgICAg
ICAgT1IgIDEuIFN0ZWFsIElQIEFkZHIgKHNlY3Rpb24gMi4xLjMuMS4yKQogICAg
ICAgICAgICAgICAyLiBJR1AgTW9yZSBTcGVjaWZpYyBSb3V0ZSBJbnRyb2R1Y3Rp
b24KICAgICAgICAgICAgICAgMy4gRXN0YWJsaXNoIHVuYXV0aG9yaXplZCBCR1Ag
c2Vzc2lvbiB3L3BlZXIgKFNlY3Rpb24gMi4xLjIpCiAgICAgICAzLiBTZW5kIHNw
b29mZWQgQkdQIFVwZGF0ZSBmcm9tIE5vbi1Sb3V0ZXIKICAgICAgIE9SICAxLiBD
b25kdWN0IFRDUCBTZXF1ZW5jZSBOdW1iZXIgQXR0YWNrIChBcHBlbmRpeCBBLjQp
CiAgICAgICAgICAgMi4gQ29uZHVjdCBNYW4taW4tdGhlLU1pZGRsZSAoQXBwZW5k
aXggQS4zKQogICBBTkQgNC4gQ3JhZnQgQkdQIE1lc3NhZ2UKCiAgIFRoaXMgaXMg
b25lIG9mIHNldmVyYWwgYXR0YWNrcyB0aGF0IGNhbiBiZSBjYXVzZWQgYnkgbWlz
Y29uZmlndXJhdGlvbgogICBhcyBvcHBvc2VkIHRvIGEgZGVsaWJlcmF0ZSBhdHRh
Y2suCgoyLjEuNCBDaGFuZ2UgUGF0aCBQcmVmZXJlbmNlIG9mIGEgUHJlZml4Cgog
ICBDaGFuZ2luZyB0aGUgcGF0aCBwcmVmZXJlbmNlIG9mIGEgcHJlZml4IGNhbiBs
ZWFkIHRvIHRoZSBzYW1lIHR5cGVzCiAgIG9mIGF0dGFja3MgdGhhdCBvY2N1ciBi
eSBpbnNlcnRpbmcgYSBuZXcgcHJlZml4IGludG8gYSBwZWVyJ3Mgcm91dGluZwog
ICB0YWJsZS4gIFRoaXMgYXRvbWljIGdvYWwgaXMgZGVmaW5lZCBieSBhbHRlcmlu
ZyB0aGUgYXR0cmlidXRlcyBvZiBhCiAgIHByZWZpeCBzbyB0aGF0IHRoZSBCR1Ag
ZGVjaXNpb24gcHJvY2VzcyBpcyBhZmZlY3RlZC4gIFRoaXMgZ29hbCBpcwogICBk
aWZmZXJlbnQgZnJvbSBvcmlnaW5hdGluZyBhbiB1bmF1dGhvcml6ZWQgcHJlZml4
IGluIHRoYXQgYWx0ZXJpbmcKICAgdGhlIGF0dHJpYnV0ZXMgaW1wbGllcyB0aGF0
IHRoZSBwcmVmaXggYWxyZWFkeSBleGlzdHMgaW4gdGhlIEJHUAogICB0YWJsZS4g
IFRoZXJlIGFyZSBkaWZmZXJlbnQgbWV0aG9kcyB0aGF0IGNhbiBiZSB1c2VkIHRv
IGFjY29tcGxpc2gKICAgZWFjaCBvZiB0aGVzZSBnb2FscyBzbyB0aGV5IHdpbGwg
YmUgYW5hbHl6ZWQgc2VwYXJhdGVseS4KCiAgIEF0dGFjazoKICAgT1IgIDEuIE1v
ZGlmeSAoQVMtUEFUSCwgTmV4dC1Ib3AsIE1FRCwgbG9jYWwtcHJlZiwgY29tbXVu
aXRlcykKICAgICAgIE9SICAxLiBWYWxpZCBCR1AgU3BlYWtlcgogICAgICAgICAg
IE9SICAxLiByb2d1ZSB0cmFuc2l0IGltcGxlbWVudGF0aW9uCgoKCkNvbnZlcnks
IGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFwcmlsIDEsIDIwMDMgICAgICAgICAg
ICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBC
R1AgQXR0YWNrIFRyZWUgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwMgoKCiAg
ICAgICAgICAgICAgIDIuIGNvbXByb21pc2UgZWRnZSAob3JpZ2luL3JlY2lwaWVu
dCkgcm91dGVyCiAgICAgICAgICAgMi4gTWFuLWluLXRoZS1taWRkbGUgYXR0YWNr
IChBcHBlbmRpeCBBLjMpCiAgICAgICAgICAgMy4gQ29tcHJvbWlzZSByb3V0ZXIg
KEFwcGVuZGl4IEEuMSkKCiAgIEluIHJlYWxpdHksIGFueSBhdHRyaWJ1dGUgY291
bGQgYmUgYWx0ZXJlZCB0byBjaGFuZ2UgdGhlIHBhdGgKICAgcHJlZmVyZW5jZS4g
IFRoZSBmaXZlIGxpc3RlZCBhcmUgdGhlIG1vc3QgY29tbW9uLgoKMi4xLjUgQ29u
ZHVjdCBEZW5pYWwvRGVncmFkYXRpb24gb2YgU2VydmljZSBBdHRhY2sgQWdhaW5z
dCBCR1AgUHJvY2VzcwoKICAgQkdQIHJvdXRpbmcgcHJvY2Vzc2VzIGFyZSBzdXNj
ZXB0aWJsZSB0byBhIHZhcmlldHkgb2YgYXR0YWNrcyB3aGljaAogICBjYW4gcHJl
dmVudCBlc3RhYmxpc2htZW50IG9mIG5ldyBzZXNzaW9ucywgZXhjaGFuZ2Ugb2Yg
cm91dGluZwogICB1cGRhdGVzLCBvciBjYXVzZSB0aGUgcm91dGVyIGl0c2VsZiB0
byBiZWNvbWUgaW5vcGVyYWJsZS4KCiAgIEF0dGFjazoKICAgT1IgIDEuIERlbmlh
bCBvZiBzZXJ2aWNlIGFnYWluc3Qgcm91dGVyIChBcHBlbmRpeCBBLjIpCiAgICAg
ICAyLiBUQ1AgUmVzb3VyY2UgRXhoYXVzdGlvbiBhZ2FpbnN0IFBvcnQgMTc5CiAg
ICAgICBPUiAgMS4gU1lOIEZsb29kIC0gZXhoYXVzdCBTWU5fUkNWRCBzdGF0ZSBp
biBUQ1Agc3RhY2sKICAgICAgICAgICAyLiBDb25uZWN0KCkgLSByZXBlYXRlZCBm
dWxsICgzLXdheSBoYW5kc2hha2UpIGNvbm5lY3Rpb25zCiAgICAgICAgICAgMy4g
TEFTVF9BQ0sgLSBjb21wbGV0ZSAzLXdheSBoYW5kc2hha2UsIHRoZW4gRklOLUFD
SwogICAgICAgMy4gSW52YWxpZCBCR1AgTWVzc2FnZXMKICAgICAgICAgICAxLiBP
UEVOCiAgICAgICAgICAgMi4gVVBEQVRFCiAgICAgICAgICAgMy4gS0VFUEFMSVZF
CiAgICAgICAgICAgNC4gTk9USUZJQ0FUSU9OCiAgICAgICA0LiBWYWxpZCBCR1Ag
TWVzc2FnZXMKICAgICAgICAgICAxLiBTZW5kIC8zMiByb3V0ZXMKICAgICAgICAg
ICAyLiBVcGRhdGUgZmxvb2RpbmcKICAgICAgICAgICAzLiBVcGRhdGUvV2l0aGRy
YXcgRmxvb2RpbmcKICAgICAgICAgICA0LiBNRDUgUmVzb3VyY2UgRXhoYXVzdGlv
bgoKICAgR2l2ZW4gdGhlIG5lYXJseSBpbmZpbml0ZSBudW1iZXIgb2YgYXR0YWNr
cyBhbmQgb3BlcmF0aW9uYWwKICAgY29uZGl0aW9ucyB0aGF0IGNvdWxkIGNhdXNl
IGEgcm91dGluZyBwcm9jZXNzIHRvIHN0b3AgcGVyZm9ybWluZyBhcwogICBleHBl
Y3RlZCwgYSBzaWduaWZpY2FudCB0ZXN0aW5nIGVmZm9ydCB3aWxsIGJlIG5lZWRl
ZCB0byBpbmNyZWFzZSB0aGUKICAgbGV2ZWwgb2YgYXNzdXJhbmNlIGluIHBvcHVs
YXIgQkdQIGltcGxlbWVudGF0aW9ucy4KCgoKCgoKCgoKCgoKCgoKCgpDb252ZXJ5
LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAxLCAyMDAzICAgICAgICAg
ICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg
QkdQIEF0dGFjayBUcmVlICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDIKCgoy
LjEuNiBSZXNldCBhIFNpbmdsZSBCR1AgU2Vzc2lvbgoKICAgSW4gdGhpcyBhdHRh
Y2ssIHRoZSBhZHZlcnNhcnkgaXMgdHJ5aW5nIHRvIGNhdXNlIGEgY3VycmVudCBC
R1AKICAgc2Vzc2lvbiBpbiB0aGUgZXN0YWJsaXNoZWQgc3RhdGUgdG8gcmVzZXQu
ICBTdWNoIGFuIGF0dGFjayBjb3VsZCBiZQogICBsYXVuY2hlZCBvdmVyIGFuZCBv
dmVyIGFnYWluIHRvIHByZXZlbnQgdHdvIHBlZXJzIGZyb20gcmVsaWFibHkKICAg
ZXhjaGFuZ2luZyByb3V0aW5nIGluZm9ybWF0aW9uLgoKICAgQXR0YWNrOgogICBP
UiAgMS4gU2VuZCBtZXNzYWdlIHRvIHJvdXRlciBjYXVzaW5nIHJlc2V0CiAgICAg
ICBPUiAgMS4gU2VuZCBSU1QgbWVzc2FnZSB0byBUQ1Agc3RhY2sKICAgICAgICAg
ICAyLiBTZW5kIEJHUCBNZXNzYWdlCiAgICAgICAgICAgT1IgIDEuIE5vdGlmeQog
ICAgICAgICAgICAgICAyLiBPcGVuCiAgICAgICAgICAgICAgIDMuIEtlZXBhbGl2
ZQogICAgICAgQU5EIDMuIFRDUCBTZXF1ZW5jZSBudW1iZXIgQXR0YWNrIChBcHBl
bmRpeCBBLjQpCiAgICAgICAyLiBBbHRlciBjb25maWd1cmF0aW9uIHZpYS4gY29t
cHJvbWlzZWQgcm91dGVyIChBcHBlbmRpeCBBLjEpCgogICBJdCBpcyB1bmtub3du
IHdoeSBhbiBhZHZlcnNhcnkgd291bGQgY2hvb3NlIHRvIHJlc2V0IGEgc2Vzc2lv
biB2aWEKICAgU2VjdGlvbiAyLjEuNi4xLjIuICBTaW5jZSB0aGUgcHJlY29uZGl0
aW9ucyBvZiBhdHRhY2sgU2VjdGlvbgogICAyLjEuNi4xLjEgYXJlIHJlcXVpcmVk
IGluIG9yZGVyIHRvIGJlIHN1Y2Nlc3NmdWwuICBBbHNvLCBpdCBzaG91bGQgYmUK
ICAgbm90ZWQgdGhhdCB0aGUgc2VxdWVuY2UgbnVtYmVyIGF0dGFjayBkZXRhaWxl
ZCBpbiBBcHBlbmRpeCBBLjQgaXMgZmFyCiAgIGZyb20gdHJpdmlhbCB0byBwcm9w
ZXJseSBleGVjdXRlLgoKMi4xLjcgU2VuZCBTcG9vZmVkIEJHUCBNZXNzYWdlCgog
ICBBbiBhZHZlcnNhcnkgY291bGQgc2VuZCBhIEJHUCBtZXNzYWdlIHRvIGEgQkdQ
IHNwZWFrZXIgYW5kCiAgIHBvdGVudGlhbGx5IGFsdGVyIHRoZSBiZWhhdmlvciBv
ZiB0aGUgcm91dGluZyBwcm9jZXNzLiAgVGhpcyBhdHRhY2sKICAgaXMgbWFpbmx5
IGRlc2lnbmVkIHRvIGluc2VydCBmYWxzZSBpbmZvcm1hdGlvbiBpbnRvIGEgQkdQ
IHNlc3Npb24sIG9yCiAgIHRvIHJlc2V0IGEgc2Vzc2lvbi4KCiAgIEF0dGFjazoK
CiAgIE9SICAxLiBUQ1AgU2VxdWVuY2UgbnVtYmVyIEF0dGFjayAoQXBwZW5kaXgg
QS40KQogICAgICAgMi4gSW50ZXJjZXB0IG9yIE1vZGlmeSBEYXRhIFRocm91Z2gg
TWFuLWluLXRoZS1NaWRkbGUgKE1JVE0pCiAgICAgICBBdHRhY2sgKEFwcGVuZGl4
IEEuMykKICAgQU5EIDMuIEJ1aWxkIGEgdmFsaWQgQkdQIHBhY2tldAoKICAgVGhp
cyBhdHRhY2sgYXNzdW1lcyB0aGF0IHRoZSBhZHZlcnNhcnkgaXMgYWJsZSB0byBj
YXVzZSB0aGUgQkdQCiAgIHNwZWFrZXIgdG8gYWNjZXB0IGEgbWVzc2FnZSB3aXRo
b3V0IGVzdGFibGlzaGluZyBhIHBlZXJpbmcKICAgcmVsYXRpb25zaGlwLiAgU3Bv
b2ZpbmcgdGhlIG1lc3NhZ2UgaXMgdGhlIHByaW1hcnkgbWVjaGFuaXNtIHRvCiAg
IGFjY29tcGxpc2ggdGhpcy4KCjIuMiBBdHRhY2sgU2NlbmFyaW9zCgogICBUaGUg
YXR0YWNrIHNjZW5hcmlvcyByZXByZXNlbnQgbGFyZ2VyIGdvYWxzIGFuIGFkdmVy
c2FyeSBtYXkgaGF2ZQogICB3aGljaCB1c2UgQkdQIGFzIGEgbWVhbnMgdG8gYWNj
b21wbGlzaCB0aGVtLiAgVGhlc2UgYXR0YWNrcyB1c2UgdGhlCiAgIGF0b21pYyBn
b2FscyBkaXNjdXNzZWQgaW4gU2VjdGlvbiAyLjEgYXMgYSBtZWNoYW5pc20gdG8g
cmVkdWNlIHRoZQogICBkdXBsaWNhdGlvbiBvZiBpbmZvcm1hdGlvbiB3aXRoaW4g
ZWFjaCB0cmVlLgoKCgpDb252ZXJ5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBB
cHJpbCAxLCAyMDAzICAgICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5l
dC1EcmFmdCAgICAgICAgICAgICAgQkdQIEF0dGFjayBUcmVlICAgICAgICAgICAg
ICAgICBPY3RvYmVyIDIwMDIKCgogICBUaGUgZm9sbG93aW5nIGF0dGFjayBzY2Vu
YXJpb3MgYXJlIGRlZmluZWQ6CgogICBvICBEaXNhYmxlIGNyaXRpY2FsIHBvcnRp
b25zIG9mIHRoZSBJbnRlcm5ldCBieSBkaXNydXB0aW5nIEludGVybmV0CiAgICAg
IHJvdXRpbmcgdGFibGVzCgogICBvICBGb3JjZSBhIG11bHRpLWhvbWVkIEFTIHRv
IHVzZSBhbiBhbHRlcm5hdGUgcGF0aCB0by9mcm9tIGFuIG91dHNpZGUKICAgICAg
bmV0d29yayBpbnN0ZWFkIG9mIHRoZSBwcmVmZXJyZWQgcGF0aAoKICAgbyAgRGlz
YWJsZSBhIHNpbmdsZS1ob21lZCBBUwoKICAgbyAgRGlzYWJsZSBhIG11bHRpLWhv
bWVkIEFTCgogICBvICBCbGFja2hvbGUgdHJhZmZpYwoKCgoKCgoKCgoKCgoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKCkNvbnZlcnksIGV0IGFsLiAgICAgICAgICBF
eHBpcmVzIEFwcmlsIDEsIDIwMDMgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQoM
CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBCR1AgQXR0YWNrIFRyZWUgICAg
ICAgICAgICAgICAgIE9jdG9iZXIgMjAwMgoKCjIuMi4xIERpc2FibGUgQ3JpdGlj
YWwgUG9ydGlvbnMgb2YgdGhlIEludGVybmV0IGJ5IERpc3J1cHRpbmcgSW50ZXJu
ZXQKICAgICAgUm91dGluZyBUYWJsZXMKCiAgIENvbW1vbiBjb25jZXJucyByZWdh
cmRpbmcgQkdQIGhhdmUgZGVzY3JpYmVkIHNjZW5hcmlvcyB3aGVyZSBsYXJnZQog
ICBzZWN0aW9uIG9mIHRoZSBJbnRlcm5ldCBiZWNvbWUgdW5yZWFjaGFibGUgZHVl
IHRvIHRoZSBsYWNrIG9mCiAgIHNlY3VyaXR5IGZlYXR1cmVzIGluIEJHUC4gIElu
IHRoZW9yeSwgdGhlIGF0dGFjayBjYW4gYmUgZG9uZSBpbiBvbmUKICAgb2YgdGhy
ZWUgbWFpbiB3YXlzOiBwaHlzaWNhbCBkZXN0cnVjdGlvbiwgc29jaWFsIGVuZ2lu
ZWVyaW5nLCBvcgogICByb3V0aW5nIGF0dGFja3MuCgogICBBdHRhY2s6CiAgIE9S
ICAxLiBQaHlzaWNhbCBEZXN0cnVjdGlvbgogICAgICAgT1IgIDEuIERlc3Ryb3kg
UGVlcmluZyBQb2ludHMKICAgICAgICAgICAyLiBTdHJhdGVnaWMgTGluayBEZXN0
cnVjdGlvbiAoYmFja2hvZSkKICAgICAgIDIuIFNvY2lhbCBFbmdpbmVlcmluZwog
ICAgICAgMy4gUm91dGluZyBBdHRhY2tzCiAgICAgICBPUiAgMS4gQWx0ZXIgZ2xv
YmFsIEludGVybmV0IHJvdXRpbmcgdGFibGUKICAgICAgICAgICBPUiAgMS4gSW5z
ZXJ0IHVuYXV0aCBwcmVmaXggaW50byByb3V0ZSB0YWJsZSAoU2VjdGlvbiAyLjEu
MykKICAgICAgICAgICAgICAgMi4gRXN0YWJsaXNoIHVuYXV0aG9yaXplZCBCR1Ag
c2Vzc2lvbiB3aXRoIHBlZXIgKFNlY3Rpb24gMi4xLjIpCiAgICAgICAgICAgQU5E
IDMuIEVuc3VyZSBwcm9wYWdhdGlvbiBpbiBzcGl0ZSBvZiBwcmVmaXggZmlsdGVy
aW5nCiAgICAgICAgICAgICAgIDQuIFJlcGVhdCBmb3IgQVNzIGF0IG11bHRpcGxl
IElTUAogICAgICAgICAgIDIuIERpc2FibGUgY3JpdGljYWwgY29yZSByb3V0ZXJz
CiAgICAgICAgICAgT1IgIDEuIFJvdXRlciBvdmVybG9hZCBsZWFkaW5nIHRvIGNy
YXNoCiAgICAgICAgICAgICAgIE9SICAxLiBERG9TCiAgICAgICAgICAgICAgICAg
ICAyLiBXb3JtCiAgICAgICAgICAgICAgICAgICAzLiBMb29wcwogICAgICAgICAg
ICAgICAgICAgNC4gQ2hhbmdlIHByZWZpeCBwYXRocyAoU2VjdGlvbiAyLjEuNCkK
ICAgICAgICAgICAgICAgMi4gRXhwbG9pdCBwZXJ2YXNpdmUgaW1wbGVtZW50YXRp
b24gZmxhdyBvbiByb3V0ZXIKICAgICAgICAgICAgICAgT1IgIDEuIE1lbW9yeSBl
eGhhdXN0aW9uCiAgICAgICAgICAgICAgICAgICAyLiBDUFUgZXhoYXVzdGlvbgog
ICAgICAgICAgICAgICAgICAgMy4gTWFnaWMgcGFja2V0IChidWZmZXIgb3ZlcmZs
b3csIGV0Yy4pCiAgICAgICAgICAgICAgIDMuIERvUyBCR1AgUHJvY2VzcyAoU2Vj
dGlvbiAyLjEuNSkKICAgICAgICAgICAgICAgNC4gRXhwbG9pdCByb3V0aW5nIHRh
YmxlIG1lbW9yeSBsaW1pdGF0aW9ucwogICAgICAgICAgICAgICBBTkQgMS4gRmlu
ZCB1bmZpbHRlcmVkIHJvdXRpbmcgZGlzdHJpYnV0aW9uIHBvaW50CiAgICAgICAg
ICAgICAgICAgICAyLiBTZW5kIHRoZSBtb3N0IHNwZWNpZmljIHJvdXRlcyB0aGF0
IHdpbGwgYmUgYWNjZXB0ZWQgYW5kCiAgICAgICAgICAgICAgICAgICBwcm9wYWdh
dGVkIHVwc3RyZWFtCgogICBTaW5jZSB0aGlzIEktRCBpcyBmb2N1c2VkIG9uIEJH
UCwgdGhpcyB0cmVlIGVsYWJvcmF0ZXMgb24gdGhlIHJvdXRpbmcKICAgcmVsYXRl
ZCBwb3J0aW9uIG9mIHRoZSB0cmVlLiAgQW55IG9mIHRoZSBhYm92ZSBsaXN0ZWQg
YXR0YWNrIGdvYWxzCiAgIGFyZSBub24tdHJpdmlhbCBhbmQgd291bGQgcmVxdWly
ZSBleHRlbnNpdmUgY29vcmRpbmF0aW9uIGFuZAogICBwb3RlbnRpYWxseSBpbnNp
ZGVyIGludm9sdmVtZW50LgoKCgoKCgoKCgoKCkNvbnZlcnksIGV0IGFsLiAgICAg
ICAgICBFeHBpcmVzIEFwcmlsIDEsIDIwMDMgICAgICAgICAgICAgICAgIFtQYWdl
IDEzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBCR1AgQXR0YWNrIFRy
ZWUgICAgICAgICAgICAgICAgIE9jdG9iZXIgMjAwMgoKCjIuMi4yIEZvcmNlIGEg
TXVsdGktaG9tZWQgQVMgdG8gdXNlIGFuIEF0ZXJuYXRlIFBhdGggdG8vZnJvbSBh
biBPdXRzaWRlCiAgICAgIE5ldHdvcmsgSW5zdGVhZCBvZiB0aGUgUHJlZmVycmVk
IFBhdGgKCiAgIEFub3RoZXIgd2F5IHRoYXQgQkdQIGNhbiBiZSBjb21wcm9taXNl
ZCBpcyBieSBmb3JjaW5nIGEgbXVsdGlob21lZCBBUwogICB0byBjaGFuZ2UgdGhl
IG5vcm1hbCBwYXRoIHByZWZlcmVuY2UuICBUaGlzIGNhbiByZXN1bHQgaW4gdGhl
IGVudGlyZQogICBBUyB1c2luZyBhIHN1Ym9wdGltYWwgcGF0aCwgb3IgdXNpbmcg
bGlua3MgdGhhdCBjb3N0IHRoZSBBUyBtb3JlCiAgIG1vbmV5LiAgSW4gdGhlIGV4
dHJlbWUgY2FzZSwgY2hhbmdpbmcgdGhlIHBhdGggcHJlZmVyZW5jZSBjb3VsZCBj
YXVzZQogICBhIGxpbmsgdG8gYmVjb21lIG92ZXJzdWJzY3JpYmVkIGFuZCByZXN1
bHQgaW4gdGhlIGxvc3Mgb2YgZGF0YSBvcgogICBjb250cm9sIHRyYWZmaWMuCgog
ICBBdHRhY2s6CiAgIE9SICAxLiBGb3JjZSB0cmFmZmljIGZyb20gb3V0c2lkZSBu
ZXR3b3JrIHRvIHVzZSBhbHRlcm5hdGUgcGF0aAogICAgICAgT1IgIDEuIExvd2Vy
IHByZWZlcmVuY2Ugb2YgcHJlZmVycmVkIHBhdGgKICAgICAgICAgICBPUiAgMS4g
Q2hhbmdlIHBhdGggcHJlZmVyZW5jZSBvZiBhIHByZWZpeCAoU2VjdGlvbiAyLjEu
NCkKICAgICAgICAgICAgICAgMi4gRG9TIEJHUCBQcm9jZXNzIChTZWN0aW9uIDIu
MS41KQogICAgICAgICAgICAgICAzLiBSZXNldCBCR1AgU2Vzc2lvbiAoU2VjdGlv
biAyLjEuNikKICAgICAgICAgICAgICAgNC4gQ29tcHJvbWlzZSBSb3V0ZXIgKEFw
cGVuZGl4IEEuMSkKICAgICAgICAgICAyLiBSYWlzZSBwcmVmZXJlbmNlIG9mIGFs
dGVybmF0ZSBwYXRoIChTZWN0aW9uIDIuMS40KQogICAgICAgMi4gRm9yY2UgdHJh
ZmZpYyBnb2luZyB0byBvdXRzaWRlIG5ldHdvcmsgdG8gdXNlIGFsdGVybmF0ZSBw
YXRoCiAgICAgICBPUiAgMS4gTG93ZXIgcHJlZmVyZW5jZSBvZiBwcmVmZXJyZWQg
cGF0aAogICAgICAgICAgIE9SICAxLiBDaGFuZ2UgcGF0aCBwcmVmZXJlbmNlIG9m
IGEgcHJlZml4IChTZWN0aW9uIDIuMS40KQogICAgICAgICAgICAgICAyLiBEb1Mg
QkdQIFByb2Nlc3MgKFNlY3Rpb24gMi4xLjUpCiAgICAgICAgICAgICAgIDMuIFJl
c2V0IEJHUCBTZXNzaW9uIChTZWN0aW9uIDIuMS42KQogICAgICAgICAgICAgICA0
LiBDb21wcm9taXNlIFJvdXRlciAoQXBwZW5kaXggQS4xKQogICAgICAgICAgIDIu
IFJhaXNlIHByZWZlcmVuY2Ugb2YgYWx0ZXJuYXRlIHBhdGggKFNlY3Rpb24gMi4x
LjQpCgoKMi4yLjMgRGlzYWJsZSBhIFNpbmdsZS1ob21lZCBBUwoKICAgVGhpcyBh
dHRhY2sgaXMgYSBzbWFsbGVyIHNjYWxlIHZlcnNpb24gb2YgdGhlIGF0dGFjayBk
ZXNjcmliZWQgaW4KICAgU2VjdGlvbiAyLjIuMS4gIEhlcmUgdGhlIGFkdmVyc2Fy
eSBuZWVkIG9ubHkgcHJldmVudCBhIHNpbmdsZS1ob21lZAogICBBUyBmcm9tIGNv
bW11bmljYXRpbmcgd2l0aCB0aGUgcmVzdCBvZiB0aGUgSW50ZXJuZXQuCgogICBB
dHRhY2s6CiAgIE9SICAxLiBEaXNhYmxlIHByb3ZpZGVyIGxpbmsKICAgICAgIE9S
ICAxLiBQaHlzaWNhbCBsaW5rIGRlc3RydWN0aW9uCiAgICAgICAgICAgMi4gU29j
aWFsIGVuZ2luZWVyaW5nCiAgICAgICAgICAgMy4gVHVybiBvZmYgdGhlIGxpbmsg
YnkgY29tcHJvbWlzaW5nIHRoZSB1cHN0cmVhbQogICAgICAgICAgIHJvdXRlciAo
QXBwZW5kaXggQS4xKQogICAgICAgMi4gRGlzYWJsZSBBUyB2aWEgcm91dGluZyBw
cm90b2NvbCBhdHRhY2sKICAgICAgIE9SICAxLiBEb1MgQkdQIFByb2Nlc3MgKFNl
Y3Rpb24gMi4xLjUpCiAgICAgICAgICAgMi4gUmVzZXQgQkdQIFNlc3Npb24gKFNl
Y3Rpb24gMi4xLjYpCiAgICAgICAgICAgMy4gQ29tcHJvbWlzZSByb3V0ZXIgKEFw
cGVuZGl4IEEuMSkKCiAgIEFueSBjcmFzaGVzIG9yIHJlc2V0cyBpbml0aWF0ZWQg
YnkgdGhlIGFkdmVyc2FyeSBpbiBTZWN0aW9uIDIuMi4zLjIuMQogICBvciAuMi4y
IHdvdWxkIHVzdWFsbHkgcmVxdWlyZSB0aGUgYXR0YWNrIGJlIGdlbmVyYXRlZCBj
b250aW51YWxseSB0bwogICBwcmV2ZW50IHRoZSByb3V0ZXIgZnJvbSByZWVzdGFi
bGlzaGluZyBwcm9wZXIgY29tbXVuaWNhdGlvbnMgd2l0aCBpdHMKICAgcGVlci4K
CgoKQ29udmVyeSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMSwgMjAw
MyAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJhZnQgICAg
ICAgICAgICAgIEJHUCBBdHRhY2sgVHJlZSAgICAgICAgICAgICAgICAgT2N0b2Jl
ciAyMDAyCgoKMi4yLjQgRGlzYWJsZSBhIE11bHRpLWhvbWVkIEFTCgogICBUaGlz
IGF0dGFjayBpcyBhIGNvbWJpbmF0aW9uIG9mIFNlY3Rpb24gMi4yLjMgYW5kIFNl
Y3Rpb24gMi4yLjEuICBUaGUKICAgbnVtYmVyIG9mIGxpbmtzIHRoZSBBUyB1bmRl
ciBhdHRhY2sgaGFzIHdpdGggb3RoZXIgQVNzIHdpbGwgZGljdGF0ZQogICB0aGUg
dHlwZSBvZiBhdHRhY2sgbmVjZXNzYXJ5IHRvIG1vc3QgZWZmaWNpZW50bHkgYWNo
aWV2ZSB0aGUKICAgYWR2ZXJzYXJ5J3Mgb2JqZWN0aXZlcy4gIFRoaXMgYXR0YWNr
IHNlcXVlbmNlLCBpbiBwYXJ0aWN1bGFyLCB3b3VsZAogICBiZW5lZml0IGZyb20g
ZnVydGhlciB0ZXN0aW5nIHRocm91Z2ggbGFiIHNpbXVsYXRpb24gYW5kIHRoZQog
ICBhc3NvY2lhdGlvbiBvZiBhdHRyaWJ1dGVzIHRvIGVhY2ggb2YgdGhlIGxlYWYg
bm9kZXMuCgogICBBdHRhY2s6CiAgIE9SICAxLiBEaXNhYmxlIGxpbmtzIDEuLi5O
IChTZWN0aW9uIDIuMi4zKQogICAgICAgMi4gRGlzYWJsZSBjcml0aWNhbCBwb3J0
aW9ucyBvZiB0aGUgQVNzIG5ldHdvcmsgKFNlY3Rpb24gMi4yLjEpCgogICBUbyBz
dW1tYXJpemUsIHRoZSBhZHZlcnNhcnkgY2FuIGVpdGhlciBjb25zaWRlciB0aGUg
YXR0YWNrIGxpa2UKICAgZGlzYWJsaW5nIHNldmVyYWwgaW5kaXZpZHVhbGx5IGNv
bm5lY3RlZCBzaW5nbGUtaG9tZWQgQVNzLCBvciBhcyBhCiAgIHNtYWxsZXIgdmVy
c2lvbiBvZiB0aGUgSW50ZXJuZXQgYXMgYSB3aG9sZS4KCjIuMi41IEJsYWNraG9s
ZSBUcmFmZmljCgogICBCR1AgY2FuIGJlIHVzZWQgdG8gYmxhY2tob2xlIHRyYWZm
aWMuICBJZiBhbiBhZHZlcnNhcnkgaGFzIGFjY2VzcyB0bwogICB0aGUgZm9yd2Fy
ZGluZyBwYXRoIG9mIHRoZSB0YXJnZXQgc3lzdGVtLCBoZSBjYW4gcXVpZXRseSBk
aXNjYXJkIHRoZQogICB0cmFmZmljIHdoaWxlIGNvbnRpbnVpbmcgdG8gZnVuY3Rp
b24gYXMgYSBCR1Agc3BlYWtlci4gIFRoZSBhZHZlcnNhcnkKICAgY291bGQgYWxz
byBhZmZlY3QgdGhlIEJHUCB0YWJsZXMgb2YgaGlzIG5laWdoYm9ycyB1c2luZyBC
R1AKICAgYWR2ZXJ0aXNlbWVudHMgc28gdGhhdCB0aGV5IHdvdWxkIHNlbmQgdHJh
ZmZpYyB0byB0aGUgaW5jb3JyZWN0CiAgIGRlc3RpbmF0aW9uLiAgT25lIHdheSB0
aGlzIGNvdWxkIGJlIGFjY29tcGxpc2hlZCBpcyB0aHJvdWdoIHRoZQogICB1bmF1
dGhvcml6ZWQgb3JpZ2luYXRpb24gb2YgYSBwcmVmaXguCgogICBBdHRhY2s6CiAg
IE9SICAxLiBEcm9wIHRyYWZmaWMgb24gdGhlIHdpcmUgaXRzZWxmIChTZWN0aW9u
IDIuMS40LjEuMikKICAgICAgIDIuIERyb3AgdHJhZmZpYyBvbiBhIHJvdXRlciAo
d2l0aG91dCB1c2luZyBCR1ApCiAgICAgICBPUiAgMS4gUG9saWN5IHJvdXRlIHRv
IG51bGwKICAgICAgICAgICAyLiBTdGF0aWMgcm91dGUgdG8gbnVsbAogICAgICAg
QU5EIDMuIEdhaW4gYWRtaW5pc3RyYXRpdmUgYWNjZXNzIHRvIHRoZSByb3V0ZXIK
ICAgICAgICAgICBPUiAgMS4gUm91Z2Ugcm91dGVyCiAgICAgICAgICAgICAgIDIu
IE1pc2NvbmZpZ3VyZWQgcm91dGVyCiAgICAgICAgICAgICAgIDMuIENvbXByb21p
c2Ugcm91dGVyIChBcHBlbmRpeCBBLjEpCiAgICAgICAzLiBEcm9wIHRyYWZmaWMg
dXNpbmcgYm9ndXMgQkdQIG1lc3NhZ2VzCiAgICAgICBPUiAgMS4gRXN0YWJsaXNo
IHVuYXV0aG9yaXplZCBCR1Agc2Vzc2lvbiB3aXRoIHBlZXIgKFNlY3Rpb24gMi4x
LjIpCiAgICAgICAgICAgMi4gT3JpZ2luYXRlIHVuYXV0aG9yaXplZCBwcmVmaXgv
YXR0cmlidXRlIChTZWN0aW9uIDIuMS4zKQogICAgICAgICAgIDMuIENvbXByb21p
c2Ugcm91dGVyIChBcHBlbmRpeCBBLjEpCgoKCgoKCgoKCgoKQ29udmVyeSwgZXQg
YWwuICAgICAgICAgIEV4cGlyZXMgQXByaWwgMSwgMjAwMyAgICAgICAgICAgICAg
ICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIEJHUCBB
dHRhY2sgVHJlZSAgICAgICAgICAgICAgICAgT2N0b2JlciAyMDAyCgoKMy4gVGVz
dGluZyBDb25zaWRlcmF0aW9ucwoKICAgQkdQIGRlc2lnbiBkZWNpc2lvbnMgKHN1
Y2ggYXMgdGhlIHNlbGVjdGlvbiBvZiBUQ1AgYXMgdGhlIHRyYW5zcG9ydAogICBw
cm90b2NvbCkgY2VydGFpbmx5IGltcGFjdCB0aGUgc2VjdXJpdHkgb2YgdGhlIElu
dGVybmV0IHJvdXRpbmcKICAgaW5mcmFzdHJ1Y3R1cmUuICBIb3dldmVyLCBvcGVy
YXRpb25hbCBjb25zaWRlcmF0aW9ucyBhbmQgdGhlIHF1YWxpdHkKICAgb2YgdGhl
IEJHUCBpbXBsZW1lbnRhdGlvbnMgbWF5IGhhdmUgYSBncmVhdGVyIGltcGFjdCBv
biBJbnRlcm5ldAogICBzZWN1cml0eS4gIFRlc3RpbmcgKGFzIHRoZSB1bHRpbWF0
ZSBkZXRlcm1pbmF0aW9uIG9mIHJlbGF0aXZlCiAgIGRpZmZpY3VsdHkgb2YgYW4g
YXR0YWNrKSBpcyBlc3BlY2lhbGx5IGNyaXRpY2FsIGZvciB0aHJlYXQvCiAgIHZ1
bG5lcmFiaWxpdHkgYW5hbHlzZXMgdGhhdCB1c2UgYXR0YWNrIHRyZWVzLiAgVGhp
cyBpcyBiZWNhdXNlIHRoZQogICBsaWtlbGlob29kLCBjcml0aWNhbGl0eSwgYW5k
IGFjY2VzcyByZXF1aXJlbWVudHMgb2YgbGVhZiBub2RlcwogICBkZXRlcm1pbmUg
d2hpY2ggYXJlIHRoZSBtb3N0IGxpa2VseSBwYXRocyB0aHJvdWdoIHRoZSB0cmVl
LgoKICAgQXMgZGlzY3Vzc2VkIGVhcmxpZXIsIHRlc3QgcHJvY2VkdXJlcyBhbmQg
cmVzdWx0cyBjb3VsZCBiZSByZWxlYXNlZAogICBpbiBhIHN1YnNlcXVlbnQgSS1E
LiAgU3VjaCBhbmFseXNpcyBzaG91bGQgYmUgZW52aXJvbm1lbnQgc3BlY2lmaWMu
CiAgIEZvciBleGFtcGxlLCB0aGUgYW5hbHlzaXMgb2YgdGhpcyBhdHRhY2sgdHJl
ZSB3aWxsIGJlIGZ1bmRhbWVudGFsbHkKICAgZGlmZmVyZW50IGZvciBJbnRlcm5l
dCBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmtzIGFuZCBlbnRlcnByaXNlCiAgIG5l
dHdvcmtzLiAgVGhlIHNhbWUgY2FuIGFsc28gYmUgc2FpZCBvZiB0aGUgZGlmZmVy
ZW5jZXMgaW4gYXR0YWNrCiAgIG1ldGhvZHMgYmV0d2VlbiBhIHJlbW90ZSBibGlu
ZCBhZHZlcnNhcnkgYW5kIGEgdHJ1c3RlZCBpbnNpZGVyLgoKCgoKCgoKCgoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgpDb252ZXJ5LCBldCBhbC4gICAgICAgICAgRXhw
aXJlcyBBcHJpbCAxLCAyMDAzICAgICAgICAgICAgICAgICBbUGFnZSAxNl0KDApJ
bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQkdQIEF0dGFjayBUcmVlICAgICAg
ICAgICAgICAgICBPY3RvYmVyIDIwMDIKCgpSZWZlcmVuY2VzCgogICBbMV0gIFNj
aG5laWVyLCBCLiwgIkF0dGFjayBUcmVlcyIsIERlY2VtYmVyIDE5OTkuCgogICBb
Ml0gIE1vb3JlLCBBLiwgRWxsaXNvbiwgUi4gYW5kIFIuIExpbmdlciwgIkF0dGFj
ayBNb2RlbGluZyBmb3IKICAgICAgICBJbmZvcm1hdGlvbiBTZWN1cml0eSBhbmQg
U3Vydml2YWJpbGl0eSIsIE1hcmNoIDIwMDEuCgogICBbM10gIE11cnBoeSwgUy4s
ICJCR1AgU2VjdXJpdHkgVnVsbmVyYWJpbGl0aWVzIEFuYWx5c2lzIiwgRmVicnVh
cnkKICAgICAgICAyMDAyLgoKICAgWzRdICBTaGlyZXksIFIuLCAiSW50ZXJuZXQg
U2VjdXJpdHkgR2xvc3NhcnksIFJGQyAyODI4IiwgRGVjZW1iZXIKICAgICAgICAx
OTk5LgoKICAgWzVdICBIZWZmZXJuYW4sIEEuLCAiUHJvdGVjdGlvbiBvZiBCR1Ag
U2Vzc2lvbnMgdmlhIHRoZSBUQ1AgTUQ1CiAgICAgICAgU2lnbmF0dXJlIE9wdGlv
biwgUkZDIDIzODUiLCBBdWd1c3QgMTk5OC4KCiAgIFs2XSAgQmVsbG92aW4sIFMu
LCAiRGVmZW5kaW5nIEFnYWluc3QgU2VxdWVuY2UgTnVtYmVyIEF0dGFja3MsIFJG
QwogICAgICAgIDE5NDgiLCBNYXkgMTk5Ni4KCiAgIFs3XSAgTmV3c2hhbSwgVC4s
ICJUaGUgUHJvYmxlbSBXaXRoIFJhbmRvbSBJbmNyZW1lbnRzIiwgTWFyY2ggMjAw
MS4KCiAgIFs4XSAgUmVraHRlciwgWS4gYW5kIFQuIExpLCAiQSBCb3JkZXIgR2F0
ZXdheSBQcm90b2NvbCA0IChCR1AtNCksIFJGQwogICAgICAgIDE3NzEiLCBNYXJj
aCAxOTk1LgoKCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgU2VhbiBDb252ZXJ5CiAg
IENpc2NvIFN5c3RlbXMsIEluYy4KICAgMTcwIFcuIFRhc21hbiBEci4KICAgU2Fu
IEpvc2UsIENBICA5NTEzNAogICBVUwoKICAgUGhvbmU6ICsxIDQwOCA4NTMgODc1
MwogICBFTWFpbDogc2VhbkBjaXNjby5jb20KCgogICBEYXZpZCBDb29rCiAgIENp
c2NvIFN5c3RlbXMsIEluYy4KICAgNzAyNSBLaXQgQ3JlZWsgUmQuCiAgIFJlc2Vh
cmNoIFRyaWFuZ2xlIFBhcmssIE5DICAyNzcwOQogICBVUwoKICAgUGhvbmU6ICsx
IDkxOSAzOTItODc3MgogICBFTWFpbDogZGFjb29rQGNpc2NvLmNvbQoKCgoKCgpD
b252ZXJ5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAxLCAyMDAzICAg
ICAgICAgICAgICAgICBbUGFnZSAxN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg
ICAgICAgQkdQIEF0dGFjayBUcmVlICAgICAgICAgICAgICAgICBPY3RvYmVyIDIw
MDIKCgogICBNYXR0aGV3IEZyYW56CiAgIENpc2NvIFN5c3RlbXMsIEluYy4KICAg
MTI1MTUgUmVzZWFyY2ggQmx2ZC4KICAgQXVzdGluLCBUWCAgNzg3NTkKICAgVVMK
CiAgIFBob25lOiArMSA1MTIgMzc4IDE2NDgKICAgRU1haWw6IG1mcmFuekBjaXNj
by5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK
CkNvbnZlcnksIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFwcmlsIDEsIDIwMDMg
ICAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0ICAgICAg
ICAgICAgICBCR1AgQXR0YWNrIFRyZWUgICAgICAgICAgICAgICAgIE9jdG9iZXIg
MjAwMgoKCkFwcGVuZGl4IEEuIFN1cHBvcnRpbmcgQXRvbWljIEdvYWxzCgpBLjEg
Q29tcHJvbWlzZSBSb3V0ZXIKCiAgIEFsdGhvdWdoIG91dHNpZGUgdGhlIHNjb3Bl
IG9mIHJvdXRpbmcgcHJvdG9jb2wgc2VjdXJpdHksIGlmIHRoZQogICByb3V0ZXJz
IHRoZW1zZWx2ZXMgY2FuIGJlIGNvbXByb21pc2VkIHRoZSByb3V0aW5nIGluZnJh
c3RydWN0dXJlIGNhbgogICBiZSBzdWJ2ZXJ0ZWQuCgoKICAgQXR0YWNrOgogICBP
UiAgMS4gR2FpbiBwaHlzaWNhbCBhY2Nlc3MgdG8gcm91dGVyCiAgICAgICBBTkQg
MS4gR2FpbiBwaHlzaWNhbCBhY2Nlc3MgdG8gZGF0YSBjZW50ZXIKICAgICAgICAg
ICAyLiBHdWVzcyBwYXNzd29yZHMKICAgICAgIE9SICAzLiBQZXJmb3JtIHBhc3N3
b3JkIHJlY292ZXJ5CiAgICAgICAyLiBHYWluIGxvZ2ljYWwgYWNjZXNzIHRvIHJv
dXRlcgogICAgICAgT1IgIDEuIENvbXByb21pc2UgbmV0d29yayBtYW5hZ2VyIHN5
c3RlbQogICAgICAgICAgIE9SICAxLiBFeHBsb2l0IGFwcGxpY2F0aW9uIGxheWVy
IHZ1bG5lcmFiaWxpdHkgaW4gc2VydmVyCiAgICAgICAgICAgICAgIDIuIEhpamFj
ayBtYW5hZ2VtZW50IHRyYWZmaWMKICAgICAgICAgICAyLiBMb2dpbiB0byByb3V0
ZXIKICAgICAgICAgICBPUiAgMS4gR3Vlc3MgcGFzc3dvcmQKICAgICAgICAgICAg
ICAgMi4gU25pZmYgcGFzc3dvcmQKICAgICAgICAgICAgICAgMy4gSGlqYWNrIG1h
bmFnZW1lbnQgc2Vzc2lvbgogICAgICAgICAgICAgICBPUiAxLiBUZWxuZXQKICAg
ICAgICAgICAgICAgICAgMi4gU1NICiAgICAgICAgICAgICAgICAgIDMuIFNOTVAK
ICAgICAgICAgICAgICAgMy4gU29jaWFsIGVuZ2luZWVyCiAgICAgICAgICAgMy4g
RXhwbG9pdCBpbXBsZW1lbnRhdGlvbiBmbGF3IGluIHByb3RvY29sL2FwcGxpY2F0
aW9uIGluIHJvdXRlcgogICAgICAgICAgIE9SICAxLiBUZWxuZXQKICAgICAgICAg
ICAgICAgMi4gU1NICiAgICAgICAgICAgICAgIDMuIFNOTVAKICAgICAgICAgICAg
ICAgNC4gUHJvcHJpZXRhcnkgbWFuYWdlbWVudCBwcm90b2NvbAoKCiAgIFRoZSBh
YmlsaXR5IG9mIGFuIGFkdmVyc2FyeSB0byBjb21wcm9taXNlIGEgQkdQIHNwZWFr
ZXIgaXMgbGFyZ2VseQogICBkZXBlbmRlbnQgb24gb3BlcmF0aW9uYWwgYmVzdCBw
cmFjdGljZXM6IHVzZSBvZiBzZWN1cmUgbWFuYWdlbWVudAogICBwcm90b2NvbHMg
YW5kIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMsIHVzZSBvZiBpbnRydXNpb24g
ZGV0ZWN0aW9uCiAgIHN5c3RlbXMsIGV0Yy4KCgoKCgoKCgoKCgoKCgpDb252ZXJ5
LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAxLCAyMDAzICAgICAgICAg
ICAgICAgICBbUGFnZSAxOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg
QkdQIEF0dGFjayBUcmVlICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDIKCgpB
LjIgRGVuaWFsIG9mIFNlcnZpY2UgKERvUykgUm91dGVyCgogICBEZW5pYWwvZGVn
cmFkYXRpb24gb2Ygc2VydmljZSBhdHRhY2tzIGNhbiBiZSBjb25kdWN0ZWQgYWdh
aW5zdAogICBuZXR3b3JrIGRldmljZXMgdXNpbmcgYSB2YXJpZXR5IG9mIHdlbGwt
a25vd24gdGVjaG5pcXVlcy4KCiAgIEF0dGFjazoKICAgT1IgIDEuIFBoeXNpY2Fs
IGRlc3RydWN0aW9uIG9mIHJvdXRlcgogICAgICAgMi4gTGluayBsYXllciBhdHRh
Y2tzCiAgICAgICBPUiAgMS4gUHJvdG9jb2wgYXR0YWNrIHVzaW5nIGxpbmsgbGF5
ZXIgcHJvdG9jb2wKICAgICAgICAgICAyLiBQaHlzaWNhbCBsaW5rIGF0dGFjawog
ICAgICAgMy4gQVJQIGF0dGFja3MKICAgICAgIDQuIElQIGF0dGFja3MKICAgICAg
IE9SICAxLiBJQ01QIE1lc3NhZ2UKICAgICAgICAgICBPUiAxLiBGbG9vZGluZwog
ICAgICAgICAgICAgIDIuIE1hbGZvcm1lZAogICAgICAgICAgIDIuIElQIEZyYWdt
ZW50YXRpb24gQXR0YWNrCiAgICAgICA1LiBVRFAgYXR0YWNrcwogICAgICAgNi4g
VENQIGF0dGFja3MKICAgICAgIE9SICAxLiBTWU4gRmxvb2QKICAgICAgICAgICAy
LiBDb25uZWN0KCkKICAgICAgICAgICAzLiBMQVNUX0FDSwogICAgICAgICAgIDQu
IE5ldy91bmRpc2NvdmVyZWQgRG9TIGFnYWluc3QgVENQCiAgICAgICA3LiBBcHBs
aWNhdGlvbi1MYXllciBEb1MKICAgICAgIE9SICAxLiBUZWxuZXQKICAgICAgICAg
ICAyLiBTU0gKICAgICAgICAgICAzLiBTTk1QCiAgICAgICAgICAgNC4gT3RoZXIg
YXBsaWNhdGlvbiBsYXllciBwcm90b2NvbAoKICAgQWxsIG9mIHRoZXNlIGF0dGFj
a3MgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIEJHUCBkZXNpZ24gb3IKICAgaW1w
bGVtZW50YXRpb24gYW5kIHVsdGltYXRlbHkgZGVwZW5kIG9uIHRoZSBzdXJ2aXZh
YmlsaXR5IG9mIHRoZQogICByb3V0aW5nIGRldmljZSBpdHNlbGYsIGl0cyBhYmls
aXR5IHdpdGhzdGFuZCBhdHRhY2ssIGFuZCB0aGUgcHJvcGVyCiAgIGNvbmZpZ3Vy
YXRpb24gb2YgdGhlIGRldmljZSBiYXNlZCBvbiBwdWJsaXNoZWQgYmVzdC1wcmFj
dGljZXMuCgoKCgoKCgoKCgoKCgoKCgoKCgpDb252ZXJ5LCBldCBhbC4gICAgICAg
ICAgRXhwaXJlcyBBcHJpbCAxLCAyMDAzICAgICAgICAgICAgICAgICBbUGFnZSAy
MF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgQkdQIEF0dGFjayBUcmVl
ICAgICAgICAgICAgICAgICBPY3RvYmVyIDIwMDIKCgpBLjMgSW50ZXJjZXB0IG9y
IE1vZGlmeSBEYXRhIFRocm91Z2ggTWFuLWluLXRoZS1NaWRkbGUgKE1JVE0pIEF0
dGFjawoKICAgTWFuIGluIHRoZSBtaWRkbGUgYXR0YWNrcyBhZ2FpbnN0IGNyeXB0
b2dyYXBoaWMgcHJvdG9jb2xzIG9yCiAgIGFwcGxpY2F0aW9uIGxheWVyIHByb3Rv
Y29scyBhbGxvdyBhbiBhZHZlcnNhcnkgdG8gZWZmZWN0aXZlbHkgcHJveHkKICAg
Y29tbXVuaWNhdGlvbiBiZXR3ZWVuIHR3byBwYXJ0aWVzIGFsbG93aW5nIGFueSBk
YXRhIHRvIGVpdGhlciBiZSByZWFkCiAgIG9yIGFsdGVyZWQuICBBbHRob3VnaCBu
b3QgaW1wb3NzaWJsZSB0byBjb25kdWN0IGFmdGVyIGEgc2Vzc2lvbiBoYXMKICAg
YmVlbiBlc3RhYmxpc2hlZCwgdGhlIGF0dGFjayBpcyBlYXNpZXIgZG9uZSBwcmlv
ciB0byBzZXNzaW9uCiAgIGluaXRpYXRpb24uCgogICBBdHRhY2s6CiAgIEFORCAx
LiBHYWluIHdyaXRlIGFjY2VzcyB0byBuZXR3b3JrIHNlZ21lbnQgb2Ygb25lIG9y
IG1vcmUgcGVlcnMKICAgICAgIDIuIFN1YnZlcnQgYWRkcmVzcyBpbmZyYXN0cnVj
dHVyZQogICAgICAgT1IgIDEuIEFSUC9NQUMgc3Bvb2ZpbmcKICAgICAgICAgICAy
LiBETlMgc3Bvb2ZpbmcKICAgICAgIDMuIFByb3h5IEJHUCBzZXNzaW9ucyBiZXR3
ZWVuIEJHUCBzcGVha2VycwoKICAgVGhlIGdvYWxzIG9mIGEgTUlUTSBhdHRhY2sg
YWdhaW5zdCBCR1AgYXJlIGFsbW9zdCBpZGVudGljYWwgdG8gYSBUQ1AKICAgU2Vx
dWVuY2UgTnVtYmVyIEF0dGFjayAoQXBwZW5kaXggQS40KSBhZ2FpbnN0IGEgQkdQ
IHNlc3Npb24uICBETlMKICAgU3Bvb2ZpbmcgbWF5IGJlIHVubGlrZWx5IGJlY2F1
c2UgbWFueSBpbXBsZW1lbnRhdGlvbnMvY29uZmlndXJhdGlvbnMKICAgYXJlIHVu
bGlrZWx5IHRvIHVzZSBob3N0bmFtZXMgaW4gcm91dGVyIGNvbmZpZ3VyYXRpb25z
LgoKQS40IFRDUCBTZXF1ZW5jZSBOdW1iZXIgQXR0YWNrCgogICBUQ1Agc3VmZmVy
cyBmcm9tIHdlbGwta25vd24gZGVzaWduIGZsYXdzIHdoaWNoIG1ha2UgaXQgcG9z
c2libGUgdG8KICAgaGlqYWNrIG9yIHRlcm1pbmF0ZSBhcHBsaWNhdGlvbnMgdGhh
dCB1c2UgaXQgYXMgdGhlaXIgdHJhbnNwb3J0CiAgIHByb3RvY29sLgoKICAgQXR0
YWNrOgogICBPUiAgMS4gQmxpbmQgU3Bvb2ZpbmcgQXR0YWNrCiAgICAgICBBTkQg
IDEuIEd1ZXNzIHNlcXVlbmNlIG51bWJlciB1c2UgYnkgYSBCR1Agc3BlYWtlcgog
ICAgICAgICAgICAyLiBJbmplY3QgdmFsaWQgQkdQIG1lc3NhZ2UKICAgICAgIDIu
IE5vbi1CbGluZCBTcG9vZmluZyBhdHRhY2sKICAgICAgIEFORCAgMS4gU25pZmYg
VHJhZmZpYyAoQXBwZW5kaXggQS41KQogICAgICAgICAgICAyLiBJbmplY3QgdmFs
aWQgQkdQIG1lc3NhZ2UgYmFzZWQgb24gc2VxdWVuY2UgbnVtYmVycwoKICAgQWRl
cXVhdGUgaW5pdGlhbCBzZXF1ZW5jZSBudW1iZXIgcmFuZG9tbmVzcyBbNl0gc2hv
dWxkIG1pdGlnYXRlIG1vc3QKICAgYmxpbmQgYXR0YWNrcywgYWx0aG91Z2ggc29t
ZSByZXNlYXJjaCBbN10gc3VnZ2VzdHMgYmxpbmQgYXR0YWNrcyBtYXkKICAgYmUg
ZWFzaWVyIHRoYXQgcHJldmlvdXNseSB0aG91Z2h0LCBlc3BlY2lhbGx5IGlmIG9u
bHkgYSBzaW5nbGUKICAgc3Bvb2ZlZCBSU1QgaXMgbmVlZGVkLgoKCgoKCgoKCgoK
CgpDb252ZXJ5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBBcHJpbCAxLCAyMDAz
ICAgICAgICAgICAgICAgICBbUGFnZSAyMV0KDApJbnRlcm5ldC1EcmFmdCAgICAg
ICAgICAgICAgQkdQIEF0dGFjayBUcmVlICAgICAgICAgICAgICAgICBPY3RvYmVy
IDIwMDIKCgpBLjUgU25pZmYgVHJhZmZpYwoKICAgRGVwZW5kaW5nIG9uIHRoZSBu
ZXR3b3JrIHRvcG9sb2d5LCB0aGVyZSBhcmUgbWFueSB3YXlzIG9mIGdhaW5pbmcK
ICAgcmVhZC1hY2Nlc3MgdG8gYSBuZXR3b3JrIHRvIGNvbmR1Y3QgcGFzc2l2ZSBh
dHRhY2tzLiAgVGhlIG1vc3QgY29tbW9uCiAgIG1ldGhvZCB3b3VsZCBiZSB0byBj
b21wcm9taXNlIGEgc3lzdGVtICh0eXBpY2FsbHkgYSBnZW5lcmFsIHB1cnBvc2UK
ICAgb3BlcmF0aW5nIHN5c3RlbSkgb24gdGhlIHNlZ21lbnQgYW5kIGluc3RhbGwg
c29mdHdhcmUgdGhlIHB1dHMgYQogICBuZXR3b3JrIGludGVyZmFjZSBjYXJkIGlu
IHByb21pc2N1b3VzIG1vZGUgYW5kIGNhcHR1cmVzIHRyYWZmaWMuCgogICBBdHRh
Y2s6CiAgIE9SICAxLiBHYWluIGxvY2FsIG5ldHdvcmsgYWNjZXNzIHRvIGEgc2Vn
bWVudAogICAgICAgQU5EICAxLiBDb21wcm9taXNlIHNlcnZlcgogICAgICAgICAg
ICAyLiBJbnN0YWxsIHNuaWZmaW5nIHNvZnR3YXJlCiAgICAgICAyLiBUYXAgcGh5
c2ljYWwgbWVkaXVtCiAgICAgICAzLiBSZWRpcmVjdCB0cmFmZmljIHRocm91Z2gg
YSBjb21wcm9taXNlZCBob3N0CgogICBBUlAvTUFDIHNwb29maW5nIG1heSBiZSBu
ZWNlc3NhcnkgdG8gc25pZmYgdHJhZmZpYyBvbiBzd2l0Y2hlZAogICBuZXR3b3Jr
cyBhbmQgbWFueSB0b29scyBhcmUgYXZhaWxhYmxlIHdoaWNoIG1ha2UgdGhpcyBh
IHRyaXZpYWwgdGFzay4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK
CkNvbnZlcnksIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIEFwcmlsIDEsIDIwMDMg
ICAgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVybmV0LURyYWZ0ICAgICAg
ICAgICAgICBCR1AgQXR0YWNrIFRyZWUgICAgICAgICAgICAgICAgIE9jdG9iZXIg
MjAwMgoKCkZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudAoKICAgQ29weXJpZ2h0IChD
KSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMikuICBBbGwgUmlnaHRzIFJlc2Vy
dmVkLgoKICAgVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1h
eSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0bwogICBvdGhlcnMsIGFuZCBkZXJp
dmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZXhwbGFp
biBpdAogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBw
cmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQKICAgYW5kIGRpc3RyaWJ1dGVkLCBp
biB3aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueQog
ICBraW5kLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNl
IGFuZCB0aGlzIHBhcmFncmFwaCBhcmUKICAgaW5jbHVkZWQgb24gYWxsIHN1Y2gg
Y29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiAgSG93ZXZlciwgdGhpcwogICBk
b2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBz
dWNoIGFzIGJ5IHJlbW92aW5nCiAgIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJl
ZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIKICAgSW50
ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1
cnBvc2Ugb2YKICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hp
Y2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IKICAgY29weXJpZ2h0cyBkZWZpbmVk
IGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlCiAgIGZv
bGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50byBsYW5n
dWFnZXMgb3RoZXIgdGhhbgogICBFbmdsaXNoLgoKICAgVGhlIGxpbWl0ZWQgcGVy
bWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxsIG5v
dCBiZQogICByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBz
dWNjZXNzb3JzIG9yIGFzc2lnbnMuCgogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUg
aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm92aWRlZCBvbiBhbgog
ICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhF
IElOVEVSTkVUIEVOR0lORUVSSU5HCiAgIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFM
TCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORwogICBC
VVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBU
SEUgSU5GT1JNQVRJT04KICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBS
SUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRgogICBNRVJDSEFOVEFC
SUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCgpBY2tu
b3dsZWRnZW1lbnQKCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0
aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUKICAgSW50ZXJuZXQgU29j
aWV0eS4KCgoKCgoKCgoKCgoKCgoKCgoKCkNvbnZlcnksIGV0IGFsLiAgICAgICAg
ICBFeHBpcmVzIEFwcmlsIDEsIDIwMDMgICAgICAgICAgICAgICAgIFtQYWdlIDIz
XQoMCg==
--5652839-0-3245154213=:9004--
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Sun Nov  3 13:36:34 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12569
	for <rpsec-archive@odin.ietf.org>; Sun, 3 Nov 2002 13:36:33 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA3IcYV31424
	for rpsec-archive@odin.ietf.org; Sun, 3 Nov 2002 13:38:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3IcYv31421
	for <rpsec-web-archive@optimus.ietf.org>; Sun, 3 Nov 2002 13:38:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12561
	for <rpsec-web-archive@ietf.org>; Sun, 3 Nov 2002 13:36:02 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3Ibhv31398;
	Sun, 3 Nov 2002 13:37:43 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3IaCv30763
	for <rpsec@optimus.ietf.org>; Sun, 3 Nov 2002 13:36:12 -0500
Received: from ca-uk-fs.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12527
	for <rpsec@ietf.org>; Sun, 3 Nov 2002 13:33:41 -0500 (EST)
Received: from DRAJNOVI-W2K1.cisco.com (drajnovi-isdn-home.cisco.com [10.49.135.250])
	by ca-uk-fs.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA05215;
	Sun, 3 Nov 2002 18:36:02 GMT
Message-Id: <4.3.2.7.2.20021103173455.04a45970@ca-uk-fs.cisco.com>
X-Sender: drajnovi@ca-uk-fs.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 03 Nov 2002 17:41:02 +0000
To: Sean Convery <sean@cisco.com>, rpsec@ietf.org
From: Damir Rajnovic <gaus@cisco.com>
Subject: Re: [RPSEC] draft-convery-bgpattack-00
Cc: riw@cisco.com, ttauber@genuity.net
In-Reply-To: <r01050400-1021-BB6E141AEDF311D6A4E30003939CDD90@[171.71.11
 9.97]>
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 15:43 01/11/2002 -0800, Sean Convery wrote:
>  OR  1. Use social engineering to obtain MD5 password

Does anybody knows how often ISPs are changing the 'secret key'
on a single link between two peers? Also, how diverse keys are
between multiple links (towards the same ISP and across all peering
points)?

If the answers to the above questions are not positive we may think
about replacing the whole secret key scheme with another one where
the secret key is a master key and we have separate session keys
which are expired and changed after some period of time.

Gaus
==============
Damir Rajnovic <psirt@cisco.com>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There is no insolvable problems. 
The question is can you accept the solution? 

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Sun Nov  3 14:11:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13065
	for <rpsec-archive@odin.ietf.org>; Sun, 3 Nov 2002 14:11:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA3JDMt00686
	for rpsec-archive@odin.ietf.org; Sun, 3 Nov 2002 14:13:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3JDMv00683
	for <rpsec-web-archive@optimus.ietf.org>; Sun, 3 Nov 2002 14:13:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13050
	for <rpsec-web-archive@ietf.org>; Sun, 3 Nov 2002 14:10:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3JD4v00665;
	Sun, 3 Nov 2002 14:13:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3JC7v00650
	for <rpsec@optimus.ietf.org>; Sun, 3 Nov 2002 14:12:07 -0500
Received: from sapporo.toad.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13028
	for <rpsec@ietf.org>; Sun, 3 Nov 2002 14:09:35 -0500 (EST)
Received: from gwu.edu (dboney-01.dslbr.toad.net [162.33.159.86])
	by sapporo.toad.net (Postfix) with ESMTP
	id 3481EA0086; Sun,  3 Nov 2002 14:12:01 -0500 (EST)
Message-ID: <3DC57500.3090209@gwu.edu>
Date: Sun, 03 Nov 2002 14:12:00 -0500
From: "David G. Boney" <dboney@gwu.edu>
Organization: The George Washington University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: rpsec@ietf.org
Cc: ttauber@genuity.net
References: <4.3.2.7.2.20021103173455.04a45970@ca-uk-fs.cisco.com>
X-Enigmail-Version: 0.63.3.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/alternative;
 boundary="------------000103080703080007070200"
Subject: [RPSEC] Re: draft-convery-bgpattack-00
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


--------------000103080703080007070200
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Are there any implementations with MD5? Does anyone even use it in practice?

I recently talked with the former founder of a small ISP. His response 
was roughly, "Crypto?" They did not use it. Furthermore, there was no 
encryption in the routing protocols with their upstream providers, UUNET 
or Sprint.

I think a survey of who is actually using any of the encryption features 
of any routing protocols would be informative.

Sincerely,
David G. Boney

Department of Electrical and Computer Engineering
The George Washington University
Phillips Hall, Suite 607
801 22nd Street, N.W.
Washington, DC 20052

http://student.seas.gwu.edu/~dboney
mailto:dboney@gwu.edu
Department Phone (202) 994-6083
Department Fax (202) 994-0227

Damir Rajnovic wrote:

>At 15:43 01/11/2002 -0800, Sean Convery wrote:
>  
>
>> OR  1. Use social engineering to obtain MD5 password
>>    
>>
>
>Does anybody knows how often ISPs are changing the 'secret key'
>on a single link between two peers? Also, how diverse keys are
>between multiple links (towards the same ISP and across all peering
>points)?
>
>If the answers to the above questions are not positive we may think
>about replacing the whole secret key scheme with another one where
>the secret key is a master key and we have separate session keys
>which are expired and changed after some period of time.
>
>Gaus
>==============
>Damir Rajnovic <psirt@cisco.com>, PSIRT Incident Manager, Cisco Systems
><http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
>200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
>==============
>There is no insolvable problems. 
>The question is can you accept the solution? 
>
>_______________________________________________
>RPSEC mailing list
>RPSEC@ietf.org
>https://www1.ietf.org/mailman/listinfo/rpsec
>
>  
>

--------------000103080703080007070200
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Are there any implementations with MD5? Does anyone even use it in practice?<br>
<br>
I recently talked with the former founder of a small ISP. His response was
roughly, "Crypto?" They did not use it. Furthermore, there was no encryption
in the routing protocols with their upstream providers, UUNET or Sprint.<br>
<br>
I think a survey of who is actually using any of the encryption features
of any routing protocols would be informative.<br>
<br>
Sincerely,<br>
David G. Boney<br>
<br>
 Department of Electrical and Computer Engineering<br>
 The George Washington University<br>
 Phillips Hall, Suite 607<br>
 801 22nd Street, N.W.<br>
 Washington, DC 20052<br>
 <br>
 <a class="moz-txt-link-freetext" href="http://student.seas.gwu.edu/~dboney">http://student.seas.gwu.edu/~dboney</a><br>
 <a class="moz-txt-link-freetext" href="mailto:dboney@gwu.edu">mailto:dboney@gwu.edu</a><br>
 Department Phone (202) 994-6083<br>
 Department Fax (202) 994-0227<br>
<br>
Damir Rajnovic wrote:<br>
<blockquote type="cite"
 cite="mid4.3.2.7.2.20021103173455.04a45970@ca-uk-fs.cisco.com">
  <pre wrap="">At 15:43 01/11/2002 -0800, Sean Convery wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap=""> OR  1. Use social engineering to obtain MD5 password
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Does anybody knows how often ISPs are changing the 'secret key'
on a single link between two peers? Also, how diverse keys are
between multiple links (towards the same ISP and across all peering
points)?

If the answers to the above questions are not positive we may think
about replacing the whole secret key scheme with another one where
the secret key is a master key and we have separate session keys
which are expired and changed after some period of time.

Gaus
==============
Damir Rajnovic <a class="moz-txt-link-rfc2396E" href="mailto:psirt@cisco.com">&lt;psirt@cisco.com&gt;</a>, PSIRT Incident Manager, Cisco Systems
<a class="moz-txt-link-rfc2396E" href="http://www.cisco.com/go/psirt">&lt;http://www.cisco.com/go/psirt&gt;</a>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There is no insolvable problems. 
The question is can you accept the solution? 

_______________________________________________
RPSEC mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RPSEC@ietf.org">RPSEC@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/rpsec">https://www1.ietf.org/mailman/listinfo/rpsec</a>

  </pre>
</blockquote>
</body>
</html>

--------------000103080703080007070200--


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Sun Nov  3 14:48:33 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13521
	for <rpsec-archive@odin.ietf.org>; Sun, 3 Nov 2002 14:48:33 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA3JoYW02268
	for rpsec-archive@odin.ietf.org; Sun, 3 Nov 2002 14:50:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3JoYv02265
	for <rpsec-web-archive@optimus.ietf.org>; Sun, 3 Nov 2002 14:50:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13517
	for <rpsec-web-archive@ietf.org>; Sun, 3 Nov 2002 14:48:02 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3JoDv02255;
	Sun, 3 Nov 2002 14:50:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3Jnmv02188
	for <rpsec@optimus.ietf.org>; Sun, 3 Nov 2002 14:49:48 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13507
	for <rpsec@ietf.org>; Sun, 3 Nov 2002 14:47:15 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA3JnHx50630;
	Sun, 3 Nov 2002 20:49:17 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Sun, 3 Nov 2002 20:49:17 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: "David G. Boney" <dboney@gwu.edu>
cc: <rpsec@ietf.org>, <ttauber@genuity.net>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <3DC57500.3090209@gwu.edu>
Message-ID: <20021103202829.Y43861-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Sun, 3 Nov 2002, David G. Boney wrote:

> Are there any implementations with MD5? Does anyone even use it in practice?

I know from personal experience Cisco implements it and Zebra doesn't.
I'm also pretty sure the major vendors implement it.

However, not many people actually use it.

> I think a survey of who is actually using any of the encryption features
> of any routing protocols would be informative.

I recently set up peering over the AMS-IX for a customer. They now have
103 peering sessions (note: some peers use two sessions) of which 4 are
protected with an MD5 password. So about 4% of the peers requested
password protection.

I have never seen Password protection on ISP<->customer links.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Sun Nov  3 15:23:23 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13968
	for <rpsec-archive@odin.ietf.org>; Sun, 3 Nov 2002 15:23:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA3KPOG03591
	for rpsec-archive@odin.ietf.org; Sun, 3 Nov 2002 15:25:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3KPOv03588
	for <rpsec-web-archive@optimus.ietf.org>; Sun, 3 Nov 2002 15:25:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13960
	for <rpsec-web-archive@ietf.org>; Sun, 3 Nov 2002 15:22:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3KP4v03574;
	Sun, 3 Nov 2002 15:25:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA3KONv03540
	for <rpsec@optimus.ietf.org>; Sun, 3 Nov 2002 15:24:23 -0500
Received: from mail1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13923
	for <rpsec@ietf.org>; Sun, 3 Nov 2002 15:21:50 -0500 (EST)
Received: from localhost (clonvick@localhost) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA08229; Sun, 3 Nov 2002 12:24:14 -0800 (PST)
Date: Sun, 3 Nov 2002 12:24:14 -0800 (PST)
From: Christopher Lonvick <clonvick@cisco.com>
To: Damir Rajnovic <gaus@cisco.com>
cc: Sean Convery <sean@cisco.com>, <rpsec@ietf.org>, <riw@cisco.com>,
        <ttauber@genuity.net>
Subject: Re: [RPSEC] draft-convery-bgpattack-00
In-Reply-To: <4.3.2.7.2.20021103173455.04a45970@ca-uk-fs.cisco.com>
Message-ID: <Pine.HPX.4.44.0211031218450.18365-100000@mail1.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Hi Gaus,

I believe that Marcus Leech has some discussion
around this in draft-ietf-idr-md5-keys-00.txt

Later,
Chris


On Sun, 3 Nov 2002, Damir Rajnovic wrote:

> At 15:43 01/11/2002 -0800, Sean Convery wrote:
> >  OR  1. Use social engineering to obtain MD5 password
>
> Does anybody knows how often ISPs are changing the 'secret key'
> on a single link between two peers? Also, how diverse keys are
> between multiple links (towards the same ISP and across all peering
> points)?
>
> If the answers to the above questions are not positive we may think
> about replacing the whole secret key scheme with another one where
> the secret key is a master key and we have separate session keys
> which are expired and changed after some period of time.
>
> Gaus
> ==============
> Damir Rajnovic <psirt@cisco.com>, PSIRT Incident Manager, Cisco Systems
> <http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
> 200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
> ==============
> There is no insolvable problems.
> The question is can you accept the solution?
>
> _______________________________________________
> RPSEC mailing list
> RPSEC@ietf.org
> https://www1.ietf.org/mailman/listinfo/rpsec
>

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 04:48:20 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07919
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 04:48:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA49oTW15281
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 04:50:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA49oTv15278
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 04:50:29 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07910
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 04:47:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA49o8v15260;
	Mon, 4 Nov 2002 04:50:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA49nFv15222
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 04:49:15 -0500
Received: from orbax.orange.dk (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07879
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 04:46:35 -0500 (EST)
Received: from msgate-b.intra.mobilix.dk (msgate-b.intra.mobilix.dk [172.16.3.107])
	by orbax.orange.dk (8.11.6+Sun/8.11.6) with ESMTP id gA49n2R06656
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 10:49:02 +0100 (CET)
Received: by msgate-b.intra.mobilix.dk with Internet Mail Service (5.5.2653.19)
	id <VNCN6J81>; Mon, 4 Nov 2002 10:47:10 +0100
Message-ID: <76F2DFF76DE8414D95AF660570B0A40B0146A238@exch01.intra.orange.dk>
From: Joachim Jensen <joa@orange.dk>
To: rpsec@ietf.org
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
Date: Mon, 4 Nov 2002 10:49:00 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


I can comment on that David,

We Orange DK is fairly large ISP. And we don't have even one encrypted BGP
session, either in IBGP or in EBGP.
and our IGP (OSPF) is not using md5 either. I think it's to difficult to
implemet md5 in a big IGP, if it's not implementet from the beginning, and
BGP encryption is not normal "praksis" -maybe because it's not seen as
sequrity issue, or all the password handling is to much work.

Venlig hilsen/Best regards

Joachim Jerberg Jensen
Orange A/S
AS_12435

 - Never make anything simple and efficient,
when a way can be found to make it complex and wonderful -



 


Are there any implementations with MD5? Does anyone even use it in practice?

I recently talked with the former founder of a small ISP. His response was
roughly, "Crypto?" They did not use it. Furthermore, there was no encryption
in the routing protocols with their upstream providers, UUNET or Sprint.

I think a survey of who is actually using any of the encryption features of
any routing protocols would be informative.

Sincerely,
David G. Boney

Department of Electrical and Computer Engineering
The George Washington University
Phillips Hall, Suite 607
801 22nd Street, N.W.
Washington, DC 20052

http://student.seas.gwu.edu/~dboney
mailto:dboney@gwu.edu
Department Phone (202) 994-6083
Department Fax (202) 994-0227

Damir Rajnovic wrote:

At 15:43 01/11/2002 -0800, Sean Convery wrote:
  
 OR  1. Use social engineering to obtain MD5 password
    

Does anybody knows how often ISPs are changing the 'secret key'
on a single link between two peers? Also, how diverse keys are
between multiple links (towards the same ISP and across all peering
points)?

If the answers to the above questions are not positive we may think
about replacing the whole secret key scheme with another one where
the secret key is a master key and we have separate session keys
which are expired and changed after some period of time.

Gaus
==============
Damir Rajnovic <psirt@cisco.com>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There is no insolvable problems. 
The question is can you accept the solution? 

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec

  
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 05:24:31 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08348
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 05:24:31 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4AQS616915
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 05:26:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4AQSv16912
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 05:26:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08343
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 05:24:00 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4AQBv16902;
	Mon, 4 Nov 2002 05:26:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4APEv16876
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 05:25:14 -0500
Received: from irmgard.exp-math.uni-essen.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08319
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 05:22:44 -0500 (EST)
Received: from lomin.exp-math.uni-essen.de (dhcp9.exp-math.uni-essen.de [132.252.150.169])
	by irmgard.exp-math.uni-essen.de (8.12.2/8.12.2) with ESMTP id gA4AOt5D050430;
	Mon, 4 Nov 2002 11:24:55 +0100
Received: by lomin.exp-math.uni-essen.de (Postfix, from userid 501)
	id 04A8A71828; Mon,  4 Nov 2002 11:24:49 +0100 (CET)
Date: Mon, 4 Nov 2002 11:24:49 +0100
From: Birger Toedtmann <btoedtmann@exp-math.uni-essen.de>
To: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Message-ID: <20021104102448.GA5287@lomin.exp-math.uni-essen.de>
References: <4.3.2.7.2.20021103173455.04a45970@ca-uk-fs.cisco.com> <3DC57500.3090209@gwu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3DC57500.3090209@gwu.edu>
User-Agent: Mutt/1.3.28i
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

David G. Boney schrieb am Sun, Nov 03, 2002 at 02:12:00PM -0500:
> Are there any implementations with MD5? Does anyone even use it in practice?
> 
> I recently talked with the former founder of a small ISP. His response 
> was roughly, "Crypto?" They did not use it. Furthermore, there was no 
> encryption in the routing protocols with their upstream providers, UUNET 
> or Sprint.
> 
> I think a survey of who is actually using any of the encryption features 
> of any routing protocols would be informative.

Until recently I worked for a mid-size ISP in Northwestern Germany.  

A year ago I tried to put MD5 on both BGP uplinks it had.  The first
uplink provider, Versatel, did not even know about security issues with
BGP, neither did they know anything about MD5 on corresponding sessions.  
Consequently, they denied the request.

The second one, ECRC (which had been bought by Cable&Wireless in 2000),
knew about it, but said: "Eh, well, if you wan't it, we will do it with 
you.  However, you'll be the first one out of 100 customers, and we'll
have to configure it manually."


Regards,

Birger Tödtmann

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 12:09:29 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22790
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 12:09:29 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4HBUj07909
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 12:11:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4HBTv07906
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 12:11:29 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22767
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 12:08:57 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4HBBv07874;
	Mon, 4 Nov 2002 12:11:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4HAuv07835
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 12:10:56 -0500
Received: from rip.psg.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22726
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 12:08:24 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com)
	by rip.psg.com with esmtp (Exim 4.10)
	id 188kkS-000EX2-00; Mon, 04 Nov 2002 09:10:48 -0800
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
References: <3DC57500.3090209@gwu.edu>
	<20021103202829.Y43861-100000@sequoia.muada.com>
Message-Id: <E188kkS-000EX2-00@rip.psg.com>
Date: Mon, 04 Nov 2002 09:10:48 -0800
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> However, not many people actually use it.

nope.  just the bigger smarter providers.  some won't peer with you
without it.

randy

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 12:46:24 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24902
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 12:46:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4HmN010367
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 12:48:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4HmNv10364
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 12:48:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24882
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 12:45:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Hh8v10080;
	Mon, 4 Nov 2002 12:43:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Hgjv10034
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 12:42:45 -0500
Received: from noxmail.sandelman.ottawa.on.ca (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24497
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 12:40:14 -0500 (EST)
Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20])
	by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gA4HgYG20695
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK)
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 12:42:40 -0500 (EST)
Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1])
	by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA4HgWNE001647
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK)
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 12:42:34 -0500
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA4HgWYn001642
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 12:42:32 -0500
Message-Id: <200211041742.gA4HgWYn001642@marajade.sandelman.ottawa.on.ca>
To: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
In-reply-to: Your message of "Mon, 04 Nov 2002 11:24:49 +0100."
             <20021104102448.GA5287@lomin.exp-math.uni-essen.de> 
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 04 Nov 2002 12:42:31 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

-----BEGIN PGP SIGNED MESSAGE-----


I don't find draft-convery-bgpattack-00 on the ietf site.
(I have a nightly rsync of it...)

My understanding of MD5, is that this secures the TCP session used by BGP. 

While I think that this can have value, particularly for multihop
arrangements, I thought that BGP was supposed to have a TTL=1, such
that its packets couldn't get routed. (I know that zebra does not do this)

So, it protects the session, which given that they typically cross
a single link, are not that vulnerable. (Sure, they can be attacked, but
it involves some amount of physical access. I realize that in ATM/SONET, that
this might still be trivial to get)

I am more concerned about the semantics of what is announced, than how
it is communicated from AS to AS.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
  



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPcaxhYqHRg3pndX9AQEPGgP+MhVKjdrfW+SWzbyf+duEh9WUlIxtG+Q+
yVjDyL75Vd0kIxIqYajm2DKPyy9Wv6qW2gh84v9DG3h92Y+NavKsK3Dk+8zgmPpV
d//nPucFb1ZjQvhJeuJcn+IovNTOp3dwDw3jXVzHVlewGMcP5W7d+SxdjaAJ3QUf
nDOg+0/Mjvg=
=9NEG
-----END PGP SIGNATURE-----
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 12:59:20 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25772
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 12:59:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4I1J111084
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 13:01:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4I1Jv11081
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 13:01:19 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25741
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 12:58:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4I14v11065;
	Mon, 4 Nov 2002 13:01:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4I09v10995
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 13:00:09 -0500
Received: from irmgard.exp-math.uni-essen.de (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25686
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 12:57:38 -0500 (EST)
Received: from lomin.exp-math.uni-essen.de (dhcp9.exp-math.uni-essen.de [132.252.150.169])
	by irmgard.exp-math.uni-essen.de (8.12.2/8.12.2) with ESMTP id gA4Hxm5D052756;
	Mon, 4 Nov 2002 18:59:49 +0100
Received: by lomin.exp-math.uni-essen.de (Postfix, from userid 501)
	id 6FA6471828; Mon,  4 Nov 2002 18:59:42 +0100 (CET)
Date: Mon, 4 Nov 2002 18:59:42 +0100
From: Birger Toedtmann <btoedtmann@exp-math.uni-essen.de>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Message-ID: <20021104175942.GA32428@lomin.exp-math.uni-essen.de>
References: <20021104102448.GA5287@lomin.exp-math.uni-essen.de> <200211041742.gA4HgWYn001642@marajade.sandelman.ottawa.on.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200211041742.gA4HgWYn001642@marajade.sandelman.ottawa.on.ca>
User-Agent: Mutt/1.3.28i
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Michael Richardson schrieb am Mon, Nov 04, 2002 at 12:42:31PM -0500:
> 
> I don't find draft-convery-bgpattack-00 on the ietf site.
> (I have a nightly rsync of it...)
> 
> My understanding of MD5, is that this secures the TCP session used by BGP. 
> 
> While I think that this can have value, particularly for multihop
> arrangements, I thought that BGP was supposed to have a TTL=1, such
> that its packets couldn't get routed. (I know that zebra does not do this)
> 
> So, it protects the session, which given that they typically cross
> a single link, are not that vulnerable. (Sure, they can be attacked, but
> it involves some amount of physical access. I realize that in ATM/SONET, that
> this might still be trivial to get)

Far from it.  In todays peering associations, it is quite common to use
"ebgp multihop" arrangements because the next speaker (sometimes a powerful 
machine is needed to hold the tables) is several hops away.  In addition
to that:  Any attacker can craft a packet that *looks like* it travelled
just one hop, but did not - so you need to watch for those packets.  But 
if you (or your peering partner) *do* packet filtering, you don't need the 
TTL=1 mechanism at all....   So this is a noop, concerning security.  

AFAIK, the feature of TTL=1 was invented to have some weak assurance that 
the BGP session is established over the correct network path.


Just my .02c,

Birger
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 13:08:21 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26321
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 13:08:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4IAL812173
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 13:10:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4IALv12170
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 13:10:21 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26302
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 13:07:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4IA3v12158;
	Mon, 4 Nov 2002 13:10:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4I9tv12127
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 13:09:55 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26284
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 13:07:24 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id NAA22489; Mon, 4 Nov 2002 13:09:54 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma022432; Mon, 4 Nov 02 13:09:21 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gA4I9G224777;
	Mon, 4 Nov 2002 13:09:16 -0500 (EST)
Date: Mon, 4 Nov 2002 13:09:16 -0500 (EST)
Message-Id: <200211041809.gA4I9G224777@raven.gw.tislabs.com>
To: mcr@sandelman.ottawa.on.ca, rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: sandy@tislabs.com
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>While I think that this can have value, particularly for multihop
>arrangements, I thought that BGP was supposed to have a TTL=1, such
>that its packets couldn't get routed. (I know that zebra does not do this)

Multi-hop arrangements between BGP peers are possible and are used.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 13:21:34 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26939
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 13:21:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4INY312822
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 13:23:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4INYv12819
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 13:23:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26909
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 13:21:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4IK6v12720;
	Mon, 4 Nov 2002 13:20:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4IJkv12643
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 13:19:46 -0500
Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26756
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 13:17:15 -0500 (EST)
Received: (from root@localhost)
	by presque.djinesys.com (8.11.3/8.11.1) id gA4IJYv35951;
	Mon, 4 Nov 2002 13:19:34 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31])
	by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4IJVC35944;
	Mon, 4 Nov 2002 13:19:31 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: (from jhaas@localhost)
	by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4IJVR07929;
	Mon, 4 Nov 2002 13:19:31 -0500 (EST)
Date: Mon, 4 Nov 2002 13:19:31 -0500
From: Jeffrey Haas <jhaas@nexthop.com>
To: Birger Toedtmann <btoedtmann@exp-math.uni-essen.de>
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Message-ID: <20021104131931.W7176@nexthop.com>
References: <20021104102448.GA5287@lomin.exp-math.uni-essen.de> <200211041742.gA4HgWYn001642@marajade.sandelman.ottawa.on.ca> <20021104175942.GA32428@lomin.exp-math.uni-essen.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20021104175942.GA32428@lomin.exp-math.uni-essen.de>; from btoedtmann@exp-math.uni-essen.de on Mon, Nov 04, 2002 at 06:59:42PM +0100
X-Virus-Scanned: by AMaViS perl-11
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Mon, Nov 04, 2002 at 06:59:42PM +0100, Birger Toedtmann wrote:
> AFAIK, the feature of TTL=1 was invented to have some weak assurance that 
> the BGP session is established over the correct network path.

As proposed by a recent draft, draft-gill-btsh-00.txt, a TTL of
255 is more secure.

> Birger

-- 
Jeff Haas 
NextHop Technologies
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 15:29:15 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04908
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 15:29:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4KVHF21586
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 15:31:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4KVHv21583
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 15:31:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04898
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 15:28:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4KUPv21522;
	Mon, 4 Nov 2002 15:30:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4KT8v21464
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 15:29:08 -0500
Received: from noxmail.sandelman.ottawa.on.ca (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04789
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 15:26:21 -0500 (EST)
Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20])
	by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gA4KSfG21120
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK)
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 15:28:47 -0500 (EST)
Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1])
	by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA4KSdNE004184
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK)
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 15:28:40 -0500
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA4KScQS004179
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 15:28:39 -0500
Message-Id: <200211042028.gA4KScQS004179@marajade.sandelman.ottawa.on.ca>
To: rpsec@ietf.org
In-reply-to: Your message of "Mon, 04 Nov 2002 18:59:42 +0100."
             <20021104175942.GA32428@lomin.exp-math.uni-essen.de> 
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 04 Nov 2002 15:28:38 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Subject: [RPSEC] prefix origin authentication (was Re: draft-convery-bgpattack-00 )
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Birger" == Birger Toedtmann <btoedtmann@exp-math.uni-essen.de> writes:
    >> So, it protects the session, which given that they typically cross
    >> a single link, are not that vulnerable. (Sure, they can be attacked, but
    >> it involves some amount of physical access. I realize that in ATM/SONET, that
    >> this might still be trivial to get)

    Birger> Far from it.  In todays peering associations, it is quite common to use
    Birger> "ebgp multihop" arrangements because the next speaker (sometimes a powerful 
    Birger> machine is needed to hold the tables) is several hops away.  In

  Fair enough.

  I have had severe difficulty with a number of ISPs to convince them make
this kind of arrangement - the last mile is now more frequently xDSL (vs T1)
of some kind, and the DSLAMs definitely do not run BGP. I had assumed that it
was still "too new" for them to cope with. (I live in the "backwaters" here
in Ottawa...)

    Birger> to that:  Any attacker can craft a packet that *looks like* it travelled
    Birger> just one hop, but did not - so you need to watch for those

  Sure, I can buy that. They need to do all the sequence number guesses to
make a useful attack, and it results in a DoS more than anything else.

    Birger> AFAIK, the feature of TTL=1 was invented to have some weak assurance that 
    Birger> the BGP session is established over the correct network path.

  No kidding.
  I'd be happiest with IPsec, using raw RSA keys (no PK*I*, just PK) to
authenticate. This is as easy as exchanging MD5, and potentially better
documented in many products. 

  This arrangement is peer-to-peer, so we can make recommendations, and
people can implement this without any broad arrangements.

  Again, I think that we need to deal with higher level requirements.

  I wonder if we are in agreement 
    1) that there should be some kind of way to authenticate prefix->AS.

  
  If so, then there is two possibilities

    2a) that this should be communicated online, within the BGP4 protocol.

    2b) that this information should be in a standard database, with
    well known proceedures for generating filtering rules from this database.
    (I consider this "offline", because you may have to go through a router
    reconfig to get new entries, etc..)

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPcbYZ4qHRg3pndX9AQEQDQP/TXDbAbUTnnEFaMcWGU/EaoJhxncBRQJm
elbiJpVEkxrb6irZbIfSWrbMu6KSXdfKR5AgJgdDWeA59VZcrytf4fo0dVtas5e5
DccAdwQG7CGXQUrbdwbHR1tTimvuSTrZsBAxgmZnutbFU5aF/Ad+lqQeWF9bVIyE
wV/U2qFQ4jA=
=Ku84
-----END PGP SIGNATURE-----
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 15:51:21 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05924
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 15:51:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4KrNu22935
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 15:53:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4KrNv22932
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 15:53:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05910
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 15:50:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Kr9v22917;
	Mon, 4 Nov 2002 15:53:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Kqbv22901
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 15:52:37 -0500
Received: from noxmail.sandelman.ottawa.on.ca (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05871
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 15:50:04 -0500 (EST)
Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20])
	by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gA4KqJG21170
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK);
	Mon, 4 Nov 2002 15:52:25 -0500 (EST)
Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1])
	by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA4KqINE004567
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK);
	Mon, 4 Nov 2002 15:52:19 -0500
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA4KqFRE004562;
	Mon, 4 Nov 2002 15:52:16 -0500
Message-Id: <200211042052.gA4KqFRE004562@marajade.sandelman.ottawa.on.ca>
To: rpsec@ietf.org
CC: vijay@umbc.edu, heas@shrubbery.net, dmm@sprint.net
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
In-reply-to: Your message of "Mon, 04 Nov 2002 13:19:31 EST."
             <20021104131931.W7176@nexthop.com> 
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 04 Nov 2002 15:52:15 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Jeffrey" == Jeffrey Haas <jhaas@nexthop.com> writes:
    >> AFAIK, the feature of TTL=1 was invented to have some weak assurance that 
    >> the BGP session is established over the correct network path.

    Jeffrey> As proposed by a recent draft, draft-gill-btsh-00.txt, a TTL of
    Jeffrey> 255 is more secure.

  yes, a nice hack.

  As section 3.1 points out, this can be done for multihop as well.
  In particular, I'll bet that 95% of multihop scenarioes have the route
server extra one hop away. (potentially, it each direction)

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPcbd/YqHRg3pndX9AQE3EAQAjZY0G56NxxwZGcwuU9YSGm30uyUskFh1
PksxBk7XWwG5fkLVQFb2VvN7OhPuXczH7rwO4hyCH0uFMZ24h6e1fZvUef+iYsWO
dkq+Urdw1OS5t8QXZD2Gu3yQPD3vbDP2CNhDUZOjHBp34xbgTDSv6SSDMtMpu1Sp
rl8HfYJSLk4=
=lywM
-----END PGP SIGNATURE-----
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 15:59:23 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06337
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 15:59:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4L1Pe23337
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 16:01:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4L1Pv23334
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 16:01:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06312
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 15:58:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4L12v23318;
	Mon, 4 Nov 2002 16:01:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4L0kv23272
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 16:00:46 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06295
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 15:58:13 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA4KwpN52714;
	Mon, 4 Nov 2002 21:58:51 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Mon, 4 Nov 2002 21:58:51 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
In-Reply-To: <200211041742.gA4HgWYn001642@marajade.sandelman.ottawa.on.ca>
Message-ID: <20021104213833.C50741-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Mon, 4 Nov 2002, Michael Richardson wrote:

> My understanding of MD5, is that this secures the TCP session used by BGP.

Yes. It basically signs every TCP segment so you're protected against
any kind of TCP trickery (such as false RSTs). But simple anti-spoofing
filters will do that too.

> While I think that this can have value, particularly for multihop
> arrangements, I thought that BGP was supposed to have a TTL=1, such
> that its packets couldn't get routed. (I know that zebra does not do this)

It does have a command to turn off this non-implemented feature, though...

> So, it protects the session, which given that they typically cross
> a single link, are not that vulnerable. (Sure, they can be attacked, but
> it involves some amount of physical access. I realize that in ATM/SONET, that
> this might still be trivial to get)

The TCP MD5 password option protects against sniffing and man in the
middle attacks too. Someone who doesn't have access to the password
can't successfully engage in a BGP session if this option is used.

> I am more concerned about the semantics of what is announced, than how
> it is communicated from AS to AS.

Between ISPs and customers this isn't a problem as the ISP filters. The
only thing a customer can do is flap a lot (which can be dampened
explicitly or because updates are delayed somewhat by default).

Between ISPs filtering is problematic because of the large numbers of
routes exchanged. Also, an ISP could attach meaningless but large
attributes to routes to exhaust another ISP's router memory, and since
the number of routes is larger flapping does more harm.

However, I think it is unnecessary to protect against "evil" ISPs since
they only get to do this once before they're disconnected and an ISP in
their right mind wouldn't do this. People with this level of paranoia
should go to the local super market and test the food there for poison.
After all, if ISPs can't trust each other, why would grocers? And
poisoning some oranges gives you much more bang for your buck than
injecting some false routing info.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 16:29:23 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07778
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 16:29:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4LVQu03733
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 16:31:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4LVQv03730
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 16:31:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07767
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 16:28:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4LQ6v02134;
	Mon, 4 Nov 2002 16:26:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4LPrv02077
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 16:25:53 -0500
Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07447
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 16:23:19 -0500 (EST)
Received: (from root@localhost)
	by presque.djinesys.com (8.11.3/8.11.1) id gA4LPcm42346;
	Mon, 4 Nov 2002 16:25:38 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31])
	by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA4LPZC42339;
	Mon, 4 Nov 2002 16:25:35 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: (from jhaas@localhost)
	by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA4LPZq08870;
	Mon, 4 Nov 2002 16:25:35 -0500 (EST)
Date: Mon, 4 Nov 2002 16:25:35 -0500
From: Jeffrey Haas <jhaas@nexthop.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Message-ID: <20021104162535.C7176@nexthop.com>
References: <200211041742.gA4HgWYn001642@marajade.sandelman.ottawa.on.ca> <20021104213833.C50741-100000@sequoia.muada.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20021104213833.C50741-100000@sequoia.muada.com>; from iljitsch@muada.com on Mon, Nov 04, 2002 at 09:58:51PM +0100
X-Virus-Scanned: by AMaViS perl-11
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Mon, Nov 04, 2002 at 09:58:51PM +0100, Iljitsch van Beijnum wrote:
> However, I think it is unnecessary to protect against "evil" ISPs since
> they only get to do this once before they're disconnected and an ISP in
> their right mind wouldn't do this.

One would like this to be true.

The initial goal of securing BGP, IMO, whether it be all at once, or
incrementally, is to prevent stupidity or misconfiguration from
harming the Internet.  For the most part, it has been fat-fingering
that has caused most of the recent harm to the network.  Bugs
and interop issues account for much of the rest.

However, we have more reason today to worry about this.  The world
is a less friendly place than it used to be.  Trust your neighbors,
but still lock your doors.

-- 
Jeff Haas 
NextHop Technologies
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 16:32:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07998
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 16:32:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4LYO404004
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 16:34:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4LYOv04001
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 16:34:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07941
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 16:31:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4LY4v03919;
	Mon, 4 Nov 2002 16:34:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4LXIv03870
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 16:33:18 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07865
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 16:30:45 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA4LWju52791;
	Mon, 4 Nov 2002 22:32:45 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Mon, 4 Nov 2002 22:32:45 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Jeffrey Haas <jhaas@nexthop.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <20021104162535.C7176@nexthop.com>
Message-ID: <20021104223029.L50741-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Mon, 4 Nov 2002, Jeffrey Haas wrote:

> > However, I think it is unnecessary to protect against "evil" ISPs since
> > they only get to do this once before they're disconnected and an ISP in
> > their right mind wouldn't do this.

> The initial goal of securing BGP, IMO, whether it be all at once, or
> incrementally, is to prevent stupidity or misconfiguration from
> harming the Internet.  For the most part, it has been fat-fingering
> that has caused most of the recent harm to the network.  Bugs
> and interop issues account for much of the rest.

Yes. This is why we need better information to build filters from, and
better ways to install them in our boxes. However, this has nothing to
do with BGP itself.

> However, we have more reason today to worry about this.  The world
> is a less friendly place than it used to be.

Not true. The world is still the same, human nature is still the same.
Only the toys get bigger and better.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 16:43:20 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08562
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 16:43:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4LjNq07638
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 16:45:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4LjNv07635
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 16:45:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08523
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 16:42:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Lj7v07617;
	Mon, 4 Nov 2002 16:45:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Lijv07590
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 16:44:45 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08489
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 16:42:12 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id QAA03072; Mon, 4 Nov 2002 16:44:43 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma003043; Mon, 4 Nov 02 16:44:18 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gA4LiDu13448;
	Mon, 4 Nov 2002 16:44:13 -0500 (EST)
Date: Mon, 4 Nov 2002 16:44:13 -0500 (EST)
Message-Id: <200211042144.gA4LiDu13448@raven.gw.tislabs.com>
To: iljitsch@muada.com, mcr@sandelman.ottawa.on.ca
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>However, I think it is unnecessary to protect against "evil" ISPs since
>they only get to do this once before they're disconnected and an ISP in
>their right mind wouldn't do this.

(A) There have been numerous occasions where ISP's have done this and
    they have not been disconnected.
(B) To speak for the paranoid:  a routing system that knew that it was
    vulnerable to one faulty/misconfigured/subverted/evil ISP should
    not rely on self-interest of such ISP's to protect the world-wide net.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 17:04:31 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09475
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 17:04:31 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4M6YY08980
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 17:06:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4M6Yv08977
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 17:06:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09436
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 17:04:00 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4M6Cv08933;
	Mon, 4 Nov 2002 17:06:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4M3Uv08805
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 17:03:30 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09346
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 17:00:56 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA4M2x452880;
	Mon, 4 Nov 2002 23:02:59 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Mon, 4 Nov 2002 23:02:59 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: <sandy@tislabs.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <200211042144.gA4LiDu13448@raven.gw.tislabs.com>
Message-ID: <20021104225841.S50741-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Mon, 4 Nov 2002 sandy@tislabs.com wrote:

> >However, I think it is unnecessary to protect against "evil" ISPs since
> >they only get to do this once before they're disconnected and an ISP in
> >their right mind wouldn't do this.

> (A) There have been numerous occasions where ISP's have done this and
>     they have not been disconnected.

Then obviously not disconnecting yielded a better result than
disconnecting.

> (B) To speak for the paranoid:  a routing system that knew that it was
>     vulnerable to one faulty/misconfigured/subverted/evil ISP should
>     not rely on self-interest of such ISP's to protect the world-wide net.

Routers need better management in order to be able to filter very large
numbers of routes, I'm all for that.

However, some basic assumption of good will between ISPs is reasonable.

We can do better things with our time than thinking up protocols to
protect us against attacks that 1. we can't really protect ourselves
against and 2. aren't going to happen anyway. BGP misconfiguration and
DoS attacks against the root nameservers ARE happening, so let's focus
on that kind of stuff.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 17:32:13 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11196
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 17:32:13 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4MYHV10962
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 17:34:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4MYHv10959
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 17:34:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11153
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 17:31:42 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4MY3v10935;
	Mon, 4 Nov 2002 17:34:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4MX1v10895
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 17:33:01 -0500
Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11094
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 17:30:27 -0500 (EST)
Received: from localhost (ttauber@localhost)
	by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id gA4MWts10259;
	Mon, 4 Nov 2002 17:32:55 -0500 (EST)
X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs
Date: Mon, 4 Nov 2002 17:32:55 -0500 (EST)
From: Tony Tauber <ttauber@genuity.net>
X-X-Sender: ttauber@mesa.bbnplanet.com
To: rpsec@ietf.org
cc: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <20021104225841.S50741-100000@sequoia.muada.com>
Message-ID: <Pine.GSO.4.40.0211041717000.28401-100000@mesa.bbnplanet.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> We can do better things with our time than thinking up protocols to
> protect us against attacks that 1. we can't really protect ourselves
> against and 2. aren't going to happen anyway. BGP misconfiguration
> and DoS attacks against the root nameservers ARE happening, so let's
> focus on that kind of stuff.

The goal of the WG is to give better security guidance to routing
protocol designers (and implementers), not to solve all problems of
the operational Internet much less world hunger.

The sincere hope is that this effort will not result in a huge
drain on the collective brainpower of the IETF nor will it take eons
to complete.

Let's focus on the actual threat-modeling drafts at hand
(beard, murphy, and convery).  In the convery draft ("Attack Tree"),
what if we think more about the generic approach than the specific
threats against BGP?  That would get this WG closer to its first goal
which the charter tells us is:

- Document threat models for routing systems

In other words, our time can be more productively spent than
conversing about how many post-it notes it takes someone's NOC
to run MD5 with a given vendor's BGP code.  That will come later. 8-)

Thanks.

Tony



_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 18:00:27 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12949
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 18:00:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4N2VH12959
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 18:02:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4N2Vv12956
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 18:02:31 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12938
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 17:59:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4N25v12917;
	Mon, 4 Nov 2002 18:02:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4N1Av12879
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 18:01:10 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12868
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 17:58:35 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05487;
	Mon, 4 Nov 2002 18:00:59 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100319b9ec970231f1@[128.89.88.34]>
In-Reply-To: <20021104213833.C50741-100000@sequoia.muada.com>
References: <20021104213833.C50741-100000@sequoia.muada.com>
Date: Mon, 4 Nov 2002 17:54:15 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: <rpsec@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 9:58 PM +0100 11/4/02, Iljitsch van Beijnum wrote:
>On Mon, 4 Nov 2002, Michael Richardson wrote:
>
>>  My understanding of MD5, is that this secures the TCP session used by BGP.
>
>Yes. It basically signs every TCP segment so you're protected against
>any kind of TCP trickery (such as false RSTs). But simple anti-spoofing
>filters will do that too.

Just a nit. The MD5 keyed hash is not a "signature" function. it is a 
message authentication code (MAC). it is also a poor one, relative to 
modern crypto design principles, which would call for use of the HMAC 
construct for this purpose.

>
>>  While I think that this can have value, particularly for multihop
>>  arrangements, I thought that BGP was supposed to have a TTL=1, such
>>  that its packets couldn't get routed. (I know that zebra does not do this)
>
>It does have a command to turn off this non-implemented feature, though...
>
>>  So, it protects the session, which given that they typically cross
>>  a single link, are not that vulnerable. (Sure, they can be attacked, but
>>  it involves some amount of physical access. I realize that in 
>>ATM/SONET, that
>>  this might still be trivial to get)
>
>The TCP MD5 password option protects against sniffing and man in the
>middle attacks too. Someone who doesn't have access to the password
>can't successfully engage in a BGP session if this option is used.

the first statement is not correct, since "sniffing" is a passive 
wiretapping attack. the MD5 option does not provide encryption and 
thus does not protect against such attacks. your second sentence is 
true, but this is a spoofing attack, not a sniffing attack.

>
>>  I am more concerned about the semantics of what is announced, than how
>>  it is communicated from AS to AS.
>
>Between ISPs and customers this isn't a problem as the ISP filters. The
>only thing a customer can do is flap a lot (which can be dampened
>explicitly or because updates are delayed somewhat by default).
>
>Between ISPs filtering is problematic because of the large numbers of
>routes exchanged. Also, an ISP could attach meaningless but large
>attributes to routes to exhaust another ISP's router memory, and since
>the number of routes is larger flapping does more harm.
>
>However, I think it is unnecessary to protect against "evil" ISPs since
>they only get to do this once before they're disconnected and an ISP in
>their right mind wouldn't do this. People with this level of paranoia
>should go to the local super market and test the food there for poison.
>After all, if ISPs can't trust each other, why would grocers? And
>poisoning some oranges gives you much more bang for your buck than
>injecting some false routing info.

This last observation is not borne out by experience.  DARPA-funded 
research reported in 2002 observed that about 1% of all advertised 
routes are in error at any time.  Given current routing table sizes, 
this amounts to about 1,000 routes.  Thus some number of ISPs do make 
mistakes and their neighbors do propagate these errors to the rest of 
the Internet. Mechanisms that detect and reject advertisements that 
are in error do seem to be needed for BGP.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 18:07:15 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13271
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 18:07:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4N9JD13835
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 18:09:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4N9Jv13832
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 18:09:19 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13251
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 18:06:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4N92v13818;
	Mon, 4 Nov 2002 18:09:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4N8Uv13803
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 18:08:30 -0500
Received: from tcb.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13231
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 18:05:55 -0500 (EST)
Received: from dog.tcb.net (danny@localhost)
	by tcb.net (8.11.6/8.11.4) with ESMTP id gA4N3bJ13728;
	Mon, 4 Nov 2002 16:03:37 -0700
Message-Id: <200211042303.gA4N3bJ13728@tcb.net>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: Stephen Kent <kent@bbn.com>
cc: rpsec@ietf.org
From: Danny McPherson <danny@tcb.net>
Reply-To: danny@tcb.net
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 04 Nov 2002 16:03:37 -0700
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


Steve,
Do you have a pointer to this study?

-danny

> This last observation is not borne out by experience.  DARPA-funded 
> research reported in 2002 observed that about 1% of all advertised 
> routes are in error at any time.  Given current routing table sizes, 
> this amounts to about 1,000 routes.  Thus some number of ISPs do make 
> mistakes and their neighbors do propagate these errors to the rest of 
> the Internet. Mechanisms that detect and reject advertisements that 
> are in error do seem to be needed for BGP.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 18:10:12 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13398
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 18:10:12 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4NCGZ13966
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 18:12:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NCGv13963
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 18:12:16 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13393
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 18:09:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NC1v13952;
	Mon, 4 Nov 2002 18:12:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NB4v13920
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 18:11:04 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13327
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 18:08:29 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA06735
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 18:10:57 -0500 (EST)
Date: Mon, 4 Nov 2002 18:10:57 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: rpsec@ietf.org
Message-ID: <Pine.GSO.4.21.0211041748350.25244-100000@ruwhite-u10.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [RPSEC] Atlanta Agenda
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Y'all:

A Proposed Atlanta Agenda:

Agenda Bashing (5 minutes):             5
RP's over IPSec (20 minutes):          25
  (Dave Ward)
draft-beard-threats (15 minutes):      40
draft-murphy-threats (15 minutes):     55
draft-convery (15 minutes):            70
  (BGP attack tree)
draft-ng-sobgp (15 minutes):           85
  (draft-white-sobgp included)
draft-behringer-mpls-security-02.txt
  (10 minutes)                         95

The attack tree did not make it under the deadline, but was
posted to the rpsec list, so I assume that no-one will have any
objections to presenting it.

draft-white-sobgp is actually misnamed on the announcement,
because I cut and pasted some things without paying attention to
what I was doing. draft-ng is bgp extensions, and draft-white is
a (rather drafty) deployment doc. The sobgp drafts are
technically idr working group drafts, but are being presented
here to get security eyes on them, and because their topic seems
to have something to do with rp security.

If anyone has any other presentations they would like to do, or
anyone wants more or less time, please let either Tony or I know.

Please, please, please, read these drafts. I don't expect the
presentations to do much more than highlight the issues raised in
them, so reading the drafts is essential to understanding what is
going on. Really. Seriously. I mean it. 

:-)

Russ


__________________________________
riw@cisco.com CCIE <>< Grace Alone












_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 18:19:18 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13760
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 18:19:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4NLMt14324
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 18:21:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NLMv14321
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 18:21:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13739
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 18:18:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NL7v14295;
	Mon, 4 Nov 2002 18:21:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NKav14246
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 18:20:36 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13707
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 18:18:01 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15024;
	Mon, 4 Nov 2002 18:20:40 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p0510031db9ecae75b456@[128.89.88.34]>
In-Reply-To: <20021104225841.S50741-100000@sequoia.muada.com>
References: <20021104225841.S50741-100000@sequoia.muada.com>
Date: Mon, 4 Nov 2002 18:17:50 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: <rpsec@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 11:02 PM +0100 11/4/02, Iljitsch van Beijnum wrote:
>On Mon, 4 Nov 2002 sandy@tislabs.com wrote:
>
>>  >However, I think it is unnecessary to protect against "evil" ISPs since
>>  >they only get to do this once before they're disconnected and an ISP in
>>  >their right mind wouldn't do this.
>
>>  (A) There have been numerous occasions where ISP's have done this and
>>      they have not been disconnected.
>
>Then obviously not disconnecting yielded a better result than
>disconnecting.
>
>>  (B) To speak for the paranoid:  a routing system that knew that it was
>>      vulnerable to one faulty/misconfigured/subverted/evil ISP should
>>      not rely on self-interest of such ISP's to protect the world-wide net.
>
>Routers need better management in order to be able to filter very large
>numbers of routes, I'm all for that.

one could do a good job of filtering using static data about who is 
the legitimate originating AS for a given block of address space, but 
that data should be obtained from whoever is authoritative for 
managing address space assignments. The authoritative folks are are 
Internet Regional Registries.  They allocate blocks to ISPs and to 
subscribers, and the ISPs may allocate blocks to subscribers or to 
downstream ISPs, forming an obvious hierarchy. because this data is 
relatively static, downloading it from repositories and constructing 
filters would be a viable means of checking origin AS assertions in 
UPDATEs. Note that just relying on an ISP to advertise this data 
correctly via a repository is not a good idea, as the same config 
errors that cause route errors today could cause errors in posted 
data, and attacks on workstations used for configuration management 
by an ISP would have the same effect.

In contrast the route authorization data is dynamic and thus is a 
poor choice for posting to a repository for later download to 
construct filters. moreover, because some (many?) ISPs consider some 
of the policy data about relationships to be sensitive, it is hard to 
convince all ISPs to publish all of this data, which further limits 
the ability to make use of this sort of relatively static data as 
input to filters.

>However, some basic assumption of good will between ISPs is reasonable.

only to the extent that you wish to be vulnerable to errors by the 
ISP, or to attacks on the ISP management system that are externally 
equivalent to these sorts of benign errors.  I would suggest that a 
goal for BGP security is to find a way to detect and reject erroneous 
UPDATEs, irrespective of the way they come about. No ISP should trust 
another ISP to always do the right thing.

>We can do better things with our time than thinking up protocols to
>protect us against attacks that 1. we can't really protect ourselves
>against and 2. aren't going to happen anyway. BGP misconfiguration and
>DoS attacks against the root nameservers ARE happening, so let's focus
>on that kind of stuff.

Not sure what attacks you think fall into category 1. Do you have 
some examples in mind?

Steve


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 18:19:18 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13769
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 18:19:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4NLMI14339
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 18:21:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NLMv14336
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 18:21:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13741
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 18:18:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NL8v14311;
	Mon, 4 Nov 2002 18:21:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NKvv14256
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 18:20:57 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13712
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 18:18:22 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA4NKOX53048;
	Tue, 5 Nov 2002 00:20:25 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Tue, 5 Nov 2002 00:20:24 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Tony Tauber <ttauber@genuity.net>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <Pine.GSO.4.40.0211041717000.28401-100000@mesa.bbnplanet.com>
Message-ID: <20021104234816.W50741-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Mon, 4 Nov 2002, Tony Tauber wrote:

> > We can do better things with our time than thinking up protocols to
> > protect us against attacks that 1. we can't really protect ourselves
> > against and 2. aren't going to happen anyway. BGP misconfiguration
> > and DoS attacks against the root nameservers ARE happening, so let's
> > focus on that kind of stuff.

> The goal of the WG is to give better security guidance to routing
> protocol designers (and implementers), not to solve all problems of
> the operational Internet much less world hunger.

Ok.

> The sincere hope is that this effort will not result in a huge
> drain on the collective brainpower of the IETF nor will it take eons
> to complete.

Ok again. However, I think we should be careful not to go overboard. But
when that happens or is about to happen we can discuss it then so I'm
going to shut up about it now.

> Let's focus on the actual threat-modeling drafts at hand
> (beard, murphy, and convery).  In the convery draft ("Attack Tree"),

I'm reading those as we speak.

I found the first murphy draft misleading as it describes lots of
attacks that are easily mitigated by proper IP filters or the MD5
option. However, this is corrected mostly in the second one.

> what if we think more about the generic approach than the specific
> threats against BGP?  That would get this WG closer to its first goal
> which the charter tells us is:

> - Document threat models for routing systems

Here's one: someone implements security that is so airtight it proves
impossible to get the "systems" "routing".  :-)

> In other words, our time can be more productively spent than
> conversing about how many post-it notes it takes someone's NOC
> to run MD5 with a given vendor's BGP code.  That will come later. 8-)

I think a discussion on operational issues is important. For instance,
in theory you can simply filter all the prefixes and AS paths for all
routing updates. However, in practice this is impossible as there is no
good source of authorative information, it would be too slow, routers
can't hold such a large amount of filtering data, and there are no good
mechanisms to install filters in routers.

Note that this problem will only get worse as information in BGP is
signed.

About draft-convery-bgpattack-00.txt:

2.1.2 BGP on Cisco routers doesn't show up on a port scan. However,
finding out the addresses for BGP routers is otherwise often fairly
trivial.

2.1.3 (and later): I'm missing the part where the invalid
router/non-router gets access to the physical infrastructure and there
is no mention of compromising the MD5 option.

2.1.5 As BGP sessions are typically connected 99.9% of the time
attacking the service on TCP port 179 will not do much but generate lots
of "connection refused" packets. There are good mechanisms to handle
/32s (filtering) or flooding (update propagation delay, flap dampening).

2.1.6 missing the MD5 and IP filter protection mechanisms.

2.1.7 man "in the middle" is not necessary as it is trivial to pose as
the peer router if there is access to all the traffic.

One thing that isn't mentioned explicitly is introducing a very large
transitive path attribute for the sole purpose of eating up memory. This
can be effective if done on a sufficiently large number of BGP routes
(in the order of ten thousands).

If people don't filter properly you can also do very funny things by
routing the BGP next hop addresses into oblivion.

Iljitsch van Beijnum

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 18:26:12 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13944
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 18:26:12 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4NSGp14539
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 18:28:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NSGv14536
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 18:28:16 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13940
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 18:25:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NS2v14525;
	Mon, 4 Nov 2002 18:28:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NRNv14498
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 18:27:23 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13903
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 18:24:47 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA4NQg553086;
	Tue, 5 Nov 2002 00:26:43 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Tue, 5 Nov 2002 00:26:42 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Danny McPherson <danny@tcb.net>
cc: Stephen Kent <kent@bbn.com>, <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
In-Reply-To: <200211042303.gA4N3bJ13728@tcb.net>
Message-ID: <20021105002420.S50741-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Mon, 4 Nov 2002, Danny McPherson wrote:

> Steve,
> Do you have a pointer to this study?

I think that would be this one:
http://www.cs.washington.edu/homes/ratul/bgp/index.html

Note that only a small part of this is due to user error.

I learned this the hard way. A while ago, when replacing a prefix list
with an identical one under a different name I triggered maximum
prefixes for a peer even though there was no time there wasn't a valid
filter in place.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 18:49:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15067
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 18:49:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA4NpOp15973
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 18:51:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NpOv15970
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 18:51:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15041
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 18:48:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4Np9v15947;
	Mon, 4 Nov 2002 18:51:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4NoEv15872
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 18:50:14 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14914
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 18:47:40 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25145;
	Mon, 4 Nov 2002 18:50:06 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100320b9ecb52245db@[128.89.88.34]>
In-Reply-To: <200211042303.gA4N3bJ13728@tcb.net>
References: <200211042303.gA4N3bJ13728@tcb.net>
Date: Mon, 4 Nov 2002 18:41:11 -0500
To: danny@tcb.net
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: rpsec@ietf.org
Content-Type: multipart/alternative; boundary="============_-1175668626==_ma============"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

--============_-1175668626==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 4:03 PM -0700 11/4/02, Danny McPherson wrote:
>Steve,
>Do you have a pointer to this study?
>
>-danny
>
>>  This last observation is not borne out by experience.  DARPA-funded
>>  research reported in 2002 observed that about 1% of all advertised
>>  routes are in error at any time.  Given current routing table sizes,
>>  this amounts to about 1,000 routes.  Thus some number of ISPs do make
>>  mistakes and their neighbors do propagate these errors to the rest of
>>  the Internet. Mechanisms that detect and reject advertisements that
>  > are in error do seem to be needed for BGP.

A paper was published by these folks in SIGCOMM 2002:

Understanding BGP Misconfiguration. Ratul Mahajan, David Wetherall 
and Tom Anderson(University of Washington)
--============_-1175668626==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [RPSEC] Re:
draft-convery-bgpattack-00</title></head><body>
<div>At 4:03 PM -0700 11/4/02, Danny McPherson wrote:</div>
<blockquote type="cite" cite>Steve,<br>
Do you have a pointer to this study?<br>
<br>
-danny<br>
<br>
&gt; This last observation is not borne out by experience.&nbsp;
DARPA-funded<br>
&gt; research reported in 2002 observed that about 1% of all
advertised<br>
&gt; routes are in error at any time.&nbsp; Given current routing
table sizes,<br>
&gt; this amounts to about 1,000 routes.&nbsp; Thus some number of
ISPs do make<br>
&gt; mistakes and their neighbors do propagate these errors to the
rest of<br>
&gt; the Internet. Mechanisms that detect and reject advertisements
that</blockquote>
<blockquote type="cite" cite>&gt; are in error do seem to be needed
for BGP.</blockquote>
<div><br></div>
<div><font color="#000000">A paper was published by these folks in
SIGCOMM 2002:</font></div>
<div><font color="#000000"><br></font></div>
<div><font face="Times New Roman" size="+3"
color="#000000"><b>Understanding BGP Misconfiguration</b>.<i> Ratul
Mahajan, David Wetherall and Tom Anderson(University of
Washington)</i></font></div>
</body>
</html>
--============_-1175668626==_ma============--
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 19:22:27 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16015
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 19:22:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA50OTf17716
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 19:24:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA50OTv17713
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 19:24:29 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15990
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 19:21:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA50O8v17681;
	Mon, 4 Nov 2002 19:24:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA50NAv17622
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 19:23:10 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15941
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 19:20:36 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA50MQw53290;
	Tue, 5 Nov 2002 01:22:26 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Tue, 5 Nov 2002 01:22:26 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Stephen Kent <kent@bbn.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <p0510031db9ecae75b456@[128.89.88.34]>
Message-ID: <20021105005802.F50741-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Mon, 4 Nov 2002, Stephen Kent wrote:

> >Routers need better management in order to be able to filter very large
> >numbers of routes, I'm all for that.

> one could do a good job of filtering using static data about who is
> the legitimate originating AS for a given block of address space, but
> that data should be obtained from whoever is authoritative for
> managing address space assignments. The authoritative folks are are
> Internet Regional Registries.

They are now. However, documentation for some of the old assignments
seems rather iffy. Providing a mapping from the prefix to the router
sourcing that prefix might also be difficult. In other words: how do I
know a certain router belongs to a certian organization? But I guess
that's for the RIRs to figure out.

> Note that just relying on an ISP to advertise this data
> correctly via a repository is not a good idea, as the same config
> errors that cause route errors today could cause errors in posted
> data, and attacks on workstations used for configuration management
> by an ISP would have the same effect.

What exactly to you want to put in the repository? You could have the
RIRs maintain the prefix to AS mapping. Then it would be necessary to
query the repository to validate this information in a routing update.
Another way to go is for the RIRs to sign the prefix to AS mapping and
the router can check the signature. However, this is very costly in
memory and processing power, and propably also in management if there is
some kind of time to live involved to prevent replays. If the full
prefix to AS mapping information is available out of band anyway, there
is no need to cryptographically protect this information: either it is
the same as the repository data = valid or it is different = invalid.

> In contrast the route authorization data is dynamic and thus is a
> poor choice for posting to a repository for later download to
> construct filters.

I'm not sure I get what you mean.

> moreover, because some (many?) ISPs consider some
> of the policy data about relationships to be sensitive,

Big babies. The AS path information is there for everyone to see anyway.

> it is hard to
> convince all ISPs to publish all of this data, which further limits
> the ability to make use of this sort of relatively static data as
> input to filters.

At some point in the recent past people would relay email for the whole
world. Today, you are tarred and feathered for that. If there is a need,
it is possible get people to change their behavior.

> >However, some basic assumption of good will between ISPs is reasonable.

> only to the extent that you wish to be vulnerable to errors by the
> ISP, or to attacks on the ISP management system that are externally
> equivalent to these sorts of benign errors.  I would suggest that a
> goal for BGP security is to find a way to detect and reject erroneous
> UPDATEs, irrespective of the way they come about. No ISP should trust
> another ISP to always do the right thing.

Your ISP can blackhole or sniff your traffic any time they want to. Is
it really useful to build elaborate protection against them modifying a
path attribute or two?

What we need is to make sure people only announce the prefixes they
should announce. Tying a prefix to an AS isn't all that hard. The size
of the data isn't even an issue: 114,000 x (5 + 2 bytes) = 800 kB. It is
harder to make sure someone isn't faking a path to a valid origin AS.
But fortunately we don't have to protect the entire AS path: just the
transit ASes for the source AS should suffice. (Unless I'm mistaken I
explained this in a message last week or so.)

> >We can do better things with our time than thinking up protocols to
> >protect us against attacks that 1. we can't really protect ourselves
> >against and 2. aren't going to happen anyway. BGP misconfiguration and
> >DoS attacks against the root nameservers ARE happening, so let's focus
> >on that kind of stuff.

> Not sure what attacks you think fall into category 1. Do you have
> some examples in mind?

If an ISP wants to do nasty things they have more than enough ways to do
it without resorting to modifying BGP updates.

Iljitsch van Beijnum

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 21:35:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19754
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 21:35:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA52bQP26209
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 21:37:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA52bQv26206
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 21:37:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19703
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 21:34:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA52b7v25778;
	Mon, 4 Nov 2002 21:37:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA52Ybv25540
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 21:34:37 -0500
Received: from noxmail.sandelman.ottawa.on.ca (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19434
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 21:32:01 -0500 (EST)
Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20])
	by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gA52YMG21968
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK)
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 21:34:28 -0500 (EST)
Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1])
	by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA52YKNE030842
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK)
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 21:34:21 -0500
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA52YJ4S030837
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 21:34:20 -0500
Message-Id: <200211050234.gA52YJ4S030837@marajade.sandelman.ottawa.on.ca>
To: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
In-reply-to: Your message of "Mon, 04 Nov 2002 21:58:51 +0100."
             <20021104213833.C50741-100000@sequoia.muada.com> 
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 04 Nov 2002 21:34:19 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


>>>>> "Iljitsch" == Iljitsch van Beijnum <iljitsch@muada.com> writes:
    Iljitsch> Between ISPs filtering is problematic because of the large numbers of
    Iljitsch> routes exchanged. Also, an ISP could attach meaningless but large
    Iljitsch> attributes to routes to exhaust another ISP's router memory, and since
    Iljitsch> the number of routes is larger flapping does more harm.

    Iljitsch> However, I think it is unnecessary to protect against "evil" ISPs since
    Iljitsch> they only get to do this once before they're disconnected and an ISP in

  Overt anti-social behaviour is easy to notice and deal with.
  It is more subtle problems that are harder. They may be the result of
subtle misconfiguration, software errors, etc. It may also be the result of a
very targetted attack.  This is a concern for both white hats and spooks.
 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
    

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 22:56:26 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21985
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 22:56:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA53wWH29989
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 22:58:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA53wVv29986
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 22:58:31 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21943
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 22:55:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA53wCv29945;
	Mon, 4 Nov 2002 22:58:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA53uev29844
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 22:56:40 -0500
Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21912
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 22:54:03 -0500 (EST)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA53uHxF006049;
	Mon, 4 Nov 2002 19:56:18 -0800 (PST)
Received: from nisser.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA53uNTQ015774;
	Mon, 4 Nov 2002 19:56:24 -0800 (PST)
Received: from 10.0.11.201 (sjc-vpn1-274.cisco.com [10.21.97.18]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA10761; Mon, 4 Nov 2002 19:56:21 -0800 (PST)
Date: Mon,  4 Nov 2002 19:56:20 -0800
From: Sean Convery <sean@cisco.com>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
To: Iljitsch van Beijnum <iljitsch@muada.com>
cc: Tony Tauber <ttauber@genuity.net>, rpsec@ietf.org
X-Priority: 3
In-Reply-To: <20021104234816.W50741-100000@sequoia.muada.com>
Message-ID: <r01050400-1021-8D95ED51F07211D6B9A20003939CDD90@[10.0.11.201]>
MIME-Version: 1.0
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Mailsmith 1.5.4 (Blindsider)
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

comments inline.

On 11/5/02 at 12:20 AM, iljitsch@muada.com wrote:
>
SNIP

First, thanks very much for reviewing the draft!
>
>About draft-convery-bgpattack-00.txt:
>
>2.1.2 BGP on Cisco routers doesn't show up on a port scan. However,
>finding out the addresses for BGP routers is otherwise often fairly
>trivial.
>
We'd like to test this with a few implementations.  The BGP RFC doesn't
explicitly state to only allow BGP conversations between configured
peers (though it intuitively makes sense).  I agree there are other ways
to find the address.  Specifically in 2.1.2 subgoal 1 "Establish session
with permissive router" we're assuming you've discovered the address and
are now trying to see if the router will speak BGP or not.

We should define "permissive router" better.  Here we mean a router that
will speak BGP to an IP address not specifically defined as a peer.
Though I don't quite understand why an implementation would do this
(large hub-and-spoke networks perhaps?), we didn't want to rule anything
out.

>2.1.3 (and later): I'm missing the part where the invalid
>router/non-router gets access to the physical infrastructure and there
>is no mention of compromising the MD5 option.
>
We tried not to presuppose a specific attack environment in this draft.
We only wanted to walk through which attacks were possible.  We're
advocating further research be done (perhaps a second draft) to analyze
these attacks from different perspectives.  As a strawman, I'd like to
see:

Topology:

- ISP BGP Implementation (perhaps different types)
- Enterprise BGP Implementation - as a side rant, much of the
conversation I've seen on idr and rpsec seems to assume an ISP
deployment.  BGP is used plenty in enterprise environments as well.
Here MITM, sniffing, etc. become much more possible.

Attacker:

- blind attacker (no special access to the network)
- insider (some special access such as an employee of the enterprise
using BGP)

The easiest way we've come up with to do the analysis would be to assign
attributes to various parts of the tree based on different topologies
and attackers.  For more info check out the end of section 1 of the
draft.

Regarding MD5, that got its own section 2.1.1.  Any attack against a
system employing MD5 would need to first run through that section of the
tree assuming the overall attack requires the generation of valid TCP
179 messages.

For the entire tree, we assumed no best practices were employed, this
would give us a base set of attacks that could then be weeded down based
on lots of factors.  Rather than reference the end of section 1 again,
let me paste the passage I'm referring to:

"This I-D illustrates a simple BGP attack tree: subsequent analysis
should assign attributes (and possibly values) to each node of the tree.
This allows more quantitative methods to be used in analyzing the attack
tree data. These attributes could include:

    * Impact of the attack
    * Ease of attack execution
    * Cost of the attack
    * Presence of countermeasures (such as best practices)
    * Access/trust requirements to conduct attack

Analysis of this data will yield the subset of attacks that result in
the most damage, are the easiest to launch, the least costly, have the
least access requirements, and are unlikely to be mitigated by current
best practices. Addressing these attacks should be the initial focus of
any improvements to BGP or relevant best practices."

>2.1.5 As BGP sessions are typically connected 99.9% of the time
>attacking the service on TCP port 179 will not do much but generate
>lots of "connection refused" packets. There are good mechanisms to
>handle /32s (filtering) or flooding (update propagation delay, flap
>/dampening).
>
I think we need some published test data to decide this either way.
Based on my experience so far, I would bet that attacking TCP 179 will
have some impact on certain implementations.

>2.1.6 missing the MD5 and IP filter protection mechanisms.
>
See previous response regarding best practices.

>2.1.7 man "in the middle" is not necessary as it is trivial to pose as
>the peer router if there is access to all the traffic.
>
I'm not sure I understand your comment.  In this attack we're not
assuming access to all the traffic.  Here the attacker is trying to send
a spoofed BGP message.  This tree shows he can do it one of two ways:

1. TCP Sequence # attack + the spoofed BGP message
2. Some type of MITM + the spoofed BGP message

Based on the attacker's location, I agree that some of these attacks
will be more or less likely.

>One thing that isn't mentioned explicitly is introducing a very large
>transitive path attribute for the sole purpose of eating up memory.
>This can be effective if done on a sufficiently large number of BGP
>routes (in the order of ten thousands).
>
Good point, this would probably need to go into Section 2.1.5.4 "Valid
BGP Messages"  It might be a further elaboration on 2.1.5.4.2 "update
flooding"...

>If people don't filter properly you can also do very funny things by
>routing the BGP next hop addresses into oblivion.
>
Can you elaborate on that further?  I think I understand what you are
referring to, I'm just not sure where to put it in the tree.  Is this a
spoofed message or an intercepted and modified message from a valid
peer?

Thanks again for your comments.

Sean

>Iljitsch van Beijnum
>
>_______________________________________________
>RPSEC mailing list
>RPSEC@ietf.org
>https://www1.ietf.org/mailman/listinfo/rpsec
>
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov  4 22:58:11 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22039
	for <rpsec-archive@odin.ietf.org>; Mon, 4 Nov 2002 22:58:11 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA540HS30133
	for rpsec-archive@odin.ietf.org; Mon, 4 Nov 2002 23:00:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA540Hv30130
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 4 Nov 2002 23:00:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22018
	for <rpsec-web-archive@ietf.org>; Mon, 4 Nov 2002 22:57:40 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5402v30112;
	Mon, 4 Nov 2002 23:00:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA53xTv30053
	for <rpsec@optimus.ietf.org>; Mon, 4 Nov 2002 22:59:29 -0500
Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22009
	for <rpsec@ietf.org>; Mon, 4 Nov 2002 22:56:52 -0500 (EST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA53xKot008247;
	Mon, 4 Nov 2002 19:59:20 -0800 (PST)
Received: from nisser.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA53xJsI027694;
	Mon, 4 Nov 2002 19:59:19 -0800 (PST)
Received: from 10.0.11.201 (sjc-vpn1-274.cisco.com [10.21.97.18]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA11707; Mon, 4 Nov 2002 19:59:17 -0800 (PST)
Date: Mon,  4 Nov 2002 19:59:15 -0800
From: Sean Convery <sean@cisco.com>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc: rpsec@ietf.org
X-Priority: 3
In-Reply-To: <200211041742.gA4HgWYn001642@marajade.sandelman.ottawa.on.ca>
Message-ID: <r01050400-1021-F685389AF07211D6B9A20003939CDD90@[10.0.11.201]>
MIME-Version: 1.0
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Mailsmith 1.5.4 (Blindsider)
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Michael,

We didn't finish in time to make the cutoff, you can find them here:

http://trinux.sourceforge.net/draft-convery-bgpattack-00.txt
http://trinux.sourceforge.net/draft-convery-bgpattack-00.html

Thanks,

Sean

On 11/4/02 at 12:42 PM, mcr@sandelman.ottawa.on.ca wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>I don't find draft-convery-bgpattack-00 on the ietf site.
>(I have a nightly rsync of it...)
>
SNIP
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 03:40:04 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07655
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 03:40:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA58gCX23779
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 03:42:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA58gCv23769
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 03:42:12 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07630
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 03:39:33 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA58fkv23671;
	Tue, 5 Nov 2002 03:41:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA58aUv22612
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 03:36:30 -0500
Received: from segue.merit.edu (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07464
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 03:33:51 -0500 (EST)
Received: from merit.edu (outtolunch.merit.edu [198.108.60.177])
	by segue.merit.edu (Postfix) with ESMTP
	id B8AB65DF29; Tue,  5 Nov 2002 03:36:18 -0500 (EST)
To: Stephen Kent <kent@bbn.com>
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
In-reply-to: Your message of "Mon, 04 Nov 2002 18:17:50 EST."
             <p0510031db9ecae75b456@[128.89.88.34]> 
Date: Tue, 05 Nov 2002 03:36:18 -0500
From: "Larry J. Blunk" <ljb@merit.edu>
Message-Id: <20021105083618.B8AB65DF29@segue.merit.edu>
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> At 11:02 PM +0100 11/4/02, Iljitsch van Beijnum wrote:
> >On Mon, 4 Nov 2002 sandy@tislabs.com wrote:
> >
> >>  >However, I think it is unnecessary to protect against "evil" ISPs since
> >>  >they only get to do this once before they're disconnected and an ISP in
> >>  >their right mind wouldn't do this.
> >
> >>  (A) There have been numerous occasions where ISP's have done this and
> >>      they have not been disconnected.
> >
> >Then obviously not disconnecting yielded a better result than
> >disconnecting.
> >
> >>  (B) To speak for the paranoid:  a routing system that knew that it was
> >>      vulnerable to one faulty/misconfigured/subverted/evil ISP should
> >>      not rely on self-interest of such ISP's to protect the world-wide net
>.
> >
> >Routers need better management in order to be able to filter very large
> >numbers of routes, I'm all for that.
> 
> one could do a good job of filtering using static data about who is 
> the legitimate originating AS for a given block of address space, but 
> that data should be obtained from whoever is authoritative for 
> managing address space assignments. The authoritative folks are are 
> Internet Regional Registries.

  (minor nit, the preferred term is Regional Internet Registries (RIR's),
   so as not to confuse them with Internet Routing Registries (IRR's).

> They allocate blocks to ISPs and to 
> subscribers, and the ISPs may allocate blocks to subscribers or to 
> downstream ISPs, forming an obvious hierarchy. because this data is 
> relatively static, downloading it from repositories and constructing 
> filters would be a viable means of checking origin AS assertions in 
> UPDATEs. Note that just relying on an ISP to advertise this data 
> correctly via a repository is not a good idea, as the same config 
> errors that cause route errors today could cause errors in posted 
> data, and attacks on workstations used for configuration management 
> by an ISP would have the same effect.

   The problem is that there is generally no such hierarchy for legacy
and provider independent address blocks -- which constitute a significant
percentage of announced space.   In many cases, the originating AS
will be "owned" by a different organization than the address prefix.
There are even cases where the originating AS is in a different RIR
than the address prefix.  Another issue is that many providers
have multiple AS's assigned to them.  Should a provider be able to
specify which of their AS'es is allowed to originate a prefix?

   Clearly, you need to be able to express the
relationship between origin AS and address prefix.  The RPSL
route object represents one mechanism to make this association.  Note
that RIPE (and soon APNIC) requires authorization from the both
the AS owner and address prefix owner in order to create a route object
in their registry.  So they are not just relying on the ISP to
get the route object right.

> 
> In contrast the route authorization data is dynamic and thus is a 
> poor choice for posting to a repository for later download to 
> construct filters. moreover, because some (many?) ISPs consider some 
> of the policy data about relationships to be sensitive, it is hard to 
> convince all ISPs to publish all of this data, which further limits 
> the ability to make use of this sort of relatively static data as 
> input to filters.

    Again, how do you allow an organization with provider independent
address space switch from one provider's origin AS to another?  I don't see
any other way than with route authorization data (approved by both
the ISP and the owner of the address space).   No matter how you
generate filters, there will clearly be some loss in dynamism.

   Also, I don't understand what "sensitive" policy data is being
exposed here.  What is being published is the "public" origin AS for
a prefix which is already accessible to all.  If you happen to have
an internal network configuration where the "real" origin AS gets
rewritten, simply don't publish that information.  There's no requirement
that the same data in the public registries be used for internal
network configuration.   I am aware of one ISP that runs one registry
for their public routing policy data and another for their internal
proprietary data.


  -Larry Blunk
   Merit


> 
> >However, some basic assumption of good will between ISPs is reasonable.
> 
> only to the extent that you wish to be vulnerable to errors by the 
> ISP, or to attacks on the ISP management system that are externally 
> equivalent to these sorts of benign errors.  I would suggest that a 
> goal for BGP security is to find a way to detect and reject erroneous 
> UPDATEs, irrespective of the way they come about. No ISP should trust 
> another ISP to always do the right thing.
> 
> >We can do better things with our time than thinking up protocols to
> >protect us against attacks that 1. we can't really protect ourselves
> >against and 2. aren't going to happen anyway. BGP misconfiguration and
> >DoS attacks against the root nameservers ARE happening, so let's focus
> >on that kind of stuff.
> 
> Not sure what attacks you think fall into category 1. Do you have 
> some examples in mind?
> 
> Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 03:40:14 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07692
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 03:40:13 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA58gL023820
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 03:42:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA58gLv23817
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 03:42:21 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07639
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 03:39:42 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA58g6v23722;
	Tue, 5 Nov 2002 03:42:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA58d3v23310
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 03:39:12 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07498
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 03:36:10 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA58cAG54500;
	Tue, 5 Nov 2002 09:38:10 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Tue, 5 Nov 2002 09:38:10 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Sean Convery <sean@cisco.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <r01050400-1021-8D95ED51F07211D6B9A20003939CDD90@[10.0.11.201]>
Message-ID: <20021105090907.T50741-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Mon, 4 Nov 2002, Sean Convery wrote:

> >2.1.2 BGP on Cisco routers doesn't show up on a port scan. However,
> >finding out the addresses for BGP routers is otherwise often fairly
> >trivial.

> We'd like to test this with a few implementations.  The BGP RFC doesn't
> explicitly state to only allow BGP conversations between configured
> peers (though it intuitively makes sense).

Obviously it would be good to recommend practices that make all kinds of
bad things harder without impact to existing functionality. Cisco's
approach of only allowing TCP connections to port 179 from configured
peers and when there is no session is a good one.

However, Zebra for instance first accepts the connection and then drops
it again if there already is a session or if the address isn't
configured.

> I agree there are other ways to find the address.

http://www.ams-ix.net/cgi-bin/publicmembers.cgi?=db_search=&sort_on=3    :-)

> We should define "permissive router" better.  Here we mean a router that
> will speak BGP to an IP address not specifically defined as a peer.
> Though I don't quite understand why an implementation would do this
> (large hub-and-spoke networks perhaps?), we didn't want to rule anything
> out.

I seem to remember Cisco had a configuration command to enable this
behavior, but I can't find it at the moment. I guess it could come in
handy if you have to set up many neighbors quickly.

> >2.1.3 (and later): I'm missing the part where the invalid
> >router/non-router gets access to the physical infrastructure and there
> >is no mention of compromising the MD5 option.

> We tried not to presuppose a specific attack environment in this draft.

If you want to steal an IP address you have to be on the physical
subnet. This can happen by design (internet exchange) or accident (telco
screws up) but usually an attacker will have to do some work for this.

> - Enterprise BGP Implementation - as a side rant, much of the
> conversation I've seen on idr and rpsec seems to assume an ISP
> deployment.  BGP is used plenty in enterprise environments as well.
> Here MITM, sniffing, etc. become much more possible.

But enterprises aren't typically in the position to propagate much
malicious routing information as their ISPs filter them.

> - blind attacker (no special access to the network)

With TCP MD5 in place they shouldn't be able to do anything except DoS.

> - insider (some special access such as an employee of the enterprise
> using BGP)

:-(

> The easiest way we've come up with to do the analysis would be to assign
> attributes to various parts of the tree based on different topologies
> and attackers.  For more info check out the end of section 1 of the
> draft.

What I'd like to see is a simple web-based tool that has the tree and
allows you to add security measures such as anti-spoofing filters, MD5,
static MAC addresses on exchanges and so on, and then see how many of
the attacks go away. This could be a learning experience. Heck, I might
make something like this.

> Regarding MD5, that got its own section 2.1.1.  Any attack against a
> system employing MD5 would need to first run through that section of the
> tree assuming the overall attack requires the generation of valid TCP
> 179 messages.

I don't think this is made explicit in every place.

> For the entire tree, we assumed no best practices were employed, this
> would give us a base set of attacks that could then be weeded down based
> on lots of factors.

You don't mention a list of best practices... It might be good to
include a list. Actually I've been working on this for a while.

> >2.1.5 As BGP sessions are typically connected 99.9% of the time
> >attacking the service on TCP port 179 will not do much but generate
> >lots of "connection refused" packets. There are good mechanisms to
> >handle /32s (filtering) or flooding (update propagation delay, flap
> >/dampening).

> I think we need some published test data to decide this either way.
> Based on my experience so far, I would bet that attacking TCP 179 will
> have some impact on certain implementations.

This should be worth a presentation at a NANOG or RIPE meeting...

> >2.1.7 man "in the middle" is not necessary as it is trivial to pose as
> >the peer router if there is access to all the traffic.

> I'm not sure I understand your comment.  In this attack we're not
> assuming access to all the traffic.  Here the attacker is trying to send
> a spoofed BGP message.

For a successful man in the middle attack you must be able to:

AND - sniff original traffic
    - inject replacement traffic
    - block original traffic

However, man in the middle is more difficult to do than simply
completely assume the identity of the neighbor and yields no extra
results.

> This tree shows he can do it one of two ways:

> 1. TCP Sequence # attack + the spoofed BGP message

This will obviously break the existing BGP session pretty quickly and
then all routing information (spoofed or otherwise) from this peer is
removed.

> 2. Some type of MITM + the spoofed BGP message

> Based on the attacker's location, I agree that some of these attacks
> will be more or less likely.

MD5.  :-)

> >If people don't filter properly you can also do very funny things by
> >routing the BGP next hop addresses into oblivion.

> Can you elaborate on that further?  I think I understand what you are
> referring to, I'm just not sure where to put it in the tree.  Is this a
> spoofed message or an intercepted and modified message from a valid
> peer?

I suppose it could be either. What you do is inject a route that makes
the next hop address for other BGP routes point to an unexpected place.
For instance, you can announce the /24 for an IX as two /25s with the
next hop address set to your router and then you'll receive all traffic
for all peers connected to the IX. (However, the sessions would probably
go down in this case.) However, this can be stopped with proper inbound
route filters.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 09:52:27 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21213
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 09:52:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5EsRj16729
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 09:54:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5EsQv16726
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 09:54:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21114
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 09:51:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Es8v16713;
	Tue, 5 Nov 2002 09:54:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Erjv16680
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 09:53:45 -0500
Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21102
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 09:51:13 -0500 (EST)
Received: (from root@localhost)
	by presque.djinesys.com (8.11.3/8.11.1) id gA5ErdJ61950;
	Tue, 5 Nov 2002 09:53:39 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31])
	by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA5EraC61943;
	Tue, 5 Nov 2002 09:53:36 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: (from jhaas@localhost)
	by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA5Eral12128;
	Tue, 5 Nov 2002 09:53:36 -0500 (EST)
Date: Tue, 5 Nov 2002 09:53:36 -0500
From: Jeffrey Haas <jhaas@nexthop.com>
To: "Larry J. Blunk" <ljb@merit.edu>
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Message-ID: <20021105095336.D12071@nexthop.com>
References: <p0510031db9ecae75b456@[128.89.88.34]> <20021105083618.B8AB65DF29@segue.merit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20021105083618.B8AB65DF29@segue.merit.edu>; from ljb@merit.edu on Tue, Nov 05, 2002 at 03:36:18AM -0500
X-Virus-Scanned: by AMaViS perl-11
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Larry,

On Tue, Nov 05, 2002 at 03:36:18AM -0500, Larry J. Blunk wrote:
>    Also, I don't understand what "sensitive" policy data is being
> exposed here.

The issue is that the databases lack "scope".  A generic IRR should
contain objects that are visible in the public Internet.  However,
as you move closer to the provider, or even explore peering or
contractual relationships you will have routes being exchanged
that are not public.  For example, some more specific subnets
(customer specific) that are exchanged between two providers that may
not make it into the global Internet.

For security and sanity purposes, registering the objects would be
nice.  But the scope of the visibility should only be the two providers
in question - per the example above.  Right now, the only scope
we really have is an entire database.

> There's no requirement
> that the same data in the public registries be used for internal
> network configuration.   I am aware of one ISP that runs one registry
> for their public routing policy data and another for their internal
> proprietary data.

But scaling this to one db per relationship is a bit awkward.
Yes, the functionality is available, but the simplicity isn't quite there.

-- 
Jeff Haas 
NextHop Technologies
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 10:00:29 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21663
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 10:00:28 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5F2S717191
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 10:02:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5F2Sv17188
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 10:02:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21608
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 09:59:57 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5F22v17154;
	Tue, 5 Nov 2002 10:02:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5F1uv17138
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 10:01:56 -0500
Received: from mail1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21552
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 09:59:25 -0500 (EST)
Received: from bgreenew2k (dhcp-10-24-19-70.cisco.com [10.24.19.70]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA09398; Tue, 5 Nov 2002 07:01:43 -0800 (PST)
Reply-To: <bgreene@cisco.com>
From: "Barry Raveendran Greene" <bgreene@cisco.com>
To: "Iljitsch van Beijnum" <iljitsch@muada.com>, <sandy@tislabs.com>
Cc: <rpsec@ietf.org>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
Date: Tue, 5 Nov 2002 07:01:43 -0800
Message-ID: <LNEHJBNJAPFNLEGJHCPEEEDGKAAA.bgreene@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20021104225841.S50741-100000@sequoia.muada.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



> > >However, I think it is unnecessary to protect against "evil" ISPs since
> > >they only get to do this once before they're disconnected and an ISP in
> > >their right mind wouldn't do this.
>
> > (A) There have been numerous occasions where ISP's have done this and
> >     they have not been disconnected.
>
> Then obviously not disconnecting yielded a better result than
> disconnecting.
>
> > (B) To speak for the paranoid:  a routing system that knew that it was
> >     vulnerable to one faulty/misconfigured/subverted/evil ISP should
> >     not rely on self-interest of such ISP's to protect the
> world-wide net.
>
> Routers need better management in order to be able to filter very large
> numbers of routes, I'm all for that.

We really need better people managing the filters that we can do today.
Remember, the problem today is that ISPs are _not_ doing what they can do
with what they have. Ingress prefix filtering on the ISP-Customer edge is
haphazard. Ingress prefix filtering on the ISP-ISP side is weak. Egress
filtering on the ISP-ISP side is almost non-existent.

Understanding why people are not doing what they can do with what they have
is critical to anything new that is recommended. Given that we have big ISPs
(in the top ten based on Skitter) who do all three prefix filter modes
around the RIR boundaries on two major vendor's equipment, I would say that
the lack of prefix filtering has more to do with laziness than issues with
"evil" ISPs.



_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 10:28:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23499
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 10:28:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5FUMR19295
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 10:30:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5FUMv19292
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 10:30:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23487
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 10:27:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5FU8v19243;
	Tue, 5 Nov 2002 10:30:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5FT8v19197
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 10:29:08 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23450
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 10:26:37 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA5FSaf55077;
	Tue, 5 Nov 2002 16:28:36 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Tue, 5 Nov 2002 16:28:36 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Barry Raveendran Greene <bgreene@cisco.com>
cc: <rpsec@ietf.org>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <LNEHJBNJAPFNLEGJHCPEEEDGKAAA.bgreene@cisco.com>
Message-ID: <20021105161538.A50741-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Tue, 5 Nov 2002, Barry Raveendran Greene wrote:

> > Routers need better management in order to be able to filter very large
> > numbers of routes, I'm all for that.

> We really need better people managing the filters that we can do today.
> Remember, the problem today is that ISPs are _not_ doing what they can do
> with what they have. Ingress prefix filtering on the ISP-Customer edge is
> haphazard.

In my experience this is done relatively well today.

> Ingress prefix filtering on the ISP-ISP side is weak.

Yes, because the number or filters and the size of the filters gets hard
to control.

> Egress filtering on the ISP-ISP side is almost non-existent.

This could be better but I think most ISPs already do this, the filters
may simply not be strict enough.

> Understanding why people are not doing what they can do with what they have
> is critical to anything new that is recommended. Given that we have big ISPs
> (in the top ten based on Skitter) who do all three prefix filter modes
> around the RIR boundaries

What do you mean with "around the RIR boundaries"?

> on two major vendor's equipment, I would say that
> the lack of prefix filtering has more to do with laziness than issues with
> "evil" ISPs.

ISPs aren't evil. (At least, not more than other people.) The problem
with very strict prefix filtering is that you're essentially rebuilding
the entire global routing table as a set of prefix filters. (Well,
actually prefix filters aren't enough as they don't look at the AS
number.) Maybe there are people who do this, and more power to them, but
doing it using today's tools is a nightmare. Only very large networks
can spare people to implement something like this.

I don't think a solution where we daily download the RIR databases and
create route filters from them is the best we can do. This WILL break a
lot of connectivity for a variety of reasons. What I'd like to see is a
standardized way for a router to consult a policy server about the
routing updates it receives. The policy server then looks in its
database and decides whether the route is good or bad. This saves huge
amounts of storing configuration information and processing on the
routers, and everything is in a central place where it can easily be
monitored, controlled and secured. Also, people can choose the level of
security they want: policy server must validate before the route is
accepted, or the route is accepted but removed when the policy server
doesn't like it. The policy server can also push simple fall-back
policies to the routers so they can continue to operate when the policy
servers become unreachable.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 10:43:39 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24717
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 10:43:39 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5FjeN21099
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 10:45:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Fjev21095
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 10:45:40 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24639
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 10:43:08 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Fj1v21059;
	Tue, 5 Nov 2002 10:45:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5FiEv21011
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 10:44:14 -0500
Received: from roam.psg.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24542
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 10:41:43 -0500 (EST)
Received: from localhost
	([127.0.0.1] helo=roam.psg.com.psg.com ident=randy)
	by roam.psg.com with esmtp (Exim 4.05)
	id 1895sB-00036r-00; Tue, 05 Nov 2002 07:44:11 -0800
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Russ White <riw@cisco.com>
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Atlanta Agenda
References: <Pine.GSO.4.21.0211041748350.25244-100000@ruwhite-u10.cisco.com>
Message-Id: <E1895sB-00036r-00@roam.psg.com>
Date: Tue, 05 Nov 2002 07:44:11 -0800
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

how about ten minutes to discuss some operators' impressions from a 
small s-bgp workshop?

randy

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 10:44:25 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24883
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 10:44:25 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5FkPO21311
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 10:46:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5FkPv21308
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 10:46:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24744
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 10:43:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Fk5v21269;
	Tue, 5 Nov 2002 10:46:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Fjiv21111
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 10:45:44 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24643
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 10:43:13 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA00317;
	Tue, 5 Nov 2002 10:45:10 -0500 (EST)
Date: Tue, 5 Nov 2002 10:45:10 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Randy Bush <randy@psg.com>
cc: rpsec@ietf.org
Subject: Re: [RPSEC] Atlanta Agenda
In-Reply-To: <E1895sB-00036r-00@roam.psg.com>
Message-ID: <Pine.GSO.4.21.0211051044460.25428-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


Sure, I could do that....

Any objections?

:-)

Russ

On Tue, 5 Nov 2002, Randy Bush wrote:

> how about ten minutes to discuss some operators' impressions from a 
> small s-bgp workshop?
> 
> randy
> 

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 11:00:38 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25867
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 11:00:38 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5G2cA22378
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 11:02:38 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5G2cv22375
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 11:02:38 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25851
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 11:00:07 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5G2Ev22359;
	Tue, 5 Nov 2002 11:02:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5G1ov22340
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 11:01:50 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25811
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 10:59:18 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA5G1Fw55177;
	Tue, 5 Nov 2002 17:01:15 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Tue, 5 Nov 2002 17:01:15 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Randy Bush <randy@psg.com>
cc: Russ White <riw@cisco.com>, <rpsec@ietf.org>
Subject: Re: [RPSEC] Atlanta Agenda
In-Reply-To: <E1895sB-00036r-00@roam.psg.com>
Message-ID: <20021105170054.M50741-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Tue, 5 Nov 2002, Randy Bush wrote:

> how about ten minutes to discuss some operators' impressions from a
> small s-bgp workshop?

I think this needs more than 10 minutes...

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 11:02:15 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26008
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 11:02:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5G4G822494
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 11:04:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5G4Gv22491
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 11:04:16 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25970
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 11:01:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5G41v22483;
	Tue, 5 Nov 2002 11:04:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5G3Jv22451
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 11:03:19 -0500
Received: from kanmx1.ca.alcatel.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25894
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 11:00:47 -0500 (EST)
Received: (qmail 11236 invoked from network); 5 Nov 2002 16:08:40 -0000
Received: (ofmipd 138.120.250.19); 5 Nov 2002 16:08:18 -0000
Date: 5 Nov 2002 11:03:10 -0500
Message-Id: <5.0.2.1.2.20021105110149.00a7dd50@camail02.ca.alcatel.com>
From: "Ben Crosby" <ben.crosby@alcatel.com>
To: "Randy Bush" <randy@psg.com>
Cc: rpsec@ietf.org
X-Sender: bcrosby@camail02.ca.alcatel.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Subject: Re: [RPSEC] Atlanta Agenda
In-Reply-To: <E1895sB-00036r-00@roam.psg.com>
References: <Pine.GSO.4.21.0211041748350.25244-100000@ruwhite-u10.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 07:44 AM 11/5/2002 -0800, Randy Bush wrote:
>how about ten minutes to discuss some operators' impressions from a
>small s-bgp workshop?
>
>randy

Randy,

Is there any chance you could share some notes / observations and any 
presentation on the mailing list in advance of the meeting for those of us 
unable to attend ?

Many thanks,
Ben.


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 11:32:34 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27741
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 11:32:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5GYZn24767
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 11:34:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5GYZv24764
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 11:34:35 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27719
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 11:32:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5GYHv24730;
	Tue, 5 Nov 2002 11:34:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5GUOv24530
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 11:30:24 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27580
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 11:27:52 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA02261
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 11:30:20 -0500 (EST)
Date: Tue, 5 Nov 2002 11:30:20 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: rpsec@ietf.org
In-Reply-To: <Pine.GSO.4.21.0211041748350.25244-100000@ruwhite-u10.cisco.com>
Message-ID: <Pine.GSO.4.21.0211051128420.25428-100000@ruwhite-u10.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [RPSEC] Re: Atlanta Agenda
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


One change, as requested:

> Agenda Bashing (5 minutes):             5
> RP's over IPSec (20 minutes):          25
>   (Dave Ward)
> draft-beard-threats (15 minutes):      40
> draft-murphy-threats (15 minutes):     55
> draft-convery (15 minutes):            70
>   (BGP attack tree)

S-BGP Operator's Meeting (10 minutes):   80
  (Randy Bush)

> draft-ng-sobgp (15 minutes):           95
>   (draft-white-sobgp included)
> draft-behringer-mpls-security-02.txt
>   (10 minutes)                         105

> Please, please, please, read these drafts. I don't expect the
> presentations to do much more than highlight the issues
> raised in them, so reading the drafts is essential to
> understanding what is going on. Really. Seriously. I mean it.

I understand that it has been proposed for anyone who has not
read the drafts will be required to chop down the largest tree in
the forest with a herring. Or something like that.

:-)

Russ


__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 12:07:25 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29546
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 12:07:25 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5H9Q927973
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 12:09:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5H9Qv27970
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 12:09:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29525
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 12:06:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5H97v27924;
	Tue, 5 Nov 2002 12:09:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5H3Av26872
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 12:03:10 -0500
Received: from noxmail.sandelman.ottawa.on.ca (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29238
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 12:00:37 -0500 (EST)
Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20])
	by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gA5H2tG24399
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK)
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 12:03:01 -0500 (EST)
Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1])
	by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA5H2rNE016674
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK)
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 12:02:54 -0500
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA5H2qWV016669
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 12:02:52 -0500
Message-Id: <200211051702.gA5H2qWV016669@marajade.sandelman.ottawa.on.ca>
To: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
In-reply-to: Your message of "Tue, 05 Nov 2002 09:38:10 +0100."
             <20021105090907.T50741-100000@sequoia.muada.com> 
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 05 Nov 2002 12:02:51 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Iljitsch" == Iljitsch van Beijnum <iljitsch@muada.com> writes:
    Iljitsch> However, Zebra for instance first accepts the connection and then drops
    Iljitsch> it again if there already is a session or if the address isn't
    Iljitsch> configured.

  Well, Zebra is just a portable application, not an entire OS.
  We do not (yet?) have a portable way for an application to express
firewall rules to the OS. A good installation of Zebra would use
ipf,ipchains,iptables,etc. to block off port 179 from other origins.

    >> We should define "permissive router" better.  Here we mean a router that
    >> will speak BGP to an IP address not specifically defined as a peer.
    >> Though I don't quite understand why an implementation would do this
    >> (large hub-and-spoke networks perhaps?), we didn't want to rule anything
    >> out.

    Iljitsch> I seem to remember Cisco had a configuration command to enable this
    Iljitsch> behavior, but I can't find it at the moment. I guess it could come in
    Iljitsch> handy if you have to set up many neighbors quickly.

  I can see it being very useful in a lab environment.

    Iljitsch> What I'd like to see is a simple web-based tool that has the tree and
    Iljitsch> allows you to add security measures such as anti-spoofing filters, MD5,
    Iljitsch> static MAC addresses on exchanges and so on, and then see how many of
    Iljitsch> the attacks go away. This could be a learning experience. Heck, I might
    Iljitsch> make something like this.

  It would be a useful general tool for security analysis of protocols.

  BTW, I found the AND/OR stuff difficult to follow. 
  It seems you can write:
  (A || B || C) && D

  as:
		OR	A
			B
			C
		AND	D

  What's weird is that the OR is to the left of the first item (prefix), while the
AND is between C and D (infix).
  Perhaps I am misreading, and in fact the above describes:
	  A || B || (C && D)

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPcf5uYqHRg3pndX9AQEPlwP/a9gwKZlhjsehgPZydyIR4vyuC3iJdjJ1
g7Mepf+Y4AR/BGYENQmNH57FBhR2hNkSTIPLEO9z/lP2cyUoomNsj7Hxy0yPJOQ3
59OWPv7OSXmM9ZwTNOJVd/90eMgcV7AYfu4fFZESPH0m5ilkkeO4tpPe4Z7tS3OU
6KSm5GJDyhQ=
=oVi+
-----END PGP SIGNATURE-----
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 12:47:28 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01601
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 12:47:28 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5HnU730017
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 12:49:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5HnUv30014
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 12:49:30 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01585
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 12:46:57 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Hn9v29989;
	Tue, 5 Nov 2002 12:49:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Hmwv29968
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 12:48:58 -0500
Received: from noxmail.sandelman.ottawa.on.ca (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01580
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 12:46:24 -0500 (EST)
Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20])
	by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gA5HmjG24534
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK)
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 12:48:51 -0500 (EST)
Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1])
	by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA5HmiNE017409
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK)
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 12:48:45 -0500
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gA5HmhLV017405
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 12:48:44 -0500
Message-Id: <200211051748.gA5HmhLV017405@marajade.sandelman.ottawa.on.ca>
To: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
In-reply-to: Your message of "Tue, 05 Nov 2002 09:53:36 EST."
             <20021105095336.D12071@nexthop.com> 
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 05 Nov 2002 12:48:43 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


>>>>> "Jeffrey" == Jeffrey Haas <jhaas@nexthop.com> writes:
    Jeffrey> Larry,

    Jeffrey> On Tue, Nov 05, 2002 at 03:36:18AM -0500, Larry J. Blunk wrote:
    >> Also, I don't understand what "sensitive" policy data is being
    >> exposed here.

    Jeffrey> The issue is that the databases lack "scope".  A generic IRR should
    Jeffrey> contain objects that are visible in the public Internet.  However,
    Jeffrey> as you move closer to the provider, or even explore peering or
    Jeffrey> contractual relationships you will have routes being exchanged
    Jeffrey> that are not public.  For example, some more specific subnets
    Jeffrey> (customer specific) that are exchanged between two providers that may
    Jeffrey> not make it into the global Internet.

    Jeffrey> For security and sanity purposes, registering the objects would be
    Jeffrey> nice.  But the scope of the visibility should only be the two providers
    Jeffrey> in question - per the example above.  Right now, the only scope
    Jeffrey> we really have is an entire database.

  So you are arguing to do this within the protocol.

    Jeffrey> But scaling this to one db per relationship is a bit awkward.
    Jeffrey> Yes, the functionality is available, but the simplicity isn't quite there.

  Signed statements scale easily, and are as easy to filter out as the
advertisements themselves.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 14:52:54 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08926
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 14:52:54 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5JsuT04790
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 14:54:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5Jsuv04787
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 14:54:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08902
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 14:52:22 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5JsVv04772;
	Tue, 5 Nov 2002 14:54:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5JrMv04702
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 14:53:22 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08820
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 14:50:48 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28217;
	Tue, 5 Nov 2002 14:53:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100301b9edcbec5afd@[128.89.88.34]>
In-Reply-To: <20021105005802.F50741-100000@sequoia.muada.com>
References: <20021105005802.F50741-100000@sequoia.muada.com>
Date: Tue, 5 Nov 2002 14:53:21 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: <rpsec@ietf.org>
Content-Type: multipart/alternative; boundary="============_-1175596439==_ma============"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

--============_-1175596439==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 1:22 AM +0100 11/5/02, Iljitsch van Beijnum wrote:
>On Mon, 4 Nov 2002, Stephen Kent wrote:
>
>>  >Routers need better management in order to be able to filter very large
>>  >numbers of routes, I'm all for that.
>
>>  one could do a good job of filtering using static data about who is
>>  the legitimate originating AS for a given block of address space, but
>>  that data should be obtained from whoever is authoritative for
>>  managing address space assignments. The authoritative folks are are
>>  Internet Regional Registries.
>
>They are now. However, documentation for some of the old assignments
>seems rather iffy. Providing a mapping from the prefix to the router
>sourcing that prefix might also be difficult. In other words: how do I
>know a certain router belongs to a certian organization? But I guess
>that's for the RIRs to figure out.

Yes, the legacy address allocation data currently held by ARIN needs 
revalidation, but in the long run these registries still represent 
the best bet for authoritative data sources.

The question you ask about associating a router with an organization 
is also an important part of BGP security, although in our work we've 
found that what is really needed is associating a router with an AS 
that it represents, rather than with an organization per se.  Since 
the registries are also authoritative for assignment of AS numbers, 
they can serve as appropriate sources for an AS # to organization 
binding, and the organization can then, transitively, authorize its 
routers to represent the AS #('s) that the organization controls.

>
>>  Note that just relying on an ISP to advertise this data
>>  correctly via a repository is not a good idea, as the same config
>>  errors that cause route errors today could cause errors in posted
>>  data, and attacks on workstations used for configuration management
>>  by an ISP would have the same effect.
>
>What exactly to you want to put in the repository? You could have the
>RIRs maintain the prefix to AS mapping. Then it would be necessary to
>query the repository to validate this information in a routing update.
>Another way to go is for the RIRs to sign the prefix to AS mapping and
>the router can check the signature. However, this is very costly in
>memory and processing power, and propably also in management if there is
>some kind of time to live involved to prevent replays. If the full
>prefix to AS mapping information is available out of band anyway, there
>is no need to cryptographically protect this information: either it is
>the same as the repository data = valid or it is different = invalid.

Your model for how to effect bindings and the verify them may be a 
valid approach, but it is not the one that we've explored in our 
S-BGP work. In our approach, the registries issues X.509 certs to the 
owners of address space and owners of As #'s. These certs enable 
these folks (ISPs and multi-homed subscribers) to sign data that 
attests to address space ownership, origin AS authorization, etc.  I 
don't think it appropriate to detail all of the S-BGP architecture 
here, since we're focusing on requirements vs. solutions, but the 
following URL provides access to the papers we published: 
http://www.net-tech.bbn.com/sbgp/sbgp-index.html

When one talks about getting data from a repository to match against 
received UPDATEs, it is important to pay close attention to the 
dynamics, as I noted earlier. For example, you noted a binding 
between a prefix and an origin AS. This binding can be changed by the 
prefix owner, by establishing a new relationship with an ISP, and the 
registry that allocated the prefix need not be in the loop for this 
change.  So while some form of repository could be used to convey 
this data, the data really can be vouched for by the prefix "owner" 
without getting the registry involved. We don't want to create 
dependencies on interacting with folks (e.g., registry folks) when 
they are not strictly needed, as that could lead to new DoS 
opportunities.

>
>>  In contrast the route authorization data is dynamic and thus is a
>>  poor choice for posting to a repository for later download to
>>  construct filters.
>
>I'm not sure I get what you mean.

The choice of which IPSs are authorized to advertise which prefixes 
is potentially a dynamic form of binding that is ill served by 
relying on posting to a repository and waiting for every ISP to 
retrieve the newly posted data. When a major outage occurs, ISPs want 
to be able to make charges in these bindings very quickly and have 
the changes propagate very quickly, and that is not consistent with a 
repository model, I think.

>  > moreover, because some (many?) ISPs consider some
>>  of the policy data about relationships to be sensitive,
>
>Big babies. The AS path information is there for everyone to see anyway.
>
>>  it is hard to
>>  convince all ISPs to publish all of this data, which further limits
>>  the ability to make use of this sort of relatively static data as
>>  input to filters.
>
>At some point in the recent past people would relay email for the whole
>world. Today, you are tarred and feathered for that. If there is a need,
>it is possible get people to change their behavior.

In my experience, people change behavior only when they perceive the need.

>  > >However, some basic assumption of good will between ISPs is reasonable.
>
>>  only to the extent that you wish to be vulnerable to errors by the
>>  ISP, or to attacks on the ISP management system that are externally
>>  equivalent to these sorts of benign errors.  I would suggest that a
>>  goal for BGP security is to find a way to detect and reject erroneous
>>  UPDATEs, irrespective of the way they come about. No ISP should trust
>>  another ISP to always do the right thing.
>
>Your ISP can blackhole or sniff your traffic any time they want to. Is
>it really useful to build elaborate protection against them modifying a
>path attribute or two?

ISPs that are NOT on any authorized path to me ought not be able to 
divert my traffic through themselves, or to black hole my traffic, 
e.g., by advertising a shorter prefix for my net.

>What we need is to make sure people only announce the prefixes they
>should announce. Tying a prefix to an AS isn't all that hard. The size
>of the data isn't even an issue: 114,000 x (5 + 2 bytes) = 800 kB. It is
>harder to make sure someone isn't faking a path to a valid origin AS.
>But fortunately we don't have to protect the entire AS path: just the
>transit ASes for the source AS should suffice. (Unless I'm mistaken I
>explained this in a message last week or so.)

I think you are mistaken.

>  > >We can do better things with our time than thinking up protocols to
>>  >protect us against attacks that 1. we can't really protect ourselves
>>  >against and 2. aren't going to happen anyway. BGP misconfiguration and
>>  >DoS attacks against the root nameservers ARE happening, so let's focus
>>  >on that kind of stuff.
>
>>  Not sure what attacks you think fall into category 1. Do you have
>>  some examples in mind?
>
>If an ISP wants to do nasty things they have more than enough ways to do
>it without resorting to modifying BGP updates.

You are right if you refer to an ISP doing nasty things to its own 
subscribers. The principle of least privilege argues that we should 
try to prevent ISP A from doing unauthorized (bad) things to the 
subscribers of ISP B.

Steve
--============_-1175596439==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [RPSEC] Re:
draft-convery-bgpattack-00</title></head><body>
<div>At 1:22 AM +0100 11/5/02, Iljitsch van Beijnum wrote:</div>
<blockquote type="cite" cite>On Mon, 4 Nov 2002, Stephen Kent
wrote:<br>
<br>
&gt; &gt;Routers need better management in order to be able to filter
very large<br>
&gt; &gt;numbers of routes, I'm all for that.<br>
<br>
&gt; one could do a good job of filtering using static data about who
is<br>
&gt; the legitimate originating AS for a given block of address space,
but<br>
&gt; that data should be obtained from whoever is authoritative
for<br>
&gt; managing address space assignments. The authoritative folks are
are<br>
&gt; Internet Regional Registries.<br>
<br>
They are now. However, documentation for some of the old
assignments<br>
seems rather iffy. Providing a mapping from the prefix to the
router<br>
sourcing that prefix might also be difficult. In other words: how do
I<br>
know a certain router belongs to a certian organization? But I
guess<br>
that's for the RIRs to figure out.</blockquote>
<div><br></div>
<div>Yes, the legacy address allocation data currently held by ARIN
needs revalidation, but in the long run these registries still
represent the best bet for authoritative data sources.</div>
<div><br></div>
<div>The question you ask about associating a router with an
organization is also an important part of BGP security, although in
our work we've found that what is really needed is associating a
router with an AS that it represents, rather than with an organization
per se.&nbsp; Since the registries are also authoritative for
assignment of AS numbers, they can serve as appropriate sources for an
AS # to organization binding, and the organization can then,
transitively, authorize its routers to represent the AS #('s) that the
organization controls.</div>
<div><br></div>
<blockquote type="cite" cite><br>
&gt; Note that just relying on an ISP to advertise this data<br>
&gt; correctly via a repository is not a good idea, as the same
config<br>
&gt; errors that cause route errors today could cause errors in
posted<br>
&gt; data, and attacks on workstations used for configuration
management<br>
&gt; by an ISP would have the same effect.<br>
<br>
What exactly to you want to put in the repository? You could have
the<br>
RIRs maintain the prefix to AS mapping. Then it would be necessary
to<br>
query the repository to validate this information in a routing
update.<br>
Another way to go is for the RIRs to sign the prefix to AS mapping
and<br>
the router can check the signature. However, this is very costly
in<br>
memory and processing power, and propably also in management if there
is<br>
some kind of time to live involved to prevent replays. If the full<br>
prefix to AS mapping information is available out of band anyway,
there<br>
is no need to cryptographically protect this information: either it
is<br>
the same as the repository data = valid or it is different =
invalid.</blockquote>
<div><br></div>
<div>Your model for how to effect bindings and the verify them may be
a valid approach, but it is not the one that we've explored in our
S-BGP work. In our approach, the registries issues X.509 certs to the
owners of address space and owners of As #'s. These certs enable these
folks (ISPs and multi-homed subscribers) to sign data that attests to
address space ownership, origin AS authorization, etc.&nbsp; I don't
think it appropriate to detail all of the S-BGP architecture here,
since we're focusing on requirements vs. solutions, but the following
URL provides access to the papers we published:
http://www.net-tech.bbn.com/sbgp/sbgp-index.html</div>
<div><br></div>
<div>When one talks about getting data from a repository to match
against received UPDATEs, it is important to pay close attention to
the dynamics, as I noted earlier. For example, you noted a binding
between a prefix and an origin AS. This binding can be changed by the
prefix owner, by establishing a new relationship with an ISP, and the
registry that allocated the prefix need not be in the loop for this
change.&nbsp; So while some form of repository could be used to convey
this data, the data really can be vouched for by the prefix
&quot;owner&quot; without getting the registry involved. We don't want
to create dependencies on interacting with folks (e.g., registry
folks) when they are not strictly needed, as that could lead to new
DoS opportunities.</div>
<div><br></div>
<blockquote type="cite" cite><br>
&gt; In contrast the route authorization data is dynamic and thus is
a<br>
&gt; poor choice for posting to a repository for later download to<br>
&gt; construct filters.<br>
<br>
I'm not sure I get what you mean.</blockquote>
<div><br></div>
<div>The choice of which IPSs are authorized to advertise which
prefixes is potentially a dynamic form of binding that is ill served
by relying on posting to a repository and waiting for every ISP to
retrieve the newly posted data. When a major outage occurs, ISPs want
to be able to make charges in these bindings very quickly and have the
changes propagate very quickly, and that is not consistent with a
repository model, I think.</div>
<div><br></div>
<blockquote type="cite" cite>&gt; moreover, because some (many?) ISPs
consider some<br>
&gt; of the policy data about relationships to be sensitive,<br>
<br>
Big babies. The AS path information is there for everyone to see
anyway.<br>
<br>
&gt; it is hard to<br>
&gt; convince all ISPs to publish all of this data, which further
limits<br>
&gt; the ability to make use of this sort of relatively static data
as<br>
&gt; input to filters.<br>
<br>
At some point in the recent past people would relay email for the
whole<br>
world. Today, you are tarred and feathered for that. If there is a
need,<br>
it is possible get people to change their behavior.</blockquote>
<div><br></div>
<div>In my experience, people change behavior only when<u> they</u>
perceive the need.</div>
<div><br></div>
<blockquote type="cite" cite>&gt; &gt;However, some basic assumption
of good will between ISPs is reasonable.<br>
<br>
&gt; only to the extent that you wish to be vulnerable to errors by
the<br>
&gt; ISP, or to attacks on the ISP management system that are
externally<br>
&gt; equivalent to these sorts of benign errors.&nbsp; I would suggest
that a<br>
&gt; goal for BGP security is to find a way to detect and reject
erroneous<br>
&gt; UPDATEs, irrespective of the way they come about. No ISP should
trust<br>
&gt; another ISP to always do the right thing.<br>
<br>
Your ISP can blackhole or sniff your traffic any time they want to.
Is<br>
it really useful to build elaborate protection against them modifying
a</blockquote>
<blockquote type="cite" cite>path attribute or two?</blockquote>
<div><br></div>
<div>ISPs that are NOT on any authorized path to me ought not be able
to divert my traffic through themselves, or to black hole my traffic,
e.g., by advertising a shorter prefix for my net.</div>
<div><br></div>
<blockquote type="cite" cite>What we need is to make sure people only
announce the prefixes they<br>
should announce. Tying a prefix to an AS isn't all that hard. The
size<br>
of the data isn't even an issue: 114,000 x (5 + 2 bytes) = 800 kB. It
is<br>
harder to make sure someone isn't faking a path to a valid origin
AS.<br>
But fortunately we don't have to protect the entire AS path: just
the<br>
transit ASes for the source AS should suffice. (Unless I'm mistaken
I<br>
explained this in a message last week or so.)</blockquote>
<div><br></div>
<div>I think you are mistaken.<br>
</div>
<blockquote type="cite" cite>&gt; &gt;We can do better things with our
time than thinking up protocols to<br>
&gt; &gt;protect us against attacks that 1. we can't really protect
ourselves<br>
&gt; &gt;against and 2. aren't going to happen anyway. BGP
misconfiguration and<br>
&gt; &gt;DoS attacks against the root nameservers ARE happening, so
let's focus<br>
&gt; &gt;on that kind of stuff.<br>
<br>
&gt; Not sure what attacks you think fall into category 1. Do you
have<br>
&gt; some examples in mind?<br>
<br>
If an ISP wants to do nasty things they have more than enough ways to
do</blockquote>
<blockquote type="cite" cite>it without resorting to modifying BGP
updates.</blockquote>
<div><br></div>
<div>You are right if you refer to an ISP doing nasty things to its
own subscribers. The principle of least privilege argues that we
should try to prevent ISP A from doing unauthorized (bad) things to
the subscribers of ISP B.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1175596439==_ma============--
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 15:22:21 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11257
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 15:22:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA5KONG06534
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 15:24:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5KONv06531
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 15:24:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11202
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 15:21:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5KO8v06510;
	Tue, 5 Nov 2002 15:24:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5KMqv06477
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 15:22:52 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11163
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 15:20:18 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12125;
	Tue, 5 Nov 2002 15:22:46 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100303b9edd49162d9@[128.89.88.34]>
In-Reply-To: <20021105083618.B8AB65DF29@segue.merit.edu>
References: <20021105083618.B8AB65DF29@segue.merit.edu>
Date: Tue, 5 Nov 2002 15:14:24 -0500
To: "Larry J. Blunk" <ljb@merit.edu>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, rpsec@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Larry,

>(IRR's).
>
>>  They allocate blocks to ISPs and to
>>  subscribers, and the ISPs may allocate blocks to subscribers or to
>>  downstream ISPs, forming an obvious hierarchy. because this data is
>>  relatively static, downloading it from repositories and constructing
>>  filters would be a viable means of checking origin AS assertions in
>>  UPDATEs. Note that just relying on an ISP to advertise this data
>>  correctly via a repository is not a good idea, as the same config
>>  errors that cause route errors today could cause errors in posted
>>  data, and attacks on workstations used for configuration management
>>  by an ISP would have the same effect.
>
>    The problem is that there is generally no such hierarchy for legacy
>and provider independent address blocks -- which constitute a significant
>percentage of announced space.   In many cases, the originating AS
>will be "owned" by a different organization than the address prefix.
>There are even cases where the originating AS is in a different RIR
>than the address prefix.  Another issue is that many providers
>have multiple AS's assigned to them.  Should a provider be able to
>specify which of their AS'es is allowed to originate a prefix?

The hierarchy for prefixes allocated prior to the 1996 formation of 
the regional registries is just a short one, from IANA to the owner. 
ARIN has held all of this data but is working to reallocate it to the 
appropriate registries, based on the geopolitical affiliation of the 
owner.  But, it is still accommodated by the hierarchic model I 
described.

There is no problem (at least in the S-BGP work) accommodating the 
situations you describe, e.g., the originating AS differering from 
the prefix owner or an ISP with multiple AS #s being able to specifcy 
which AS originates which prefixes.  We also accommodate AS sets, 
path aggregation, etc.  Yes, all of these real world characteristics 
of BGP must be accommodated by any viable solution.

>    Clearly, you need to be able to express the
>relationship between origin AS and address prefix.  The RPSL
>route object represents one mechanism to make this association.  Note
>that RIPE (and soon APNIC) requires authorization from the both
>the AS owner and address prefix owner in order to create a route object
>in their registry.  So they are not just relying on the ISP to
>get the route object right.

Yes, RPSL can be used to express this data, and the approach used in 
S-BGP is roughly equivalent, but with explicit articulation of how 
the owner securely expresses this relationship.

>  > In contrast the route authorization data is dynamic and thus is a
>  > poor choice for posting to a repository for later download to
>>  construct filters. moreover, because some (many?) ISPs consider some
>>  of the policy data about relationships to be sensitive, it is hard to
>>  convince all ISPs to publish all of this data, which further limits
>>  the ability to make use of this sort of relatively static data as
>>  input to filters.
>
>     Again, how do you allow an organization with provider independent
>address space switch from one provider's origin AS to another?  I don't see
>any other way than with route authorization data (approved by both
>the ISP and the owner of the address space).   No matter how you
>generate filters, there will clearly be some loss in dynamism.

I refer you to the S-BGP documents, a URL for which I posted earlier 
today, for the details on how an orgabnization with a prefix that is 
provider independent expresses the origin AS binding.

Yes, if one choose to use filters and to construct them from static 
data sources, then there is a dynamics mismatch.

>    Also, I don't understand what "sensitive" policy data is being
>exposed here.  What is being published is the "public" origin AS for
>a prefix which is already accessible to all.  If you happen to have
>an internal network configuration where the "real" origin AS gets
>rewritten, simply don't publish that information.  There's no requirement
>that the same data in the public registries be used for internal
>network configuration.   I am aware of one ISP that runs one registry
>for their public routing policy data and another for their internal
>proprietary data.

If the route registries included only the origin AS info, I agree 
that this would not be too sensitive, but my understanding is that 
these registries also include info about the routes authorized 
between ISPs, including fallback paths, and that's where the info 
becomes more sensitive.

Securing the origin AS for a prefix is a good start, but it falls 
well short of addressing many forms of routing attacks, as I noted in 
a previous message.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov  5 22:20:28 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08038
	for <rpsec-archive@odin.ietf.org>; Tue, 5 Nov 2002 22:20:28 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA63MYY31480
	for rpsec-archive@odin.ietf.org; Tue, 5 Nov 2002 22:22:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA63MYv31477
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 5 Nov 2002 22:22:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08006
	for <rpsec-web-archive@ietf.org>; Tue, 5 Nov 2002 22:19:57 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA63M7v31446;
	Tue, 5 Nov 2002 22:22:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA63Lav31367
	for <rpsec@optimus.ietf.org>; Tue, 5 Nov 2002 22:21:36 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07985
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 22:19:00 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA00240
	for <rpsec@ietf.org>; Tue, 5 Nov 2002 22:21:28 -0500 (EST)
Date: Tue, 5 Nov 2002 22:21:28 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: rpsec@ietf.org
In-Reply-To: <Pine.GSO.4.21.0211051128420.25428-100000@ruwhite-u10.cisco.com>
Message-ID: <Pine.GSO.4.21.0211052219280.25525-100000@ruwhite-u10.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [RPSEC] Re: Atlanta Agenda
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


Another change, as requested:

Agenda Bashing (5 minutes):             5
RP's over IPSec (20 minutes):          25
  (Dave Ward)
draft-beard-threats (15 minutes):      40
draft-murphy-threats (15 minutes):     55
draft-convery (15 minutes):            70
  (BGP attack tree)
S-BGP Operator's Meeting (15 minutes): 85
  (Randy Bush)
draft-ng-sobgp (15 minutes):          100
  (draft-white-sobgp included)

I've also given Randy some more time, and could increase others
as needed. I assume we're likely to go over with mic time
included. Now, stop reading your email, and get back to reading
those drafts!

Russ

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 03:52:17 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09503
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 03:52:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA68sPi26996
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 03:54:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA68sPv26993
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 03:54:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09497
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 03:51:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA68s5v26975;
	Wed, 6 Nov 2002 03:54:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA68rov26960
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 03:53:50 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09481
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 03:51:11 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA68qx957645;
	Wed, 6 Nov 2002 09:52:59 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Wed, 6 Nov 2002 09:52:58 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Stephen Kent <kent@bbn.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <p05100301b9edcbec5afd@[128.89.88.34]>
Message-ID: <20021106093019.D50741-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Tue, 5 Nov 2002, Stephen Kent wrote:

> >If the full
> >prefix to AS mapping information is available out of band anyway, there
> >is no need to cryptographically protect this information: either it is
> >the same as the repository data = valid or it is different = invalid.

> Your model for how to effect bindings and the verify them may be a
> valid approach, but it is not the one that we've explored in our
> S-BGP work.

There are other things that aren't explored well enough in S-BGP. One
thing that bothers me a lot is the fact that a routing update must be
generated for each neighbor individually. This breaks a common
optimization where the same update is sent to a large number of
neighbors. I'm not convinced that having some kind of destination
identifier in an update is necessary, but if it is it should still be
possible to somehow group neighbors so the optimization remains intact.

Did you calculate the extra memory needed for full S-BGP deployment
throughout the internet?

And I think a solution where the routers themselves do all the
authenticating is inherently problematic because of performance and
security issues. A flimsy lock on a colo rack isn't enough to protect
your secret keys.

> In our approach, the registries issues X.509 certs to the
> owners of address space and owners of As #'s. These certs enable
> these folks (ISPs and multi-homed subscribers) to sign data that
> attests to address space ownership, origin AS authorization, etc.  I
> don't think it appropriate to detail all of the S-BGP architecture
> here, since we're focusing on requirements vs. solutions,

Well, we can use S-BGP as an example of what we should require.  :-)

> >>  I would suggest that a
> >>  goal for BGP security is to find a way to detect and reject erroneous
> >>  UPDATEs, irrespective of the way they come about. No ISP should trust
> >>  another ISP to always do the right thing.

> >Your ISP can blackhole or sniff your traffic any time they want to. Is
> >it really useful to build elaborate protection against them modifying a
> >path attribute or two?

> ISPs that are NOT on any authorized path to me ought not be able to
> divert my traffic through themselves, or to black hole my traffic,
> e.g., by advertising a shorter prefix for my net.

Ok, we're in agreement there. However, I wonder if there isn't a less
heavy-weight way to detect this situation than do public key crypto on
each update. One optimization would be to only check updates that would
install a new better path towards a destination. Also, AS paths are
often very similar across a somewhat large number of routes, so there is
probably a way to check the path once and accept many updates rather
than do it for each update individually.

> >What we need is to make sure people only announce the prefixes they
> >should announce. Tying a prefix to an AS isn't all that hard. The size
> >of the data isn't even an issue: 114,000 x (5 + 2 bytes) = 800 kB. It is
> >harder to make sure someone isn't faking a path to a valid origin AS.
> >But fortunately we don't have to protect the entire AS path: just the
> >transit ASes for the source AS should suffice. (Unless I'm mistaken I
> >explained this in a message last week or so.)

> I think you are mistaken.

It's a bit longer ago. Here it is again, with slight modifications:

Validating the AS path is difficult if we look at the AS path as
something that can take many shapes. But in reality, it consists only of
two things:

- the part the source of the routing update has a business relationship
  with, and
- the part that the part that the source of the traffic has a business
  relationship with

Suppose:

- AS1 is a customer of AS2
- AS2 is a customer of AS3
- AS5 is a customer of AS4
- ASes 3 and 4 peer

The AS path as seen by AS1 is: 2 3 4 5. AS2 trusts AS3 because they
(presumably) have a tamper-proof and direct connection to them, and they
pay them money to handle the traffic. The same is true for AS1 with AS2.
AS1 also trusts AS3, because indirectly, AS1 is also a customer of AS3
and the connection is through the trusted AS2.

However, AS3 may not necessarily trust AS4, even though they have a
direct connection. ISPs may peer with hundreds of ASes and some of those
send hundreds or thousands of routes. It is hard (using current tools
and mechanisms) for AS3 to verify independently that everything they
hear from AS4 is correct.

This could be remedied by AS5 including all the possible trusted partial
paths in an update and signing it. So AS5 creates an announcement that
includes the address information, a signature from a registry that
confirms the addresses belong to AS5, and the partial path "4 5". When AS1
receives this information with the path 2 3 4 5 it can decide this is a
trustworthy path because it trusts 2 3 and the signature covers 4 5.

(In reality AS5 will be multihomed so the list of possible paths becomes
"4 5", "6 5", "4 6 5" and "6 4 5".)

Or maybe the set of possible transit ASes could be unstructured.

Iljitsch van Beijnum

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 08:01:35 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16053
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 08:01:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6D3XN09897
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 08:03:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6D3Xv09894
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 08:03:33 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16029
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 08:01:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6D3Bv09881;
	Wed, 6 Nov 2002 08:03:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6D2wv09861
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 08:02:58 -0500
Received: from roam.psg.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16002
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 08:00:28 -0500 (EST)
Received: from localhost
	([127.0.0.1] helo=roam.psg.com.psg.com ident=randy)
	by roam.psg.com with esmtp (Exim 4.05)
	id 189Ppe-0009vd-00; Wed, 06 Nov 2002 05:02:54 -0800
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Russ White <riw@cisco.com>
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Re: Atlanta Agenda
References: <Pine.GSO.4.21.0211051128420.25428-100000@ruwhite-u10.cisco.com>
	<Pine.GSO.4.21.0211052219280.25525-100000@ruwhite-u10.cisco.com>
Message-Id: <E189Ppe-0009vd-00@roam.psg.com>
Date: Wed, 06 Nov 2002 05:02:54 -0800
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> I've also given Randy some more time

not needed.  i don't have that much to say.  i'll donate five
minutes back to general discussion of directions and strategy,
which i think is quite important.

randy

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 08:51:24 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17975
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 08:51:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6DrNN13462
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 08:53:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6DrNv13459
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 08:53:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17971
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 08:50:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Dr8v13449;
	Wed, 6 Nov 2002 08:53:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Dqiv13425
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 08:52:44 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17968
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 08:50:14 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id IAA27658; Wed, 6 Nov 2002 08:52:46 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma027616; Wed, 6 Nov 02 08:52:08 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gA6Dq2404947;
	Wed, 6 Nov 2002 08:52:02 -0500 (EST)
Date: Wed, 6 Nov 2002 08:52:02 -0500 (EST)
Message-Id: <200211061352.gA6Dq2404947@raven.gw.tislabs.com>
To: iljitsch@muada.com, kent@bbn.com
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>There are other things that aren't explored well enough in S-BGP. One
>thing that bothers me a lot is the fact that a routing update must be
>generated for each neighbor individually. This breaks a common
>optimization where the same update is sent to a large number of
>neighbors. I'm not convinced that having some kind of destination
>identifier in an update is necessary, but if it is it should still be
>possible to somehow group neighbors so the optimization remains intact.

The separate updates to each neighbor are needed because the neighbor's
identity has to be included in what is signed.  Otherwise, someone could
take a lot of purloined updates from the net, break them up into pieces
and reassemble into whatever sort of AS_Path they wanted.

Yes, this is a bummer because it removes the opportunity to optimize
if you are advertising the same thing to lots of neighbors.

The signature scheme might be expandable so that you sign a set of
neighbor identities into the update, rather than just one.  This would
be useful if you had lots and lots of neighbors that you could break
into a lot of groups of lots of neighbors, where the advertised routes
to each neighbor in one group would be the same - then you would still
get some optimization.  Would such situations be common?

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 09:05:32 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19305
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 09:05:32 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6E7WE14828
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 09:07:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6E7Wv14825
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 09:07:32 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19267
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 09:05:01 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6E76v14415;
	Wed, 6 Nov 2002 09:07:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6E64v14188
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 09:06:04 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19134
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 09:03:32 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA6E5Lk58113;
	Wed, 6 Nov 2002 15:05:21 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Wed, 6 Nov 2002 15:05:21 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: <sandy@tislabs.com>
cc: <kent@bbn.com>, <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <200211061352.gA6Dq2404947@raven.gw.tislabs.com>
Message-ID: <20021106145416.S50741-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, 6 Nov 2002 sandy@tislabs.com wrote:

> The separate updates to each neighbor are needed because the neighbor's
> identity has to be included in what is signed.  Otherwise, someone could
> take a lot of purloined updates from the net, break them up into pieces
> and reassemble into whatever sort of AS_Path they wanted.

I'll have to reread S-BGP as it has been a couple of months or so, so
maybe I'm saying things that are discussed in the draft, but...

Wouldn't AS X be the only one who can successfully send an update with
AS X as the first/last AS in the AS path? If AS Y took this update and
announced it then either it would have to add AS Y as per RFC 1771 and
the path and thus the entire update would be different, or it wouldn't
and a very simple sanity check would fail.

> Yes, this is a bummer because it removes the opportunity to optimize
> if you are advertising the same thing to lots of neighbors.

If this was important enough to implement now, it will certainly be an
important optimization if routers have to sign each update.

> The signature scheme might be expandable so that you sign a set of
> neighbor identities into the update, rather than just one.  This would
> be useful if you had lots and lots of neighbors that you could break
> into a lot of groups of lots of neighbors, where the advertised routes
> to each neighbor in one group would be the same - then you would still
> get some optimization.  Would such situations be common?

Yes, except maybe for the "lots of groups" part. A lot of traffic is
exchanged at internet exchanges. Typically, all peer routers share the
same settings for outbound updates. For instance, I manage a router with
103 peers in 4 groups, with the largest group having some 40 neighbors.

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 09:35:31 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22047
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 09:35:31 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6EbVD17081
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 09:37:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6EbVv17078
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 09:37:31 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22002
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 09:35:00 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Eb4v16637;
	Wed, 6 Nov 2002 09:37:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Eajv16469
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 09:36:45 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21928
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 09:34:14 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id JAA29730; Wed, 6 Nov 2002 09:36:46 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma029652; Wed, 6 Nov 02 09:36:18 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gA6EaDS09150;
	Wed, 6 Nov 2002 09:36:13 -0500 (EST)
Date: Wed, 6 Nov 2002 09:36:13 -0500 (EST)
Message-Id: <200211061436.gA6EaDS09150@raven.gw.tislabs.com>
To: iljitsch@muada.com, sandy@tislabs.com
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: kent@bbn.com, rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>Wouldn't AS X be the only one who can successfully send an update with
>AS X as the first/last AS in the AS path? If AS Y took this update and
>announced it then either it would have to add AS Y as per RFC 1771 and
>the path and thus the entire update would be different, or it wouldn't
>and a very simple sanity check would fail.

(a) See recent discussion on idr list about whether AS's always, always,
always add their own AS to the AS_PATH before transmitting updates.

(b) If someone finds an AS_PATH that ends in AS X, signed by AS X but
without including AS X's neighbor in the signature, then that someone
(call it AS N) can announce an AS_PATH that ends in "...., AS X, AS N"
without actually being a neighbor of AS_X.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 10:12:27 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25278
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 10:12:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6FERP19807
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 10:14:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FERv19804
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 10:14:27 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25267
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 10:11:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FE8v19796;
	Wed, 6 Nov 2002 10:14:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FDcv19767
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 10:13:38 -0500
Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25205
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 10:11:06 -0500 (EST)
Received: (from root@localhost)
	by presque.djinesys.com (8.11.3/8.11.1) id gA6FDXL08896;
	Wed, 6 Nov 2002 10:13:33 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31])
	by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA6FDUC08889;
	Wed, 6 Nov 2002 10:13:30 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: (from jhaas@localhost)
	by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA6FDUc18854;
	Wed, 6 Nov 2002 10:13:30 -0500 (EST)
Date: Wed, 6 Nov 2002 10:13:30 -0500
From: Jeffrey Haas <jhaas@nexthop.com>
To: sandy@tislabs.com
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Message-ID: <20021106101330.A18700@nexthop.com>
References: <200211061436.gA6EaDS09150@raven.gw.tislabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200211061436.gA6EaDS09150@raven.gw.tislabs.com>; from sandy@tislabs.com on Wed, Nov 06, 2002 at 09:36:13AM -0500
X-Virus-Scanned: by AMaViS perl-11
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Please note that since I haven't had a chance to read s-bgp I may
have missed some of the intricacies of this thread.

On Wed, Nov 06, 2002 at 09:36:13AM -0500, sandy@tislabs.com wrote:
> (a) See recent discussion on idr list about whether AS's always, always,
> always add their own AS to the AS_PATH before transmitting updates.

The only typical (and extremely a-typical at that) example of this
situation is with a route server.

Given what route servers are used for (typically, inter-domain proxying
of routing policy), it is likely that in an environment where 
certificates are used that each route server peer will delegate some
form of signing authority to the server where that authority isn't
*exactly* the same as the peer itself.

Thus, I authorize the server to sign my updates (which I have already
signed) with something weaker that says that "I am authorized to
transparently proxy this route.  Once you validate me, ignore me."

Or, in other words, the signing would be bound to the originating
peer's update - a co-signature if you will.

> --Sandy

-- 
Jeff Haas 
NextHop Technologies
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 10:34:19 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26986
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 10:34:19 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6FaKm21222
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 10:36:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FaKv21219
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 10:36:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26971
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 10:33:48 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Fa5v21205;
	Wed, 6 Nov 2002 10:36:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FXpv20982
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 10:33:51 -0500
Received: from mail1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26827
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 10:31:19 -0500 (EST)
Received: from bgreenew2k (dhcp-10-24-19-70.cisco.com [10.24.19.70]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA15641; Wed, 6 Nov 2002 07:30:38 -0800 (PST)
Reply-To: <bgreene@cisco.com>
From: "Barry Raveendran Greene" <bgreene@cisco.com>
To: <sandy@tislabs.com>, <iljitsch@muada.com>, <kent@bbn.com>
Cc: <rpsec@ietf.org>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
Date: Wed, 6 Nov 2002 07:30:30 -0800
Message-ID: <LNEHJBNJAPFNLEGJHCPEGELBKAAA.bgreene@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200211061352.gA6Dq2404947@raven.gw.tislabs.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



> >There are other things that aren't explored well enough in S-BGP. One
> >thing that bothers me a lot is the fact that a routing update must be
> >generated for each neighbor individually. This breaks a common
> >optimization where the same update is sent to a large number of
> >neighbors. I'm not convinced that having some kind of destination
> >identifier in an update is necessary, but if it is it should still be
> >possible to somehow group neighbors so the optimization remains intact.
>
> The separate updates to each neighbor are needed because the neighbor's
> identity has to be included in what is signed.  Otherwise, someone could
> take a lot of purloined updates from the net, break them up into pieces
> and reassemble into whatever sort of AS_Path they wanted.
>
> Yes, this is a bummer because it removes the opportunity to optimize
> if you are advertising the same thing to lots of neighbors.

It is also operationally not deployable and capital exclusive. Peer Groups
are a necessity to convergence speeds. No peer groups means really slow
convergence. This is eBGP and iBGP peer groups - both are deployed. The only
thing holding up faster deployment is the ability to teach people the value
of them. Once ISPs know, they draft up a deployment plan and push them out.
The additional benefit peer groups provide is memory optimization. Some
equipment with memory/RIB/FIB requirements designed for the mid-90's need
peer groups as means to optimize memory. So removing this capability means
that you force capital spending and network wide extended maintenance
windows to execute the upgrades.

IMHO - "Security requirements" that force Internet capital spending and
network wide maintenance windows to deploy are not going to be adopted by
the operations community.

Barry

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 10:35:24 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27069
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 10:35:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6FbOS21823
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 10:37:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FbOv21820
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 10:37:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27008
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 10:34:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FbAv21648;
	Wed, 6 Nov 2002 10:37:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FZBv21047
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 10:35:11 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26915
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 10:32:39 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id KAA02996; Wed, 6 Nov 2002 10:35:11 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma002970; Wed, 6 Nov 02 10:34:20 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gA6FYFl13961;
	Wed, 6 Nov 2002 10:34:15 -0500 (EST)
Date: Wed, 6 Nov 2002 10:34:15 -0500 (EST)
Message-Id: <200211061534.gA6FYFl13961@raven.gw.tislabs.com>
To: jhaas@nexthop.com, sandy@tislabs.com
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>> (a) See recent discussion on idr list about whether AS's always, always,
>> always add their own AS to the AS_PATH before transmitting updates.
>
>The only typical (and extremely a-typical at that) example of this
>situation is with a route server.
>...
>Thus, I authorize the server to sign my updates (which I have already
>signed) with something weaker that says that "I am authorized to
>transparently proxy this route.  Once you validate me, ignore me."

Yes, something like this might be introduced to allow for route servers.
There are other checks and balances (I've been watching too much election
news) in SBGP that ensure that a router is truly authorized to speak
for an AS and such that would have to be accounted for.

But I don't want to get segued into talking about route servers.  The
conversation had to do with the need to include your neighbor id in what
you sign for an update and Iljitsch's response implied that this had
something to do with checking the AS that is on top of the list.
It doesn't, as I tried to point out.  But I noted the coincidence of the
discussion on the idr list.  I brought it up only for the purpose of
noting the coincidence.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 10:47:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27957
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 10:47:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6FnNZ22719
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 10:49:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FnNv22716
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 10:49:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27936
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 10:46:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Fi1v22253;
	Wed, 6 Nov 2002 10:44:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FhIv22212
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 10:43:18 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27341
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 10:40:46 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id KAA03267; Wed, 6 Nov 2002 10:43:18 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma003226; Wed, 6 Nov 02 10:42:46 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gA6FgfF14354;
	Wed, 6 Nov 2002 10:42:41 -0500 (EST)
Date: Wed, 6 Nov 2002 10:42:41 -0500 (EST)
Message-Id: <200211061542.gA6FgfF14354@raven.gw.tislabs.com>
To: bgreene@cisco.com
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>IMHO - "Security requirements" that force Internet capital spending and
>network wide maintenance windows to deploy are not going to be adopted by
>the operations community.

Not a surprising development and reminiscent of the auto manufacturers'
stance on seat belts, crash resistent bumpers, air bags, ...  Those whose
focus is the bottom line always want to be shown a financial incentive.
"How about 'survival'?" seems to be unpersuasive.

"network wide maintenance windows" - you mean the need to have recourse
to a registry of some sort?  Or the need to deploy the protections over the
whole network?  Or something else?

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 10:48:28 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28053
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 10:48:28 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6FoTL22812
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 10:50:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FoTv22809
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 10:50:29 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28021
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 10:47:57 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Fo4v22785;
	Wed, 6 Nov 2002 10:50:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6FnPv22731
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 10:49:25 -0500
Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27940
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 10:46:52 -0500 (EST)
Received: (from root@localhost)
	by presque.djinesys.com (8.11.3/8.11.1) id gA6FnJm10141;
	Wed, 6 Nov 2002 10:49:19 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31])
	by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA6FnGC10134;
	Wed, 6 Nov 2002 10:49:16 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: (from jhaas@localhost)
	by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA6FnGR19053;
	Wed, 6 Nov 2002 10:49:16 -0500 (EST)
Date: Wed, 6 Nov 2002 10:49:16 -0500
From: Jeffrey Haas <jhaas@nexthop.com>
To: sandy@tislabs.com
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Message-ID: <20021106104916.D18700@nexthop.com>
References: <200211061534.gA6FYFl13961@raven.gw.tislabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200211061534.gA6FYFl13961@raven.gw.tislabs.com>; from sandy@tislabs.com on Wed, Nov 06, 2002 at 10:34:15AM -0500
X-Virus-Scanned: by AMaViS perl-11
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, Nov 06, 2002 at 10:34:15AM -0500, sandy@tislabs.com wrote:
> But I don't want to get segued into talking about route servers.

Then lets not.  They are an extremely edge case. :-)

> --Sandy

-- 
Jeff Haas 
NextHop Technologies
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 11:00:24 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28904
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 11:00:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6G2Po23350
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 11:02:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6G2Pv23347
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 11:02:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28880
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 10:59:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6G2Av23331;
	Wed, 6 Nov 2002 11:02:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Fxjv23119
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 10:59:45 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28814
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 10:57:13 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA18568;
	Wed, 6 Nov 2002 10:59:10 -0500 (EST)
Date: Wed, 6 Nov 2002 10:59:10 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Randy Bush <randy@psg.com>
cc: rpsec@ietf.org
Subject: Re: [RPSEC] Re: Atlanta Agenda
In-Reply-To: <E189Ppe-0009vd-00@roam.psg.com>
Message-ID: <Pine.GSO.4.21.0211061059020.25695-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


That's fine.... Duly noted.

:-)

Russ

On Wed, 6 Nov 2002, Randy Bush wrote:

> > I've also given Randy some more time
> 
> not needed.  i don't have that much to say.  i'll donate five
> minutes back to general discussion of directions and strategy,
> which i think is quite important.
> 
> randy
> 

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 11:09:16 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29393
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 11:09:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6GBHO24461
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 11:11:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6GBHv24458
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 11:11:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29374
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 11:08:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6GB3v24444;
	Wed, 6 Nov 2002 11:11:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6GAjv24419
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 11:10:45 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29331
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 11:08:13 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA6G9wf58620;
	Wed, 6 Nov 2002 17:09:58 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Wed, 6 Nov 2002 17:09:58 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: <sandy@tislabs.com>
cc: <kent@bbn.com>, <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <200211061436.gA6EaDS09150@raven.gw.tislabs.com>
Message-ID: <20021106165943.W58530-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, 6 Nov 2002 sandy@tislabs.com wrote:

> >Wouldn't AS X be the only one who can successfully send an update with
> >AS X as the first/last AS in the AS path? If AS Y took this update and
> >announced it then either it would have to add AS Y as per RFC 1771 and
> >the path and thus the entire update would be different, or it wouldn't
> >and a very simple sanity check would fail.

> (a) See recent discussion on idr list about whether AS's always, always,
> always add their own AS to the AS_PATH before transmitting updates.

I can't be sure from memory that this is required as per the RFC, but if
it isn't strictly required than not doing it is so rare that it
shouldn't be hard to either mandate it should or have some special
processing/manual configuration for the exceptions.

> (b) If someone finds an AS_PATH that ends in AS X, signed by AS X but
> without including AS X's neighbor in the signature, then that someone
> (call it AS N) can announce an AS_PATH that ends in "...., AS X, AS N"
> without actually being a neighbor of AS_X.

I don't see what this has to do with having a neighbor identifier in the
update message. Since the AS path is different here, this situation
should be caught in the AS path validation phase.

Also note that protecting against abuse by AS N (for instance, AS N
claims to have the bast path to a destination that AS X really has the
best path to) on the basis that AS N isn't a neighbor of AS X is too
weak as it is not extremely unlikely ASes X and N peer.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 11:39:27 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00793
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 11:39:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6GfTe26878
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 11:41:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6GfTv26875
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 11:41:29 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00785
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 11:38:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Gf6v26831;
	Wed, 6 Nov 2002 11:41:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6GdWv26664
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 11:39:32 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00659
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 11:36:59 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA6Gcxg58703;
	Wed, 6 Nov 2002 17:38:59 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Wed, 6 Nov 2002 17:38:59 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: <sandy@tislabs.com>
cc: <bgreene@cisco.com>, <rpsec@ietf.org>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <200211061542.gA6FgfF14354@raven.gw.tislabs.com>
Message-ID: <20021106171433.J58530-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, 6 Nov 2002 sandy@tislabs.com wrote:

> >IMHO - "Security requirements" that force Internet capital spending and
> >network wide maintenance windows to deploy are not going to be adopted by
> >the operations community.

> Not a surprising development and reminiscent of the auto manufacturers'
> stance on seat belts, crash resistent bumpers, air bags, ...  Those whose
> focus is the bottom line always want to be shown a financial incentive.
> "How about 'survival'?" seems to be unpersuasive.

Routers are a lot like regular computers in many ways, but you can only
expect to sell a very small number compared to computers. I'm not a
router builder but I think that's the reason why router CPUs are so slow
compared to those of regular computers: the design costs to keep up with
the latest CPU technology would be too high.

As far as I can tell, verifying a signature takes in the order of a
millisecond on a decent CPU. So with 115,000 routes in the global
routing table, that's 2 minutes to initialize BGP, assuming one
signature must be checked per route. I don't think this is acceptable,
especially not considering router CPUs may be slower, there is other
processing to do as well and the expected growth of the global routing
table. This means routers must be equipped with crypto modules.

Then there is memory. There are still many routers in production that
are already in trouble memory-wise as their design allows only 32, 64 or
128 MB and a Cisco needs 256 MB to comfortably run BGP. I've tried to
add up all the extra fields but I couldn't be sure how much of what goes
where, but it looks like S-BGP will take at least twice the memory of
regular BGP.

This means some routers must be replaced completely and all others need
hardware upgrades. So expect resistance from the people who have to pay
the bill. Especially if there is so much of a byte wasted in your packet
formats, or there is a place where crypto is used when the same result
could be obtained without it.

Also note that the perceived need for more security in BGP can't be all
that high, as we can tell by the level of MD5 option deployment.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 12:24:24 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02899
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 12:24:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6HQRC29987
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 12:26:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6HQQv29984
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 12:26:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02887
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 12:23:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6HQDv29954;
	Wed, 6 Nov 2002 12:26:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6HPDv29912
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 12:25:13 -0500
Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02868
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 12:22:40 -0500 (EST)
Received: (from root@localhost)
	by presque.djinesys.com (8.11.3/8.11.1) id gA6HOkt13245;
	Wed, 6 Nov 2002 12:24:46 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31])
	by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA6HOfC13230;
	Wed, 6 Nov 2002 12:24:41 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: (from jhaas@localhost)
	by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA6HOfo19715;
	Wed, 6 Nov 2002 12:24:41 -0500 (EST)
Date: Wed, 6 Nov 2002 12:24:41 -0500
From: Jeffrey Haas <jhaas@nexthop.com>
To: sandy@tislabs.com
Cc: bgreene@cisco.com, rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Message-ID: <20021106122441.G18700@nexthop.com>
References: <200211061542.gA6FgfF14354@raven.gw.tislabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200211061542.gA6FgfF14354@raven.gw.tislabs.com>; from sandy@tislabs.com on Wed, Nov 06, 2002 at 10:42:41AM -0500
X-Virus-Scanned: by AMaViS perl-11
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, Nov 06, 2002 at 10:42:41AM -0500, sandy@tislabs.com wrote:
> Not a surprising development and reminiscent of the auto manufacturers'
> stance on seat belts, crash resistent bumpers, air bags, ...  Those whose
> focus is the bottom line always want to be shown a financial incentive.
> "How about 'survival'?" seems to be unpersuasive.

The usual incentive in that case was laws and lawsuits.
Do we really want to go there?

-- 
Jeff Haas 
NextHop Technologies
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 12:37:20 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03408
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 12:37:19 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6HdMk31109
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 12:39:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6HdMv31106
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 12:39:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03382
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 12:36:48 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Hd3v31077;
	Wed, 6 Nov 2002 12:39:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6HcLv31048
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 12:38:21 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03361
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 12:35:48 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id MAA06445; Wed, 6 Nov 2002 12:38:21 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma006418; Wed, 6 Nov 02 12:37:43 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gA6Hbbt19688;
	Wed, 6 Nov 2002 12:37:37 -0500 (EST)
Date: Wed, 6 Nov 2002 12:37:37 -0500 (EST)
Message-Id: <200211061737.gA6Hbbt19688@raven.gw.tislabs.com>
To: iljitsch@muada.com, sandy@tislabs.com
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: kent@bbn.com, rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>> (b) If someone finds an AS_PATH that ends in AS X, signed by AS X but
>> without including AS X's neighbor in the signature, then that someone
>> (call it AS N) can announce an AS_PATH that ends in "...., AS X, AS N"
>> without actually being a neighbor of AS_X.
>
>I don't see what this has to do with having a neighbor identifier in the
>update message. Since the AS path is different here, this situation
>should be caught in the AS path validation phase.

It would not be caught in the AS path validation phase.  N has a valid
signed path that ends in AS X, signed by AS X.  (We're presuming the
don't-include-neighbor-id-in-signature approach.)  AS N adds itself
to the path and signs that.  All signatures check.

>Also note that protecting against abuse by AS N (for instance, AS N
>claims to have the bast path to a destination that AS X really has the
>best path to) on the basis that AS N isn't a neighbor of AS X is too
>weak as it is not extremely unlikely ASes X and N peer.

"not extremely unlikely" == "likely"?  Why?

Think of the AS 7007 situation, where AS 7007 reduced every AS path
it got to nothing and sent out updates with an AS path of only "AS 7007".
Presume instead that it truncated the AS path down to some small subsequence,
say, the originating AS on the list.  Then it makes a new update,
with the AS path = (originatingAS, AS 7007).  AS 7007 is not a neighbor of
"originatingAS" for the most part, so this is a bogus AS path.  But
signature checking won't catch this unless each AS includes its AS
neighbor in what is signed.

BBN has a way of describing this - they say that the updates and signatures
mean "I am authorizing my neighbor AS Q to announce a route through me".

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 12:38:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03442
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 12:38:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6HeO031212
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 12:40:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6HeOv31209
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 12:40:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03430
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 12:37:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6He1v31181;
	Wed, 6 Nov 2002 12:40:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6HdMv31121
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 12:39:22 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03380
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 12:36:48 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id MAA06474; Wed, 6 Nov 2002 12:39:21 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma006468; Wed, 6 Nov 02 12:38:51 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gA6Hclf19765;
	Wed, 6 Nov 2002 12:38:47 -0500 (EST)
Date: Wed, 6 Nov 2002 12:38:47 -0500 (EST)
Message-Id: <200211061738.gA6Hclf19765@raven.gw.tislabs.com>
To: rpsec@ietf.org
Cc: sandy@tislabs.com
Subject: [RPSEC] another threat analysis draft
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


At the same time that Dennis's draft got announced, I offered the following
draft to the chairs.  Tony suggested that I send it to the list as well.
I don't claim that it presents an opposing viewpoint, but I do think that
it has a bit different focus in organization and presentation.

So here it is.

--Sandy










Network Working Group                                      Sandra Murphy
INTERNET DRAFT                                                  NAI Labs
draft-murphy-threat-00.txt                                  October 2002


                    Routing Protocol Threat Analysis



Status of this Memo

This document is an Internet-Draft and is subject to 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/1id-abstracts.html

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

Abstract

Routing protocols are subject to attacks that can harm individual users
or the network operations as a whole.  The lack of a common set of
security requirements has led to the use in existing routing protocol of
a variety of different security solutions, which provide various levels
of security coverage.

The RPSEC working group intends to deliver a set of security
requirements for consideration of routing protocol designers.  The first
step in developing the security requirements is to analyze the threats
that face routing protocols.  This document describes the threats,
including threat consequences, threat sources and capabilities, threat
actions, and a breakdown of routing functions that might be separately
attacked.






Murphy                     Expires: April 2003                  [Page 1]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002


Table of Contents


 Status of this Memo ..............................................    1
 Abstract .........................................................    1
1 Introduction ....................................................    3
2 Routing Functions ...............................................    4
2.1 Targeted Functions ............................................    4
3 Threats Sources (Attackers) .....................................    5
3.1 Outsiders .....................................................    5
3.2 Insiders ......................................................    6
4 Threat Actions (Attacks) ........................................    7
5 Threat Consequences (Compromise) ................................    8
6 Security Considerations .........................................    9
7 References ......................................................    9
8 Author's Address ................................................   10


































Murphy                     Expires: April 2003                  [Page 2]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002


1.  Introduction

The RPSEC working group is tasked to deliver a description of the
security requirements for routing protocols.  This internet draft
discusses an analysis of the threats that face routing protocols, as a
precursor to developing a common set of security requirements for
routing protocols.

The RPSEC working group is addressing security requirements of routing
protocols, not the security requirements of routers or of operations of
routing systems.  Therefore, this draft specifically does not address
threats to routers (hacking, denial of service flooding attacks, etc.)
or to specific routing protocol implementations (bugs, etc.).  The
security requirements derived from this threat analysis are intended to
be guidance to those who are designing routing protocols; if the threat
is directed at some aspect of routing outside the routing protocol there
is nothing the protocol designers can do to address the threat.

The intent is to construct security requirements that will be applicable
across a wide range of routing protocols: both inter-domain and intra-
domain (EGP and IGP), both wired and wireless, both unicast and
multicast, protocols based on any underlying protocol level (over the
link layer, over IP, over TCP, over clouds, over virtual topologies as
in peer-to-peer, etc.), protocols that communicate over point-to-point
links, over multi-point links, over anycast or multicast links, over
broadcast, and protocols that are multi-hop or directly connected.
While the security solutions that are possible are strongly affected by
such differences, the security requirements should be the same.

The term threat is used in many different ways.  There is the threat
consequence, or compromise, which is the damage done by an attack on a
vulnerability.  There is the threat source, or attacker, which is the
entity in the system that is mounting an attack.  This could be one
single user, a host, a network, or a distributed set of users, hosts,
etc.  There is the threat action, or attack, which is the activity that
the attacker uses to cause the compromise.

This analysis will consider each of these separately.  Security
requirements can be stated in terms of preventing the attack, or in
terms of avoiding the compromise (which does not necessarily mean that
the attack is prevented, only that the damage is avoided somehow), in
terms of eliminating a vulnerability that can be attacked, or in terms
of excluding certain attackers.







Murphy                     Expires: April 2003                  [Page 3]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002


2.  Routing Functions

Routing protocols in general have several common functions:

Transport subsystem
     The routing protocol transmits messages to its peers using some
     underlying protocol.  For some, as in OSPF, this is IP.  For
     others, this can be a broadcast link layer, as in AODV.  Still
     others may run over TCP.  In many cases, the routing protocol is
     subject to attacks on its underlying protocol.

Neighbor state maintenance
     Each protocol has a different mechanism for determining its peers
     in the routing topology.  Some protocols have distinct exchanges
     through which they establish peering relationships, e.g., Hello
     exchanges in OSPF. The peering relationship formation is the first
     step of topology determination.  For protocols that maintain state
     about their peering relationships, attacks that disrupt the peering
     relationship can have 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 peering relationship and
     cause any related topology information to be flushed.

Database maintenance
     Routing protocols exchange network topology and reachability
     information.  The routers collect this information in routing
     databases in varying detail.  The maintenance of these databases is
     a significant portion of the function of a routing protocol.  The
     information in the database must be authentic and authorized,
     otherwise the function of routing in the overall network is
     damaged.  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.

2.1.  Targeted Functions

Just as a router's functions can be divided into control and data plane
(protocol traffic vs data traffic), so the routing protocol has a





Murphy                     Expires: April 2003                  [Page 4]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002


control and a data plane.  A routing protocol has some message exchanges
that are intended only for control of the protocol state.  This is the
routing protocol control plane.  Other message exchanges are intended to
distribute the information used to perform the forwarding function,
whether that is to establish a forwarding table in each router or to
return a description of the route to use.  This is the routing protocol
data plane.  Each of the routing functions may have both control and
data aspects, but there will naturally be an emphasis on one or the
other.  Neighbor maintenance is likely to be focused on the routing
protocol control plane aspects, for example, while database maintenance
may have more focus on the routing protocol data plane aspects.

Both the control and the data plane are subject to attack.  An attacker
who is able to target the routing protocol control plane so as to break
a neighbor (e.g., peering, adjacency) relationship can have a strong
effect on the behavior of routing in those routers and likely the
surrounding neighborhood.  An attacker who is able to break a database
exchange between two routers can also effect 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.

3.  Threats Sources (Attackers)

Attackers can be outsiders or insiders.  An insider is a legitimate
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 a legitimate 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).

3.1.  Outsiders

Outsiders can be a remote host in the network, a host on the immediate
peer to peer link, a protocol speaker on a peer to peer link that is not
a configured peer.

Outsider capabilities:

     The strongest assumption is that the outsider has complete access
     to the communication between two legitimate peers so it can read
     any message, can delete messages, can replay any message it had
     read, can modify messages and can insert new messages.  This might
     be true, for example, if the protocol was intended to run over a





Murphy                     Expires: April 2003                  [Page 5]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002


     layer that provided only datagram service - link layer or UDP,
     perhaps - and no authentication was offered.

     A lesser assumption is that the outsider can insert new messages
     into the peer to peer communication but cannot read messages.

     An outsider might be able to read messages and replay messages it
     had read, but not to create new messages.

     An outsider might be able only to read messages, not insert
     messages.

     The outsider might only have the ability to cut the communication
     between peers through the underlying protocol.

Outsiders can be prevented from disrupting routing by providing peer to
peer authentication.  But the protection provided is dependent on
whether the protection is in some underlying protocol, whether link
layer, IP, TCP, etc.  or the protection is in the protocol layer itself.
If the underlying protocol is itself subject to attack (e.g., the
protocol is stateful and the state can be manipulated by an attack),
then protection in the protocol layer will not eliminate those attacks.

3.2.  Insiders

Insiders have a powerful opportunity to disrupt the routing system.
Given their position of trust in the routing system, they possess the
capabilities of the strongest outsider attacker in terms of access to
the communication and in terms of access to routing information.

Routing protocol peers also have access to context that provides an
opportunity to detect bogus routing information.  The difficulty is to
continue to provide rapid response to legitimate network dynamic
behavior while eliminating bogus information, particularly when the
range of legitimate network behavior is large.  For example, a wired
network where the connectivity is sparse may be able to filter routing
information near the "edge" of the network.  But in the core of the
network or in a richly connected network, the possible routing
information may be so varied as to make filtering less useful.  Also, a
wireless network has few constraints on connectivity, so there is no
basis on which to construct filters.

Insider capabilities:







Murphy                     Expires: April 2003                  [Page 6]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002


     Complete access to peer to peer communication, to the underlying
     protocol state, to routing information, to authentication data,
     etc.  Able to insert new or modified messages, replay old messages,
     delete messages, read messages, etc. at will.

When a host or network behaves in a way contrary to the protocol
specification or in a way that is not authorized, the behavior is called
a "Byzantine failure".  These failures can include timing errors
(producing messages at intervals contrary to the specification),
protocol errors (producing messages at variance with the specification,
e.g., responding with the incorrect message type), or data errors
(producing messages that carry faulty data).

Byzantine routing failures have been observed in the Internet since its
inception.  Failures can be the result of hardware or software faults,
of misconfiguration by the router operators, or of deliberate subversion
by a malicious party.  The great majority of publicized accounts of
Byzantine failures have been of faulty or misconfigured routers.  Public
accounts of deliberately subverted routers have been rare.

4.  Threat Actions (Attacks)

The activities that might be used to attack a routing protocols include:

masquerade
     The attacker, whether insider or outsider, may adopt the identity
     of a legitimate peer. (This is an attack against origin
     authenticity.)

interception
     The attacker gains access to routing information that is considered
     sensitive.  (This is an attack against confidentiality, i.e.,
     privacy.)

falsification
     The attacker is able to substitute modified messages for valid
     routing messages.  (This is an attack against integrity.)

misuse
     The attacker is able to introduce unauthorized routing information
     that disrupts routing behavior.  (This is an attack against
     authorized use.)

replay
     The attacker is able to re-introduce previously transmitted





Murphy                     Expires: April 2003                  [Page 7]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002


     messages.  (This is an attack against freshness.)

These attacks might be used by insider or outsider to accomplish any of
the compromises listed below.

5.  Threat Consequences (Compromise)

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.

The damage that might result from attacks against the network as a whole
include:

     network congestion: more data traffic is forwarded through some
     portion of the network than would otherwise need to carry the
     traffic,

     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,

     looping: data traffic is forwarded along a route that loops, so
     that the data is never delivered (resulting in network congestion),

     partition: some portion of the network believes that it is
     partitioned from the rest of the network when it is not,

     disclosure: the routing information is sensitive and is revealed to
     an unauthorized entity,

     churn: the forwarding in the network changes (unnecessarily) at a
     rapid pace, resulting in large variations in the data delivery
     patterns (and adversely affecting congestion control techniques),

     instability: the protocol becomes unstable so that convergence on a
     global forwarding state is not achieved, and

     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 include:







Murphy                     Expires: April 2003                  [Page 8]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002


     starvation: data traffic destined for the network or host is
     forwarded to a part of the network that cannot deliver it,

     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,

     cut: some portion of the network believes that it has no route to
     the host or network when it is in fact connected,

     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,

     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 protected against
an attack that eavesdropped on one destination's traffic without
protecting against an attack that overwhelmed a router.  Or that
prevented a starvation attack against one host, but not against a net-
wide blackhole.  The security requirements must be clear as to which
compromises are being avoided and which must be addressed by other means
(e.g., by administrative means outside the protocol).

6.  Security Considerations

This entire memo is about security, describing the threats to routing
protocols.

7.  References

[1]  Y. Rekhter and T. Li,  "A Border Gateway Protocol 4 (BGP-4)",
     RFC1771, March 1995.

[2]  John Moy, "OSPF Version 2", RFC 1583, March 1994.

[3]  C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy and C. Orange,
     "Routing Policy System Security", RFC 2725,  December, 1999.

[4]  R. Shirey,"Internet Security Glossary", RFC 2828, May 2000.







Murphy                     Expires: April 2003                  [Page 9]

INTERNET DRAFT      Routing Protocol Threat Analysis        October 2002


8.  Author's Address

Sandra Murphy
Network Associates, Inc.
NAI Labs
3060 Washington Road
Glenwood, MD  21738
EMail: Sandy@tislabs.com










































Murphy                     Expires: April 2003                 [Page 10]

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 12:44:17 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03695
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 12:44:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6HkJX31464
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 12:46:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6HkJv31461
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 12:46:19 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03671
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 12:43:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Hk2v31449;
	Wed, 6 Nov 2002 12:46:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6HjNv31427
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 12:45:23 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03649
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 12:42:50 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id MAA06570; Wed, 6 Nov 2002 12:45:23 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma006553; Wed, 6 Nov 02 12:44:36 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gA6HiVT19972;
	Wed, 6 Nov 2002 12:44:31 -0500 (EST)
Date: Wed, 6 Nov 2002 12:44:31 -0500 (EST)
Message-Id: <200211061744.gA6HiVT19972@raven.gw.tislabs.com>
To: rpsec@ietf.org
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
Cc: iljitsch@muada.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>Also note that the perceived need for more security in BGP can't be all
>that high, as we can tell by the level of MD5 option deployment.

Sadly, "perceived need" has little to do with "actual need".

As we can tell from the level of IPSEC and security deployment compared with
the level of DDoS attacks from compromised or spoofed hosts.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 13:56:23 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06793
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 13:56:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6IwRl03760
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 13:58:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6IwRv03757
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 13:58:27 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06783
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 13:55:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6Iw8v03735;
	Wed, 6 Nov 2002 13:58:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6IvQv03692
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 13:57:26 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06750
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 13:54:52 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA27129
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 13:57:21 -0500 (EST)
Date: Wed, 6 Nov 2002 13:57:21 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: rpsec@ietf.org
In-Reply-To: <Pine.GSO.4.21.0211052219280.25525-100000@ruwhite-u10.cisco.com>
Message-ID: <Pine.GSO.4.21.0211061327590.25755-100000@ruwhite-u10.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [RPSEC] Re: Atlanta Agenda
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


Minor Change:

> Agenda Bashing (5 minutes):             5
> RP's over IPSec (20 minutes):          25
>   (Dave Ward)
> draft-beard-threats (15 minutes):      40
> draft-murphy-threats (15 minutes):     55

Discussion on how to handle these 
  drafts (10 minutes):                   65

> draft-convery (15 minutes):            80
>   (BGP attack tree)
> S-BGP Operator's Meeting (10 minutes): 90
>   (Randy Bush)
> draft-ng-sobgp (15 minutes):          105
>   (draft-white-sobgp included)

:-)

Russ


__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 15:33:36 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10976
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 15:33:36 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6KZd409899
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 15:35:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6KZdv09896
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 15:35:39 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10968
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 15:33:05 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6KZGv09886;
	Wed, 6 Nov 2002 15:35:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6KYwv09863
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 15:34:58 -0500
Received: from roam.psg.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10946
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 15:32:24 -0500 (EST)
Received: from localhost
	([127.0.0.1] helo=roam.psg.com.psg.com ident=randy)
	by roam.psg.com with esmtp (Exim 4.05)
	id 189Wt2-000BAl-00; Wed, 06 Nov 2002 12:34:52 -0800
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: <bgreene@cisco.com>
Cc: rpsec@ietf.org
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
References: <200211061352.gA6Dq2404947@raven.gw.tislabs.com>
	<LNEHJBNJAPFNLEGJHCPEGELBKAAA.bgreene@cisco.com>
Message-Id: <E189Wt2-000BAl-00@roam.psg.com>
Date: Wed, 06 Nov 2002 12:34:52 -0800
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> Peer Groups are a necessity to convergence speeds.

as far as i can tell, this seems to be a vendor-specific artifact

randy

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 16:07:26 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12461
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 16:07:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6L9T112578
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 16:09:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6L9Tv12575
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 16:09:29 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12452
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 16:06:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6L65v11815;
	Wed, 6 Nov 2002 16:06:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6L5Jv11784
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 16:05:19 -0500
Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12243
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 16:02:44 -0500 (EST)
Received: (from root@localhost)
	by presque.djinesys.com (8.11.3/8.11.1) id gA6L4fr19326;
	Wed, 6 Nov 2002 16:04:41 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31])
	by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA6L4cC19319;
	Wed, 6 Nov 2002 16:04:38 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: (from jhaas@localhost)
	by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gA6L4co02175;
	Wed, 6 Nov 2002 16:04:38 -0500 (EST)
Date: Wed, 6 Nov 2002 16:04:38 -0500
From: Jeffrey Haas <jhaas@nexthop.com>
To: Randy Bush <randy@psg.com>
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Message-ID: <20021106160437.H18700@nexthop.com>
References: <200211061352.gA6Dq2404947@raven.gw.tislabs.com> <LNEHJBNJAPFNLEGJHCPEGELBKAAA.bgreene@cisco.com> <E189Wt2-000BAl-00@roam.psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E189Wt2-000BAl-00@roam.psg.com>; from randy@psg.com on Wed, Nov 06, 2002 at 12:34:52PM -0800
X-Virus-Scanned: by AMaViS perl-11
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, Nov 06, 2002 at 12:34:52PM -0800, Randy Bush wrote:
> > Peer Groups are a necessity to convergence speeds.
> 
> as far as i can tell, this seems to be a vendor-specific artifact

But a very common one.

> randy

-- 
Jeff Haas 
NextHop Technologies
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 16:25:35 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12973
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 16:25:35 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA6LRdj13247
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 16:27:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6LRdv13244
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 16:27:39 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12952
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 16:25:04 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6LL6v13032;
	Wed, 6 Nov 2002 16:21:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6LKqv12998
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 16:20:52 -0500
Received: from wolfe.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12724
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 16:18:17 -0500 (EST)
Received: by wolfe.bbn.com (Postfix, from userid 13538)
	id 967C116484; Wed,  6 Nov 2002 16:20:45 -0500 (EST)
From: Charles Lynn <clynn@bbn.com>
To: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <20021106093019.D50741-100000@sequoia.muada.com>
References: <200211061352.gA6Dq2404947@raven.gw.tislabs.com>
	    <20021106145416.S50741-100000@sequoia.muada.com>
Message-Id: <20021106212045.967C116484@wolfe.bbn.com>
Date: Wed,  6 Nov 2002 16:20:45 -0500 (EST)
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Iljitsch,
				   
> There are other things that aren't explored well enough in S-BGP. One
> thing that bothers me a lot is the fact that a routing update must be
> generated for each neighbor individually.

This statement is incorrect.  S-BGP MAY sign a single update, that
includes the AS number(s) of each of the ASes to which the update will
be sent.  The current S-BGP code base supports this.

> I'm not convinced that having some kind of destination
> identifier in an update is necessary, but if it is it should still be
> possible to somehow group neighbors so the optimization remains intact.

The optimization remains intact.

> Did you calculate the extra memory needed for full S-BGP deployment
> throughout the internet?

The reference

http://www.ir.bbn.com/projects/s-bgp/NDSS00.S-BGP.ps

gives the numbers that were estimated at the time it was presented
(Feb 00).  The net has grown since then, of course, and the numbers
were based primarily on ARIN data.  Note that an initial deployment
would not need memory for a "full deployment throughout the internet"
as I think it is very unlikely that any security mechanisms will see
"full deployment", say within a year or so.  However I agree that the
numbers for a full deployment (of any security mechanism) need to be
examined so the, e.g., the router vendors can work the capacity
requirements into their product lines.  (I think that I've heard the
lament that "routers don't have enough memory for the current size of
the routing tables" for a couple decades. :-)

> And I think a solution where the routers themselves do all the
> authenticating is inherently problematic because of performance and
> security issues.

I'm not an ISP operator, but I would think (please correct me if my
view is off-base) that having to contact an external server to do the
processing whenever a router receives an update - as has been
suggested in some documents I have read - would be much worse, from
the reachability standpoint and the "high value target" perspective.
Do you think otherwise?

The above reference showed that "all the authenticating" is not that
much of a load for a router with a modern processor.  Since the time
the work was presented, crypto chips that can do thousands of
operations per second have become available.  I've heard of designs
for systems that can perform IPsec on 10 GBit links.  Note however
that some high-speed crypto peripherals could not meet their
advertised rate in the S-BGP context due to their way of handling the
switching of public keys.  (It turned out that software crypto was
actually faster than the hardware!)  I'm sure that the hardware folk
can design the chips to satisfy the requirements, if currently available
chip sets are found to be inadequate.  The VPN market should make the
hardware competitive.

> A flimsy lock on a colo rack isn't enough to protect your secret keys.

If someone can get to your hardware, you likely have more to be
concerned about than the secret key.  If the secret key (DSA private
key for S-BGP) is in a well designed piece of crypto hardware, getting
it out without someone noticing would be, I think, a very low
probability event.

> Well, we can use S-BGP as an example of what we should require.  :-)

Yes, please do.  It is an example of what can be done (an existence
proof if you will) that tries to consider the whole system and the
supporting pieces.  Drawing packet layouts and specifying a protocol
are the easy parts.

> However, I wonder if there isn't a less heavy-weight way to detect
> this situation than do public key crypto on each update.

There may be.  We need to consider the alternatives and especially the
requirements.  We should not dismiss options because someone thinks they
are too hard or take too much time or space or whatever.  Once we have
requirements, we can do the detailed engineering to see what solutions
we can collectively find, and what they "cost".

> One optimization would be to only check updates that would
> install a new better path towards a destination.

(The current S-BGP implementation can be configured to do this.)

> Also, AS paths are
> often very similar across a somewhat large number of routes, so there is
> probably a way to check the path once and accept many updates rather
> than do it for each update individually.

Yes.  But the S-BGP experience has been that the data structures (the
S-BGP team thought were) needed to do this took more processing time
and memory than not trying to use that optimization.  Maybe other
implementors, if we turn them loose on the problem, will find otherwise.


> It's a bit longer ago. Here it is again, with slight modifications:
<snip>

> AS2 trusts AS3 

What does it mean to "trust an AS"?  That you "trust" all the
employees of the organization that operates the AS?  That seems to
still be vulnerable to the historic "attacks" where an employee
mis-types something.

Maybe one reason that you have reached the conclusion that only the
first couple hops need protection is because the average AS path
length is very short -- the routing tables that can be found around
the net showed an average length something like 3.5 hops.  Thus the
notion of only needing to protect the first couple hops is "close" to
actually protecting the whole path.  Would you reach the same
conclusion if the average AS path length were, say, six or seven hops?

The notion of signing a list of possible paths seems, to me, more like
an authenticated topology than how packets should be routed at a given
point in time.  Do you have any estimates for how much space it would
take for a full deployment of such a mechanism?

Sandy commented...

> The signature scheme might be expandable so that you sign a set of
> neighbor identities into the update, rather than just one.  This would
> be useful if you had lots and lots of neighbors that you could break
> into a lot of groups of lots of neighbors, where the advertised routes
> to each neighbor in one group would be the same - then you would still
> get some optimization.  Would such situations be common?

Note that the "grouping" is unlikely to be "free".  It will take space
to record, processing cycles to implement, and management cycles to
maintain, for each or the posited hundreds or routers in an ISP.

And Iljitsch commented ...

> Yes, except maybe for the "lots of groups" part. A lot of traffic is
> exchanged at internet exchanges. Typically, all peer routers share the
> same settings for outbound updates. For instance, I manage a router with
> 103 peers in 4 groups, with the largest group having some 40 neighbors.

(I've been told that many ISPs are moving to private peering
arrangements.)  We certainly need to consider the case you have
described.  We need to get a list of all the topologies that need to
be supported into the requirements list.  Are there any others
(besides private peerings and internet exchanges) that are significant?

Charlie
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov  6 22:26:50 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21652
	for <rpsec-archive@odin.ietf.org>; Wed, 6 Nov 2002 22:26:50 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA73Sva00969
	for rpsec-archive@odin.ietf.org; Wed, 6 Nov 2002 22:28:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA73Svv00966
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 6 Nov 2002 22:28:57 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21635
	for <rpsec-web-archive@ietf.org>; Wed, 6 Nov 2002 22:26:19 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA73SRv00948;
	Wed, 6 Nov 2002 22:28:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6NeBv21643
	for <rpsec@optimus.ietf.org>; Wed, 6 Nov 2002 18:40:11 -0500
Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17040
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 18:37:34 -0500 (EST)
Received: (from root@localhost)
	by presque.djinesys.com (8.11.3/8.11.1) id gA6Ne3d24027
	for rpsec@ietf.org; Wed, 6 Nov 2002 18:40:03 -0500 (EST)
	(envelope-from shares@nexthop.com)
Received: from mail.corp.nexthop.com ([64.211.218.233])
	by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gA6NduC24004
	for <rpsec@ietf.org>; Wed, 6 Nov 2002 18:39:56 -0500 (EST)
	(envelope-from shares@nexthop.com)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
Date: Wed, 6 Nov 2002 18:38:51 -0500
Message-ID: <BE36D687C8CBFA4AB76F5CD3E3C0FB4E964E8E@aa-exchange1.corp.nexthop.com>
Thread-Topic: [RPSEC] Re: draft-convery-bgpattack-00
Thread-Index: AcKF3I1Ywy60rBmvSW2UGg7oYidR/QADw9bw
From: "Susan Hares" <shares@nexthop.com>
To: "Charles Lynn" <clynn@bbn.com>, <rpsec@ietf.org>
X-Virus-Scanned: by AMaViS perl-11
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA6NeBv21644
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Charlie:

How does SBGP handle Aggregation or 
proxy aggregation?

Sue Hares

-----Original Message-----
From: Charles Lynn [mailto:clynn@bbn.com]
Sent: Wednesday, November 06, 2002 4:21 PM
To: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00


Iljitsch,
				   
> There are other things that aren't explored well enough in S-BGP. One
> thing that bothers me a lot is the fact that a routing update must be
> generated for each neighbor individually.

This statement is incorrect.  S-BGP MAY sign a single update, that
includes the AS number(s) of each of the ASes to which the update will
be sent.  The current S-BGP code base supports this.

> I'm not convinced that having some kind of destination
> identifier in an update is necessary, but if it is it should still be
> possible to somehow group neighbors so the optimization remains intact.

The optimization remains intact.

> Did you calculate the extra memory needed for full S-BGP deployment
> throughout the internet?

The reference

http://www.ir.bbn.com/projects/s-bgp/NDSS00.S-BGP.ps

gives the numbers that were estimated at the time it was presented
(Feb 00).  The net has grown since then, of course, and the numbers
were based primarily on ARIN data.  Note that an initial deployment
would not need memory for a "full deployment throughout the internet"
as I think it is very unlikely that any security mechanisms will see
"full deployment", say within a year or so.  However I agree that the
numbers for a full deployment (of any security mechanism) need to be
examined so the, e.g., the router vendors can work the capacity
requirements into their product lines.  (I think that I've heard the
lament that "routers don't have enough memory for the current size of
the routing tables" for a couple decades. :-)

> And I think a solution where the routers themselves do all the
> authenticating is inherently problematic because of performance and
> security issues.

I'm not an ISP operator, but I would think (please correct me if my
view is off-base) that having to contact an external server to do the
processing whenever a router receives an update - as has been
suggested in some documents I have read - would be much worse, from
the reachability standpoint and the "high value target" perspective.
Do you think otherwise?

The above reference showed that "all the authenticating" is not that
much of a load for a router with a modern processor.  Since the time
the work was presented, crypto chips that can do thousands of
operations per second have become available.  I've heard of designs
for systems that can perform IPsec on 10 GBit links.  Note however
that some high-speed crypto peripherals could not meet their
advertised rate in the S-BGP context due to their way of handling the
switching of public keys.  (It turned out that software crypto was
actually faster than the hardware!)  I'm sure that the hardware folk
can design the chips to satisfy the requirements, if currently available
chip sets are found to be inadequate.  The VPN market should make the
hardware competitive.

> A flimsy lock on a colo rack isn't enough to protect your secret keys.

If someone can get to your hardware, you likely have more to be
concerned about than the secret key.  If the secret key (DSA private
key for S-BGP) is in a well designed piece of crypto hardware, getting
it out without someone noticing would be, I think, a very low
probability event.

> Well, we can use S-BGP as an example of what we should require.  :-)

Yes, please do.  It is an example of what can be done (an existence
proof if you will) that tries to consider the whole system and the
supporting pieces.  Drawing packet layouts and specifying a protocol
are the easy parts.

> However, I wonder if there isn't a less heavy-weight way to detect
> this situation than do public key crypto on each update.

There may be.  We need to consider the alternatives and especially the
requirements.  We should not dismiss options because someone thinks they
are too hard or take too much time or space or whatever.  Once we have
requirements, we can do the detailed engineering to see what solutions
we can collectively find, and what they "cost".

> One optimization would be to only check updates that would
> install a new better path towards a destination.

(The current S-BGP implementation can be configured to do this.)

> Also, AS paths are
> often very similar across a somewhat large number of routes, so there is
> probably a way to check the path once and accept many updates rather
> than do it for each update individually.

Yes.  But the S-BGP experience has been that the data structures (the
S-BGP team thought were) needed to do this took more processing time
and memory than not trying to use that optimization.  Maybe other
implementors, if we turn them loose on the problem, will find otherwise.


> It's a bit longer ago. Here it is again, with slight modifications:
<snip>

> AS2 trusts AS3 

What does it mean to "trust an AS"?  That you "trust" all the
employees of the organization that operates the AS?  That seems to
still be vulnerable to the historic "attacks" where an employee
mis-types something.

Maybe one reason that you have reached the conclusion that only the
first couple hops need protection is because the average AS path
length is very short -- the routing tables that can be found around
the net showed an average length something like 3.5 hops.  Thus the
notion of only needing to protect the first couple hops is "close" to
actually protecting the whole path.  Would you reach the same
conclusion if the average AS path length were, say, six or seven hops?

The notion of signing a list of possible paths seems, to me, more like
an authenticated topology than how packets should be routed at a given
point in time.  Do you have any estimates for how much space it would
take for a full deployment of such a mechanism?

Sandy commented...

> The signature scheme might be expandable so that you sign a set of
> neighbor identities into the update, rather than just one.  This would
> be useful if you had lots and lots of neighbors that you could break
> into a lot of groups of lots of neighbors, where the advertised routes
> to each neighbor in one group would be the same - then you would still
> get some optimization.  Would such situations be common?

Note that the "grouping" is unlikely to be "free".  It will take space
to record, processing cycles to implement, and management cycles to
maintain, for each or the posited hundreds or routers in an ISP.

And Iljitsch commented ...

> Yes, except maybe for the "lots of groups" part. A lot of traffic is
> exchanged at internet exchanges. Typically, all peer routers share the
> same settings for outbound updates. For instance, I manage a router with
> 103 peers in 4 groups, with the largest group having some 40 neighbors.

(I've been told that many ISPs are moving to private peering
arrangements.)  We certainly need to consider the case you have
described.  We need to get a list of all the topologies that need to
be supported into the requirements list.  Are there any others
(besides private peerings and internet exchanges) that are significant?

Charlie
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov  7 03:28:51 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07073
	for <rpsec-archive@odin.ietf.org>; Thu, 7 Nov 2002 03:28:51 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA78V0J26834
	for rpsec-archive@odin.ietf.org; Thu, 7 Nov 2002 03:31:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA78Uwv26831
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 7 Nov 2002 03:30:58 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07065
	for <rpsec-web-archive@ietf.org>; Thu, 7 Nov 2002 03:28:18 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA78U6v26784;
	Thu, 7 Nov 2002 03:30:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA78O2v26612
	for <rpsec@optimus.ietf.org>; Thu, 7 Nov 2002 03:24:02 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06949
	for <rpsec@ietf.org>; Thu, 7 Nov 2002 03:21:23 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA78KxI60249;
	Thu, 7 Nov 2002 09:20:59 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Thu, 7 Nov 2002 09:20:59 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Susan Hares <shares@nexthop.com>
cc: <rpsec@ietf.org>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <BE36D687C8CBFA4AB76F5CD3E3C0FB4E964E8E@aa-exchange1.corp.nexthop.com>
Message-ID: <20021107091951.M58530-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, 6 Nov 2002, Susan Hares wrote:

> How does SBGP handle Aggregation or
> proxy aggregation?

Isn't aggregation anywhere else than at the source of the announcement a
relic from the BGP3 transition? Ie do people still use it?

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov  7 09:04:15 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24561
	for <rpsec-archive@odin.ietf.org>; Thu, 7 Nov 2002 09:04:14 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA7E6E719187
	for rpsec-archive@odin.ietf.org; Thu, 7 Nov 2002 09:06:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7E6Ev19184
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 7 Nov 2002 09:06:14 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24543
	for <rpsec-web-archive@ietf.org>; Thu, 7 Nov 2002 09:03:29 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7E5Uv19132;
	Thu, 7 Nov 2002 09:05:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7E44v19033
	for <rpsec@optimus.ietf.org>; Thu, 7 Nov 2002 09:04:04 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24509
	for <rpsec@ietf.org>; Thu, 7 Nov 2002 09:01:32 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA7E3GT60663;
	Thu, 7 Nov 2002 15:03:17 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Thu, 7 Nov 2002 15:03:16 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: <sandy@tislabs.com>
cc: <kent@bbn.com>, <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <200211061737.gA6Hbbt19688@raven.gw.tislabs.com>
Message-ID: <20021107145140.V58530-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, 6 Nov 2002 sandy@tislabs.com wrote:

> >I don't see what this has to do with having a neighbor identifier in the
> >update message. Since the AS path is different here, this situation
> >should be caught in the AS path validation phase.

> It would not be caught in the AS path validation phase.  N has a valid
> signed path that ends in AS X, signed by AS X.  (We're presuming the
> don't-include-neighbor-id-in-signature approach.)  AS N adds itself
> to the path and signs that.  All signatures check.

Ah, I see now. I was under the impression including the destination AS
was only relevant to the update message and not to the signing of the
path. I see a few ways around this:

- include all neighbors in one signature: more costly in terms of
  memory, less in processing
- don't include the AS for peering neighbors but only transit neighbors
  in the signature. Then peers don't get to announce the route any
  further, which is good, mostly. Customers of the peer would have to
  accept the route without a signature, though.
- make some kind of virtual AS group

> >Also note that protecting against abuse by AS N (for instance, AS N
> >claims to have the bast path to a destination that AS X really has the
> >best path to) on the basis that AS N isn't a neighbor of AS X is too
> >weak as it is not extremely unlikely ASes X and N peer.

> "not extremely unlikely" == "likely"?  Why?

Because there is simply a lot of peering. The peering relationship is
one where both parties benefit from not having to send traffic over more
expensive link. It doesn't mean they trust each other. (If you _don't_
trust someone it may even be better to peer because then you know which
stuff is theirs.)

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov  7 09:41:17 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26251
	for <rpsec-archive@odin.ietf.org>; Thu, 7 Nov 2002 09:41:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA7EhHi22096
	for rpsec-archive@odin.ietf.org; Thu, 7 Nov 2002 09:43:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7EhHv22093
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 7 Nov 2002 09:43:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26219
	for <rpsec-web-archive@ietf.org>; Thu, 7 Nov 2002 09:40:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7Eh3v22084;
	Thu, 7 Nov 2002 09:43:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7EgAv22053
	for <rpsec@optimus.ietf.org>; Thu, 7 Nov 2002 09:42:10 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26202
	for <rpsec@ietf.org>; Thu, 7 Nov 2002 09:39:39 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id JAA02376; Thu, 7 Nov 2002 09:42:12 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma002363; Thu, 7 Nov 02 09:41:31 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gA7EfPu14442;
	Thu, 7 Nov 2002 09:41:25 -0500 (EST)
Date: Thu, 7 Nov 2002 09:41:25 -0500 (EST)
Message-Id: <200211071441.gA7EfPu14442@raven.gw.tislabs.com>
To: iljitsch@muada.com
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>- include all neighbors in one signature: more costly in terms of
>  memory, less in processing

You have probably read Charlie Lynn's mail by now where he says that
SBGP can do this.  And we had discussed earlier grouping neighbors.

Which brings up the point that I should and will stop trying to answer
questions about the SBGP stuff, since I'm definitely not the expert here.

>Because there is simply a lot of peering.

Well, it's widely know that the average AS_PATH is not long.  But it
isn't *2*.  Which means that there are lots of cases where two AS's
aren't neighbors.  Which opens opportunities for influencing routing
to the bad, if you don't have protections.

>- don't include the AS for peering neighbors but only transit neighbors
>  in the signature. Then peers don't get to announce the route any
>  further, which is good, mostly. Customers of the peer would have to
>  accept the route without a signature, though.

I don't get this at all.  But, more importantly, I don't think that we
should be trying to work out the details of a solution for BGP.
Certainly not in this working group.

The original comment that sparked this thread was that the SBGP
protections eliminated certain optimizations that are used and desirable.
That was incorrect, as Charlie's message shows.  But the lesson for
this working group is (1) most security solutions can have an effect
on optimizations and (2) should the security requirements prohibit
impact on optimizations?  permit the impact?  limit the impact?  Etc.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov  7 11:03:19 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29783
	for <rpsec-archive@odin.ietf.org>; Thu, 7 Nov 2002 11:03:19 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA7G5KD27583
	for rpsec-archive@odin.ietf.org; Thu, 7 Nov 2002 11:05:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7G5Kv27580
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 7 Nov 2002 11:05:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29709
	for <rpsec-web-archive@ietf.org>; Thu, 7 Nov 2002 11:02:48 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7G4ov27502;
	Thu, 7 Nov 2002 11:04:50 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7FwJv27210
	for <rpsec@optimus.ietf.org>; Thu, 7 Nov 2002 10:58:19 -0500
Received: from wolfe.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29262
	for <rpsec@ietf.org>; Thu, 7 Nov 2002 10:55:46 -0500 (EST)
Received: by wolfe.bbn.com (Postfix, from userid 13538)
	id C5A6416484; Thu,  7 Nov 2002 10:58:14 -0500 (EST)
From: Charles Lynn <clynn@bbn.com>
To: rpsec@ietf.org
Cc: shares@nexthop.com, iljitsch@muada.com, clynn@bbn.com
Subject: Aggregation in S-BGP was RE: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <BE36D687C8CBFA4AB76F5CD3E3C0FB4E964E8E@aa-exchange1.corp.nexthop.com>
Message-Id: <20021107155814.C5A6416484@wolfe.bbn.com>
Date: Thu,  7 Nov 2002 10:58:14 -0500 (EST)
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Hi Sue,

> How does SBGP handle Aggregation or proxy aggregation?

The basic model is that the BGP implementation combines some set of
routes into an aggregate.  The S-BGP mechanisms then insert into the
attestation path attribute (used to carry the signatures, etc.) enough
information to be able to verify all the pieces that were aggregated.

The number of Adj-RIB-In entries (and the FIB entries derived from it)
in speakers that receive the aggregate is thus unchanged by the S-BGP
mechanisms (provided that the content of the aggregate passes the
security checks).  However the size of the Adj-RIB-In entry for the
S-BGP protected aggregate is obviously larger than it would be for
the non-S-BGP case.

In cases where the aggregator claims to be the originator for the
aggregate, the organizations with the right to use the prefixes being
aggregated (which might happen to be/include the aggregator) need to
authorize the aggregating AS to do so, using the usual "address
attestation".

Iljitsch commented...

> Isn't aggregation anywhere else than at the source of the announcement
> a relic from the BGP3 transition? Ie do people still use it?

Last time I looked (viewpoints of routing UPDATEs vary), about 0.2 %
of advertised routes contained AS Sets (one form of aggregation).

To be clear, "aggregation ... at the source of the announcement" could
be interpreted as, e.g., by an ISP that aggregates routes from
customers that are using portions of the ISP's address space, or
alternatively as an ISP that aggregates routes from several sources
and claims to be the originator (removing information about the
aggregated routes to the NLRI in the process).  S-BGP handles either
form, but the latter produces a larger UPDATE message.

(In the cases we looked at, the aggregated UPDATE received by the AS
 that peered with an aggregating AS was larger than would have been the
 case if the aggregation had not been performed, but the aggregated
 UPDATE message was smaller than the sum of the non-aggregated UPDATEs
 for ASes two or more AS-hops away from the aggregator.  Additional live
 data from ASes doing aggregation -- the UPDATEs being aggregated and
 the aggregated UPDATE -- would be helpful for additional analysis.)

Charlie
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov  7 16:12:56 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12664
	for <rpsec-archive@odin.ietf.org>; Thu, 7 Nov 2002 16:12:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA7LF0F20666
	for rpsec-archive@odin.ietf.org; Thu, 7 Nov 2002 16:15:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7LExv20663
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 7 Nov 2002 16:14:59 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12639
	for <rpsec-web-archive@ietf.org>; Thu, 7 Nov 2002 16:12:25 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7LEdv20651;
	Thu, 7 Nov 2002 16:14:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7KZ4v15502
	for <rpsec@optimus.ietf.org>; Thu, 7 Nov 2002 15:35:04 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965
	for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST)
Message-Id: <200211072011.PAA08965@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
To: All IETF Working Groups: ;
x-msg: NoteWell
Date: Thu, 07 Nov 2002 15:11:40 -0500
Subject: [RPSEC] Note Well Statement
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov  7 17:11:25 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15372
	for <rpsec-archive@odin.ietf.org>; Thu, 7 Nov 2002 17:11:25 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA7MDUL25377
	for rpsec-archive@odin.ietf.org; Thu, 7 Nov 2002 17:13:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7MDTv25373
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 7 Nov 2002 17:13:29 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15363
	for <rpsec-web-archive@ietf.org>; Thu, 7 Nov 2002 17:10:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7MD9v25356;
	Thu, 7 Nov 2002 17:13:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7MCCv25311
	for <rpsec@optimus.ietf.org>; Thu, 7 Nov 2002 17:12:12 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15337
	for <rpsec@ietf.org>; Thu, 7 Nov 2002 17:09:21 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04989;
	Thu, 7 Nov 2002 17:11:46 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100311b9f0917c10e4@[128.89.88.34]>
In-Reply-To: <20021106171433.J58530-100000@sequoia.muada.com>
References: <20021106171433.J58530-100000@sequoia.muada.com>
Date: Thu, 7 Nov 2002 17:07:42 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
Cc: <rpsec@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Iljitsch,

>On Wed, 6 Nov 2002 sandy@tislabs.com wrote:
>
>>  >IMHO - "Security requirements" that force Internet capital spending and
>>  >network wide maintenance windows to deploy are not going to be adopted by
>>  >the operations community.
>
>>  Not a surprising development and reminiscent of the auto manufacturers'
>>  stance on seat belts, crash resistent bumpers, air bags, ...  Those whose
>>  focus is the bottom line always want to be shown a financial incentive.
>>  "How about 'survival'?" seems to be unpersuasive.
>
>Routers are a lot like regular computers in many ways, but you can only
>expect to sell a very small number compared to computers. I'm not a
>router builder but I think that's the reason why router CPUs are so slow
>compared to those of regular computers: the design costs to keep up with
>the latest CPU technology would be too high.

The performance of the CPU used for BGP varies from model to model 
and from vendor to vendor.

>As far as I can tell, verifying a signature takes in the order of a
>millisecond on a decent CPU. So with 115,000 routes in the global
>routing table, that's 2 minutes to initialize BGP, assuming one
>signature must be checked per route. I don't think this is acceptable,
>especially not considering router CPUs may be slower, there is other
>processing to do as well and the expected growth of the global routing
>table. This means routers must be equipped with crypto modules.

We realized long ago that startup transients could be a serious 
timing concern, and so we have suggested that routers destined to 
support S-BGP would ideally have non-volatile storage sufficient to 
hold a recent copy of the RAs, as well as the AAs and PKI data. Few 
(if any) routers deployed today have this cap[ability, but it would 
be cheap to provide in the future, e.g., flash memory prices are 
fairly low even today.

>Then there is memory. There are still many routers in production that
>are already in trouble memory-wise as their design allows only 32, 64 or
>128 MB and a Cisco needs 256 MB to comfortably run BGP. I've tried to
>add up all the extra fields but I couldn't be sure how much of what goes
>where, but it looks like S-BGP will take at least twice the memory of
>regular BGP.

Again, no argument that currently deployed routers would not 
generally have sufficient memory to hold all the RAs if everyone ran 
S-BGP, but then these routers would probably no longer be in use by 
the time everybody would be ready to run S-BGP. The factors (to first 
order) that determine the extra memory requirements under S-BGP are 
the number of ADJ-RIBs the router holds, the number of routes in the 
RIBs, and the average path length for the routes. The total memory 
requirement is a function of these factors, plus the extent to which 
S-BGP is deployed, i.e., the fraction of routes that are S-BGP 
protected. In any case, we're not talking about more memory than my 
laptop and desktop have, and the costs are not great, but you are 
right that most routers in use today simply do not have the ability 
to support enough memory, although some do. But, as noted above, the 
initial stages of incremental deployment would not need as much extra 
memory as full deployment.

>This means some routers must be replaced completely and all others need
>hardware upgrades. So expect resistance from the people who have to pay
>the bill. Especially if there is so much of a byte wasted in your packet
>formats, or there is a place where crypto is used when the same result
>could be obtained without it.
>

Yes, routers would need to be replaced over time, but routers are 
replaced over time anyway, so the question is in part one of timing, 
and incremental deployment is, by definition, staged over time. 
Also, it would be possible to use ancillary devices with multi-hop 
BGP to avoid a "fork lift upgrade" for some routers, if one can 
tolerate managing the extra boxes.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov  8 09:32:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19877
	for <rpsec-archive@odin.ietf.org>; Fri, 8 Nov 2002 09:32:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA8EYP529147
	for rpsec-archive@odin.ietf.org; Fri, 8 Nov 2002 09:34:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8EYPv29144
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 8 Nov 2002 09:34:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19867
	for <rpsec-web-archive@ietf.org>; Fri, 8 Nov 2002 09:31:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8EXLv29029;
	Fri, 8 Nov 2002 09:33:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA83Cgv10407
	for <rpsec@optimus.ietf.org>; Thu, 7 Nov 2002 22:12:42 -0500
Received: from EXECDSL.COM (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22789
	for <rpsec@ietf.org>; Thu, 7 Nov 2002 22:10:00 -0500 (EST)
Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com)
  by EXECDSL.COM (CommuniGate Pro SMTP 3.3)
  with ESMTP id 3935276 for rpsec@ietf.org; Thu, 07 Nov 2002 22:12:29 -0500
Message-Id: <5.1.0.14.0.20021107220526.02713900@mail.stevecrocker.com>
X-Sender: joel@stevecrocker.com@mail.stevecrocker.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 07 Nov 2002 22:10:36 -0500
To: <rpsec@ietf.org>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <p05100311b9f0917c10e4@[128.89.88.34]>
References: <20021106171433.J58530-100000@sequoia.muada.com>
 <20021106171433.J58530-100000@sequoia.muada.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

What I see in S-BGP and this discussion is:

1) An approach that attempts to comprehensively provide security for BGP
2) An approach that for deployment probably requires significant 
enhancements in the actual routing hardware (storage, increased memory, 
crypto hardware).

It seems this overlooks several things:
A) The indications are that operators are not interested in (or possibly 
even capable of) deploying solutions with this complexity
B) We could probably get a lot of coverage (but not as complete) with a 
much simpler solution or set of solutions.
C) Securing BGP this carefully when the rest of the infrastructure is 
completely insecure seems almost counter-productive.

Note that currently many operators do not deploy source address filtering, 
or even martian address filtering with their customers.  And that is only 
the tip of the iceberg of simple things that need to be done.  It would 
seem that whatever energy it would take to even begin serious development 
and deployment of S-BGP could be much better spent getting some of the 
simple steps that are necessary deployed.  Then we could examine again to 
determine what makes sense to do next based on that experience.

Yours,
Joel M. Halpern

At 05:07 PM 11/7/2002 -0500, Stephen Kent wrote:
>Iljitsch,
>
>>On Wed, 6 Nov 2002 sandy@tislabs.com wrote:
>>
>>>  >IMHO - "Security requirements" that force Internet capital spending and
>>>  >network wide maintenance windows to deploy are not going to be adopted by
>>>  >the operations community.
>>
>>>  Not a surprising development and reminiscent of the auto manufacturers'
>>>  stance on seat belts, crash resistent bumpers, air bags, ...  Those whose
>>>  focus is the bottom line always want to be shown a financial incentive.
>>>  "How about 'survival'?" seems to be unpersuasive.
>>
>>Routers are a lot like regular computers in many ways, but you can only
>>expect to sell a very small number compared to computers. I'm not a
>>router builder but I think that's the reason why router CPUs are so slow
>>compared to those of regular computers: the design costs to keep up with
>>the latest CPU technology would be too high.
>
>The performance of the CPU used for BGP varies from model to model and 
>from vendor to vendor.
>
>>As far as I can tell, verifying a signature takes in the order of a
>>millisecond on a decent CPU. So with 115,000 routes in the global
>>routing table, that's 2 minutes to initialize BGP, assuming one
>>signature must be checked per route. I don't think this is acceptable,
>>especially not considering router CPUs may be slower, there is other
>>processing to do as well and the expected growth of the global routing
>>table. This means routers must be equipped with crypto modules.
>
>We realized long ago that startup transients could be a serious timing 
>concern, and so we have suggested that routers destined to support S-BGP 
>would ideally have non-volatile storage sufficient to hold a recent copy 
>of the RAs, as well as the AAs and PKI data. Few (if any) routers deployed 
>today have this cap[ability, but it would be cheap to provide in the 
>future, e.g., flash memory prices are fairly low even today.
>
>>Then there is memory. There are still many routers in production that
>>are already in trouble memory-wise as their design allows only 32, 64 or
>>128 MB and a Cisco needs 256 MB to comfortably run BGP. I've tried to
>>add up all the extra fields but I couldn't be sure how much of what goes
>>where, but it looks like S-BGP will take at least twice the memory of
>>regular BGP.
>
>Again, no argument that currently deployed routers would not generally 
>have sufficient memory to hold all the RAs if everyone ran S-BGP, but then 
>these routers would probably no longer be in use by the time everybody 
>would be ready to run S-BGP. The factors (to first order) that determine 
>the extra memory requirements under S-BGP are the number of ADJ-RIBs the 
>router holds, the number of routes in the RIBs, and the average path 
>length for the routes. The total memory requirement is a function of these 
>factors, plus the extent to which S-BGP is deployed, i.e., the fraction of 
>routes that are S-BGP protected. In any case, we're not talking about more 
>memory than my laptop and desktop have, and the costs are not great, but 
>you are right that most routers in use today simply do not have the 
>ability to support enough memory, although some do. But, as noted above, 
>the initial stages of incremental deployment would not need as much extra 
>memory as full deployment.
>
>>This means some routers must be replaced completely and all others need
>>hardware upgrades. So expect resistance from the people who have to pay
>>the bill. Especially if there is so much of a byte wasted in your packet
>>formats, or there is a place where crypto is used when the same result
>>could be obtained without it.
>
>Yes, routers would need to be replaced over time, but routers are replaced 
>over time anyway, so the question is in part one of timing, and 
>incremental deployment is, by definition, staged over time. Also, it would 
>be possible to use ancillary devices with multi-hop BGP to avoid a "fork 
>lift upgrade" for some routers, if one can tolerate managing the extra boxes.
>
>Steve
>_______________________________________________
>RPSEC mailing list
>RPSEC@ietf.org
>https://www1.ietf.org/mailman/listinfo/rpsec


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov  8 10:36:34 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23384
	for <rpsec-archive@odin.ietf.org>; Fri, 8 Nov 2002 10:36:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA8Fcab04077
	for rpsec-archive@odin.ietf.org; Fri, 8 Nov 2002 10:38:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Fcav04074
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 8 Nov 2002 10:38:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23346
	for <rpsec-web-archive@ietf.org>; Fri, 8 Nov 2002 10:36:02 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8FcHv04051;
	Fri, 8 Nov 2002 10:38:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8FbGv03723
	for <rpsec@optimus.ietf.org>; Fri, 8 Nov 2002 10:37:16 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23198
	for <rpsec@ietf.org>; Fri, 8 Nov 2002 10:34:43 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21394;
	Fri, 8 Nov 2002 10:37:19 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100306b9f1866d9d36@[128.89.88.34]>
In-Reply-To: <5.1.0.14.0.20021107220526.02713900@mail.stevecrocker.com>
References: <20021106171433.J58530-100000@sequoia.muada.com>
 <20021106171433.J58530-100000@sequoia.muada.com>
 <5.1.0.14.0.20021107220526.02713900@mail.stevecrocker.com>
Date: Fri, 8 Nov 2002 10:35:20 -0500
To: "Joel M. Halpern" <joel@stevecrocker.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
Cc: <rpsec@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Joel,

>What I see in S-BGP and this discussion is:
>
>1) An approach that attempts to comprehensively provide security for BGP

yes

>2) An approach that for deployment probably requires significant 
>enhancements in the actual routing hardware (storage, increased 
>memory, crypto hardware).

in the long run yes, but maybe not for initial, incremental 
deployment because, by definition, there are fewer entries with RAs 
and thus less space is required in RIBs and fewer sigs to generate or 
check, etc.

>It seems this overlooks several things:
>A) The indications are that operators are not interested in (or 
>possibly even capable of) deploying solutions with this complexity

agreed, but at least in the U.S. there is an increased focus on 
infrastructure security, and Richard Clark has hinted that if ISPs do 
not do a better job, the Government may "help"

>B) We could probably get a lot of coverage (but not as complete) 
>with a much simpler solution or set of solutions.

Do you have a specific example in mind? So far we have few, if any 
proposals that have been well analyzed re the security they provide, 
so I find it a bit hard to understand how you can confidently make 
this statement. Also, one needs to have a metric by which you can 
characterize the extent of "coverage" in order to compare two 
security proposals. What metric do you envision?

>C) Securing BGP this carefully when the rest of the infrastructure 
>is completely insecure seems almost counter-productive.

What "rest of the infrastructure" do you have in mind? Routing is 
separate from DNS, for example, in terms of what attacks can do, so 
it is justifiable to pursue securing these independently. Also, the 
design of S-BGP is such that it protects the set of ISPs who use it 
from false advertisements about the parts of the address space by the 
ISPs who do not use it. So, it offers incremental benefits even 
without full deployment.

>Note that currently many operators do not deploy source address 
>filtering, or even martian address filtering with their customers. 
>And that is only the tip of the iceberg of simple things that need 
>to be done.  It would seem that whatever energy it would take to 
>even begin serious development and deployment of S-BGP could be much 
>better spent getting some of the simple steps that are necessary 
>deployed.  Then we could examine again to determine what makes sense 
>to do next based on that experience.

There is a difference between approaches to security that rely on 
other ISPs to do the right thing, and approaches that let you know if 
other ISPs are doing the right thing. S-BGP falls into the latter 
category and thus is more resistant to benign failures and attacks 
against internal ISP route management components or procedures, vs. 
schemes that rely on ISPs doing local source address filtering, for 
example. Yes, there are other things ISPs could be doing to make life 
better, but these measures are not very resistant to many forms of 
attacks and they represent considerable management burdens for ISPs. 
So in part the question is whether one should devote effort to 
halfway measures, or devote more effort to more comprehensive 
measures.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov  8 12:20:27 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29510
	for <rpsec-archive@odin.ietf.org>; Fri, 8 Nov 2002 12:20:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA8HMUP12914
	for rpsec-archive@odin.ietf.org; Fri, 8 Nov 2002 12:22:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8HMUv12911
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 8 Nov 2002 12:22:30 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29471
	for <rpsec-web-archive@ietf.org>; Fri, 8 Nov 2002 12:19:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8HM6v12874;
	Fri, 8 Nov 2002 12:22:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8HLAv12792
	for <rpsec@optimus.ietf.org>; Fri, 8 Nov 2002 12:21:10 -0500
Received: from rip.psg.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29386
	for <rpsec@ietf.org>; Fri, 8 Nov 2002 12:18:35 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com)
	by rip.psg.com with esmtp (Exim 4.10)
	id 18ACob-000DkW-00; Fri, 08 Nov 2002 09:21:05 -0800
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Joel M. Halpern" <joel@stevecrocker.com>
Cc: <rpsec@ietf.org>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
References: <20021106171433.J58530-100000@sequoia.muada.com>
	<5.1.0.14.0.20021107220526.02713900@mail.stevecrocker.com>
Message-Id: <E18ACob-000DkW-00@rip.psg.com>
Date: Fri, 08 Nov 2002 09:21:05 -0800
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> 1) An approach that attempts to comprehensively provide security for BGP
> 2) An approach that for deployment probably requires significant 
> enhancements in the actual routing hardware (storage, increased memory, 
> crypto hardware).
> 
> It seems this overlooks several things:
> A) The indications are that operators are not interested in (or possibly 
> even capable of) deploying solutions with this complexity
> B) We could probably get a lot of coverage (but not as complete) with a 
> much simpler solution or set of solutions.
> C) Securing BGP this carefully when the rest of the infrastructure is 
> completely insecure seems almost counter-productive.
> 
> Note that currently many operators do not deploy source address
> filtering, or even martian address filtering with their
> customers.  And that is only the tip of the iceberg of simple
> things that need to be done.  It would seem that whatever energy
> it would take to even begin serious development and deployment of
> S-BGP could be much better spent getting some of the simple steps
> that are necessary deployed.  Then we could examine again to
> determine what makes sense to do next based on that experience.

what this analysis omits is what we will have to do in a month or
three years when we get _serious_ widespread routing attacks [0].
as serious defense will, as you well point out, take some time to
deploy, it seems prudent to start now, rather than have a large
window of major problems while we deploy too late.

randy

---

[0] - note that we have already seen real non-trivial routing
      attacks.  folk just don't talk about them in public.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov  8 17:52:50 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20828
	for <rpsec-archive@odin.ietf.org>; Fri, 8 Nov 2002 17:52:49 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA8Msuu05973
	for rpsec-archive@odin.ietf.org; Fri, 8 Nov 2002 17:54:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Msuv05970
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 8 Nov 2002 17:54:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20777
	for <rpsec-web-archive@ietf.org>; Fri, 8 Nov 2002 17:52:18 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8MsNv05950;
	Fri, 8 Nov 2002 17:54:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Mr1v05901
	for <rpsec@optimus.ietf.org>; Fri, 8 Nov 2002 17:53:01 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20724
	for <rpsec@ietf.org>; Fri, 8 Nov 2002 17:50:24 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA8MqN563832;
	Fri, 8 Nov 2002 23:52:23 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Fri, 8 Nov 2002 23:52:23 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: "Joel M. Halpern" <joel@stevecrocker.com>
cc: <rpsec@ietf.org>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <5.1.0.14.0.20021107220526.02713900@mail.stevecrocker.com>
Message-ID: <20021108233801.C62928-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Thu, 7 Nov 2002, Joel M. Halpern wrote:

> It seems this overlooks several things:
> A) The indications are that operators are not interested in (or possibly
> even capable of) deploying solutions with this complexity

Good point. Also, this is very much a double edged sword: on the one
hand, the expensive crypto checks validate that what's in the routing
tables is good, but on the other hand they'll keep out stuff, and
certainly not all of what they'll keep out will be bad. If I look at the
way routing registry entries are maintained today, I expect the first
few networks that implement this will suffer from noticably degraded
connectivity to the rest of the world.

> B) We could probably get a lot of coverage (but not as complete) with a
> much simpler solution or set of solutions.

Agree. I think soBGP is much better than S-BGP in this regard, but both
of them are stuck on a track that I think is wrong for this: the source
provides information to the router, and the router validates this
information using cryptographic means. This is a good approach if the
information the source will be providing can't be checked by other
means. However, that is not the case here: it is possible to collect the
information about what the source may be announcing beforehand, and then
simply check the actual announcement against this information. This way
the routers don't need to do any crypto.

> C) Securing BGP this carefully when the rest of the infrastructure is
> completely insecure seems almost counter-productive.

> Note that currently many operators do not deploy source address filtering,

Which is indeed a big problem as it makes very hard to trace DoS attacks
possible. These happen every day, and many ISPs don't do very little to
stop it. Routing attacks are rare enough that I've never heard anyone
say they encountered one. I don't doubt Randy's remark that there have
been some, but the fact that the victims don't want to talk about it
makes me assume the attacks could probably have stopped using today's
technology.

However, just because there is problem A doesn't mean you shouldn't do
anything about problem B. It's not like work on routing security will
take away time from installing anti-spoofing filters.

> or even martian address filtering with their customers.

Martian filters aren't a good idea as they remove some symptoms but not
the cause. If someone doesn't filter, I like seeing those packets from
192.168.0.0/16 to inform me of this fact.

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov  8 17:54:21 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20963
	for <rpsec-archive@odin.ietf.org>; Fri, 8 Nov 2002 17:54:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA8MuSe06075
	for rpsec-archive@odin.ietf.org; Fri, 8 Nov 2002 17:56:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8MuRv06072
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 8 Nov 2002 17:56:27 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20916
	for <rpsec-web-archive@ietf.org>; Fri, 8 Nov 2002 17:53:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Mu2v06059;
	Fri, 8 Nov 2002 17:56:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Mtov06010
	for <rpsec@optimus.ietf.org>; Fri, 8 Nov 2002 17:55:50 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20844
	for <rpsec@ietf.org>; Fri, 8 Nov 2002 17:53:12 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA8Mt0163844;
	Fri, 8 Nov 2002 23:55:00 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Fri, 8 Nov 2002 23:55:00 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Stephen Kent <kent@bbn.com>
cc: <rpsec@ietf.org>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <p05100306b9f1866d9d36@[128.89.88.34]>
Message-ID: <20021108235307.C62928-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Fri, 8 Nov 2002, Stephen Kent wrote:

> There is a difference between approaches to security that rely on
> other ISPs to do the right thing, and approaches that let you know if
> other ISPs are doing the right thing. S-BGP falls into the latter
> category and thus is more resistant to benign failures and attacks
> against internal ISP route management components or procedures, vs.
> schemes that rely on ISPs doing local source address filtering, for
> example.

Source address filtering can be done in other places than just the
customer edge. It is possible to do this on peering interfaces as well,
if done with care. Unfortunately, it can't be done on transit
interfaces. So the tier-1 ISPs (who get all their traffic from peering)
should step up to the plate and start doing this to protect the rest of
us.

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov  8 18:06:20 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21435
	for <rpsec-archive@odin.ietf.org>; Fri, 8 Nov 2002 18:06:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA8N8QC07140
	for rpsec-archive@odin.ietf.org; Fri, 8 Nov 2002 18:08:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8N8Qv07137
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 8 Nov 2002 18:08:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21369
	for <rpsec-web-archive@ietf.org>; Fri, 8 Nov 2002 18:05:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8N8Dv07095;
	Fri, 8 Nov 2002 18:08:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8N6Tv06396
	for <rpsec@optimus.ietf.org>; Fri, 8 Nov 2002 18:06:29 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21309
	for <rpsec@ietf.org>; Fri, 8 Nov 2002 18:03:51 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA8N5vt63872
	for <rpsec@ietf.org>; Sat, 9 Nov 2002 00:05:57 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Sat, 9 Nov 2002 00:05:57 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: <rpsec@ietf.org>
Message-ID: <20021108235508.R62928-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [RPSEC] changing the next hop
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

I'm not sure of anyone thought of this attack before:

When connected to an internet exchange, network A announces a route
(which is probably a bogus route, but it may be a route that A can
rightfully announce) with a next hop address pointing to a router from
network B.

I'll spare this public forum the details, but I think this seemingly not
very serious attack mode can be used to do some real harm if A peers
with a good number of networks with very bad filtering. Note that B
can't do anything to protect itself against this in principle, but it
would be possible to remove the "real harm" part if and when this
happens. Also note that this attack must be launched from a router
connected to the exchange.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov  8 18:24:12 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22040
	for <rpsec-archive@odin.ietf.org>; Fri, 8 Nov 2002 18:24:12 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA8NQJc08044
	for rpsec-archive@odin.ietf.org; Fri, 8 Nov 2002 18:26:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8NQJv08041
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 8 Nov 2002 18:26:19 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22008
	for <rpsec-web-archive@ietf.org>; Fri, 8 Nov 2002 18:23:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8NQ6v08026;
	Fri, 8 Nov 2002 18:26:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8NP1v07993
	for <rpsec@optimus.ietf.org>; Fri, 8 Nov 2002 18:25:01 -0500
Received: from xmxpita.excite.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21981
	for <rpsec@ietf.org>; Fri, 8 Nov 2002 18:22:24 -0500 (EST)
Received: by xmxpita.excite.com (Postfix, from userid 110)
	id 27759133CC; Fri,  8 Nov 2002 18:24:52 -0500 (EST)
To: rpsec@ietf.org
Received: from [149.169.41.112] by xprdmailfe5.nwk.excite.com via HTTP; Fri, 08 Nov 2002 18:24:52 EST
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: ID = 0296a4b3fd28fe6fb07af689d1af0c35
Reply-To: carl221@excite.com
From: "" <carl221@excite.com>
MIME-Version: 1.0
X-Sender: carl221@excite.com
X-Mailer: PHP
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <20021108232452.27759133CC@xmxpita.excite.com>
Date: Fri,  8 Nov 2002 18:24:52 -0500 (EST)
Content-Transfer-Encoding: 7bit
Subject: [RPSEC] SCADA System Routing
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Dear All,

I am working on a PhD research in Routing and Securing data in a SCADA system.  Could anyone help in providing some information on data routing in a SCADA system?  I would also appreciate any other information on intrusion detection systems (IDS).

Your help will be gratefully appreciated.

Joseph,





_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov  8 18:25:08 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22091
	for <rpsec-archive@odin.ietf.org>; Fri, 8 Nov 2002 18:25:08 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA8NRFQ08154
	for rpsec-archive@odin.ietf.org; Fri, 8 Nov 2002 18:27:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8NRFv08151
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 8 Nov 2002 18:27:15 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22077
	for <rpsec-web-archive@ietf.org>; Fri, 8 Nov 2002 18:24:37 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8NR1v08103;
	Fri, 8 Nov 2002 18:27:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8NQ8v08034
	for <rpsec@optimus.ietf.org>; Fri, 8 Nov 2002 18:26:08 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22003
	for <rpsec@ietf.org>; Fri, 8 Nov 2002 18:23:31 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06092;
	Fri, 8 Nov 2002 18:26:08 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100318b9f1f596bb3d@[128.89.88.34]>
In-Reply-To: <20021108235307.C62928-100000@sequoia.muada.com>
References: <20021108235307.C62928-100000@sequoia.muada.com>
Date: Fri, 8 Nov 2002 18:21:51 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
Cc: <rpsec@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 11:55 PM +0100 11/8/02, Iljitsch van Beijnum wrote:
>On Fri, 8 Nov 2002, Stephen Kent wrote:
>
>>  There is a difference between approaches to security that rely on
>>  other ISPs to do the right thing, and approaches that let you know if
>>  other ISPs are doing the right thing. S-BGP falls into the latter
>>  category and thus is more resistant to benign failures and attacks
>>  against internal ISP route management components or procedures, vs.
>>  schemes that rely on ISPs doing local source address filtering, for
>>  example.
>
>Source address filtering can be done in other places than just the
>customer edge. It is possible to do this on peering interfaces as well,
>if done with care. Unfortunately, it can't be done on transit
>interfaces. So the tier-1 ISPs (who get all their traffic from peering)
>should step up to the plate and start doing this to protect the rest of
>us.

I realize that one can filter other than at the edge, but it gets 
harder to do it the further one goes away from the edge, with transit 
interfaces being the agreed upon limiting case. Your last sentence 
conflicts with my observation about the undesirability of relying on 
others to protect you, as far as security goes.

Its somewhat analogous to living in an apartment building; you can 
lock your own door to keep out unwanted visitors, or you can rely on 
all your fellow apartment dwellers to not loose their keys and to not 
buzz in bad visitors.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Sat Nov  9 12:12:38 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21714
	for <rpsec-archive@odin.ietf.org>; Sat, 9 Nov 2002 12:12:38 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA9HEgt03971
	for rpsec-archive@odin.ietf.org; Sat, 9 Nov 2002 12:14:42 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA9HEgv03968
	for <rpsec-web-archive@optimus.ietf.org>; Sat, 9 Nov 2002 12:14:42 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21702
	for <rpsec-web-archive@ietf.org>; Sat, 9 Nov 2002 12:12:07 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA9HE8v03927;
	Sat, 9 Nov 2002 12:14:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA9H4kv02747
	for <rpsec@optimus.ietf.org>; Sat, 9 Nov 2002 12:04:46 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21566
	for <rpsec@ietf.org>; Sat, 9 Nov 2002 12:02:11 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gA9H43M68144;
	Sat, 9 Nov 2002 18:04:03 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Sat, 9 Nov 2002 18:04:03 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Stephen Kent <kent@bbn.com>
cc: <rpsec@ietf.org>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
In-Reply-To: <p05100318b9f1f596bb3d@[128.89.88.34]>
Message-ID: <20021109175850.Q62928-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Fri, 8 Nov 2002, Stephen Kent wrote:

> >Source address filtering can be done in other places than just the
> >customer edge. It is possible to do this on peering interfaces as well,
> >if done with care. Unfortunately, it can't be done on transit
> >interfaces. So the tier-1 ISPs (who get all their traffic from peering)
> >should step up to the plate and start doing this to protect the rest of
> >us.

> I realize that one can filter other than at the edge, but it gets
> harder to do it the further one goes away from the edge, with transit
> interfaces being the agreed upon limiting case. Your last sentence
> conflicts with my observation about the undesirability of relying on
> others to protect you, as far as security goes.

> Its somewhat analogous to living in an apartment building; you can
> lock your own door to keep out unwanted visitors, or you can rely on
> all your fellow apartment dwellers to not loose their keys and to not
> buzz in bad visitors.

You should be able to rely on the door man to keep people out who are
recognizable as undesirable elements. After all, that's what you pay
for.

We all (directly or indirectly) pay the tier-1 networks so it is
reasonable to ask them to do anti-spoofing filtering on their peering
interfaces, for the exact reason you mention: expecting all ISPs to
filter their customers is the short road to disappointment.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Sat Nov  9 12:44:20 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22166
	for <rpsec-archive@odin.ietf.org>; Sat, 9 Nov 2002 12:44:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gA9HkPu05586
	for rpsec-archive@odin.ietf.org; Sat, 9 Nov 2002 12:46:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA9HkOv05583
	for <rpsec-web-archive@optimus.ietf.org>; Sat, 9 Nov 2002 12:46:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22150
	for <rpsec-web-archive@ietf.org>; Sat, 9 Nov 2002 12:43:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA9Hk7v05555;
	Sat, 9 Nov 2002 12:46:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA9Hjgv05528
	for <rpsec@optimus.ietf.org>; Sat, 9 Nov 2002 12:45:42 -0500
Received: from rip.psg.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22132
	for <rpsec@ietf.org>; Sat, 9 Nov 2002 12:43:07 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com)
	by rip.psg.com with esmtp (Exim 4.10)
	id 18AZfs-000OMs-00; Sat, 09 Nov 2002 09:45:36 -0800
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] changing the next hop
References: <20021108235508.R62928-100000@sequoia.muada.com>
Message-Id: <E18AZfs-000OMs-00@rip.psg.com>
Date: Sat, 09 Nov 2002 09:45:36 -0800
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> When connected to an internet exchange, network A announces a route
> (which is probably a bogus route, but it may be a route that A can
> rightfully announce) with a next hop address pointing to a router from
> network B.

old, old, old.  e.g. see nanog from about '96, when i turned off a
peer for doing so and they whined, screamed, lied, huffed, bluffed,
...

randy

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Sun Nov 10 13:38:04 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21414
	for <rpsec-archive@odin.ietf.org>; Sun, 10 Nov 2002 13:38:04 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAAIe9217181
	for rpsec-archive@odin.ietf.org; Sun, 10 Nov 2002 13:40:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAAIe9v17178
	for <rpsec-web-archive@optimus.ietf.org>; Sun, 10 Nov 2002 13:40:09 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21398
	for <rpsec-web-archive@ietf.org>; Sun, 10 Nov 2002 13:37:33 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAAIdRv17114;
	Sun, 10 Nov 2002 13:39:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAAIcVv17089
	for <rpsec@optimus.ietf.org>; Sun, 10 Nov 2002 13:38:31 -0500
Received: from wolfe.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21381
	for <rpsec@ietf.org>; Sun, 10 Nov 2002 13:35:55 -0500 (EST)
Received: by wolfe.bbn.com (Postfix, from userid 13538)
	id D10E316484; Sun, 10 Nov 2002 13:38:26 -0500 (EST)
From: Charles Lynn <clynn@bbn.com>
To: rpsec@ietf.org
Cc: "Joel M. Halpern" <joel@stevecrocker.com>,
        Iljitsch van Beijnum <iljitsch@muada.com>, CLynn@bbn.com
Subject: [RPSEC] Potential requirements
References: <20021108233801.C62928-100000@sequoia.muada.com>
	 <5.1.0.14.0.20021107220526.02713900@mail.stevecrocker.com>
	 <p05100306b9f1866d9d36@[128.89.88.34]>
	 <20021108235307.C62928-100000@sequoia.muada.com>
	 <p05100319b9f1fbd432bd@[128.89.88.34]>
	 <20021109180418.M62928-100000@sequoia.muada.com>
Message-Id: <20021110183826.D10E316484@wolfe.bbn.com>
Date: Sun, 10 Nov 2002 13:38:26 -0500 (EST)
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Folks,

I think that Iljitsch's response to Joel and his observations suggest
possible requirements for any security solutions that the group may
generate.  Here are some candidates, interspersed with recent
motivating remarks.  What other requirements would folks like to
propose?


> On Thu, 7 Nov 2002, Joel M. Halpern wrote:
> 
> > It seems this overlooks several things:
> > A) The indications are that operators are not interested in (or possibly
> >    even capable of) deploying solutions with this complexity
> 
> Good point. Also, this is very much a double edged sword: on the one
> hand, the expensive crypto checks validate that what's in the routing
> tables is good, but on the other hand they'll keep out stuff, and
> certainly not all of what they'll keep out will be bad.

Do folks think that the false positives would be limited to one-time
events at the beginning of an ISP's learning curve, or an ongoing
operational challenge?

Might the following proposed requirements address this issue?

Proposed Requirement:
    There must be a way for an ISP to evaluate their security
    mechanisms and configurations in both a laboratory setting and in
    the live Internet without impacting any router's Decision Process.

Proposed Requirement:
    There must be an automated mechanism that allows other ISPs to
    determine whether or not a given ISP/customer/whoever's routes
    should be rejected if a security mechanisms detect a problem.

Proposed Requirement:
    Once the mechanism (posited in the previous paragraph) has been
    turned on by an ISP, there must be a way to turn it back off.  The
    allowed time interval between when it is turned back off and when
    every other ISP ceases to make routing decisions base on the
    countermeasures information must be less than <some unit of time,
    TBD>.

> If I look at the way routing registry entries are maintained today,

Do folks think that there is a viable way to address this issue, so
that the information in the routing registry can be relied upon (after
some TBD date in the future)?

> I expect the first few networks that implement this will suffer from
> noticeably degraded connectivity to the rest of the world.

I think that this is an over generalization; it probably depends on
whatever solutions are eventually adopted :-).  There is the granularity
of protection issue to consider.  Is there a ...

Proposed Requirement:
    Security solutions must allow a granularity of protection at the
    level of an individual prefix.

Proposed Requirement:
    Any solution must allow for the co-existence of both protected and
    non-protected information, and the authoritative source of the
    information must be able to control whether or not the information
    is to be considered authentic.

Proposed Requirement:
    The (unauthorized?) removal of protection information by a third
    party must be detectable.

What do folks think should happen if tampering is detected?
Should the route be rejected?
Only used if no other tamper-free route is available?
Something else?


> > B) We could probably get a lot of coverage (but not as complete) with a
> >    much simpler solution or set of solutions.
> 
> Agree. I think soBGP is much better than S-BGP in this regard, but both
> of them are stuck on a track that I think is wrong for this: the source
> provides information to the router, and the router validates this
> information using cryptographic means. This is a good approach if the
> information the source will be providing can't be checked by other
> means. However, that is not the case here: it is possible to collect the
> information about what the source may be announcing beforehand, and then
> simply check the actual announcement against this information.

You are correct that the routers do not need to perform any crypto on
the raw origination information provided by the source; the NOCs can
do that once on behalf of all the routers in the AS.  In fact that is
exactly what S-BGP does for the relatively static authorized
originating AS information.  Generalizing a bit, do folks think that
the following is a reasonable requirement?

Proposed Requirement:
    Security solutions should provide mechanisms that allow processing
    to be off-loaded from routers to other assets when doing so would
    noticeably increase, e.g., the convergence time.  Deployment of
    off-loading must be implemented in a way that can maintain the
    integrity of the results of the processing, not introduce any
    single points of failure, and not contain vulnerabilities that
    introduce an unacceptable level of risk.

This raises the question of time scales.  What requirements would be
appropriate concerning "timeliness"?  For example, when an organization
receives a new IP address prefix, how long should they expect to have
to wait before the information has propagated to the furthest corners
of the Internet?

Should there be something like an 80/20 guideline where 80 % of the
Internet should see the new prefix by time T but the other 20 % may
take longer?

Note that both s0BGP and S-BGP use out-of-band data registries /
repositories to hold origin information.  As the interval T
decreases, the data has to be propagated faster.  At some T the use of
out-of-band information stores would cease to be viable and in-band
mechanisms would be required (which may preclude the ability to
off-load processing and crypto from the routers).

Should the working group try to set guidelines so that customer can
have reasonable expectations of how long things will take?

Other situations include a customer who switches providers: how long
should it take for the rest of the Internet to learn of the change?
Does the answer depend on whether the customer has his own prefix or
is/was using a prefix from the soon to be former provider?  What about
when a customer decides to become multi-homed?  Should there be a
guideline for how long it will take to propagate that information?
Does the answer depend on the prefix?

> This way the routers don't need to do any crypto.

I think "any" is too strong a term, at least if one does not consider
clear-text passwords to be adequate to protect access to a router.
Do folks think that the following should be a requirement?

Proposed Requirement:
    There needs to be a mechanism that uses "strong" authentication to
    verify the authenticity of management access to a router, and that
    can assure the integrity of management commands or data communicated
    between a router and its authorized managers.

<SNIP>

> I don't doubt Randy's remark that there have been some, but the fact
> that the victims don't want to talk about it makes me assume the
> attacks could probably have stopped using today's technology.

A different perspective is that a public acknowledgement that an ISP
has been successfully attacked might cause sufficient concern in the
customer base that would push an ISP struggling to survive over the
edge.

Maybe consumers need to be educated to the fact that attacks happen,
and they are, if we do a good job, no big deal.  Banks are robbed,
there is credit card fraud, neither seem to drive folks away from the
use of banks or credit cards.  We need to get to the point where
attacks on the internet do not even make the news.


> However, just because there is problem A doesn't mean you shouldn't
> do anything about problem B. It's not like work on routing security
> will take away time from installing anti-spoofing filters.

True for the case you point out, but it may not be true for all A and B.

> > or even martian address filtering with their customers.
> 
> Martian filters aren't a good idea as they remove some symptoms but not
> the cause. If someone doesn't filter, I like seeing those packets from
> 192.168.0.0/16 to inform me of this fact.

Are there requirements that the working group should make concerning
organizations that want to intercommunicate across the public Internet
using those addresses?  What mechanisms are used today, VPNs?  If so,
should there be any requirements about mechanisms to prevent the
leaking of addresses from one of a customer's VPNs into their other VPNs?
Are simple route filters the answer?  What about when the filters are
mis-configured?  Maybe that is "their problem" and not the ISP/pubic
internet's problem.  Would that be consistent with customer expectations?


> Source address filtering can be done in other places than just the
> customer edge. It is possible to do this on peering interfaces as well,
> if done with care. Unfortunately, it can't be done on transit
> interfaces.

Should we enumerate and document the factors that lead to the
conclusion that it can't be done?  E.g., things that were infeasible a
year ago might no longer be so next year.  Is it "simply" an issue of
memory or processing power?  Is it an issue that any prefix might be
received on any transit interface (even if that prefix has not been
advertised to a peer via that interface -- as might be the case if ISP
A does not want to provide transit service for ISPs B and C that peer
directly)?  Is it because it is hard to specify/manage a filter for
the small set of prefixes to be excluded since doing so requires
enumeration of the very large complement set of acceptable prefixes?
Is it an issue that the current mechanisms used to implement user
traffic filtering cannot keep up with the line rates?  Is it a return
on investment argument that the possible errors caught are so few that
the cost of catching them is not worth it?


> > If one coordinates attacks designed to effect DoS on central servers
> > for route checking with injection of bad routes, then we have a
> > recipe for a successful attack.
> 
> I think if there is a successful DoS attack on central infrastructure,

Should there be a requirement that routing must continue to "work"
when access to "central infrastructure" is not available?  If so, for
how long - 5 minutes, and hour, half a day, a few days?  Should any
effects of denied access be limited to "future changes" to peerings or
new prefixes being allocated, i.e., anything that was able to be
routed before the attack should continue to be routed after it?

> then a few bad routes are the least of your concerns.

Wouldn't the "damage" be more a function of which (customer's) routes
were adversely impacted, than a function of the number of impacted routes?

> Also, these boxes don't have to talk to the rest of the world so
> they can easily be protected against flooding attacks.

What requirements are necessary to implement such a mechanism?  It
seems like all the routers in the AS would need to be able to
reach/route to the boxes.  One might not advertise the prefixes used
by the boxes outside the AS and/or place ingress filters on the data
traffic to block outside access to the boxes.  But couldn't one
implement an IP-in-IP attack where the outer header reaches into an AS
and the inner header goes to the box(es)?  Are requirements needed
about which routers may or may not perform decapsulation?

> I would like to see external routing policy boxes anyway, regardless
> of new BGP security mechanisms, since it allows easier and better
> management.

I've heard different answers about whether ISPs must/should/may
"register" their routing policy.  Is there now consensus on an answer?
Maybe there are different flavors of policy -- some policy that
everyone agrees must be registered and some policy that may not.
Has anyone tried to break down the different types of policy and
to categorize the information?

If the answer were "must register", and some organization(s) declined
to do so, should there be a requirement that failure to register not
impact the ability of any other organization to route their customers'
traffic, and any weaknesses/damages be limited to the customers of the
ISP that chose not to register their policy?


Are the security requirements the working group produces to be limited
to an Internet that has essentially static inter-AS peerings (as I
think is the case for today's ISPs), or should there be a requirement
to support a more dynamic topology where whole networks move their
attachment point from one ISP to another?

<SNIP>

> Remember that not everything is implemented in the way that would be
> most beneficial, for a variety of reasons.

Should there be a requirement that A's bad implementation (of either
software or "policy" or whatever) not result in increased risk for B?

Charlie
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov 11 07:01:30 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16074
	for <rpsec-archive@odin.ietf.org>; Mon, 11 Nov 2002 07:01:30 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gABC3X306320
	for rpsec-archive@odin.ietf.org; Mon, 11 Nov 2002 07:03:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABC3Xv06317
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 11 Nov 2002 07:03:33 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16051
	for <rpsec-web-archive@ietf.org>; Mon, 11 Nov 2002 07:00:59 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABC3Av06306;
	Mon, 11 Nov 2002 07:03:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABC0Av06229
	for <rpsec@optimus.ietf.org>; Mon, 11 Nov 2002 07:00:10 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16021
	for <rpsec@ietf.org>; Mon, 11 Nov 2002 06:57:35 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gABBxFf71231;
	Mon, 11 Nov 2002 12:59:16 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Mon, 11 Nov 2002 12:59:15 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Charles Lynn <clynn@bbn.com>
cc: <rpsec@ietf.org>, "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <20021110183826.D10E316484@wolfe.bbn.com>
Message-ID: <20021111120039.Q62928-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Sun, 10 Nov 2002, Charles Lynn wrote:

> > Good point. Also, this is very much a double edged sword: on the one
> > hand, the expensive crypto checks validate that what's in the routing
> > tables is good, but on the other hand they'll keep out stuff, and
> > certainly not all of what they'll keep out will be bad.

> Do folks think that the false positives would be limited to one-time
> events at the beginning of an ISP's learning curve, or an ongoing
> operational challenge?

I think it will remain fairly constant as more and more people implement
it and start climbing up that learning curve. Also, it never goes away
completely: all this secret stuff is hard to manage so it will go wrong
a few percent of the time.

> Proposed Requirement:
>     There must be a way for an ISP to evaluate their security
>     mechanisms and configurations in both a laboratory setting and in
>     the live Internet without impacting any router's Decision Process.

Agree.

> Proposed Requirement:
>     There must be an automated mechanism that allows other ISPs to
>     determine whether or not a given ISP/customer/whoever's routes
>     should be rejected if a security mechanisms detect a problem.

How about this, in addition to what you're suggesting:

	An implementation must provide a way for the user to select
	different actions for when routing information can't be
	validated, but the failure appears to be in the validation
	mechanisms and the risk level is low (for instance, the routing
	information is the same as existing routing information) and for
	when the failure either doesn't appear to be in the validation
	mechisms and/or the risk level is higher.

> > If I look at the way routing registry entries are maintained today,

> Do folks think that there is a viable way to address this issue, so
> that the information in the routing registry can be relied upon (after
> some TBD date in the future)?

Routing registries will get better, but it is very dangerous to depend
on them, as there are only a few and they do not have the built in
redundancy features such as (for instance) the DNS root servers.
Example: last week there was a power outage in Amsterdam, which took out
RIPE. Now this will get better (generators were already scheduled for
delivery it seems) but the risk won't go away completely.

The large ISPs are in a good position to sign the certificates for their
customers. They can also cross-sign. Then you only need a few
certificates for the largest ISPs in your router. This and the IRR data
could be complementary: a customer would have two chances to get it
right rather than one.

> > I expect the first few networks that implement this will suffer from
> > noticeably degraded connectivity to the rest of the world.

> I think that this is an over generalization; it probably depends on
> whatever solutions are eventually adopted :-).

Sure, a bad solution can make it worse... If you implement this and it
allows _everything_ even though we know many people don't register their
stuff properly today, then obviously the security checks aren't very
strict.  :-)

If it allows less than anything you break connectivity.

> Proposed Requirement:
>     Security solutions must allow a granularity of protection at the
>     level of an individual prefix.

> Proposed Requirement:
>     Any solution must allow for the co-existence of both protected and
>     non-protected information, and the authoritative source of the
>     information must be able to control whether or not the information
>     is to be considered authentic.

Yes. But we should explicitly list that a solution may need to be
configured with 100,000+ individual prefixes that are allowed without
protection. In other words: a 100k+ access list.

> What do folks think should happen if tampering is detected?
> Should the route be rejected?
> Only used if no other tamper-free route is available?
> Something else?

1. Raise an alarm
2. Behavior (use/don't use/only if nothing else) should be configurable

> Proposed Requirement:
>     Security solutions should provide mechanisms that allow processing
>     to be off-loaded from routers to other assets when doing so would
>     noticeably increase, e.g., the convergence time.

No. The convergence time is a cost tradeoff: throwing hardware at it
makes any solution fast, but ultimately it should be the user who
decides whether she wants to buy some 25k RSA per second cards for a
router or do this on a cluster of quad 2 GHz P3s.

>     Deployment of
>     off-loading must be implemented in a way that can maintain the
>     integrity of the results of the processing, not introduce any
>     single points of failure, and not contain vulnerabilities that
>     introduce an unacceptable level of risk.

Seems a bit general to me, but sure, this is what we want.

> This raises the question of time scales.  What requirements would be
> appropriate concerning "timeliness"?  For example, when an organization
> receives a new IP address prefix, how long should they expect to have
> to wait before the information has propagated to the furthest corners
> of the Internet?

It may take several minutes (30/40 seconds per AS) today under worst
case conditions. I'd say anything that takes more than 5 seconds per AS
by design is no good. (Sure, in practice it could be more.)

> Note that both s0BGP and S-BGP use out-of-band data registries /
> repositories to hold origin information.  As the interval T
> decreases, the data has to be propagated faster.  At some T the use of
> out-of-band information stores would cease to be viable and in-band
> mechanisms would be required (which may preclude the ability to
> off-load processing and crypto from the routers).

There are two problems:

1. A new prefix is announced, with completely new
   authentication/authorization data. This may take a few minutes, or
   even 24 hours if depending on a registry (preferably faster, though).

2. A previously know prefix is reannounced. This must be fast (not
   significantly slower than today).

> Should the working group try to set guidelines so that customer can
> have reasonable expectations of how long things will take?

It would be good if everyone could agree on reasonable guidelines, yes.
That should save everyone disagreements later on.

> Other situations include a customer who switches providers: how long
> should it take for the rest of the Internet to learn of the change?

See case 1. above.

> > This way the routers don't need to do any crypto.

> I think "any" is too strong a term, at least if one does not consider
> clear-text passwords to be adequate to protect access to a router.

Ok, "per routing update".

> Do folks think that the following should be a requirement?

> Proposed Requirement:
>     There needs to be a mechanism that uses "strong" authentication to
>     verify the authenticity of management access to a router, and that
>     can assure the integrity of management commands or data communicated
>     between a router and its authorized managers.

I think most routers already support SSH and SNMPv3, but it never hurts
to say this is a good thing, of course...

> > I don't doubt Randy's remark that there have been some, but the fact
> > that the victims don't want to talk about it makes me assume the
> > attacks could probably have stopped using today's technology.

> A different perspective is that a public acknowledgement that an ISP
> has been successfully attacked might cause sufficient concern in the
> customer base that would push an ISP struggling to survive over the
> edge.

Then Randy could have said "I know of a ... attack but I'm not telling
you on which network".

> > Martian filters aren't a good idea as they remove some symptoms but not
> > the cause. If someone doesn't filter, I like seeing those packets from
> > 192.168.0.0/16 to inform me of this fact.

> Are there requirements that the working group should make concerning
> organizations that want to intercommunicate across the public Internet
> using those addresses?

???

> > Source address filtering can be done in other places than just the
> > customer edge. It is possible to do this on peering interfaces as well,
> > if done with care. Unfortunately, it can't be done on transit
> > interfaces.

> Should we enumerate and document the factors that lead to the
> conclusion that it can't be done?  E.g., things that were infeasible a
> year ago might no longer be so next year.

Well, let me rephrase: you can do anti-spoofing filtering on a transit
connection, but it won't help you much as by definition a transit
connection will deliver packets from the entire internet, so all
possible source addresses should be accepted over a transit link. In
other words: you can have a list of all people that are allowed to enter
the bank vault, but you can't make a list of all people who are allowed
to enter the front door of the bank as it is open to the public.

> > > If one coordinates attacks designed to effect DoS on central servers
> > > for route checking with injection of bad routes, then we have a
> > > recipe for a successful attack.

> > I think if there is a successful DoS attack on central infrastructure,

> Should there be a requirement that routing must continue to "work"
> when access to "central infrastructure" is not available?

Note, this is central to an AS, not central to the whole network.

> If so, for how long - 5 minutes, and hour, half a day, a few days?

Yes, it should continue to work. How long? Simple: as long as possible.

> Should any
> effects of denied access be limited to "future changes" to peerings or
> new prefixes being allocated, i.e., anything that was able to be
> routed before the attack should continue to be routed after it?

Yes, that sounds reasonable.

> > then a few bad routes are the least of your concerns.

> Wouldn't the "damage" be more a function of which (customer's) routes
> were adversely impacted, than a function of the number of impacted routes?

I don't understand.

> > Also, these boxes don't have to talk to the rest of the world so
> > they can easily be protected against flooding attacks.

> What requirements are necessary to implement such a mechanism?  It
> seems like all the routers in the AS would need to be able to
> reach/route to the boxes.

All the routers served by that box, yes.

>  One might not advertise the prefixes used
> by the boxes outside the AS and/or place ingress filters on the data
> traffic to block outside access to the boxes.

Yes, or use RFC 1918 space.

> But couldn't one
> implement an IP-in-IP attack where the outer header reaches into an AS
> and the inner header goes to the box(es)?  Are requirements needed
> about which routers may or may not perform decapsulation?

Can we trust people to implement something reasonable here?

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov 11 10:26:36 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22171
	for <rpsec-archive@odin.ietf.org>; Mon, 11 Nov 2002 10:26:36 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gABFSfa16651
	for rpsec-archive@odin.ietf.org; Mon, 11 Nov 2002 10:28:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABFSfv16648
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 11 Nov 2002 10:28:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22116
	for <rpsec-web-archive@ietf.org>; Mon, 11 Nov 2002 10:26:05 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABFSLv16580;
	Mon, 11 Nov 2002 10:28:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABF9Pv15713
	for <rpsec@optimus.ietf.org>; Mon, 11 Nov 2002 10:09:25 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21316
	for <rpsec@ietf.org>; Mon, 11 Nov 2002 10:06:49 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04231;
	Mon, 11 Nov 2002 10:09:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100302b9f577408a9b@[128.89.88.34]>
In-Reply-To: <20021109175850.Q62928-100000@sequoia.muada.com>
References: <20021109175850.Q62928-100000@sequoia.muada.com>
Date: Mon, 11 Nov 2002 10:06:30 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00
Cc: <rpsec@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 6:04 PM +0100 11/9/02, Iljitsch van Beijnum wrote:
>On Fri, 8 Nov 2002, Stephen Kent wrote:
>
>>  >Source address filtering can be done in other places than just the
>>  >customer edge. It is possible to do this on peering interfaces as well,
>>  >if done with care. Unfortunately, it can't be done on transit
>>  >interfaces. So the tier-1 ISPs (who get all their traffic from peering)
>>  >should step up to the plate and start doing this to protect the rest of
>>  >us.
>
>>  I realize that one can filter other than at the edge, but it gets
>>  harder to do it the further one goes away from the edge, with transit
>>  interfaces being the agreed upon limiting case. Your last sentence
>>  conflicts with my observation about the undesirability of relying on
>>  others to protect you, as far as security goes.
>
>>  Its somewhat analogous to living in an apartment building; you can
>>  lock your own door to keep out unwanted visitors, or you can rely on
>>  all your fellow apartment dwellers to not loose their keys and to not
>>  buzz in bad visitors.
>
>You should be able to rely on the door man to keep people out who are
>recognizable as undesirable elements. After all, that's what you pay
>for.
>
>We all (directly or indirectly) pay the tier-1 networks so it is
>reasonable to ask them to do anti-spoofing filtering on their peering
>interfaces, for the exact reason you mention: expecting all ISPs to
>filter their customers is the short road to disappointment.

Amsterdam must be a more civilized place than most major U.S. cities :-)

Most apartment complexes here do not have doormen. The "undesirable 
elements" can and do gain entrance by "buzzing" apartments randomly 
in hopes someone will let them in, or by following in legitimate 
residents (tailgating), showing up dressed as a delivery person, etc. 
So, we have adopted a more defensive posture and assume the need to 
secure entrance to individual apartments as the responsibility of the 
residents.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov 11 10:54:19 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23048
	for <rpsec-archive@odin.ietf.org>; Mon, 11 Nov 2002 10:54:19 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gABFuOn18585
	for rpsec-archive@odin.ietf.org; Mon, 11 Nov 2002 10:56:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABFuOv18582
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 11 Nov 2002 10:56:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23034
	for <rpsec-web-archive@ietf.org>; Mon, 11 Nov 2002 10:53:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABFu9v18572;
	Mon, 11 Nov 2002 10:56:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABFtHv18486
	for <rpsec@optimus.ietf.org>; Mon, 11 Nov 2002 10:55:17 -0500
Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22972
	for <rpsec@ietf.org>; Mon, 11 Nov 2002 10:52:40 -0500 (EST)
Received: from localhost (ttauber@localhost)
	by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id gABFt6Q18024;
	Mon, 11 Nov 2002 10:55:06 -0500 (EST)
X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs
Date: Mon, 11 Nov 2002 10:55:06 -0500 (EST)
From: Tony Tauber <ttauber@genuity.net>
X-X-Sender: ttauber@mesa.bbnplanet.com
To: Charles Lynn <clynn@bbn.com>
cc: rpsec@ietf.org, "Joel M. Halpern" <joel@stevecrocker.com>,
        Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <20021110183826.D10E316484@wolfe.bbn.com>
Message-ID: <Pine.GSO.4.40.0211111037550.28401-100000@mesa.bbnplanet.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Sun, 10 Nov 2002, Charles Lynn wrote:

> Folks,
>
> I think that Iljitsch's response to Joel and his observations
> suggest possible requirements for any security solutions that the
> group may generate.  Here are some candidates, interspersed with
> recent motivating remarks.  What other requirements would folks like
> to propose?

Charlie,

Thanks for trying to start to mold this freewheeling discussion into
something more focused.  We should always be thinking, IMO, of how
the conversations on this list relate to the mission of this WG.

I think things should be kept relatively quite generic.
Perhaps we could characterize what you've proposed below as
"Operational Requirements for Inter-domain Security Mechanisms?"
I think BGP or any proposed modifications to it should not be
specifically mentioned in such requirements (or else we'd be talking
about solutions); and indeed that's what you've achieved nicely below.

Provoking people to think about timescales that are acceptable or
unacceptable is useful also.

On the last point below about crypto and authentication for management
functions, I think that part is out of scope for functions of routing
protocols.

This reshaping is quite promising and perhaps could become the seed
for a brief draft which could inform the proposed BGP enhancements or
any subsequent work in the Inter-domain arena.

Tony

> Do folks think that the false positives would be limited to one-time
> events at the beginning of an ISP's learning curve, or an ongoing
> operational challenge?
>
> Might the following proposed requirements address this issue?
>
> Proposed Requirement:
>     There must be a way for an ISP to evaluate their security
>     mechanisms and configurations in both a laboratory setting and in
>     the live Internet without impacting any router's Decision Process.
>
> Proposed Requirement:
>     There must be an automated mechanism that allows other ISPs to
>     determine whether or not a given ISP/customer/whoever's routes
>     should be rejected if a security mechanisms detect a problem.
>
> Proposed Requirement:
>     Once the mechanism (posited in the previous paragraph) has been
>     turned on by an ISP, there must be a way to turn it back off.  The
>     allowed time interval between when it is turned back off and when
>     every other ISP ceases to make routing decisions base on the
>     countermeasures information must be less than <some unit of time,
>     TBD>.
>
> Proposed Requirement:
>     Security solutions must allow a granularity of protection at the
>     level of an individual prefix.
>
> Proposed Requirement:
>     Any solution must allow for the co-existence of both protected
>     and non-protected information, and the authoritative source of
>     the information must be able to control whether or not the
>     information is to be considered authentic.
>
> Proposed Requirement:
>     The (unauthorized?) removal of protection information by a third
>     party must be detectable.
>
> What do folks think should happen if tampering is detected?
> Should the route be rejected?
> Only used if no other tamper-free route is available?
> Something else?
>
> Proposed Requirement:
>     Security solutions should provide mechanisms that allow processing
>     to be off-loaded from routers to other assets when doing so would
>     noticeably increase, e.g., the convergence time.  Deployment of
>     off-loading must be implemented in a way that can maintain the
>     integrity of the results of the processing, not introduce any
>     single points of failure, and not contain vulnerabilities that
>     introduce an unacceptable level of risk.
>
> This raises the question of time scales.  What requirements would be
> appropriate concerning "timeliness"?  For example, when an organization
> receives a new IP address prefix, how long should they expect to have
> to wait before the information has propagated to the furthest corners
> of the Internet?
>
> Should there be something like an 80/20 guideline where 80 % of the
> Internet should see the new prefix by time T but the other 20 % may
> take longer?
>
> I think "any" is too strong a term, at least if one does not consider
> clear-text passwords to be adequate to protect access to a router.
> Do folks think that the following should be a requirement?
>
> Proposed Requirement:
>     There needs to be a mechanism that uses "strong" authentication to
>     verify the authenticity of management access to a router, and that
>     can assure the integrity of management commands or data communicated
>     between a router and its authorized managers.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov 11 11:12:12 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23446
	for <rpsec-archive@odin.ietf.org>; Mon, 11 Nov 2002 11:12:12 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gABGEIG19863
	for rpsec-archive@odin.ietf.org; Mon, 11 Nov 2002 11:14:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABGEIv19860
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 11 Nov 2002 11:14:18 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23434
	for <rpsec-web-archive@ietf.org>; Mon, 11 Nov 2002 11:11:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABGE4v19850;
	Mon, 11 Nov 2002 11:14:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABG9jv19689
	for <rpsec@optimus.ietf.org>; Mon, 11 Nov 2002 11:09:45 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23377
	for <rpsec@ietf.org>; Mon, 11 Nov 2002 11:07:08 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id LAA11538; Mon, 11 Nov 2002 11:09:47 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma011515; Mon, 11 Nov 02 11:08:54 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gABG8ll15522;
	Mon, 11 Nov 2002 11:08:47 -0500 (EST)
Date: Mon, 11 Nov 2002 11:08:47 -0500 (EST)
Message-Id: <200211111608.gABG8ll15522@raven.gw.tislabs.com>
To: clynn@bbn.com, iljitsch@muada.com
Subject: Re: [RPSEC] Potential requirements
Cc: joel@stevecrocker.com, rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>> Proposed Requirement:
>>     There must be a way for an ISP to evaluate their security
>>     mechanisms and configurations in both a laboratory setting and in
>>     the live Internet without impacting any router's Decision Process.
>
>Agree.


Strongly disagree.

This is the Routing *PROTOCOL* Security Requirements working group,
not the Routing *SYSTEM* Security Requriements working group.

Writing a site security handbook especially for ISP's might be a good
idea but not the task of this group.

It's difficult to separate considerations of routing protocols (e.g., BGP)
from considerations of operating by using routing protocols (e.g., ISPs)
because so often the two are coincident.

But the issues involved differ and the protections possible differ.

If we want to take on ISPs' security, we'll need a much longer time line.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov 11 12:34:57 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25465
	for <rpsec-archive@odin.ietf.org>; Mon, 11 Nov 2002 12:34:57 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gABHb2H24607
	for rpsec-archive@odin.ietf.org; Mon, 11 Nov 2002 12:37:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABHb2v24604
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 11 Nov 2002 12:37:02 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25458
	for <rpsec-web-archive@ietf.org>; Mon, 11 Nov 2002 12:34:26 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABHaev24516;
	Mon, 11 Nov 2002 12:36:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABHZpv24463
	for <rpsec@optimus.ietf.org>; Mon, 11 Nov 2002 12:35:51 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25450
	for <rpsec@ietf.org>; Mon, 11 Nov 2002 12:33:15 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gABHYxY71680;
	Mon, 11 Nov 2002 18:34:59 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Mon, 11 Nov 2002 18:34:58 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: <sandy@tislabs.com>
cc: <clynn@bbn.com>, <joel@stevecrocker.com>, <rpsec@ietf.org>
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <200211111608.gABG8ll15522@raven.gw.tislabs.com>
Message-ID: <20021111181518.A62928-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Mon, 11 Nov 2002 sandy@tislabs.com wrote:

> >>     There must be a way for an ISP to evaluate their security
> >>     mechanisms and configurations in both a laboratory setting and in
> >>     the live Internet without impacting any router's Decision Process.

> >Agree.

> Strongly disagree.

> This is the Routing *PROTOCOL* Security Requirements working group,
> not the Routing *SYSTEM* Security Requriements working group.

> Writing a site security handbook especially for ISP's might be a good
> idea but not the task of this group.

I don't think this falls outside the scope of routing security
requirements, although it comes close and you are right that we
shouldn't require things that are out of scope for what we're doing
here.

Maybe it's a bit obvious, but IMO it is a valid requirement to be able
to test this first in a lab and then on real infrastructure, but without
impacting the way packets flow just yet. I would like to generalize the
latter into the following:

	It must be possible for the processing of new security
	mechanisms in existing protocols to be disabled and reenabled
	without disrupting any routing protocol state. In the disabled
	state, the implementation must continue to accept and possibly
	relay security information as required by the protocol
	additions, but it should otherwise act as if unaware of this
	information.

and

	It must be possible for any routing protocol security mechanisms
	to be used in a "warning-only" mode, where the security
	information is processed, but it is ignored in the route
	selection process. The instances where application of the
	security information would lead to different routing decisions
	are logged.

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov 11 12:46:11 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25688
	for <rpsec-archive@odin.ietf.org>; Mon, 11 Nov 2002 12:46:11 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gABHmGI25523
	for rpsec-archive@odin.ietf.org; Mon, 11 Nov 2002 12:48:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABHmGv25520
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 11 Nov 2002 12:48:16 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25663
	for <rpsec-web-archive@ietf.org>; Mon, 11 Nov 2002 12:44:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABHl3v25485;
	Mon, 11 Nov 2002 12:47:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABHkNv25454
	for <rpsec@optimus.ietf.org>; Mon, 11 Nov 2002 12:46:23 -0500
Received: from mail1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25657
	for <rpsec@ietf.org>; Mon, 11 Nov 2002 12:43:46 -0500 (EST)
Received: from bgreenew2k (dhcp-10-24-19-69.cisco.com [10.24.19.69]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA07799; Mon, 11 Nov 2002 09:45:55 -0800 (PST)
Reply-To: <bgreene@cisco.com>
From: "Barry Raveendran Greene" <bgreene@cisco.com>
To: <sandy@tislabs.com>, <clynn@bbn.com>, <iljitsch@muada.com>
Cc: <joel@stevecrocker.com>, <rpsec@ietf.org>
Subject: RE: [RPSEC] Potential requirements
Date: Mon, 11 Nov 2002 09:45:50 -0800
Message-ID: <LNEHJBNJAPFNLEGJHCPEAEIIKCAA.bgreene@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <200211111608.gABG8ll15522@raven.gw.tislabs.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



Routing security that does not take one the systems approach is making
fundamental errors. If you want to make improvements in BGP's security, then
you HAVE TO UNDERSTAND WHAT YOU CAN DO WITH TODAY'S TOOLS! You also have to
understand why people do and do not used these tools. Not know those factors
will mean you go down a path of designing undeployable "routing protocol
security features."

One of the problems I'm seeing in this group is the division between the
people running routing protocols in an ISP's network and the people sitting
in the labs studying routing protocols. If you want the two worlds to reach
consensus, then efforts to make sure both side understands the other. If
that means documents to clue in both sides as a foundation document, then
yes, it would be within the charter.


> >> Proposed Requirement:
> >>     There must be a way for an ISP to evaluate their security
> >>     mechanisms and configurations in both a laboratory setting and in
> >>     the live Internet without impacting any router's Decision Process.
> >
> >Agree.
>
>
> Strongly disagree.
>
> This is the Routing *PROTOCOL* Security Requirements working group,
> not the Routing *SYSTEM* Security Requirements working group.
>
> Writing a site security handbook especially for ISP's might be a good
> idea but not the task of this group.
>
> It's difficult to separate considerations of routing protocols (e.g., BGP)
> from considerations of operating by using routing protocols (e.g., ISPs)
> because so often the two are coincident.
>
> But the issues involved differ and the protections possible differ.
>
> If we want to take on ISPs' security, we'll need a much longer time line.
>
> --Sandy
> _______________________________________________
> RPSEC mailing list
> RPSEC@ietf.org
> https://www1.ietf.org/mailman/listinfo/rpsec
>

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Mon Nov 11 23:38:56 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11658
	for <rpsec-archive@odin.ietf.org>; Mon, 11 Nov 2002 23:38:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAC4f8M28528
	for rpsec-archive@odin.ietf.org; Mon, 11 Nov 2002 23:41:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAC4f7v28525
	for <rpsec-web-archive@optimus.ietf.org>; Mon, 11 Nov 2002 23:41:07 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11648
	for <rpsec-web-archive@ietf.org>; Mon, 11 Nov 2002 23:38:24 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAC4eJv28500;
	Mon, 11 Nov 2002 23:40:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAC4e0v28465
	for <rpsec@optimus.ietf.org>; Mon, 11 Nov 2002 23:40:00 -0500
Received: from netserver.braingia.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11636
	for <rpsec@ietf.org>; Mon, 11 Nov 2002 23:37:11 -0500 (EST)
Received: from netserver.braingia.org (netserver.braingia.org [192.168.1.10])
	by netserver.braingia.org (8.12.4/8.12.4/Debian-4) with ESMTP id gAC4ddT8023918
	for <rpsec@ietf.org>; Mon, 11 Nov 2002 22:39:39 -0600
Received: (from suehring@localhost)
	by netserver.braingia.org (8.12.4/8.12.4/Debian-4) id gAC4ddKO023917
	for rpsec@ietf.org; Mon, 11 Nov 2002 22:39:39 -0600
Date: Mon, 11 Nov 2002 22:39:39 -0600
From: Steve Suehring <suehring@braingia.org>
To: rpsec@ietf.org
Subject: Re: [RPSEC] Potential requirements
Message-ID: <20021112043939.GA23703@netserver.braingia.com>
References: <20021108233801.C62928-100000@sequoia.muada.com> <5.1.0.14.0.20021107220526.02713900@mail.stevecrocker.com> <p05100306b9f1866d9d36@[128.89.88.34]> <20021108235307.C62928-100000@sequoia.muada.com> <p05100319b9f1fbd432bd@[128.89.88.34]> <20021109180418.M62928-100000@sequoia.muada.com> <20021110183826.D10E316484@wolfe.bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021110183826.D10E316484@wolfe.bbn.com>
User-Agent: Mutt/1.3.27i
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


Comments inline.

On Sun, Nov 10, 2002 at 01:38:26PM -0500, Charles Lynn wrote:
> Do folks think that the false positives would be limited to one-time
> events at the beginning of an ISP's learning curve, or an ongoing
> operational challenge?

I believe that the problems would mostly be encountered at the beginning.  
Once learned, mistakes usually don't happen twice.  Usually.

> Proposed Requirement:
>     There must be a way for an ISP to evaluate their security
>     mechanisms and configurations in both a laboratory setting and in
>     the live Internet without impacting any router's Decision Process.

I can see the benefit of this but it may be difficult for ISP's to really 
do this, so maybe it should read as "There SHOULD be a way for an 
ISP..."(?)

> Proposed Requirement:
>     There must be an automated mechanism that allows other ISPs to
>     determine whether or not a given ISP/customer/whoever's routes
>     should be rejected if a security mechanisms detect a problem.

I would propose that flexibility be built into this so a policy can be 
utilized to enable the ISP to determine the action based on the source 
and/or security violation.

The new proposed requirement would be something like:

===
Proposed Requirement:
  Networks [ed. note:  maybe "AS" instead of "Networks"?] participating
  in routing exchanges must produce a routing  protocol security policy
  to determine what action, if any, will be taken when a security 
  violation occurs.  The policy may contain items such as source, 
  violation, and resulting action to take.  Further, there must be 
  an automated mechanism to enforce the routing protocol security 
  policy and can take action according to the policy.
===

Now, with that all typed out, I'm not so sure that it's feasible in the 
real world.

> Proposed Requirement:
>     Security solutions should provide mechanisms that allow processing
>     to be off-loaded from routers to other assets when doing so would
>     noticeably increase, e.g., the convergence time.  Deployment of
>     off-loading must be implemented in a way that can maintain the
>     integrity of the results of the processing, not introduce any
>     single points of failure, and not contain vulnerabilities that
>     introduce an unacceptable level of risk.

In general I tend to agree with this, I'm a believer that routers should 
route things.  However, I'm trying to come up with a practical solution to 
implement the proposed requirement.  I'm only coming up with one in my 
mind so far, but need to think about it some more before I make a 
complete fool of myself.  Anyone else?

> If the answer were "must register", and some organization(s) declined
> to do so, should there be a requirement that failure to register not
> impact the ability of any other organization to route their customers'
> traffic, and any weaknesses/damages be limited to the customers of the
> ISP that chose not to register their policy?

From a non-technical standpoint, what would be the consequences of a "must
register" scenario if an organization refuses to register their policy and
suddenly their customers are blackholed?  Litigation?  Against whom?  
From a security standpoint, would the process of registration possibly
release more information than it should to unauthorized individuals?

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 07:04:34 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28306
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 07:04:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACC6bT27347
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 07:06:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACC6bv27344
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 07:06:37 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28302
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 07:04:03 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACC6Cv27334;
	Tue, 12 Nov 2002 07:06:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACC2tv27227
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 07:02:55 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28227
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 07:00:21 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA18779;
	Tue, 12 Nov 2002 07:02:52 -0500 (EST)
Date: Tue, 12 Nov 2002 07:02:52 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: idr@merit.edu, rpsec@ietf.org
Message-ID: <Pine.GSO.4.21.0211120639530.28148-100000@ruwhite-u10.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [RPSEC] soBGP Drafts Updated....
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


It's too late for the Secretariat to handle these, so we've
posted them on a publicly accesible ftp server for perusal. Minor
changes, mostly, to deal with initial comments, are included, and
the formatting is cleaned up somewhat.

ftp://www.riw.us/draft-ng-sobgp-bgp-extensions-01.txt
ftp://www.riw.us/draft-white-sobgp-deployment-01.txt

Russ

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 08:29:25 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29957
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 08:29:25 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACDVTA32263
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 08:31:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACDVTv32260
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 08:31:29 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29953
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 08:28:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACDV9v32227;
	Tue, 12 Nov 2002 08:31:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACDUZv32184
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 08:30:35 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29923
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 08:28:00 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA20818
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 08:30:31 -0500 (EST)
Date: Tue, 12 Nov 2002 08:30:31 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: rpsec@ietf.org
Message-ID: <Pine.GSO.4.21.0211120824460.28148-100000@ruwhite-u10.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [RPSEC] Chrater Question
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Y'all:

From the most recent posts to the lists, I think we have an issue
with the charter we need to think about, and figure out. I
thought we had concensus on this at the first bof meeting, but it
appears that either the concensus has changed, or (?)....

So, the question is:

Should this working only focus on "generic" requirements docs, or
do we believe that there will, by nature, need to be one
requirements doc per routing protocol? If there will be, by
nature, one requirements doc per protocol, should this working
group consider those, or simply refer them to the protocol
working group?

Consider, when answering this, that requirements docs do not
entail suggested changes to the protocols, and could be fed, once
they are rfc'd to the appropriate working group as input towards
protocol changes, if they are handled here. Note also that it
will probably be easier to get security smart people looking at
things here than in the individual routing protocol working
groups.

Should this working group be limited to two documents, a single
threats draft, and a single requirements draft, or is there more
latitude, and more documents which would be appropriate to
address?

Thoughts?

<asbestos suit on>

:-)

Russ

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 10:26:21 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02767
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 10:26:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACFSQr06981
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 10:28:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFSQv06978
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 10:28:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02747
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 10:25:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFS6v06943;
	Tue, 12 Nov 2002 10:28:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFR8v06865
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 10:27:08 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02654
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 10:24:31 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id KAA12736; Tue, 12 Nov 2002 10:27:10 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma012712; Tue, 12 Nov 02 10:26:32 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gACFQOC20864;
	Tue, 12 Nov 2002 10:26:24 -0500 (EST)
Date: Tue, 12 Nov 2002 10:26:24 -0500 (EST)
Message-Id: <200211121526.gACFQOC20864@raven.gw.tislabs.com>
To: iljitsch@muada.com, sandy@tislabs.com
Subject: Re: [RPSEC] Potential requirements
Cc: clynn@bbn.com, joel@stevecrocker.com, rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>I don't think this falls outside the scope of routing security
>requirements, although it comes close and you are right that we
>shouldn't require things that are out of scope for what we're doing
>here.

Ah, and there's my point right there.  We are not developing
"routing security requirements", we are developing "routing protocol
security requirements".  Try thinking of routing in wireless networks
or routing in multicast networks.  What we develop is supposed to be
applicable to routing protocols in those realms as well.  We aren't
even supposed to restrict ourselves to inter-AS routing protocols
(e.g., BGP).

Charlie's requirement:

>Proposed Requirement:
>    There must be a way for an ISP to evaluate their security
>    mechanisms and configurations in both a laboratory setting and in
>    the live Internet without impacting any router's Decision Process.

and your suggested rewording:

>        It must be possible for any routing protocol security mechanisms
>        to be used in a "warning-only" mode, where the security
>        information is processed, but it is ignored in the route
>        selection process. The instances where application of the
>        security information would lead to different routing decisions
>        are logged.

This rewording is not what I had thought the original statement to
mean.  If this is the point of the requirement, then that *is* a
legitimate requirement for routing protocols - that the security
mechanism should be capable of operating in an observatory mode we might make.
And protections that are produced are sometimes reliant on protections
that are checked.  So it might be possible to make the security
mechanisms invisible locally, but much tougher to make that stick
globally.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 10:29:42 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02863
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 10:29:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACFVlb07250
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 10:31:47 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFVlv07247
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 10:31:47 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02848
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 10:29:11 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFVYv07221;
	Tue, 12 Nov 2002 10:31:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFT9v07048
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 10:29:09 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02781
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 10:26:32 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id KAA12802; Tue, 12 Nov 2002 10:29:12 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma012770; Tue, 12 Nov 02 10:28:36 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gACFSUL20996;
	Tue, 12 Nov 2002 10:28:30 -0500 (EST)
Date: Tue, 12 Nov 2002 10:28:30 -0500 (EST)
Message-Id: <200211121528.gACFSUL20996@raven.gw.tislabs.com>
To: bgreene@cisco.com
Subject: RE: [RPSEC] Potential requirements
Cc: joel@stevecrocker.com, rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>Routing security that does not take one the systems approach is making
>fundamental errors. If you want to make improvements in BGP's security, then
>you HAVE TO UNDERSTAND WHAT YOU CAN DO WITH TODAY'S TOOLS! You also have to
>understand why people do and do not used these tools. Not know those factors
>will mean you go down a path of designing undeployable "routing protocol
>security features."

Understanding today's tools is one thing.  Writing requirements about
how ISPs are supposed to use today's tools IS ANOTHER THING ENTIRELY
AND NOT THE JOB OF THIS WORKING GROUP.


>If you want the two worlds to reach
>consensus, then efforts to make sure both side understands the other. If
>that means documents to clue in both sides as a foundation document, then
>yes, it would be within the charter.

I'm all for understanding.  Foundation documents are OK.  Requirements
for how ISP's operate are not.

Defining what it means to evaluate the security mechanisms and
configurations (SSH, HTTPS, SNMPv3, Kerberos, SMIME, IPSEC, Secure
FTP, etc., and of course OSPF/RIP/BGP authentication) an ISP uses is a
huge task well beyond our capabilities.


--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 10:30:11 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02902
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 10:30:11 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACFWGZ07320
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 10:32:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFWGv07317
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 10:32:16 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02859
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 10:29:39 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFW1v07301;
	Tue, 12 Nov 2002 10:32:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFVEv07192
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 10:31:14 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02845
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 10:28:37 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id KAA12873; Tue, 12 Nov 2002 10:31:15 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma012847; Tue, 12 Nov 02 10:30:51 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gACFUi821206;
	Tue, 12 Nov 2002 10:30:44 -0500 (EST)
Date: Tue, 12 Nov 2002 10:30:44 -0500 (EST)
Message-Id: <200211121530.gACFUi821206@raven.gw.tislabs.com>
To: rpsec@ietf.org, suehring@braingia.org
Subject: Re: [RPSEC] Potential requirements
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>The new proposed requirement would be something like:
>
>===
>Proposed Requirement:
>  Networks [ed. note:  maybe "AS" instead of "Networks"?]

No, because these security requirements are supposed to cover all
routing protocols, not just BGP.  In the wireless world, it might
not even be "networks", just "nodes".

>                                                          participating
>  in routing exchanges must produce a routing  protocol security policy
>  to determine what action, if any, will be taken when a security 
>  violation occurs. The policy may contain items such as source, 
>  violation, and resulting action to take.  Further, there must be 
>  an automated mechanism to enforce the routing protocol security 
>  policy and can take action according to the policy.
 

How would a routing protocol ensure that the routing protocol security
policy determined an action to be taken?  Are you suggesting that every
routing protocol spec include a spec for the language in which the
policy would be expressed, so the routing protocol could examine it?
How would a routing protocol ensure that an automated mechanism
existed to take action according to the policy?  Are you suggesting
that the routing protocol itself perform all actions related to a
security violation?

Again - this is an operational requirement for ISPs.  A good idea, a
great idea - but not a security requirement for the routing protocol.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 10:39:40 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03267
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 10:39:40 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACFfkq08592
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 10:41:46 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFfkv08589
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 10:41:46 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03234
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 10:39:09 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFfXv08549;
	Tue, 12 Nov 2002 10:41:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFc2v08310
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 10:38:02 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03102
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 10:35:26 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16069;
	Tue, 12 Nov 2002 10:38:12 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100304b9f6d03bbeda@[128.89.88.34]>
In-Reply-To: 
 <Pine.GSO.4.21.0211120824460.28148-100000@ruwhite-u10.cisco.com>
References: 
 <Pine.GSO.4.21.0211120824460.28148-100000@ruwhite-u10.cisco.com>
Date: Tue, 12 Nov 2002 10:37:31 -0500
To: Russ White <riw@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Chrater Question
Cc: rpsec@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 8:30 AM -0500 11/12/02, Russ White wrote:
>Y'all:
>
>>From the most recent posts to the lists, I think we have an issue
>with the charter we need to think about, and figure out. I
>thought we had concensus on this at the first bof meeting, but it
>appears that either the concensus has changed, or (?)....
>
>So, the question is:
>
>Should this working only focus on "generic" requirements docs, or
>do we believe that there will, by nature, need to be one
>requirements doc per routing protocol? If there will be, by
>nature, one requirements doc per protocol, should this working
>group consider those, or simply refer them to the protocol
>working group?
>
>Consider, when answering this, that requirements docs do not
>entail suggested changes to the protocols, and could be fed, once
>they are rfc'd to the appropriate working group as input towards
>protocol changes, if they are handled here. Note also that it
>will probably be easier to get security smart people looking at
>things here than in the individual routing protocol working
>groups.
>
>Should this working group be limited to two documents, a single
>threats draft, and a single requirements draft, or is there more
>latitude, and more documents which would be appropriate to
>address?
>
>Thoughts?
>
><asbestos suit on>
>
>:-)
>
>Russ
>

I think both sorts of docs are needed. Higher level documents that 
characterize the threat model and what we mean by security for 
routing, and lower level docs that apply to specific protocols, 
translating the high level requirements into the domains of these 
protocol.  The latter set of docs might be developed by the  WGs 
responsible for the specific protocols, or could be done here, 
depending on what the IESG thinks is appropriate.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 10:39:41 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03272
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 10:39:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACFflg08607
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 10:41:47 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFflv08604
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 10:41:47 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03236
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 10:39:09 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFfWv08532;
	Tue, 12 Nov 2002 10:41:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFYIv07577
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 10:34:18 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02969
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 10:31:42 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id KAA13065; Tue, 12 Nov 2002 10:34:21 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma013035; Tue, 12 Nov 02 10:33:34 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gACFXRE21390;
	Tue, 12 Nov 2002 10:33:27 -0500 (EST)
Date: Tue, 12 Nov 2002 10:33:27 -0500 (EST)
Message-Id: <200211121533.gACFXRE21390@raven.gw.tislabs.com>
To: iljitsch@muada.com
Subject: Re: [RPSEC] Potential requirements
Cc: rpsec@ietf.org, sandy@tislabs.com
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

(Oops.  Some weird editing error there.  The following should make more
sense.)

>I don't think this falls outside the scope of routing security
>requirements, although it comes close and you are right that we
>shouldn't require things that are out of scope for what we're doing
>here.

Ah, and there's my point right there.  We are not developing
"routing security requirements", we are developing "routing protocol
security requirements".  Try thinking of routing in wireless networks
or routing in peer-peer networks.  What we develop is supposed to be
applicable to routing protocols in those realms as well.  We aren't
even supposed to restrict ourselves to inter-AS routing protocols
(e.g., BGP).

Charlie's requirement:

>Proposed Requirement:
>    There must be a way for an ISP to evaluate their security
>    mechanisms and configurations in both a laboratory setting and in
>    the live Internet without impacting any router's Decision Process.

and your suggested rewording:

>        It must be possible for any routing protocol security mechanisms
>        to be used in a "warning-only" mode, where the security
>        information is processed, but it is ignored in the route
>        selection process. The instances where application of the
>        security information would lead to different routing decisions
>        are logged.

This rewording is not what I had thought the original statement to
mean.  If this is the point of the requirement, then that *is* a
legitimate requirement for routing protocols - that the security
mechanism should be capable of operating in an observatory mode where
it checks security protections but merely reports the results without
rejecting packets or adding any security protections to packets.  That
would be the only way to ensure that the routing protocol's security
mechanisms did not alter any router's decisions.

Note, however, that your statement is focussed only on what the
receiver of protected information might do.  If a router does not
produce protections, the fact that protections are not there might
change the decision some other router down the line might make.
And protections that are produced are sometimes reliant on protections
that are checked.  So it might be possible to make the security
mechanisms invisible locally, but much tougher to make that stick
globally.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 10:39:41 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03289
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 10:39:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACFflv08622
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 10:41:47 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFflv08619
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 10:41:47 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03240
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 10:39:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFfXv08565;
	Tue, 12 Nov 2002 10:41:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFdlv08392
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 10:39:47 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03192
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 10:37:10 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA24953;
	Tue, 12 Nov 2002 10:39:32 -0500 (EST)
Date: Tue, 12 Nov 2002 10:39:32 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: rpsec@ietf.org
Subject: Re: [RPSEC] Chrater Question
In-Reply-To: <p05100304b9f6d03bbeda@[128.89.88.34]>
Message-ID: <Pine.GSO.4.21.0211121038580.28148-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> >Should this working only focus on "generic" requirements docs, or
> >do we believe that there will, by nature, need to be one
> >requirements doc per routing protocol? If there will be, by
> >nature, one requirements doc per protocol, should this working
> >group consider those, or simply refer them to the protocol
> >working group?

> I think both sorts of docs are needed. Higher level documents
> that characterize the threat model and what we mean by
> security for routing, and lower level docs that apply to
> specific protocols, translating the high level requirements
> into the domains of these protocol.  The latter set of docs
> might be developed by the WGs responsible for the specific
> protocols, or could be done here, depending on what the IESG
> thinks is appropriate.

Okay--but is there a concensus of the working group we can feed
to the AD's to chew on?

:-)

Russ


__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 10:53:17 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04161
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 10:53:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACFtNg09526
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 10:55:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFtMv09521
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 10:55:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04116
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 10:52:45 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFt1v09459;
	Tue, 12 Nov 2002 10:55:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFsIv09417
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 10:54:18 -0500
Received: from netserver.braingia.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04046
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 10:51:41 -0500 (EST)
Received: from netserver.braingia.org (netserver.braingia.org [192.168.1.10])
	by netserver.braingia.org (8.12.4/8.12.4/Debian-4) with ESMTP id gACFsBT8027799;
	Tue, 12 Nov 2002 09:54:11 -0600
Received: (from suehring@localhost)
	by netserver.braingia.org (8.12.4/8.12.4/Debian-4) id gACFsBvO027798;
	Tue, 12 Nov 2002 09:54:11 -0600
Date: Tue, 12 Nov 2002 09:54:11 -0600
From: Steve Suehring <suehring@braingia.org>
To: sandy@tislabs.com
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Potential requirements
Message-ID: <20021112155411.GA27526@netserver.braingia.com>
References: <200211121530.gACFUi821206@raven.gw.tislabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200211121530.gACFUi821206@raven.gw.tislabs.com>
User-Agent: Mutt/1.3.27i
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Tue, Nov 12, 2002 at 10:30:44AM -0500, sandy@tislabs.com wrote:
> No, because these security requirements are supposed to cover all
> routing protocols, not just BGP.  In the wireless world, it might
> not even be "networks", just "nodes".

Correct.  My mistake on the phrasing.

> Are you suggesting
> that the routing protocol itself perform all actions related to a
> security violation?

Certainly not.  Maybe I'm misunderstanding the wording contained in the
WG's charter and previous posts that routing systems are within the scope.  
I'm reading that to be a little wider scope than I probably should.  I
apologize.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 11:41:03 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04162
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 10:53:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACFtNT09539
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 10:55:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFtNv09523
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 10:55:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04114
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 10:52:45 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFt3v09475;
	Tue, 12 Nov 2002 10:55:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACFsKv09421
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 10:54:20 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04050
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 10:51:43 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA25561;
	Tue, 12 Nov 2002 10:53:40 -0500 (EST)
Date: Tue, 12 Nov 2002 10:53:40 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: sandy@tislabs.com
cc: clynn@bbn.com, iljitsch@muada.com, joel@stevecrocker.com, rpsec@ietf.org
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <200211111608.gABG8ll15522@raven.gw.tislabs.com>
Message-ID: <Pine.GSO.4.21.0211120830380.28148-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> This is the Routing *PROTOCOL* Security Requirements working
> group, not the Routing *SYSTEM* Security Requriements working
> group.

I think, perhaps, it might be good to try and define the
difference. For instance, does the routing system include:

-- The routing protocol?
-- Processes which implement that routing protocol running on
   specific devices?
-- The devices on which such processes execute?
-- The authority to originate routing information through such
   processes?
-- The validation that a given device actually is supposed
   to run such processes, and interact with other devices
   also running such processes it is connected to?
-- The interaction between two devices running such processes?

Before we say that we should or should not address a "routing
system," we need to define the term first. Is the authorization
and vlaidity of routing information a part of the protocol, or
the system? 

Can you, in fact, secure a protocol simply by securing the
communication between two devices running that protocol, and when
you move into areas of validity of membership, and authorization,
you are, by definition, moving into a "system," rather than a
"protocol?"

:-)

Russ


__________________________________
riw@cisco.com CCIE <>< Grace Alone



_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 11:46:29 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05997
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 11:46:29 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACGmai13143
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 11:48:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACGmav13140
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 11:48:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05992
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 11:45:58 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACGhHv12791;
	Tue, 12 Nov 2002 11:43:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACGcfv12580
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 11:38:41 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05646
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 11:36:04 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14965;
	Tue, 12 Nov 2002 11:38:43 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100306b9f6dbc273eb@[128.89.88.34]>
In-Reply-To: 
 <Pine.GSO.4.21.0211120830380.28148-100000@ruwhite-u10.cisco.com>
References: 
 <Pine.GSO.4.21.0211120830380.28148-100000@ruwhite-u10.cisco.com>
Date: Tue, 12 Nov 2002 11:29:07 -0500
To: Russ White <riw@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Potential requirements
Cc: rpsec@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 10:53 AM -0500 11/12/02, Russ White wrote:
>  > This is the Routing *PROTOCOL* Security Requirements working
>>  group, not the Routing *SYSTEM* Security Requriements working
>>  group.
>
>I think, perhaps, it might be good to try and define the
>difference. For instance, does the routing system include:
>
>-- The routing protocol?
>-- Processes which implement that routing protocol running on
>    specific devices?
>-- The devices on which such processes execute?
>-- The authority to originate routing information through such
>    processes?
>-- The validation that a given device actually is supposed
>    to run such processes, and interact with other devices
>    also running such processes it is connected to?
>-- The interaction between two devices running such processes?
>
>Before we say that we should or should not address a "routing
>system," we need to define the term first. Is the authorization
>and vlaidity of routing information a part of the protocol, or
>the system?
>
>Can you, in fact, secure a protocol simply by securing the
>communication between two devices running that protocol, and when
>you move into areas of validity of membership, and authorization,
>you are, by definition, moving into a "system," rather than a
>"protocol?"
>
>:-)
>
>Russ

Protocols embody semantics and the security of the protocol must 
relate to those semantics. So, for example, a BGP UPDATE message is 
an assertion that the owner of a block of addresses authorized an AS 
to advertise that block, and that each AS along the path authorized 
the next AS to advertise the block. A security model for BGP, for 
example, needs to encompass these semantics. So, even if we talk in 
terms of securing routing protocols, vs. systems, there is more to 
the task than your concluding remarks above would suggest. Again, 
absent a threat model, we cannot make any reasonable decisions about 
what is or is out of scope even relative to the nominally restrictive 
notion of securing routing protocols.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 11:50:10 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06073
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 11:50:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACGqHP13324
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 11:52:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACGqHv13321
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 11:52:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06058
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 11:49:39 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACGq3v13295;
	Tue, 12 Nov 2002 11:52:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACGpuv13261
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 11:51:56 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06047
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 11:49:18 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA27786;
	Tue, 12 Nov 2002 11:51:38 -0500 (EST)
Date: Tue, 12 Nov 2002 11:51:38 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: rpsec@ietf.org
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <p05100306b9f6dbc273eb@[128.89.88.34]>
Message-ID: <Pine.GSO.4.21.0211121146120.28148-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> Protocols embody semantics and the security of the protocol
> must relate to those semantics. So, for example, a BGP UPDATE
> message is an assertion that the owner of a block of
> addresses authorized an AS to advertise that block, and that
> each AS along the path authorized the next AS to advertise
> the block. A security model for BGP, for example, needs to
> encompass these semantics. So, even if we talk in terms of
> securing routing protocols, vs. systems, there is more to the
> task than your concluding remarks above would suggest. Again,
> absent a threat model, we cannot make any reasonable
> decisions about what is or is out of scope even relative to
> the nominally restrictive notion of securing routing
> protocols.

Well, most protocol designers and implementors would disagree on
this point--a protocol is simply a set of signals for sending
information, and knowing how to parse it intelligently. Protocols
do not, in any way, imply the correctness of what is sent. IPsec
cannot validate the contents of what is sent, only that it is
sent without medling, prying eyes seeing it, etc.

This is a very common distinction in the routing world.... Coders
implement protocols in the sense of building the processes which
follow the fsm described in a protocol spec. However, coders
don't often (necessarily) know how those protocols are used in
the real world, how they are deployed. For this, we rely on
deployers, which is an entirely different class of engineer. It's
not that one knows more than the other, etc, but their knowledge
realms are different.

I see the same divide here. Being able to make certain the
symantics of the protocol are properly followed is not the same
as making certain the information carried in the correct symatics
is also correct.

:-)

Russ


__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 12:47:28 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07934
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 12:47:28 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACHnaH17214
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 12:49:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACHnav17211
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 12:49:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07890
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 12:46:57 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACHnGv17183;
	Tue, 12 Nov 2002 12:49:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACHmZv17119
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 12:48:35 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07858
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 12:45:56 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27219;
	Tue, 12 Nov 2002 12:47:45 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p0510030bb9f6ea63e3df@[128.89.88.34]>
In-Reply-To: 
 <Pine.GSO.4.21.0211121146120.28148-100000@ruwhite-u10.cisco.com>
References: 
 <Pine.GSO.4.21.0211121146120.28148-100000@ruwhite-u10.cisco.com>
Date: Tue, 12 Nov 2002 12:45:14 -0500
To: Russ White <riw@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Potential requirements
Cc: rpsec@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 11:51 AM -0500 11/12/02, Russ White wrote:
>  > Protocols embody semantics and the security of the protocol
>>  must relate to those semantics. So, for example, a BGP UPDATE
>>  message is an assertion that the owner of a block of
>>  addresses authorized an AS to advertise that block, and that
>>  each AS along the path authorized the next AS to advertise
>>  the block. A security model for BGP, for example, needs to
>>  encompass these semantics. So, even if we talk in terms of
>>  securing routing protocols, vs. systems, there is more to the
>>  task than your concluding remarks above would suggest. Again,
>>  absent a threat model, we cannot make any reasonable
>>  decisions about what is or is out of scope even relative to
>>  the nominally restrictive notion of securing routing
>>  protocols.
>
>Well, most protocol designers and implementors would disagree on
>this point--a protocol is simply a set of signals for sending
>information, and knowing how to parse it intelligently. Protocols
>do not, in any way, imply the correctness of what is sent. IPsec
>cannot validate the contents of what is sent, only that it is
>sent without medling, prying eyes seeing it, etc.

A protocol is not just the format of what is sent on the wire, 
although that is a common misperception. It also entails the state 
machine that each peer executes to determine what to do with the 
messages. I think we agree on that. Protocols at higher layers tend 
to have richer semantics and the processing embodies these semantics. 
For example, XML tags data in a fashion that maps the data to higher 
level meaning, as opposed to simple HTML tags that deal with data 
types but cannot tell a phone number from a credit card number. BGP 
is a routing protocol and the algorithm a BGP router uses to select a 
route from among the paths it receives from peers is based on the 
semantics I described in my previous message. Thus, to secure BGP, 
one must be cognizant of these semantics, and to the extent that the 
security features do this, the offered security will be better.

One can and should provide point-to-point communication security for 
BGP traffic using the MD5 crypto checksum hack or using IPsec, and at 
layer 3 or layer 4, where the semantics are simple, these security 
measures are appropriate. But a layer 3/4 security mechanism does 
address the wide range of security problems we face for BGP, and thus 
securing that protocol means securing the application in an 
application-specific fashion. So, your comments re IPsec are correct, 
but that is OK because the semantics for IPsec match that of the 
protocol layer at which it operates, and that layer is application 
independent.

Also, as someone who has designed protocols for a rather long time, I 
guess I question your opening assertion as well :-)

>This is a very common distinction in the routing world.... Coders
>implement protocols in the sense of building the processes which
>follow the fsm described in a protocol spec. However, coders
>don't often (necessarily) know how those protocols are used in
>the real world, how they are deployed. For this, we rely on
>deployers, which is an entirely different class of engineer. It's
>not that one knows more than the other, etc, but their knowledge
>realms are different.

We disagree again. Your comments might be true for a lower layer 
protocol, but for application protocols an understand of the context 
of use is essential to good protocol design. yes, there is a point at 
which people responsible for deployment take on responsibility for 
configuration and operation of the protocol implementations, but they 
cannot change protocols, only manage them via the controls provided 
by the protocol implementers and designers.

>I see the same divide here. Being able to make certain the
>symantics of the protocol are properly followed is not the same
>as making certain the information carried in the correct symatics
>is also correct.

An implementation of a protocol cannot operate "correctly" if the 
data delivered as inputs is in error. And when errors go beyond 
simple transmission errors or FSM errors, a higher level of error 
detection and rejection, a semantic-based error control mechanism, is 
needed. In routing, our ultimate security goal is correct operation, 
since incorrect or degraded operation is obviously not desirable and 
can lead to a variety of security problems. I don't see how one can 
aspire to correct operation of a routing protocol ignorant of the 
semantics that define correct operation.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 13:12:18 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08920
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 13:12:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACIEOX19161
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 13:14:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIEOv19158
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 13:14:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08889
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 13:11:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIE3v19135;
	Tue, 12 Nov 2002 13:14:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIDbv19078
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 13:13:37 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08840
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 13:10:59 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA01229;
	Tue, 12 Nov 2002 13:13:19 -0500 (EST)
Date: Tue, 12 Nov 2002 13:13:19 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: rpsec@ietf.org
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <p0510030bb9f6ea63e3df@[128.89.88.34]>
Message-ID: <Pine.GSO.4.21.0211121308440.28314-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


So, you are stating that the authorization to advertise a
specific prefix is part of the BGP protocol itself? Or the actual
path being "correct" from a policy perspective is a part of the
BGP protocol itself?

Okay, so let's say that BGP is a policy propogation mechanism, so
you _could_ stretch it in this case. But can you stretch it in
the case of OSPF, IS-IS, PIM, etc? In other words, as the same
question: Could the authorization to advertise a certain
destination as reachable through this device be a part of the
OSPF protocol itself?

I don't see it that way; I see those things as a part of the
routing system. I do not see forwarding packets, not device
security, as part of the routing system, however. So, I think, in
the end, we agree on what we are talking about, but not on the
terms used to talk about that "thing" (although there may be
disagreement at the edges). 

Which is why I think we need to define exactly what we mean when
we say "routing system," and "routing protocol." We have become
very focused on BGP, which isn't a "real" routing protocol, and
thus blurs the lines we are talking about. When we look at
different protocols (RIP, may we never have to worry about
security for RIP, though), we get a different picture, and one
that we still need to take into account.

:-)

Russ

On Tue, 12 Nov 2002, Stephen Kent wrote:

> At 11:51 AM -0500 11/12/02, Russ White wrote:
> >  > Protocols embody semantics and the security of the protocol
> >>  must relate to those semantics. So, for example, a BGP UPDATE
> >>  message is an assertion that the owner of a block of
> >>  addresses authorized an AS to advertise that block, and that
> >>  each AS along the path authorized the next AS to advertise
> >>  the block. A security model for BGP, for example, needs to
> >>  encompass these semantics. So, even if we talk in terms of
> >>  securing routing protocols, vs. systems, there is more to the
> >>  task than your concluding remarks above would suggest. Again,
> >>  absent a threat model, we cannot make any reasonable
> >>  decisions about what is or is out of scope even relative to
> >>  the nominally restrictive notion of securing routing
> >>  protocols.
> >
> >Well, most protocol designers and implementors would disagree on
> >this point--a protocol is simply a set of signals for sending
> >information, and knowing how to parse it intelligently. Protocols
> >do not, in any way, imply the correctness of what is sent. IPsec
> >cannot validate the contents of what is sent, only that it is
> >sent without medling, prying eyes seeing it, etc.
> 
> A protocol is not just the format of what is sent on the wire, 
> although that is a common misperception. It also entails the state 
> machine that each peer executes to determine what to do with the 
> messages. I think we agree on that. Protocols at higher layers tend 
> to have richer semantics and the processing embodies these semantics. 
> For example, XML tags data in a fashion that maps the data to higher 
> level meaning, as opposed to simple HTML tags that deal with data 
> types but cannot tell a phone number from a credit card number. BGP 
> is a routing protocol and the algorithm a BGP router uses to select a 
> route from among the paths it receives from peers is based on the 
> semantics I described in my previous message. Thus, to secure BGP, 
> one must be cognizant of these semantics, and to the extent that the 
> security features do this, the offered security will be better.
> 
> One can and should provide point-to-point communication security for 
> BGP traffic using the MD5 crypto checksum hack or using IPsec, and at 
> layer 3 or layer 4, where the semantics are simple, these security 
> measures are appropriate. But a layer 3/4 security mechanism does 
> address the wide range of security problems we face for BGP, and thus 
> securing that protocol means securing the application in an 
> application-specific fashion. So, your comments re IPsec are correct, 
> but that is OK because the semantics for IPsec match that of the 
> protocol layer at which it operates, and that layer is application 
> independent.
> 
> Also, as someone who has designed protocols for a rather long time, I 
> guess I question your opening assertion as well :-)
> 
> >This is a very common distinction in the routing world.... Coders
> >implement protocols in the sense of building the processes which
> >follow the fsm described in a protocol spec. However, coders
> >don't often (necessarily) know how those protocols are used in
> >the real world, how they are deployed. For this, we rely on
> >deployers, which is an entirely different class of engineer. It's
> >not that one knows more than the other, etc, but their knowledge
> >realms are different.
> 
> We disagree again. Your comments might be true for a lower layer 
> protocol, but for application protocols an understand of the context 
> of use is essential to good protocol design. yes, there is a point at 
> which people responsible for deployment take on responsibility for 
> configuration and operation of the protocol implementations, but they 
> cannot change protocols, only manage them via the controls provided 
> by the protocol implementers and designers.
> 
> >I see the same divide here. Being able to make certain the
> >symantics of the protocol are properly followed is not the same
> >as making certain the information carried in the correct symatics
> >is also correct.
> 
> An implementation of a protocol cannot operate "correctly" if the 
> data delivered as inputs is in error. And when errors go beyond 
> simple transmission errors or FSM errors, a higher level of error 
> detection and rejection, a semantic-based error control mechanism, is 
> needed. In routing, our ultimate security goal is correct operation, 
> since incorrect or degraded operation is obviously not desirable and 
> can lead to a variety of security problems. I don't see how one can 
> aspire to correct operation of a routing protocol ignorant of the 
> semantics that define correct operation.
> 
> Steve
> 

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 13:22:13 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09304
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 13:22:13 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACIOJn19769
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 13:24:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIOJv19766
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 13:24:19 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09257
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 13:21:42 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIO5v19758;
	Tue, 12 Nov 2002 13:24:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACINNv19713
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 13:23:23 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09221
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 13:20:45 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gACIMSi73982;
	Tue, 12 Nov 2002 19:22:28 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Tue, 12 Nov 2002 19:22:28 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Stephen Kent <kent@bbn.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <p0510030bb9f6ea63e3df@[128.89.88.34]>
Message-ID: <20021112191054.W73325-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Tue, 12 Nov 2002, Stephen Kent wrote:

> BGP is a routing protocol and the algorithm a BGP router uses to select a
> route from among the paths it receives from peers is based on the
> semantics I described in my previous message.

From RFC 1771:

   For each newly received or replacement feasible route, the local BGP
   speaker shall determine a degree of preference. If the route is
   learned from a BGP speaker in the local autonomous system, either the
   value of the LOCAL_PREF attribute shall be taken as the degree of
   preference, or the local system shall compute the degree of
   preference of the route based on preconfigured policy information. If
   the route is learned from a BGP speaker in a neighboring autonomous
   system, then the degree of preference shall be computed based on
   preconfigured policy information.  The exact nature of this policy
   information and the computation involved is a local matter.

Current BGP implementations use the AS path length to select routes, but
this is something implementors came up with, and not an inherent quality
of BGP. The reason the AS path exists is to detect loops.

> Thus, to secure BGP,
> one must be cognizant of these semantics, and to the extent that the
> security features do this, the offered security will be better.

It appears we have to look at implementations too. There wouldn't be
much reason to protect the AS path if it were only used for loop
detection.

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 13:34:18 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09701
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 13:34:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACIaOL20270
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 13:36:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIaOv20267
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 13:36:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09683
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 13:33:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIa6v20250;
	Tue, 12 Nov 2002 13:36:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIZav20220
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 13:35:36 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09669
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 13:32:58 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gACIZ4F74013
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 19:35:04 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Tue, 12 Nov 2002 19:35:04 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: <rpsec@ietf.org>
Message-ID: <20021112192308.L73325-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [RPSEC] Interoperation between solutions
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

We may end up in a situation where part of the internet uses S-BGP and
another part uses soBGP. We need something to make the two work
together. Proposed requirement:

	An interdomain routing protocol security solution must have
	provisions to allow the use of proxy validation servers between
	areas of the network where the solution is used, and other areas
	of the network where other solutions are in use. It must be
	possible to determine the real origin of the routing
	information that has passed the proxy server, but validation of
	this information must be based on the proxy server's credentials
	and a possible implicit or explicit indication of the security
	level of the original information, as determined and validated
	by the proxy server. Information passing a proxy server shall
	not be given a higher security level than that warranted by the
	proxy server's credentials, even if the proxy server indicates
	the original information has a higher security level. The
	security level of individual proxy servers must be configurable.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 13:56:23 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10350
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 13:56:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACIwUE21563
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 13:58:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIwUv21558
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 13:58:30 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10332
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 13:55:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIwFv21546;
	Tue, 12 Nov 2002 13:58:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIviv21516
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 13:57:44 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10317
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 13:55:02 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00885;
	Tue, 12 Nov 2002 13:57:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p0510030fb9f6fa439ec5@[128.89.88.34]>
In-Reply-To: 
 <Pine.GSO.4.21.0211121308440.28314-100000@ruwhite-u10.cisco.com>
References: 
 <Pine.GSO.4.21.0211121308440.28314-100000@ruwhite-u10.cisco.com>
Date: Tue, 12 Nov 2002 13:49:11 -0500
To: Russ White <riw@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Potential requirements
Cc: rpsec@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 1:13 PM -0500 11/12/02, Russ White wrote:
>So, you are stating that the authorization to advertise a
>specific prefix is part of the BGP protocol itself? Or the actual
>path being "correct" from a policy perspective is a part of the
>BGP protocol itself?

I am stating that BGP correct operation is based on an implicit 
assumption that the origin AS is authorized to advertise the address 
block by the owner, etc. Do you disagree?

>Okay, so let's say that BGP is a policy propogation mechanism, so
>you _could_ stretch it in this case. But can you stretch it in
>the case of OSPF, IS-IS, PIM, etc? In other words, as the same
>question: Could the authorization to advertise a certain
>destination as reachable through this device be a part of the
>OSPF protocol itself?

I was using BGP as a specific example, one that I have studied for 
some time. I defer to Sandy or someone else who has studied OSPF to 
suggest analogous constraints for that protocol.

>I don't see it that way; I see those things as a part of the
>routing system. I do not see forwarding packets, not device
>security, as part of the routing system, however. So, I think, in
>the end, we agree on what we are talking about, but not on the
>terms used to talk about that "thing" (although there may be
>disagreement at the edges).

Routing exists to tell routers where to forward packets, with the 
intent that the packets be delivered to the intended destination, 
subject to various other constraints we impose on routes. Because of 
the major role played by local policies in BGP, there are significant 
limits on the extent to which we can ensure that all of the inputs 
that we use in a local route computation are valid. But to the extent 
that we can validate those inputs, we eliminate means by which 
attackers can adversely influence the computation and disrupt 
routing. Attacks also can disrupt routing by causing routers to 
devote resources to processing bad packets, etc., and so not all the 
safeguards we need will be defined just through the protocols.  A 
system security approach is needed. But, within the definition of a 
routing protocol, we should detect and reject bad data to avoid 
making bad routing decisions on the basis of detectably bad inputs.

>Which is why I think we need to define exactly what we mean when
>we say "routing system," and "routing protocol." We have become
>very focused on BGP, which isn't a "real" routing protocol, and
>thus blurs the lines we are talking about. When we look at
>different protocols (RIP, may we never have to worry about
>security for RIP, though), we get a different picture, and one
>that we still need to take into account.

I don't mean to suggest that one size fits all routing protocols. The 
semantics differ and must be characterized individually for each 
protocol, to be ale to make usefully detailed statements about the 
security requirements for each protocol.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 13:56:24 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10351
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 13:56:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACIwUr21576
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 13:58:30 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIwUv21560
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 13:58:30 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10333
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 13:55:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIwAv21530;
	Tue, 12 Nov 2002 13:58:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIvbv21512
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 13:57:37 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10314
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 13:54:59 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00890;
	Tue, 12 Nov 2002 13:57:39 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100310b9f6fdfb7e8b@[128.89.88.34]>
In-Reply-To: <20021112191054.W73325-100000@sequoia.muada.com>
References: <20021112191054.W73325-100000@sequoia.muada.com>
Date: Tue, 12 Nov 2002 13:52:14 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Potential requirements
Cc: <rpsec@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 7:22 PM +0100 11/12/02, Iljitsch van Beijnum wrote:
>On Tue, 12 Nov 2002, Stephen Kent wrote:
>
>>  BGP is a routing protocol and the algorithm a BGP router uses to select a
>>  route from among the paths it receives from peers is based on the
>>  semantics I described in my previous message.
>
>>From RFC 1771:
>
>    For each newly received or replacement feasible route, the local BGP
>    speaker shall determine a degree of preference. If the route is
>    learned from a BGP speaker in the local autonomous system, either the
>    value of the LOCAL_PREF attribute shall be taken as the degree of
>    preference, or the local system shall compute the degree of
>    preference of the route based on preconfigured policy information. If
>    the route is learned from a BGP speaker in a neighboring autonomous
>    system, then the degree of preference shall be computed based on
>    preconfigured policy information.  The exact nature of this policy
>    information and the computation involved is a local matter.
>
>Current BGP implementations use the AS path length to select routes, but
>this is something implementors came up with, and not an inherent quality
>of BGP. The reason the AS path exists is to detect loops.

I think it is a stretch to say that AS path length is usually used as 
a primary factor to select routes. Many routing algorithms have, 
historically, used path length or hop count as primary factor.

Steve

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 13:57:07 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10391
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 13:57:07 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACIxEB21628
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 13:59:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIxDv21625
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 13:59:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10377
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 13:56:36 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIx0v21607;
	Tue, 12 Nov 2002 13:59:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACIwJv21554
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 13:58:19 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10328
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 13:55:41 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gACIvjk74070;
	Tue, 12 Nov 2002 19:57:45 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Tue, 12 Nov 2002 19:57:45 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: <sandy@tislabs.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <200211121533.gACFXRE21390@raven.gw.tislabs.com>
Message-ID: <20021112195435.G73325-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Tue, 12 Nov 2002 sandy@tislabs.com wrote:

> and your suggested rewording:

> >        It must be possible for any routing protocol security mechanisms
> >        to be used in a "warning-only" mode, where the security
> >        information is processed, but it is ignored in the route
> >        selection process. The instances where application of the
> >        security information would lead to different routing decisions
> >        are logged.

> This rewording is not what I had thought the original statement to
> mean.

That's why I used the word "generalize" rather than "reword".

> If this is the point of the requirement, then that *is* a
> legitimate requirement for routing protocols - that the security
> mechanism should be capable of operating in an observatory mode where
> it checks security protections but merely reports the results without
> rejecting packets or adding any security protections to packets.  That
> would be the only way to ensure that the routing protocol's security
> mechanisms did not alter any router's decisions.

Yes.

> Note, however, that your statement is focussed only on what the
> receiver of protected information might do.  If a router does not
> produce protections, the fact that protections are not there might
> change the decision some other router down the line might make.
> And protections that are produced are sometimes reliant on protections
> that are checked.  So it might be possible to make the security
> mechanisms invisible locally, but much tougher to make that stick
> globally.

There will be problems if you're going to flip this switch in a router
that is in the middle of a secure cloud, yes. However, it should be
possible to do some good testing this way at the edge of the secure part
of the network.

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 14:05:10 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10559
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 14:05:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACJ7HJ22414
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 14:07:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJ7Hv22411
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 14:07:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10548
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 14:04:39 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJ72v21956;
	Tue, 12 Nov 2002 14:07:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJ69v21868
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 14:06:09 -0500
Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10518
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 14:03:31 -0500 (EST)
Received: from localhost (ttauber@localhost)
	by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id gACJ4od19445;
	Tue, 12 Nov 2002 14:04:50 -0500 (EST)
X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs
Date: Tue, 12 Nov 2002 14:04:50 -0500 (EST)
From: Tony Tauber <ttauber@genuity.net>
X-X-Sender: ttauber@mesa.bbnplanet.com
To: Russ White <riw@cisco.com>
cc: Stephen Kent <kent@bbn.com>, <rpsec@ietf.org>
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <Pine.GSO.4.21.0211121308440.28314-100000@ruwhite-u10.cisco.com>
Message-ID: <Pine.GSO.4.40.0211121322440.19351-100000@mesa.bbnplanet.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

> I think we need to define exactly what we mean when
> we say "routing system," and "routing protocol."

To put a pragmatic spin back on things, I think we have to focus on
where the threats come whichever it is.

The threats are things like subverting or interrupting the flow of
traffic so consider the vulnerabilities which give rise to these.

$0.25

Tony


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 14:06:09 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10584
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 14:06:09 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACJ8Gw22563
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 14:08:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJ8Gv22560
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 14:08:16 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10577
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 14:05:38 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJ81v22543;
	Tue, 12 Nov 2002 14:08:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJ72v21966
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 14:07:02 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10542
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 14:04:24 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id OAA21584; Tue, 12 Nov 2002 14:07:03 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma021571; Tue, 12 Nov 02 14:06:07 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gACJ60X07339;
	Tue, 12 Nov 2002 14:06:00 -0500 (EST)
Date: Tue, 12 Nov 2002 14:06:00 -0500 (EST)
Message-Id: <200211121906.gACJ60X07339@raven.gw.tislabs.com>
To: rpsec@ietf.org
Cc: sandy@tislabs.com
Subject: [RPSEC] a link to my threat draft
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

I've been asked to put the draft I wrote up somewhere accessible.
Putting it on our ftp site was easier (bureaucratically) than putting
it on the web site, so you can reach it at:
ftp://ftp.tislabs.com/pub/rpsec/draft-murphy-threat-00.txt

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 14:16:51 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10782
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 14:16:51 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACJIwX22986
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 14:18:58 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJIwv22983
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 14:18:58 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10772
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 14:16:20 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJIiv22959;
	Tue, 12 Nov 2002 14:18:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJHJv22882
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 14:17:19 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10734
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 14:14:42 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13281;
	Tue, 12 Nov 2002 14:17:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100312b9f700ab2026@[128.89.88.34]>
In-Reply-To: <20021112192308.L73325-100000@sequoia.muada.com>
References: <20021112192308.L73325-100000@sequoia.muada.com>
Date: Tue, 12 Nov 2002 14:09:24 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Interoperation between solutions
Cc: <rpsec@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 7:35 PM +0100 11/12/02, Iljitsch van Beijnum wrote:
>We may end up in a situation where part of the internet uses S-BGP and
>another part uses soBGP. We need something to make the two work
>together. Proposed requirement:
>
>	An interdomain routing protocol security solution must have
>	provisions to allow the use of proxy validation servers between
>	areas of the network where the solution is used, and other areas
>	of the network where other solutions are in use. It must be
>	possible to determine the real origin of the routing
>	information that has passed the proxy server, but validation of
>	this information must be based on the proxy server's credentials
>	and a possible implicit or explicit indication of the security
>	level of the original information, as determined and validated
>	by the proxy server. Information passing a proxy server shall
>	not be given a higher security level than that warranted by the
>	proxy server's credentials, even if the proxy server indicates
>	the original information has a higher security level. The
>	security level of individual proxy servers must be configurable.
>

I think this suggestion is getting way ahead of what this WG is supposed to do.
It has the flavor of "I know what the answer is and I want to make 
sure we craft requirements that accommodate my idea of the right 
answer."

This WG is supposed to develop security requirements for routing 
protocols.  We have had a lot of discussion of S-BGP as an example, 
but it's adoption and deployment is far from certain and ought not be 
the focus of most of our discussions. soBGP is very, very new. I know 
of no published papers analyzing it from any perspective: security, 
performance, etc., unlike S-BGP.  So unless you believe that the 
corporate affiliation of its authors automatically ensures its 
adoption (hardly an IETF way of doing business), it is even less 
certain to be adopted or deployed.

This sort of requirements gerrymandering is very inappropriate.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 14:23:09 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11040
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 14:23:08 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACJPGX23271
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 14:25:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJPFv23268
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 14:25:15 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10992
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 14:22:37 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJP2v23217;
	Tue, 12 Nov 2002 14:25:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJJnv23011
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 14:19:49 -0500
Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10823
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 14:17:11 -0500 (EST)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gACJJhIX012346;
	Tue, 12 Nov 2002 11:19:43 -0800 (PST)
Received: from nisser.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id gACJJWOZ019147;
	Tue, 12 Nov 2002 11:19:32 -0800 (PST)
Received: from 172.16.30.208 (sjc-vpn1-595.cisco.com [10.21.98.83]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA20169; Tue, 12 Nov 2002 11:19:39 -0800 (PST)
Date: Tue, 12 Nov 2002 11:19:27 -0800
From: Sean Convery <sean@cisco.com>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
cc: rpsec@ietf.org
X-Priority: 3
In-Reply-To: <200211051702.gA5H2qWV016669@marajade.sandelman.ottawa.on.ca>
Message-ID: <r01050400-1021-B562A354F67311D69B890003939CDD90@[172.16.30.208]>
MIME-Version: 1.0
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Mailsmith 1.5.4 (Blindsider)
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On 11/5/02 at 12:02 PM, mcr@sandelman.ottawa.on.ca wrote:
>
>  BTW, I found the AND/OR stuff difficult to follow. 
>  It seems you can write:
>  (A || B || C) && D
>
>  as:
>       OR  A
>           B
>           C
>       AND D
>
>  What's weird is that the OR is to the left of the first item
(prefix), while the
>AND is between C and D (infix).
>  Perhaps I am misreading, and in fact the above describes:
>     A || B || (C && D)

What it should mean is (A or B or C) AND D

as in:

Attack:
OR  1. Send message to router causing reset
    OR  1. Send RST message to TCP stack
        2. Send BGP Message
        OR  1. Notify
            2. Open
            3. Keepalive
    AND 3. TCP Sequence number Attack (Appendix A.4)
    2. Alter configuration via. compromised router (Appendix A.1)
    
You can send message causing a reset by 1. sending the message to the
TCP stack, or 2. sending a BGP message.  But in both cases you need 3.
the TCP sequence number attack.

There shouldn't be any cases where an AND or OR is between two numbers.
it should alway be on the same line as a goal on the tree.

We tried to explain the notation in the Intro section.  If you can
provide some specific comments on how to make this better (short of
rewriting the CERT paper :)) we'd love to hear them.

Thanks,

Sean
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 14:23:10 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11055
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 14:23:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACJPH123286
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 14:25:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJPHv23283
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 14:25:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10997
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 14:22:39 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJP3v23233;
	Tue, 12 Nov 2002 14:25:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJJtv23019
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 14:19:55 -0500
Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10826
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 14:17:16 -0500 (EST)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gACJJhep011819;
	Tue, 12 Nov 2002 11:19:43 -0800 (PST)
Received: from nisser.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id gACJJcW7019221;
	Tue, 12 Nov 2002 11:19:38 -0800 (PST)
Received: from 172.16.30.208 (sjc-vpn1-595.cisco.com [10.21.98.83]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA20250; Tue, 12 Nov 2002 11:19:45 -0800 (PST)
Date: Tue, 12 Nov 2002 11:03:21 -0800
From: Sean Convery <sean@cisco.com>
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00
To: Iljitsch van Beijnum <iljitsch@muada.com>
cc: rpsec@ietf.org
X-Priority: 3
In-Reply-To: <20021105090907.T50741-100000@sequoia.muada.com>
Message-ID: <r01050400-1021-B9016420F67311D69B890003939CDD90@[172.16.30.208]>
MIME-Version: 1.0
Content-Type: text/plain; Charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Mailsmith 1.5.4 (Blindsider)
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


On 11/5/02 at 9:38 AM, iljitsch@muada.com wrote:

SNIP
>> - Enterprise BGP Implementation - as a side rant, much of the
>> conversation I've seen on idr and rpsec seems to assume an ISP
>> deployment.  BGP is used plenty in enterprise environments as well.
>> Here MITM, sniffing, etc. become much more possible.
>
>But enterprises aren't typically in the position to propagate much
>malicious routing information as their ISPs filter them.
>
Right, but they are more than capable of being hacked on the inside
(regardless of filtering), which is one of the things we should be
concerned about.

SNIP
>> The easiest way we've come up with to do the analysis would be to
>> assign attributes to various parts of the tree based on different
>> topologies and attackers.  For more info check out the end of
>> section 1 of the draft.
>
>What I'd like to see is a simple web-based tool that has the tree and
>allows you to add security measures such as anti-spoofing filters, MD5,
>static MAC addresses on exchanges and so on, and then see how many of
>the attacks go away. This could be a learning experience. Heck, I might
>make something like this.
>
We agree and would love your help. :) Dave Cook is doing some modelling
to create the tree graphically from the source XML file.  We could
probably extend it to do something like this...

>> Regarding MD5, that got its own section 2.1.1.  Any attack against a
>> system employing MD5 would need to first run through that section of
>> the tree assuming the overall attack requires the generation of
>> valid TCP 179 messages.
>
>I don't think this is made explicit in every place.
>
Right, see my previous below response, we're assuming no best practices
in place: 

>> For the entire tree, we assumed no best practices were employed,
>> this would give us a base set of attacks that could then be weeded
>> down based on lots of factors.
>
>You don't mention a list of best practices... It might be good to
>include a list. Actually I've been working on this for a while.
>
I would think best practices for BGP would need to be in a separate
draft.  There are lots of BPs spread all over the web, has anyone
grouped them all together for the IETF?

SNIP
>
>>> 2.1.7 man "in the middle" is not necessary as it is trivial to pose
>>> as the peer router if there is access to all the traffic.
>
>> I'm not sure I understand your comment.  In this attack we're not
>> assuming access to all the traffic.  Here the attacker is trying to
>> send a spoofed BGP message.
>
>For a successful man in the middle attack you must be able to:
>
>AND - sniff original traffic
>    - inject replacement traffic
>    - block original traffic
>
>However, man in the middle is more difficult to do than simply
>completely assume the identity of the neighbor and yields no extra
>results.
>
>> This tree shows he can do it one of two ways:
>
>> 1. TCP Sequence # attack + the spoofed BGP message
>
>This will obviously break the existing BGP session pretty quickly and
>then all routing information (spoofed or otherwise) from this peer is
>removed.
>
Again, we'd love to test this out. I agree, things could go badly for
the BGP session.
>
>> >If people don't filter properly you can also do very funny things by
>> >routing the BGP next hop addresses into oblivion.
>
>> Can you elaborate on that further?  I think I understand what you
>> are referring to, I'm just not sure where to put it in the tree.  Is
>> this a spoofed message or an intercepted and modified message from a
>> valid peer?
>
>I suppose it could be either. What you do is inject a route that makes
>the next hop address for other BGP routes point to an unexpected
>place. For instance, you can announce the /24 for an IX as two /25s
>with the next hop address set to your router and then you'll receive
>all traffic for all peers connected to the IX. (However, the sessions
>would probably go down in this case.) However, this can be stopped
>with proper inbound route filters.
>
Now I got it.  We do have some info on more specific route introduction,
but it is specific to IGP, We can probably broaden this definition in
2.1.3.

Thanks again,

Sean
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 14:31:16 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11394
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 14:31:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACJXNZ23745
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 14:33:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJXNv23742
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 14:33:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11344
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 14:30:45 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJX7v23713;
	Tue, 12 Nov 2002 14:33:07 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJWCv23601
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 14:32:12 -0500
Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11268
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 14:29:34 -0500 (EST)
Received: from localhost (ttauber@localhost)
	by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id gACJVmE19496;
	Tue, 12 Nov 2002 14:31:48 -0500 (EST)
X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs
Date: Tue, 12 Nov 2002 14:31:48 -0500 (EST)
From: Tony Tauber <ttauber@genuity.net>
X-X-Sender: ttauber@mesa.bbnplanet.com
To: Stephen Kent <kent@bbn.com>
cc: Iljitsch van Beijnum <iljitsch@muada.com>, <rpsec@ietf.org>
Subject: Re: [RPSEC] Interoperation between solutions
In-Reply-To: <p05100312b9f700ab2026@[128.89.88.34]>
Message-ID: <Pine.GSO.4.40.0211121421330.19351-100000@mesa.bbnplanet.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Tue, 12 Nov 2002, Stephen Kent wrote:

> I think this suggestion is getting way ahead of what this WG is
> supposed to do.

Complete agreement.

The S-BGP and so-BGP things may be timely and/or coincident with some
current themes in the community and world around us.  They also might
provide decent food for thought or discussion but are not the primary
mission of this WG whatsoever.

Let's focus on the threats drafts.

Tony


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 14:48:19 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11742
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 14:48:19 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACJoRL24952
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 14:50:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJoRv24949
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 14:50:27 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11730
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 14:47:48 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJo9v24927;
	Tue, 12 Nov 2002 14:50:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJnJv24868
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 14:49:19 -0500
Received: from nic-naa.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11712
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 14:46:40 -0500 (EST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1])
	by nic-naa.net (8.12.6/8.12.6) with ESMTP id gACJn48f000618;
	Tue, 12 Nov 2002 14:49:04 -0500 (EST)
	(envelope-from brunner@nic-naa.net)
Message-Id: <200211121949.gACJn48f000618@nic-naa.net>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: Tony Tauber <ttauber@genuity.net>
cc: Stephen Kent <kent@bbn.com>, Iljitsch van Beijnum <iljitsch@muada.com>,
        rpsec@ietf.org, brunner@nic-naa.net
Subject: Re: [RPSEC] Interoperation between solutions 
In-Reply-To: Message from Tony Tauber <ttauber@genuity.net> 
   of "Tue, 12 Nov 2002 14:31:48 EST." <Pine.GSO.4.40.0211121421330.19351-100000@mesa.bbnplanet.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 12 Nov 2002 14:49:04 -0500
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


... there are the distinctions between network element signaling (common
control) and forwarding and control seperation... 

i'm just a hobbist now, but the several times i worked on things that ran
routing algorithms, the distinctions seemed helpful.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 14:55:13 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12467
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 14:55:13 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACJvK325480
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 14:57:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJvKv25477
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 14:57:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12462
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 14:54:42 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJv6v25466;
	Tue, 12 Nov 2002 14:57:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJuPv25435
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 14:56:25 -0500
Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12455
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 14:53:46 -0500 (EST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gACJrKI00830;
	Tue, 12 Nov 2002 14:53:20 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKCRYKH>; Tue, 12 Nov 2002 14:53:20 -0500
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6044B4ED8@zcard0ke.ca.nortel.com>
From: "Dennis Beard" <beardd@nortelnetworks.com>
To: Russ White <riw@cisco.com>, rpsec@ietf.org
Date: Tue, 12 Nov 2002 14:53:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28A85.2308ADD0"
Subject: [RPSEC] Potential Requirements New Thread
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=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_01C28A85.2308ADD0
Content-Type: text/plain

Let's remain with a charter that deals with security of routing protocols
and not the routing system per se.  Having said that, can we list
specifically what is considered "protocol" and not discuss "system"?  Such a
list would reinforce our charter statement.  These specifics can be shown to
the WG with a proviso that our charter would be modified to clarify what we
mean by routing protocol.

Start the list here as the previous thread is getting too long.
1.
2.
3.
etc.

Regards,

Dennis Beard




------_=_NextPart_001_01C28A85.2308ADD0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>Potential Requirements New Thread</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Let's remain with a charter that deals =
with security of routing protocols and not the routing system per =
se.&nbsp; Having said that, can we list specifically what is considered =
&quot;protocol&quot; and not discuss &quot;system&quot;?&nbsp; Such a =
list would reinforce our charter statement.&nbsp; These specifics can =
be shown to the WG with a proviso that our charter would be modified to =
clarify what we mean by routing protocol.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Start the list here as the previous =
thread is getting too long.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">1.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">2.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">3.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">etc.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dennis Beard</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C28A85.2308ADD0--
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 15:02:27 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12838
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 15:02:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACK4Ze25871
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 15:04:35 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACK4Zv25868
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 15:04:35 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12816
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 15:01:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACK4Av25855;
	Tue, 12 Nov 2002 15:04:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACK3Vv25826
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 15:03:31 -0500
Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12762
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 15:00:52 -0500 (EST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gACK2gI07235;
	Tue, 12 Nov 2002 15:02:42 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKCRYTB>; Tue, 12 Nov 2002 15:02:42 -0500
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6044B4F0B@zcard0ke.ca.nortel.com>
From: "Dennis Beard" <beardd@nortelnetworks.com>
To: Stephen Kent <kent@bbn.com>, Iljitsch van Beijnum <iljitsch@muada.com>
Cc: rpsec@ietf.org
Subject: RE: [RPSEC] Interoperation between solutions
Date: Tue, 12 Nov 2002 15:02:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28A86.72F642AC"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=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_01C28A86.72F642AC
Content-Type: text/plain

How do we define requirements if the threat work is not done?  Why the
discussion on requirements at this point?  Perhaps I am missing the point or
did we get ahead of ourselves.

Regards,

Dennis Beard

-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com] 
Sent: Tuesday, November 12, 2002 2:09 PM
To: Iljitsch van Beijnum
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Interoperation between solutions


At 7:35 PM +0100 11/12/02, Iljitsch van Beijnum wrote:
>We may end up in a situation where part of the internet uses S-BGP and 
>another part uses soBGP. We need something to make the two work 
>together. Proposed requirement:
>
>	An interdomain routing protocol security solution must have
>	provisions to allow the use of proxy validation servers between
>	areas of the network where the solution is used, and other areas
>	of the network where other solutions are in use. It must be
>	possible to determine the real origin of the routing
>	information that has passed the proxy server, but validation of
>	this information must be based on the proxy server's credentials
>	and a possible implicit or explicit indication of the security
>	level of the original information, as determined and validated
>	by the proxy server. Information passing a proxy server shall
>	not be given a higher security level than that warranted by the
>	proxy server's credentials, even if the proxy server indicates
>	the original information has a higher security level. The
>	security level of individual proxy servers must be configurable.
>

I think this suggestion is getting way ahead of what this WG is supposed to
do. It has the flavor of "I know what the answer is and I want to make 
sure we craft requirements that accommodate my idea of the right 
answer."

This WG is supposed to develop security requirements for routing 
protocols.  We have had a lot of discussion of S-BGP as an example, 
but it's adoption and deployment is far from certain and ought not be 
the focus of most of our discussions. soBGP is very, very new. I know 
of no published papers analyzing it from any perspective: security, 
performance, etc., unlike S-BGP.  So unless you believe that the 
corporate affiliation of its authors automatically ensures its 
adoption (hardly an IETF way of doing business), it is even less 
certain to be adopted or deployed.

This sort of requirements gerrymandering is very inappropriate.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec

------_=_NextPart_001_01C28A86.72F642AC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [RPSEC] Interoperation between solutions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>How do we define requirements if the threat work is =
not done?&nbsp; Why the discussion on requirements at this point?&nbsp; =
Perhaps I am missing the point or did we get ahead of =
ourselves.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Dennis Beard</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Stephen Kent [<A =
HREF=3D"mailto:kent@bbn.com">mailto:kent@bbn.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, November 12, 2002 2:09 PM</FONT>
<BR><FONT SIZE=3D2>To: Iljitsch van Beijnum</FONT>
<BR><FONT SIZE=3D2>Cc: rpsec@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [RPSEC] Interoperation between =
solutions</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>At 7:35 PM +0100 11/12/02, Iljitsch van Beijnum =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;We may end up in a situation where part of the =
internet uses S-BGP and </FONT>
<BR><FONT SIZE=3D2>&gt;another part uses soBGP. We need something to =
make the two work </FONT>
<BR><FONT SIZE=3D2>&gt;together. Proposed requirement:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; An =
interdomain routing protocol security solution must have</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provisions =
to allow the use of proxy validation servers between</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; areas of =
the network where the solution is used, and other areas</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the =
network where other solutions are in use. It must be</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; possible to =
determine the real origin of the routing</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information =
that has passed the proxy server, but validation of</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this =
information must be based on the proxy server's credentials</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and a =
possible implicit or explicit indication of the security</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; level of =
the original information, as determined and validated</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; by the =
proxy server. Information passing a proxy server shall</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; not be =
given a higher security level than that warranted by the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; proxy =
server's credentials, even if the proxy server indicates</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
original information has a higher security level. The</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; security =
level of individual proxy servers must be configurable.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT SIZE=3D2>I think this suggestion is getting way ahead of what =
this WG is supposed to do. It has the flavor of &quot;I know what the =
answer is and I want to make </FONT></P>

<P><FONT SIZE=3D2>sure we craft requirements that accommodate my idea =
of the right </FONT>
<BR><FONT SIZE=3D2>answer.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>This WG is supposed to develop security requirements =
for routing </FONT>
<BR><FONT SIZE=3D2>protocols.&nbsp; We have had a lot of discussion of =
S-BGP as an example, </FONT>
<BR><FONT SIZE=3D2>but it's adoption and deployment is far from certain =
and ought not be </FONT>
<BR><FONT SIZE=3D2>the focus of most of our discussions. soBGP is very, =
very new. I know </FONT>
<BR><FONT SIZE=3D2>of no published papers analyzing it from any =
perspective: security, </FONT>
<BR><FONT SIZE=3D2>performance, etc., unlike S-BGP.&nbsp; So unless you =
believe that the </FONT>
<BR><FONT SIZE=3D2>corporate affiliation of its authors automatically =
ensures its </FONT>
<BR><FONT SIZE=3D2>adoption (hardly an IETF way of doing business), it =
is even less </FONT>
<BR><FONT SIZE=3D2>certain to be adopted or deployed.</FONT>
</P>

<P><FONT SIZE=3D2>This sort of requirements gerrymandering is very =
inappropriate.</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
<BR><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>RPSEC mailing list</FONT>
<BR><FONT SIZE=3D2>RPSEC@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/rpsec" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/rpsec</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C28A86.72F642AC--
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 15:50:10 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14878
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 15:50:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACKqIj29371
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 15:52:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACKqIv29368
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 15:52:18 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14866
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 15:49:39 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACKq5v29353;
	Tue, 12 Nov 2002 15:52:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACKp7v29324
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 15:51:07 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14793
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 15:48:28 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gACKoLu74315;
	Tue, 12 Nov 2002 21:50:21 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Tue, 12 Nov 2002 21:50:21 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Stephen Kent <kent@bbn.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Interoperation between solutions
In-Reply-To: <p05100312b9f700ab2026@[128.89.88.34]>
Message-ID: <20021112212128.X73325-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Tue, 12 Nov 2002, Stephen Kent wrote:

> >We may end up in a situation where part of the internet uses S-BGP and
> >another part uses soBGP. We need something to make the two work
> >together. Proposed requirement:

> I think this suggestion is getting way ahead of what this WG is supposed to do.

Well, it's in the archive now to be scooped up whenever the time for it
to be relevant comes.

> This WG is supposed to develop security requirements for routing
> protocols.  We have had a lot of discussion of S-BGP as an example,
> but it's adoption and deployment is far from certain and ought not be
> the focus of most of our discussions. soBGP is very, very new.

So when Z-BGP and xyBGP are deployed we need something to make those
work together. And with the currently deployed BGP security measures.
The requirement is a valid one. I'll try not to make the mistake of
citing work in progress to show the relevance of a requirement again.

> I know of no published papers analyzing it from any perspective: security,
> performance, etc., unlike S-BGP.

The fact that S-BGP behavior is better documented doesn't mean the
behavior is better.  :-)

> So unless you believe that the
> corporate affiliation of its authors automatically ensures its
> adoption (hardly an IETF way of doing business), it is even less
> certain to be adopted or deployed.

I believe soBGP has several very interesting properties which may help
it catch up with S-BGP in a relatively short time. On the other hand,
S-BGP couples the light touch of an elephant to the strength of one, so
I'm not about to underestimate it.

But the real solution is to abandon BGP as its architecture just isn't
suitable for all of this. Each route is treated as an individual entity.
This is an example of a poorly normalized database. Having a good
"database design" for a routing protocol makes securing it much easier
while at the same time minimizing convergence times. But here I go
talking about solutions again...

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 16:43:36 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17298
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 16:43:36 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACLjjB00847
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 16:45:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACLjjv00844
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 16:45:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17294
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 16:43:05 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACLjLv00834;
	Tue, 12 Nov 2002 16:45:21 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACLiwv00798
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 16:44:58 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17271
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 16:42:19 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id QAA29819; Tue, 12 Nov 2002 16:44:58 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma029793; Tue, 12 Nov 02 16:44:12 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gACLi5X21712;
	Tue, 12 Nov 2002 16:44:05 -0500 (EST)
Date: Tue, 12 Nov 2002 16:44:05 -0500 (EST)
Message-Id: <200211122144.gACLi5X21712@raven.gw.tislabs.com>
To: kent@bbn.com, riw@cisco.com
Subject: Re: [RPSEC] Potential requirements
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Russ said:

>Should this working only focus on "generic" requirements docs, or
>do we believe that there will, by nature, need to be one
>requirements doc per routing protocol? If there will be, by
>nature, one requirements doc per protocol, should this working
>group consider those, or simply refer them to the protocol
>working group?
>
>Consider, when answering this, that requirements docs do not
>entail suggested changes to the protocols, and could be fed, once
>they are rfc'd to the appropriate working group as input towards
>protocol changes, if they are handled here. Note also that it
>will probably be easier to get security smart people looking at
>things here than in the individual routing protocol working
>groups.
>
>Should this working group be limited to two documents, a single
>threats draft, and a single requirements draft, or is there more
>latitude, and more documents which would be appropriate to
>address?

For my two cents worth, I would say that there should be one threats
and one requirements document, with different instantiations of the
requirements document or both for individual protocols.  But there
could not possibly be an instantiation done in this working group for
each and every routing protocol - we would never finish.  OTOH, we
need some worked examples to test out the opinion that the threats and
requirements are generic - so we'll need to choose a representative
set.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 16:46:05 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17441
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 16:46:05 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACLmE000981
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 16:48:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACLmEv00978
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 16:48:14 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17419
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 16:45:34 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACLm1v00949;
	Tue, 12 Nov 2002 16:48:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACLl1v00885
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 16:47:01 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17353
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 16:44:21 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id QAA29906; Tue, 12 Nov 2002 16:47:00 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma029871; Tue, 12 Nov 02 16:46:23 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gACLkHM21804;
	Tue, 12 Nov 2002 16:46:17 -0500 (EST)
Date: Tue, 12 Nov 2002 16:46:17 -0500 (EST)
Message-Id: <200211122146.gACLkHM21804@raven.gw.tislabs.com>
To: kent@bbn.com, riw@cisco.com
Subject: Re: [RPSEC] Potential requirements
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


Russ said:

>Before we say that we should or should not address a "routing
>system," we need to define the term first. Is the authorization
>and vlaidity of routing information a part of the protocol, or
>the system? 
>
>Can you, in fact, secure a protocol simply by securing the
>communication between two devices running that protocol, and when
>you move into areas of validity of membership, and authorization,
>you are, by definition, moving into a "system," rather than a
>"protocol?"

and then

>Well, most protocol designers and implementors would disagree on
>this point--a protocol is simply a set of signals for sending
>information, and knowing how to parse it intelligently. Protocols
>do not, in any way, imply the correctness of what is sent. IPsec
>cannot validate the contents of what is sent, only that it is
>sent without medling, prying eyes seeing it, etc.

I would disagree with your characterization of protocols.  I believe
that a protocol spec always includes the actions that a receiver takes
upon receiving protocol messages as well as when and what a sender
sends.  "Actions taken when certain syntax is seen" is the usual way
of specifying semantics.  So protocol specs always include semantics.

The problems with many protocols is that the actions taken indicate
assumptions about the message contents that are not guaranteed to be
true.

So IP (and TCP) takes certain actions on receiving an IP packet from an
IP address that assume that the sender of the IP packet is the source
IP address.  That assumption was false and led to the development of
IPSEC to make the assumption true.

So DNS takes certain actions on receiving a query response that
assume that the information in the response originated from an
authoritative zone.  That assumption was false and led to the
development of DNSSEC to make the assumption true.

So BGP takes certain actions on receiving an UPDATE that assume that
the originator of an address is authorized to originate that address
and that the UPDATE has passed through the AS's in the AS_PATH.
That assumption was false and led to the development of S-BGP (and
SoBGP and filters and etc.) to make the assumption true.

So OSPF takes certain actions on receiving LSA's that assume that the
Advertising Router in the LSA is the ID of the (original) sender of
the LSA.  That assumption was false and led to Radia Perlman's work
and RFC 2154.

Information that is communicated in the protocol message and must satisfy
certain security properties for the protocol to behave properly should
be considered part of the protocol.

Information that is not communicated in the protocol might be part of the
protocol configuration (like routing policy, for example) but can't
be secured by anything the protocol does aren't protocol security
requirements.  (Maybe "infrastructure" could be used to talk about
these things that the protocol relies on being there.)

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 16:49:08 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17553
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 16:49:08 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACLpHn01173
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 16:51:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACLpHv01170
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 16:51:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17541
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 16:48:37 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACLp3v01154;
	Tue, 12 Nov 2002 16:51:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACLo4v01097
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 16:50:04 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17486
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 16:47:24 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id QAA00053; Tue, 12 Nov 2002 16:50:04 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma000004; Tue, 12 Nov 02 16:49:05 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gACLmw022054;
	Tue, 12 Nov 2002 16:48:58 -0500 (EST)
Date: Tue, 12 Nov 2002 16:48:58 -0500 (EST)
Message-Id: <200211122148.gACLmw022054@raven.gw.tislabs.com>
To: kent@bbn.com, riw@cisco.com
Subject: Re: [RPSEC] Potential requirements
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Russ said:

>Okay, so let's say that BGP is a policy propogation mechanism, so
>you _could_ stretch it in this case. But can you stretch it in
>the case of OSPF, IS-IS, PIM, etc? In other words, as the same
>question: Could the authorization to advertise a certain
>destination as reachable through this device be a part of the
>OSPF protocol itself?

OSPF and IS-IS are link state, so they are different animals.  But in
these protocols, a router floods information about its links to
everywhere.  Nothing in either protocol prevents a router from sending
out information about another router's links (by getting the source
field in the link info wrong, for example).  (Routers everywhere
construct SPF trees from this incorrect data and the fun begins.)  So
in that sense, in OSPF and IS-IS, there is an assumption about the
authorization to speak for a link.  Radia Perlman's work talks about
how to protect this authorization assumption in link state protocols
and RFC2154 talks about how to do it for OSPF in particular.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 17:02:11 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17931
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 17:02:11 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gACM4Km02090
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 17:04:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACM4Kv02087
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 17:04:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17920
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 17:01:40 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACM46v02077;
	Tue, 12 Nov 2002 17:04:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACM3pv02044
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 17:03:51 -0500
Received: from server2000.arneill-py.sacramento.ca.us (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17908
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 17:01:10 -0500 (EST)
Subject: RE: [RPSEC] Chrater Question
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Date: Tue, 12 Nov 2002 14:04:17 -0800
Message-ID: <2B81403386729140A3A899A8B39B046405E452@server2000>
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: [RPSEC] Chrater Question
Thread-Index: AcKKjHIzvAMC1HqISaq1k5hK1KfPhwABsUOQ
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Russ White" <riw@cisco.com>, <rpsec@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gACM3pv02045
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Russ,


[Where did you get the asbestos suit? I need one too]

> Russ White wrote:
> Should this working only focus on "generic" requirements
> docs, or do we believe that there will, by nature, need
> to be one requirements doc per routing protocol?

It depends on what you call "generic".
- If it's truly generic, I don't see how one size could fit all.
- If you are talking about a single document that has a chapter for each
known protocol and an author list that takes half a page, I don't see
the point of creating such a monster and one doc per protocol would be
preferable, IMHO.


> If there will be, by nature, one requirements doc per
> protocol, should this working group consider those, or
> simply refer them to the protocol working group?

Consider them here, IMHO. Do feedback often to the protocol working
group though, because impossible to meet requirements or requirements
that do not reach consensus in the protocol working group are of no use.


> Note also that it will probably be easier to get security
> smart people looking at things here than in the individual
> routing protocol working groups.

Agreed.


> Should this working group be limited to two documents,
> a single threats draft, and a single requirements draft,
> or is there more latitude, and more documents which would
> be appropriate to address?

My view as a protocol developer:

- I see a need for a single threats doc and a single requirements doc,
but IMHO these should be truly generic and short, which means that there
also is a need for protocol-specific docs.

Which leads me to what I would like this WG to do:
1. Assess what is wrong with my protocol's security.
2. Evaluate what I could or should do to enhance it.
3. Produce a recommendations doc that includes both generic security
issues and the ones that are specific to my protocol.

Note that this should be, IMHO, a continuing process for new protocols
that still are work in progress, as there is flexibility in releasing
interim drafts.

Michel.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 20:22:05 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21924
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 20:22:05 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAD1OFE12768
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 20:24:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD1OFv12765
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 20:24:15 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21919
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 20:21:34 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD1Nnv12739;
	Tue, 12 Nov 2002 20:23:49 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD1MLv12707
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 20:22:21 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21903
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 20:19:40 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA18913;
	Tue, 12 Nov 2002 20:22:07 -0500 (EST)
Date: Tue, 12 Nov 2002 20:22:06 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: rpsec@ietf.org
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <p0510030fb9f6fa439ec5@[128.89.88.34]>
Message-ID: <Pine.GSO.4.21.0211121922460.28336-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> >So, you are stating that the authorization to advertise a
> >specific prefix is part of the BGP protocol itself? Or the actual
> >path being "correct" from a policy perspective is a part of the
> >BGP protocol itself?
> 
> I am stating that BGP correct operation is based on an
> implicit assumption that the origin AS is authorized to
> advertise the address block by the owner, etc. Do you
> disagree?

Yes. :-)

If my daughter walks into a store with my credit card and
attempts to buy something, does her physical access to my credit
card mean that she is authorized to use it? No. Does a router's
apparent physical access to a given destination mean it is
authorized to advertise that destination? No.

Today, there are two parts to the way a routing protocol process
on a specific device determines it may advertise a particular
destination as reachable through this device:

-- The destination is configured to be directly connected, or
through a manually configured route statement claiming the route
is reachable "this way."

-- The routing protocol is configured to advertise said
destination.

Thus, today, we assume that the operator provides the
authorization for the routing protocol to advertise a particular
destination from a particular device. If you cannot, or do not,
make the assumption that manual configuration constitutes
authorization (which is why we have threats drafts, etc.), then
you must build some authorization into the system.

Advertisement of reachability is not tatamount to authorization
to advertise that reachability.

> I don't mean to suggest that one size fits all routing
> protocols. The semantics differ and must be characterized
> individually for each protocol, to be ale to make usefully
> detailed statements about the security requirements for each
> protocol.

Right.... Again, I think we are talking about the same thing,
just using different words. I think that the authorization to
advertise a destination is not part of the routing protocol, but
part of the routing system. I do not include access to the
physical device to be in the routing system; the configuration
which authorizes that device to advertise a given destination is
a part of the routing system, but not part of the routing
protocol.

I think you're saying that the manual configuration which
(today) constitutes the authorization to advertise a given
reachable destination is part of the routing protocol.

Is that correct?

:-)

Russ


__________________________________
riw@cisco.com CCIE <>< Grace Alone



_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 20:25:29 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21953
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 20:25:29 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAD1RdW12892
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 20:27:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD1Rcv12889
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 20:27:39 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21949
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 20:24:58 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD1R5v12856;
	Tue, 12 Nov 2002 20:27:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD1Qxv12842
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 20:26:59 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21939
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 20:24:18 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA19034;
	Tue, 12 Nov 2002 20:26:43 -0500 (EST)
Date: Tue, 12 Nov 2002 20:26:43 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: sandy@tislabs.com
cc: kent@bbn.com, rpsec@ietf.org
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <200211122148.gACLmw022054@raven.gw.tislabs.com>
Message-ID: <Pine.GSO.4.21.0211122024370.28369-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> >Okay, so let's say that BGP is a policy propogation mechanism, so
> >you _could_ stretch it in this case. But can you stretch it in
> >the case of OSPF, IS-IS, PIM, etc? In other words, as the same
> >question: Could the authorization to advertise a certain
> >destination as reachable through this device be a part of the
> >OSPF protocol itself?
> 
> Radia Perlman's work talks about how to protect this
> authorization assumption in link state protocols and RFC2154
> talks about how to do it for OSPF in particular.

Actually, according to RFC2154:

The basic idea of this proposal is to add digital signatures to
OSPF LSA data, distribute certified router information and keys,
and use a neighbor-to-neighbor authentication algorithm (like
keyed MD5) to protect local protocol exchanges.

Just because a device signs something as actually originating
from the device itself, it doesn't prove the device is authorized
to transmit that reachability information. In other words, my
daughter can sign to use my credit card. I now know who used my
credit card, but nothing in that signature indicates she is
actually authorized to use it.

:-)

Russ



__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 20:30:06 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22048
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 20:30:06 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAD1WGf13115
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 20:32:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD1WGv13111
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 20:32:16 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22033
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 20:29:35 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD1W2v13097;
	Tue, 12 Nov 2002 20:32:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD1VAv13066
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 20:31:10 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22009
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 20:28:29 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA19200;
	Tue, 12 Nov 2002 20:30:58 -0500 (EST)
Date: Tue, 12 Nov 2002 20:30:58 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Dennis Beard <beardd@nortelnetworks.com>
cc: rpsec@ietf.org
In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6044B4ED8@zcard0ke.ca.nortel.com>
Message-ID: <Pine.GSO.4.21.0211122026490.28369-100000@ruwhite-u10.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [RPSEC] Re: Potential Requirements New Thread
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> Let's remain with a charter that deals with security of
> routing protocols and not the routing system per se.  Having
> said that, can we list specifically what is considered
> "protocol" and not discuss "system"?  Such a list would
> reinforce our charter statement.  These specifics can be
> shown to the WG with a proviso that our charter would be
> modified to clarify what we mean by routing protocol.

> Start the list here as the previous thread is getting too long.

So, I'll use entity here, since I don't think that a "router" is
a good term for this purpose--an entity could actually be a san
network within the network, a redistribution router representing
and entire network, an AS, or a single router.... Etc.

-- The ability to verify that the entity advertising a particular
destination as reachable is actually authorized to advertise that
destination.

-- The ability to verify that the entity claiming to be
advertising a particular piece of information is actually the
entity which is advertising it.

-- The ability to verify the path the update has taken.

Note there is a major problem with this last one--in that the
path an update takes is no necessarily the path the traffic will
take. In the end, after looking at this particular issue for a
while, I'm not so certain that verifying the path of a routing
update, particularly in a vector based protocol, is all that
useful....

I hope this little list will get people thinking about
more.... Some other ideas were mentioned on the list that seem
important to me as well.

:-)

Russ

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 12 21:18:23 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23619
	for <rpsec-archive@odin.ietf.org>; Tue, 12 Nov 2002 21:18:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAD2KYp17143
	for rpsec-archive@odin.ietf.org; Tue, 12 Nov 2002 21:20:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD2KXv17140
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 12 Nov 2002 21:20:33 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23598
	for <rpsec-web-archive@ietf.org>; Tue, 12 Nov 2002 21:17:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD2K3v17120;
	Tue, 12 Nov 2002 21:20:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAD2Jqv17078
	for <rpsec@optimus.ietf.org>; Tue, 12 Nov 2002 21:19:52 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23594
	for <rpsec@ietf.org>; Tue, 12 Nov 2002 21:17:11 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA21220;
	Tue, 12 Nov 2002 21:19:37 -0500 (EST)
Date: Tue, 12 Nov 2002 21:19:37 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Stephen Kent <kent@bbn.com>
cc: rpsec@ietf.org
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <p05100306b9f6dbc273eb@[128.89.88.34]>
Message-ID: <Pine.GSO.4.21.0211122116480.28369-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> Protocols embody semantics and the security of the protocol
> must relate to those semantics. So, for example, a BGP UPDATE
> message is an assertion that the owner of a block of
> addresses authorized an AS to advertise that block,

And my point is that checking this assertion should be both a
part of any threat model(s), and a part of any requirements
document(s) that we put forth. Otherwise, you've not secured the
routing information, no matter whether you classify it as a
system or a protocol.

:-)

Russ

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 07:52:41 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29222
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 07:52:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADCsjI26759
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 07:54:45 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADCsjv26756
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 07:54:45 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29158
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 07:52:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADCsFv26727;
	Wed, 13 Nov 2002 07:54:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADCrjv26700
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 07:53:45 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29124
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 07:51:10 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA06543;
	Wed, 13 Nov 2002 07:53:39 -0500 (EST)
Date: Wed, 13 Nov 2002 07:53:39 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Michel Py <michel@arneill-py.sacramento.ca.us>
cc: rpsec@ietf.org
Subject: RE: [RPSEC] Chrater Question
In-Reply-To: <2B81403386729140A3A899A8B39B046405E452@server2000>
Message-ID: <Pine.GSO.4.21.0211130750190.28539-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> Which leads me to what I would like this WG to do:
> 1. Assess what is wrong with my protocol's security.
> 2. Evaluate what I could or should do to enhance it.
> 3. Produce a recommendations doc that includes both generic security
> issues and the ones that are specific to my protocol.
> 
> Note that this should be, IMHO, a continuing process for new
> protocols that still are work in progress, as there is
> flexibility in releasing interim drafts.

Thanks, Michael, for the feedback. I think we probably need to
have some further discussion on this: so far, we have:

-- We should have one generic threats and one generic
requirements draft.
-- We should also have protocol specific recommendations (or
requirements?) drafts, as we can get them done.
-- We shouldn't have protocol specific requirements drafts, but
only one generic requirements draft.

Any other thoughts/issues/etc.? It's be nice to be able to wrap
this discussion up in Atlanta, with the AD's present, so we can
understand where we are going....

:-)

Russ

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 07:53:12 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29249
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 07:53:12 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADCtHf26806
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 07:55:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADCtHv26803
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 07:55:17 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29236
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 07:52:41 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADCt2v26789;
	Wed, 13 Nov 2002 07:55:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADCs7v26720
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 07:54:07 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29130
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 07:51:32 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id HAA23790; Wed, 13 Nov 2002 07:54:11 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma023750; Wed, 13 Nov 02 07:53:31 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gADCrO208529;
	Wed, 13 Nov 2002 07:53:24 -0500 (EST)
Date: Wed, 13 Nov 2002 07:53:24 -0500 (EST)
Message-Id: <200211131253.gADCrO208529@raven.gw.tislabs.com>
To: riw@cisco.com, sandy@tislabs.com
Subject: Re: [RPSEC] Potential requirements
Cc: kent@bbn.com, rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>Just because a device signs something as actually originating
>from the device itself, it doesn't prove the device is authorized
>to transmit that reachability information.

Actually, I'm pretty familiar with the RFC 2154 :-)

You missed the part about the router's public key being signed by
some trusted entity in a public key lsa that includes info on
what roles the router is allowed to use (ABR, ASBR, etc.) and what
network addresses it is allowed to advertise.  The PKLSA also authorizes
the router to produce LSA's with that router ID, obviously.

So exactly the authorization info you are requesting is already
in the RFC and was one of the major points of the RFC.

I'm glad you agree with the need for authorization of routing
information.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 07:55:09 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29295
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 07:55:09 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADCvDL26899
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 07:57:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADCvDv26896
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 07:57:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29283
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 07:54:38 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADCv0v26886;
	Wed, 13 Nov 2002 07:57:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADCuEv26840
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 07:56:14 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29268
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 07:53:39 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA06826;
	Wed, 13 Nov 2002 07:56:05 -0500 (EST)
Date: Wed, 13 Nov 2002 07:56:05 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: sandy@tislabs.com
cc: kent@bbn.com, rpsec@ietf.org
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <200211131253.gADCrO208529@raven.gw.tislabs.com>
Message-ID: <Pine.GSO.4.21.0211130754450.28539-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> >Just because a device signs something as actually originating
> >from the device itself, it doesn't prove the device is authorized
> >to transmit that reachability information.
> 
> Actually, I'm pretty familiar with the RFC 2154 :-)

I know. :-)

> I'm glad you agree with the need for authorization of routing
> information.

Definitely, I'm just trying to make certain that we draw that
out, and that it's addressed in varioud docs we work on here,
since it (kindof) looked like we were loosing the distinction
between authorization and authentication.

:-)

Russ


__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 08:07:18 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29473
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 08:07:18 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADD9NE28048
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 08:09:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADD9Mv28045
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 08:09:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29468
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 08:06:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADD95v28012;
	Wed, 13 Nov 2002 08:09:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADD8Ov27972
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 08:08:24 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29457
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 08:05:49 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id IAA24526; Wed, 13 Nov 2002 08:08:28 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma024464; Wed, 13 Nov 02 08:07:41 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gADD7Yu09903;
	Wed, 13 Nov 2002 08:07:34 -0500 (EST)
Date: Wed, 13 Nov 2002 08:07:34 -0500 (EST)
Message-Id: <200211131307.gADD7Yu09903@raven.gw.tislabs.com>
To: beardd@nortelnetworks.com, riw@cisco.com
Subject: Re: [RPSEC] Re: Potential Requirements New Thread
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>-- The ability to verify the path the update has taken.

This is important in BGP, since it's part of the protocol info used
in making decisions.  But do you think it is important in all routing
protocols?

In OSPF, for example, the flooding technique could conceivably make
the same LSA reach you through lots of different paths and the path
matters very little (not at all, except perhaps for timing issues?)
in how the protocol or even subsequent forwarding behaves.

In wireless protocols, sometimes the path matters quite a bit in
the protocol (e.g., DSR records the path) and in others it doesn't.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 08:23:19 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29988
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 08:23:19 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADDPOf28660
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 08:25:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDPNv28657
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 08:25:23 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29976
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 08:22:48 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDP6v28639;
	Wed, 13 Nov 2002 08:25:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDOAv28586
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 08:24:10 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29936
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 08:21:34 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gADDNX275795;
	Wed, 13 Nov 2002 14:23:33 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Wed, 13 Nov 2002 14:23:33 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Russ White <riw@cisco.com>
cc: Michel Py <michel@arneill-py.sacramento.ca.us>, <rpsec@ietf.org>
Subject: RE: [RPSEC] Chrater Question
In-Reply-To: <Pine.GSO.4.21.0211130750190.28539-100000@ruwhite-u10.cisco.com>
Message-ID: <20021113140806.I73325-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, 13 Nov 2002, Russ White wrote:

> -- We should have one generic threats and one generic
> requirements draft.
> -- We should also have protocol specific recommendations (or
> requirements?) drafts, as we can get them done.
> -- We shouldn't have protocol specific requirements drafts, but
> only one generic requirements draft.

> Any other thoughts/issues/etc.? It's be nice to be able to wrap
> this discussion up in Atlanta, with the AD's present, so we can
> understand where we are going....

I think it would be useful to separate IGP and EGP issues. Once again
I'll risk getting ahead of things by naming instances of real-world
routing protocols, but bear with me as I think it will make things
clearer.

IGPs such as OSPF or IS-IS (do we even want to look at RIP???) simply
detect routers and start exchanging routing information. Obviously some
level of protection can and should be used here, but at what point is
the advantage of having a dynamic routing protocol in the first place
lost as more and more information must be explicitly stated in order to
validate the potential flow of packets?

BGP on the other hand requires neighbor relationships to be set up
explicitly, so adding some means to better secure this doesn't really go
against the grain of the protocol, and since the whole point of an IGP
is to exchange routing information with other autonomous systems,
checking the received routing information to see if it's valid makes
much more sense than in an IGP.

Then there is the fact that there are "competing" IGPs, you get to
control the IGP yourself, and if you really, really hate them, you can
run without one. Running without BGP or using a different EGP is not an
option for most people at this time, so the level of consensus about
what's good for BGP and what isn't should be much higher than that for
an IGP.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 08:24:11 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00014
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 08:24:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADDQFB28735
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 08:26:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDQFv28732
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 08:26:15 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00006
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 08:23:40 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDQ1v28719;
	Wed, 13 Nov 2002 08:26:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDPcv28693
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 08:25:38 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29984
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 08:23:03 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id IAA25200; Wed, 13 Nov 2002 08:25:42 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma025144; Wed, 13 Nov 02 08:25:25 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gADDPHY11426;
	Wed, 13 Nov 2002 08:25:17 -0500 (EST)
Date: Wed, 13 Nov 2002 08:25:17 -0500 (EST)
Message-Id: <200211131325.gADDPHY11426@raven.gw.tislabs.com>
To: kent@bbn.com, riw@cisco.com
Subject: Re: [RPSEC] Potential requirements
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>> I am stating that BGP correct operation is based on an
>> implicit assumption that the origin AS is authorized to
>> advertise the address block by the owner, etc. Do you
>> disagree?
>
>Yes. :-)
>If my daughter walks into a store with my credit card and
>attempts to buy something, does her physical access to my credit
>card mean that she is authorized to use it? No. Does a router's
>apparent physical access to a given destination mean it is
>authorized to advertise that destination? No.

Russ, I think you've missed the point.  Steve's not saying that the
appearance of a network originiation in the message is authorization,
he's saying that the appearance is treated as though it were.  The BGP
protocol behaves as if the appearance of an origination in a message
means that AS is authorized to originate that network.  So the analogy
would be if the merchant behaves as if the physical access to the card
meant your daughter was authorized to use it.  And then you'd be in
trouble.  But the merchant does not make that assumption - the
merchant wants a signature on the credit card slip that matches the
signature on the card.  And S-BGP provides the proof of authorization
that is missing but assumed in the current protocol.

>I think you're saying that the manual configuration which
>(today) constitutes the authorization to advertise a given
>reachable destination is part of the routing protocol.

It is precisely because the receiving router can't possible know
from the message it receives that the sender was manually configured
to send that info or that the manual configuration was authorized
that we find ourselves in these straits.  The crypto protections
provide the proof of the authorization that can be carried in the
protocol.  The manual configuration is not part of the protocol,
the crypto enhancements could be.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 08:37:17 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00409
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 08:37:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADDdMo29884
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 08:39:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDdMv29881
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 08:39:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00390
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 08:36:46 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDd8v29864;
	Wed, 13 Nov 2002 08:39:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDctv29844
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 08:38:55 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00382
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 08:36:19 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA08906;
	Wed, 13 Nov 2002 08:38:47 -0500 (EST)
Date: Wed, 13 Nov 2002 08:38:47 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: sandy@tislabs.com
cc: beardd@nortelnetworks.com, rpsec@ietf.org
Subject: Re: [RPSEC] Re: Potential Requirements New Thread
In-Reply-To: <200211131307.gADD7Yu09903@raven.gw.tislabs.com>
Message-ID: <Pine.GSO.4.21.0211130833520.28539-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> >-- The ability to verify the path the update has taken.
> 
> This is important in BGP, since it's part of the protocol
> info used in making decisions.  But do you think it is
> important in all routing protocols?
> 
> In OSPF, for example, the flooding technique could
> conceivably make the same LSA reach you through lots of
> different paths and the path matters very little (not at all,
> except perhaps for timing issues?) in how the protocol or
> even subsequent forwarding behaves.
> 
> In wireless protocols, sometimes the path matters quite a bit
> in the protocol (e.g., DSR records the path) and in others it
> doesn't.

Agreed.... I'm actually wondering how much of a difference
knowing the path in BGP makes. The path of the update doesn't
necessarily dictate the path of the packet following a given
route, so it doesn't secure the path. And the path is used in the
decision process only as a way to prevent loops (being a first
level tie breaker is only incidental, really).

The only part of the path that really seems to matter is:

-- Knowing the origin 
-- Knowing that the origin actually originated this prefix

The only time the entire path seems really useful is if you are
certain the packets will be taking that same path, and since IP
is a hop by hop protocol, I don't know that you can tie the two
together.

:-)

Russ

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 08:50:23 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00860
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 08:50:23 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADDqST30633
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 08:52:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDqSv30630
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 08:52:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00836
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 08:49:52 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDqCv30621;
	Wed, 13 Nov 2002 08:52:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDpqv30596
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 08:51:52 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00807
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 08:49:16 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gADDpMY75836;
	Wed, 13 Nov 2002 14:51:22 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Wed, 13 Nov 2002 14:51:21 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: <sandy@tislabs.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] a link to my threat draft
In-Reply-To: <200211121906.gACJ60X07339@raven.gw.tislabs.com>
Message-ID: <20021113142609.Y73325-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Tue, 12 Nov 2002 sandy@tislabs.com wrote:

> I've been asked to put the draft I wrote up somewhere accessible.
> Putting it on our ftp site was easier (bureaucratically) than putting
> it on the web site, so you can reach it at:
> ftp://ftp.tislabs.com/pub/rpsec/draft-murphy-threat-00.txt

	The RPSEC working group is addressing security requirements of routing
	protocols, not the security requirements of routers or of operations of
	routing systems.  Therefore, this draft specifically does not address
	threats to routers (hacking, denial of service flooding attacks, etc.)
	or to specific routing protocol implementations (bugs, etc.).

From the charter:

	The RPSEC working group is charged with the following tasks:

	- Document threat models for routing systems
	- Document security requirements for routing systems
	- Provide a common area for discussion between security and routing
	  experts on the topic of securing the routing system

Building an ultrasecure protocol and running it on flimsy boxes doesn't
help. Building extremely secure routers and then run vulnerable
protocols on them doesn't either. There must be an integrated approach.

One very important question is: what amount of damage do we think is
acceptable when an attack is launched from the inside, either by someone
with legitimate access to a router, or when a router is compromised? Ie
do we want our cops to walk around in their bullet proof vests at the
police station in case another cop starts shooting, or are they supposed
to be safe inside? Both approaches have their advantages, but this
question exists on a more fundamental level than just routing _protocol_
security.

About the rest of the draft: it is a good enumeration of all possible
bad things that can happen, but each exists in a vacuum. Which threats
are so easy to eliminate that we shouldn't waste time focussing on them?
Which are so hard to eliminate we shouldn't even bother trying? What
kind of damage can we expect?

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 09:00:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01304
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 09:00:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADE2Rv31146
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 09:02:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADE2Rv31143
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 09:02:27 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01276
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 08:59:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADE25v31106;
	Wed, 13 Nov 2002 09:02:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADE1Fv31053
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 09:01:15 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01237
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 08:58:39 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gADE0bd75855;
	Wed, 13 Nov 2002 15:00:37 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Wed, 13 Nov 2002 15:00:36 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Russ White <riw@cisco.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Re: Potential Requirements New Thread
In-Reply-To: <Pine.GSO.4.21.0211130833520.28539-100000@ruwhite-u10.cisco.com>
Message-ID: <20021113145324.E73325-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, 13 Nov 2002, Russ White wrote:

> The only part of the path that really seems to matter is:

> -- Knowing the origin
> -- Knowing that the origin actually originated this prefix

> The only time the entire path seems really useful is if you are
> certain the packets will be taking that same path, and since IP
> is a hop by hop protocol, I don't know that you can tie the two
> together.

So look at the part of the path that is relevant to you: the next hop.
That means you need a mechanism to correlate the origin with the next
hop. But then, maybe the next hop itself is valid, but the router there
made a mistake. So you'll end up validating the whole path anyway.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 09:00:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01317
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 09:00:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADE2Sb31161
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 09:02:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADE2Sv31158
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 09:02:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01278
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 08:59:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADE2Av31134;
	Wed, 13 Nov 2002 09:02:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADE1Yv31066
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 09:01:34 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01255
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 08:58:57 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id JAA26907; Wed, 13 Nov 2002 09:01:36 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma026822; Wed, 13 Nov 02 09:00:57 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gADE0om14560;
	Wed, 13 Nov 2002 09:00:50 -0500 (EST)
Date: Wed, 13 Nov 2002 09:00:50 -0500 (EST)
Message-Id: <200211131400.gADE0om14560@raven.gw.tislabs.com>
To: riw@cisco.com, sandy@tislabs.com
Subject: Re: [RPSEC] Re: Potential Requirements New Thread
Cc: beardd@nortelnetworks.com, rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>And the path is used in the
>decision process only as a way to prevent loops (being a first
>level tie breaker is only incidental, really).

I'm not sure what you mean by "incidental".

>-- Knowing the origin 
>-- Knowing that the origin actually originated this prefix

So if AS 7007 had truncated the AS_PATH to the originating AS and then
added itself to the path and advertised that path of length 2,
would that have not influenced lots of traffic to head to AS7007
that would otherwise not have gone that way?

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 09:20:21 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02021
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 09:20:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADEMQo32640
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 09:22:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEMQv32637
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 09:22:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02016
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 09:19:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEMDv32627;
	Wed, 13 Nov 2002 09:22:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADELTv32598
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 09:21:29 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01967
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 09:18:53 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA10307;
	Wed, 13 Nov 2002 09:20:49 -0500 (EST)
Date: Wed, 13 Nov 2002 09:20:49 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: sandy@tislabs.com
cc: beardd@nortelnetworks.com, rpsec@ietf.org
Subject: Re: [RPSEC] Re: Potential Requirements New Thread
In-Reply-To: <200211131400.gADE0om14560@raven.gw.tislabs.com>
Message-ID: <Pine.GSO.4.21.0211130902490.28539-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> >-- Knowing the origin 
> >-- Knowing that the origin actually originated this prefix
> 
> So if AS 7007 had truncated the AS_PATH to the originating AS
> and then added itself to the path and advertised that path of
> length 2, would that have not influenced lots of traffic to
> head to AS7007 that would otherwise not have gone that way?

It may, or it may not. There are a lot of overriding influences.
For instance, AS7007 could simply originate two prefixes covering
the same space, but one bit longer, and it won't matter what the
AS path is. Or, if the next hop out AS happens to set the local
pref for some internal policy, it won't make any different what
AS7007 does with the AS path. With the new "Custom Decision"
draft, life becomes more interesting in this respect.

This is one of those knots we get tangled in on a regular basis
in bgp--what difference does AS path prepend _really_ make? It
seems to sometimes, and others it doesn't, depending on the
situation out in parts of the network you can't control.
Bascially, the next hop chosen is regulated by the AS which
receives the route, not the one which originates it, which makes
solving any problems related to path verification a very
interesting knot to untangle.

You _do_ want to prevent someone from spoofing an AS--saying they
are connected to someone they aren't, or saying they are someone
they're not, but verifying the path doesn't (seem to) necessarily
prove these things. So, I suppose my question is, what would we
accomplish by protecting the AS Path, per se? We should protect
against spoofing (and protecting the as path may be an answer to
that), but the AS path itself, as an item of interest, doesn't
appear to be all that interesting (to me).

I'm just thinking in terms of the same thing with OSPF and IS-IS,
where, as you say, the path isn't all that interesting of an
aspect to try and protect in those protocols (and I agree with
that), and how that fits into the current threat drafts (and the
bgp attack tree).

:-)

Russ

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 09:37:19 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02556
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 09:37:19 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADEdO101606
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 09:39:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEdOv01603
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 09:39:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02553
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 09:36:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEd8v01593;
	Wed, 13 Nov 2002 09:39:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEcDv01558
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 09:38:13 -0500
Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02519
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 09:35:36 -0500 (EST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gADEbl009713;
	Wed, 13 Nov 2002 09:37:47 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKCSC50>; Wed, 13 Nov 2002 09:37:48 -0500
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6044FD23A@zcard0ke.ca.nortel.com>
From: "Dennis Beard" <beardd@nortelnetworks.com>
To: Russ White <riw@cisco.com>,
        Michel Py
	 <michel@arneill-py.sacramento.ca.us>
Cc: rpsec@ietf.org
Subject: RE: [RPSEC] Chrater Question
Date: Wed, 13 Nov 2002 09:37:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28B22.3B17012C"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=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_01C28B22.3B17012C
Content-Type: text/plain

Thank you Russ for clarifying the three WG/Charter positions that we have in
front of us going into Atlanta.  To keep focused, those baseline positions
are:

1.  We should have one generic threats and one generic requirements draft.
2.  We should also have protocol specific recommendations (or requirements?)
drafts, as we can get them done.
3.  We shouldn't have protocol specific requirements drafts, but only one
generic requirements draft.

E-mail chains are convenient, but they tend to take us off track.  As
co-chairs, the best service you can provide is to nail down the charter
principals and ensure that any related drafts support the principal goals.
Same way with the e-mail threads - help us stay focused.  

Regards,

Dennis

-----Original Message-----
From: Russ White [mailto:ruwhite@cisco.com] 
Sent: Wednesday, November 13, 2002 7:54 AM
To: Michel Py
Cc: rpsec@ietf.org
Subject: RE: [RPSEC] Chrater Question



> Which leads me to what I would like this WG to do:
> 1. Assess what is wrong with my protocol's security.
> 2. Evaluate what I could or should do to enhance it.
> 3. Produce a recommendations doc that includes both generic security 
> issues and the ones that are specific to my protocol.
> 
> Note that this should be, IMHO, a continuing process for new protocols 
> that still are work in progress, as there is flexibility in releasing 
> interim drafts.

Thanks, Michael, for the feedback. I think we probably need to have some
further discussion on this: so far, we have:

-- We should have one generic threats and one generic requirements draft.
-- We should also have protocol specific recommendations (or
requirements?) drafts, as we can get them done.
-- We shouldn't have protocol specific requirements drafts, but only one
generic requirements draft.

Any other thoughts/issues/etc.? It's be nice to be able to wrap this
discussion up in Atlanta, with the AD's present, so we can understand where
we are going....

:-)

Russ

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec

------_=_NextPart_001_01C28B22.3B17012C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [RPSEC] Chrater Question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Thank you Russ for clarifying the three WG/Charter =
positions that we have in front of us going into Atlanta.&nbsp; To keep =
focused, those baseline positions are:</FONT></P>

<P><FONT SIZE=3D2>1.&nbsp; We should have one generic threats and one =
generic requirements draft.</FONT>
<BR><FONT SIZE=3D2>2.&nbsp; We should also have protocol specific =
recommendations (or requirements?) drafts, as we can get them =
done.</FONT>
<BR><FONT SIZE=3D2>3.&nbsp; We shouldn't have protocol specific =
requirements drafts, but only one generic requirements draft.</FONT>
</P>

<P><FONT SIZE=3D2>E-mail chains are convenient, but they tend to take =
us off track.&nbsp; As co-chairs, the best service you can provide is =
to nail down the charter principals and ensure that any related drafts =
support the principal goals.&nbsp; Same way with the e-mail threads - =
help us stay focused.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Dennis</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Russ White [<A =
HREF=3D"mailto:ruwhite@cisco.com">mailto:ruwhite@cisco.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, November 13, 2002 7:54 AM</FONT>
<BR><FONT SIZE=3D2>To: Michel Py</FONT>
<BR><FONT SIZE=3D2>Cc: rpsec@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [RPSEC] Chrater Question</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; Which leads me to what I would like this WG to =
do:</FONT>
<BR><FONT SIZE=3D2>&gt; 1. Assess what is wrong with my protocol's =
security.</FONT>
<BR><FONT SIZE=3D2>&gt; 2. Evaluate what I could or should do to =
enhance it.</FONT>
<BR><FONT SIZE=3D2>&gt; 3. Produce a recommendations doc that includes =
both generic security </FONT>
<BR><FONT SIZE=3D2>&gt; issues and the ones that are specific to my =
protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Note that this should be, IMHO, a continuing =
process for new protocols </FONT>
<BR><FONT SIZE=3D2>&gt; that still are work in progress, as there is =
flexibility in releasing </FONT>
<BR><FONT SIZE=3D2>&gt; interim drafts.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks, Michael, for the feedback. I think we =
probably need to have some further discussion on this: so far, we =
have:</FONT>
</P>

<P><FONT SIZE=3D2>-- We should have one generic threats and one generic =
requirements draft.</FONT>
<BR><FONT SIZE=3D2>-- We should also have protocol specific =
recommendations (or</FONT>
<BR><FONT SIZE=3D2>requirements?) drafts, as we can get them =
done.</FONT>
<BR><FONT SIZE=3D2>-- We shouldn't have protocol specific requirements =
drafts, but only one generic requirements draft.</FONT>
</P>

<P><FONT SIZE=3D2>Any other thoughts/issues/etc.? It's be nice to be =
able to wrap this discussion up in Atlanta, with the AD's present, so =
we can understand where we are going....</FONT></P>

<P><FONT SIZE=3D2>:-)</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>

<P><FONT SIZE=3D2>__________________________________</FONT>
<BR><FONT SIZE=3D2>riw@cisco.com CCIE &lt;&gt;&lt; Grace Alone</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>RPSEC mailing list</FONT>
<BR><FONT SIZE=3D2>RPSEC@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/rpsec" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/rpsec</A></FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C28B22.3B17012C--
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 09:51:14 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03202
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 09:51:14 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADErKe02226
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 09:53:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADErKv02223
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 09:53:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03159
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 09:50:43 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEr5v02185;
	Wed, 13 Nov 2002 09:53:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEpZv02057
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 09:51:35 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03051
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 09:48:58 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id JAA29181; Wed, 13 Nov 2002 09:51:38 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma029140; Wed, 13 Nov 02 09:50:36 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gADEoT018336;
	Wed, 13 Nov 2002 09:50:29 -0500 (EST)
Date: Wed, 13 Nov 2002 09:50:29 -0500 (EST)
Message-Id: <200211131450.gADEoT018336@raven.gw.tislabs.com>
To: iljitsch@muada.com, sandy@tislabs.com
Subject: Re: [RPSEC] a link to my threat draft
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

> I've been asked to put the draft I wrote up somewhere accessible.
>> Putting it on our ftp site was easier (bureaucratically) than putting
>> it on the web site, so you can reach it at:
>> ftp://ftp.tislabs.com/pub/rpsec/draft-murphy-threat-00.txt
>
>        The RPSEC working group is addressing security requirements of routing
>        protocols, not the security requirements of routers or of operations of
>        routing systems.  Therefore, this draft specifically does not address
>        threats to routers (hacking, denial of service flooding attacks, etc.)
>        or to specific routing protocol implementations (bugs, etc.).
>
>>From the charter:
>
>        The RPSEC working group is charged with the following tasks:
>
>        - Document threat models for routing systems
>        - Document security requirements for routing systems
>        - Provide a common area for discussion between security and routing
>          experts on the topic of securing the routing system
>


Good point, I should have chosen a different word than "system" since
it collides with the term used in the charter.  I'll change the draft
- how about "operational environment"?

When I see "routing system" in the charter, I think that means the
protocol and any databases it uses - not the protections on telnet
access to the routers or the quality controls on the router software
(or the presence of under floor water sensors or locks on the front
door or...).

I've obviously got one idea of the task of the working group that
is not shared by everyone on this list.

Here's another quote from the charter:

>The products of this working group will be used by routing protocol designers
>to ensure adequate coverage of security in the future, including well
>known and possible threats. 

There is no way that the routing protocol itself can ensure security
attributes of the router itself.  The routing protocols can only
ensure the security of the information they carry.  Expecting the
group to come up with security requirments that would help protocol
designers know how to avoid implementation bugs or logic bombs or
denial of service attacks (in data traffic flooding attacks) directed
at or through routers, or ensure the use of ingress/egress/prefix/AS_PATH
filters, etc., is not a winning strategy.  The routing protocols can't
protect those features.

The charter as written says that we're supposed to help those who are
designing protocols, not those who are trying to operate ISPs.  The
two might be coincident in BGP but they aren't coincident in other
routing protocols. Obviously the security for the operational
environment (hey, that almost works!) will effect the ability to route
traffic correctly in any routing protocol.  But the security of the
operational environment can't be protected by the routing protocol.
So the protocol designers can't be expected to meet security
requirements that relate to the operational environment.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 09:55:38 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03467
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 09:55:38 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADEviX02580
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 09:57:44 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEviv02577
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 09:57:44 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03408
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 09:55:07 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEvVv02492;
	Wed, 13 Nov 2002 09:57:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADErbv02246
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 09:53:37 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03192
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 09:51:00 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id JAA29317; Wed, 13 Nov 2002 09:53:40 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma029288; Wed, 13 Nov 02 09:53:08 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gADEr1W18555;
	Wed, 13 Nov 2002 09:53:01 -0500 (EST)
Date: Wed, 13 Nov 2002 09:53:01 -0500 (EST)
Message-Id: <200211131453.gADEr1W18555@raven.gw.tislabs.com>
To: iljitsch@muada.com, sandy@tislabs.com
Subject: Re: [RPSEC] a link to my threat draft
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>Building an ultrasecure protocol and running it on flimsy boxes doesn't
>help. Building extremely secure routers and then run vulnerable
>protocols on them doesn't either. There must be an integrated approach.

Well, sure, but nothing we require of routing protocols can effect
whether the box is flimsy or not.

>One very important question is: what amount of damage do we think is
>acceptable when an attack is launched from the inside, either by someone
>with legitimate access to a router, or when a router is compromised? Ie
>do we want our cops to walk around in their bullet proof vests at the
>police station in case another cop starts shooting, or are they supposed
>to be safe inside? Both approaches have their advantages, but this
>question exists on a more fundamental level than just routing _protocol_
>security.

You can't prevent all damage, all the time.  But that doesn't mean
you shouldn't try to prevent any damage, any time.  And routing protocols
are in a special category, since decisions locally can cause damage
over a wide spread area.  Kind of like a country deciding not to
vaccinate its citizens as too costly - diseases spread across borders.

When the damage to the rest of the universe caused by a legitimate
participant is severe, you need to provide as much protection as you
can in the protocol.  If that is impossible or deemed too costly, then
you have to consider other non-protocol mechanisms for reducing the
risk.  These are usually administrative controls - which gets into
scary territory real quick, like regulatory agencies deciding who can
be a player in a protocol based on configuration management and
quality controls and security.  There already are registries, sure,
but their use is voluntary.

>About the rest of the draft: it is a good enumeration of all possible
>bad things that can happen, but each exists in a vacuum. Which threats
>are so easy to eliminate that we shouldn't waste time focussing on them?
>Which are so hard to eliminate we shouldn't even bother trying? What
>kind of damage can we expect?

[What do you mean by "threat" - "threat consequence" (i.e., damage),
"threat action" (i.e., attack), "threat source" (i.e., attacker)?]

The damages I list as the threat consequences.  One of the reasons
why I listed them is I've seen proposed security solutions for some
routing protocols that addressed just one type of damage to the net,
not the underlying attack or vulnerability.  So the other types
of damage would still be possible even with the security solution
in place.

One attack (threat action) can be used to bring about lots of
different kinds of damage, so we can't just focus on one type of
damage.  And the damage that can be caused by an attack varies a
whole lot by protocol.  And the cost of preventing the attacks
vary a whole lot by protocol, so eliminating an attack (threat
action) or attacker (threat source) from an overall discussion
is premature.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 09:58:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03683
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 09:58:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADF0SD03008
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 10:00:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADF0Sv03005
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 10:00:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03605
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 09:57:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADF08v02900;
	Wed, 13 Nov 2002 10:00:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADEvlv02592
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 09:57:47 -0500
Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03412
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 09:55:09 -0500 (EST)
Received: (from root@localhost)
	by presque.djinesys.com (8.11.3/8.11.1) id gADEvgf71558
	for rpsec@ietf.org; Wed, 13 Nov 2002 09:57:42 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31])
	by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gADEvdC71551
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 09:57:39 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: (from jhaas@localhost)
	by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gADEvdT03341
	for rpsec@ietf.org; Wed, 13 Nov 2002 09:57:39 -0500 (EST)
Date: Wed, 13 Nov 2002 09:57:39 -0500
From: Jeffrey Haas <jhaas@nexthop.com>
To: rpsec@ietf.org
Subject: Re: [RPSEC] Re: Potential Requirements New Thread
Message-ID: <20021113095739.A3179@nexthop.com>
References: <200211131400.gADE0om14560@raven.gw.tislabs.com> <Pine.GSO.4.21.0211130902490.28539-100000@ruwhite-u10.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.21.0211130902490.28539-100000@ruwhite-u10.cisco.com>; from ruwhite@cisco.com on Wed, Nov 13, 2002 at 09:20:49AM -0500
X-Virus-Scanned: by AMaViS perl-11
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, Nov 13, 2002 at 09:20:49AM -0500, Russ White wrote:
> This is one of those knots we get tangled in on a regular basis
> in bgp--what difference does AS path prepend _really_ make?

To be a little more general, in BGP an announcement has the potential
to have a "capture effect".  In the absence of a more specific 
announcement, advertising reachability has the chance to capture
traffic towards the advertiser of that reachability even if the
resulting path is not the one that is advertised.

However, having that route only means it has the *potential* to
capture traffic at a given router.  Whether it does or not depends
on policy.

At least from the perspective of a regional ISP who doesn't
provide a lot of transit services, prepending can make HUGE
differences to your traffic flows.  However, its a very coarse knob
due to the locality of the effect.

> You _do_ want to prevent someone from spoofing an AS--saying they
> are connected to someone they aren't, or saying they are someone
> they're not, but verifying the path doesn't (seem to) necessarily
> prove these things. So, I suppose my question is, what would we
> accomplish by protecting the AS Path, per se?

While we can't protect the entire path due to the absence of
perfect information due to implicit and explicit aggregation,
validating the path of what we *do* potentially limits the risk.

The question is, are we getting a good bang for the buck out of
this imperfect check?

To restate a previous post - the best you might be able to come up
with is "foo originated this route.  bar, who is adjacent to
me propagated this route to me.  Is he allowed to?"  If you use
that route, you *know* that they're going to get the traffic.
You don't know what they're going to do with it once they have it.

> I'm just thinking in terms of the same thing with OSPF and IS-IS,
> where, as you say, the path isn't all that interesting of an
> aspect to try and protect in those protocols 

I'm somewhat ignorant of the nitty-gritty of various IGPs, however
a similar threat (I think?) is that you can advertise signed
and authenticated LSA's to your heart's content.  This just implies
that if the routers *used* those LSA's as advertised all routers
should theoretically route packets according to the algorithm.

If a box maliciously forwarded packets a different direction from
what the IGP said, how could you tell from the routing protocol
perspective?  I don't think you can.

> Russ

-- 
Jeff Haas 
NextHop Technologies
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 10:02:27 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03836
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 10:02:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADF4XR03206
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 10:04:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADF4Xv03203
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 10:04:33 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03828
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 10:01:56 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADF46v03172;
	Wed, 13 Nov 2002 10:04:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADF1fv03087
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 10:01:41 -0500
Received: from presque.djinesys.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03702
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 09:59:04 -0500 (EST)
Received: (from root@localhost)
	by presque.djinesys.com (8.11.3/8.11.1) id gADF1b171676
	for rpsec@ietf.org; Wed, 13 Nov 2002 10:01:37 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31])
	by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gADF1XC71669
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 10:01:33 -0500 (EST)
	(envelope-from jhaas@jhaas.nexthop.com)
Received: (from jhaas@localhost)
	by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gADF1XP03362
	for rpsec@ietf.org; Wed, 13 Nov 2002 10:01:33 -0500 (EST)
Date: Wed, 13 Nov 2002 10:01:33 -0500
From: Jeffrey Haas <jhaas@nexthop.com>
To: rpsec@ietf.org
Subject: Re: [RPSEC] Potential requirements
Message-ID: <20021113100133.B3179@nexthop.com>
References: <Pine.GSO.4.21.0211121308440.28314-100000@ruwhite-u10.cisco.com> <Pine.GSO.4.40.0211121322440.19351-100000@mesa.bbnplanet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.40.0211121322440.19351-100000@mesa.bbnplanet.com>; from ttauber@genuity.net on Tue, Nov 12, 2002 at 02:04:50PM -0500
X-Virus-Scanned: by AMaViS perl-11
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Russ was previously heard to say:
> I think we need to define exactly what we mean when
> we say "routing system," and "routing protocol."

It occurs to me that we might be running into a definition issue with
the word "protocol" that I've seen before.

People who implement routing protocols usually think PDUs and FSMs.

Crypto people tend to think of the flow of information through a
system.  (If I had my copy of Applied Cryptography, I'd paste Bruce S.'s
definition.)

Keeping the different contexts in mind might help us see eye to eye a
bit easier.

-- 
Jeff Haas 
NextHop Technologies
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 10:13:20 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04229
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 10:13:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADFFQG04329
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 10:15:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADFFQv04326
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 10:15:26 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04207
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 10:12:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADFFAv04289;
	Wed, 13 Nov 2002 10:15:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADFCdv04148
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 10:12:39 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04099
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 10:10:01 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gADFC6875999;
	Wed, 13 Nov 2002 16:12:06 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Wed, 13 Nov 2002 16:12:06 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: <sandy@tislabs.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] a link to my threat draft
In-Reply-To: <200211131450.gADEoT018336@raven.gw.tislabs.com>
Message-ID: <20021113160128.U73325-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, 13 Nov 2002 sandy@tislabs.com wrote:

> There is no way that the routing protocol itself can ensure security
> attributes of the router itself.

That's true, but a routing protocol can impose restrictions on a router
that make the router less secure. For instance, whithout reading the
RFC, I think a BGP router is required to use the same address for the
actual EBGP session as for the next hop (ignoring some not very ordinary
cases). This means the BGP session needs to live on an IP address that
is visible to the world, which makes all sorts of attacks easier and/or
protecting against them harder.

Also, something requiring sensitive private keys to be stored on a
router is a risky proposition, given that routers aren't always easily
physically secured: they must be present where the traffic is, and can't
always be moved to places that are secure. So maybe the protocols should
have provisions to be able to separate the location where forwarding
happens from the location where signatures are generated. Or maybe not.
But we should at least consider these questions.

> Expecting the
> group to come up with security requirments that would help protocol
> designers know how to avoid implementation bugs or logic bombs or
> denial of service attacks (in data traffic flooding attacks) directed
> at or through routers, or ensure the use of ingress/egress/prefix/AS_PATH
> filters, etc., is not a winning strategy.  The routing protocols can't
> protect those features.

How can we know this before we discuss it?

At the very least protocol designers shouldn't create new holes, which
means they must be aware of existing ones.

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 11:07:34 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06251
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 11:07:34 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADG9fq08871
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 11:09:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADG9fv08868
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 11:09:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06215
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 11:07:04 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADG99v08852;
	Wed, 13 Nov 2002 11:09:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADG8wv08821
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 11:08:58 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06197
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 11:06:19 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id LAA02311; Wed, 13 Nov 2002 11:08:58 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma002286; Wed, 13 Nov 02 11:08:53 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gADG8hr24085;
	Wed, 13 Nov 2002 11:08:43 -0500 (EST)
Date: Wed, 13 Nov 2002 11:08:43 -0500 (EST)
Message-Id: <200211131608.gADG8hr24085@raven.gw.tislabs.com>
To: jhaas@nexthop.com, rpsec@ietf.org
Subject: Re: [RPSEC] Re: Potential Requirements New Thread
Cc: sandy@tislabs.com
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>To restate a previous post - the best you might be able to come up
>with is "foo originated this route.  bar, who is adjacent to
>me propagated this route to me.  Is he allowed to?"

The definition of "allowed to" in BGP is based on bar having received
a route from someone (who was allowed to).  In OSPF, bar is allowed
to propagate any LSA.  In fact, bar is expected to propagate all LSA's.
In AODV and DSR, the answer is more like the answer for BGP - the
"allowed to" is couched in terms of bar having based the propagated
route on some valid inputs from its neighbors.

>If a box maliciously forwarded packets a different direction from
>what the IGP said, how could you tell from the routing protocol
>perspective?  I don't think you can.

DSR is one case where the forwarding and the routing protocol are
strongly linked.  The data traffic is supposed to carry a (valid)
source route it got from DSR.  Of course, that doesn't preclude a
router from disobeying the source route.  But that is one case where
the routing protocol and the data traffic forwarding path are intended to be
linked.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 11:21:27 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06977
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 11:21:27 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADGNYT09783
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 11:23:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGNYv09780
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 11:23:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06914
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 11:20:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGNJv09747;
	Wed, 13 Nov 2002 11:23:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGMMv09412
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 11:22:22 -0500
Received: from server2000.arneill-py.sacramento.ca.us (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06792
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 11:19:44 -0500 (EST)
Subject: RE: [RPSEC] Chrater Question
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Date: Wed, 13 Nov 2002 08:22:53 -0800
Message-ID: <2B81403386729140A3A899A8B39B046405E45F@server2000>
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: [RPSEC] Chrater Question
Thread-Index: AcKLE9YB9hm/4dbZQjGFMRg53XdINwAGO0/Q
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: "Russ White" <riw@cisco.com>
Cc: <rpsec@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gADGMMv09413
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit

Russ,

> Russ White wrote:
> recommendations (or requirements?) drafts

A few more thoughts:

- Mixing protocols in a "generic" requirements draft that would
necessarily be bigger than a specific one is a sure way to reduce its
reading success. In other words, if I'm a protocol developer that works
on a link-state protocol, I could care less about security requirements
that are unique to distance vector protocols and I don't like to have to
find where the part that is relevant to me is in that huge doc.

- As I mentioned before, security is important, but it's only 10 percent
of the compromise that makes a good routing protocol. An ultra-secure
protocol that can't do anything but be secure is of no use. Don't ask
for miracles unless you know how to make them happen.

- In the recommendations vs. requirements dept, the one thing you don't
want to do is to dig yourself into the same kind of hole that multi6
currently is in (some requirements contradict some others). In the long
run, the success of the work produced by this WG will be judged not by
how consensual or good the requirement docs are, but how much of them
will be included in the actual protocols.

Michel.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 11:41:16 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07615
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 11:41:16 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADGhOv11526
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 11:43:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGhOv11523
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 11:43:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07601
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 11:40:45 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGh5v11504;
	Wed, 13 Nov 2002 11:43:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGgVv11446
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 11:42:31 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07537
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 11:39:52 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27654;
	Wed, 13 Nov 2002 11:41:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100301b9f82c0a1e3e@[128.89.88.34]>
In-Reply-To: 
 <Pine.GSO.4.21.0211121922460.28336-100000@ruwhite-u10.cisco.com>
References: 
 <Pine.GSO.4.21.0211121922460.28336-100000@ruwhite-u10.cisco.com>
Date: Wed, 13 Nov 2002 11:32:44 -0500
To: Russ White <riw@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Potential requirements
Cc: rpsec@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 8:22 PM -0500 11/12/02, Russ White wrote:
>  > >So, you are stating that the authorization to advertise a
>>  >specific prefix is part of the BGP protocol itself? Or the actual
>>  >path being "correct" from a policy perspective is a part of the
>>  >BGP protocol itself?
>>
>>  I am stating that BGP correct operation is based on an
>>  implicit assumption that the origin AS is authorized to
>>  advertise the address block by the owner, etc. Do you
>>  disagree?
>
>Yes. :-)
>
>If my daughter walks into a store with my credit card and
>attempts to buy something, does her physical access to my credit
>card mean that she is authorized to use it? No. Does a router's
>apparent physical access to a given destination mean it is
>authorized to advertise that destination? No.
>
>Today, there are two parts to the way a routing protocol process
>on a specific device determines it may advertise a particular
>destination as reachable through this device:
>
>-- The destination is configured to be directly connected, or
>through a manually configured route statement claiming the route
>is reachable "this way."
>
>-- The routing protocol is configured to advertise said
>destination.
>
>Thus, today, we assume that the operator provides the
>authorization for the routing protocol to advertise a particular
>destination from a particular device. If you cannot, or do not,
>make the assumption that manual configuration constitutes
>authorization (which is why we have threats drafts, etc.), then
>you must build some authorization into the system.
>
>Advertisement of reachability is not tatamount to authorization
>to advertise that reachability.

You seem to be making a distinction between authorization via local 
assertion vs. authorization via a more formal structure. We know that 
the former is prone to error, and vulnerable to attack. So, I think 
we need to abandon the notion of implicit authorization via local 
assertion.

Using your phrase from above, I would say that advertisement of 
reachability SHOULD be equivalent to authorization to advertise hat 
reachability and that BGP assumes this is the case in making routing 
decisions. To argue otherwise is to say that it is a good thing to 
make routing decisions based on unauthentic data, which is ludicrous.

>  > I don't mean to suggest that one size fits all routing
>>  protocols. The semantics differ and must be characterized
>>  individually for each protocol, to be ale to make usefully
>>  detailed statements about the security requirements for each
>>  protocol.
>
>Right.... Again, I think we are talking about the same thing,
>just using different words. I think that the authorization to
>advertise a destination is not part of the routing protocol, but
>part of the routing system. I do not include access to the
>physical device to be in the routing system; the configuration
>which authorizes that device to advertise a given destination is
>a part of the routing system, but not part of the routing
>protocol.

We disagree, because the protocol has as it (unstated?) goal the 
propagation of accurate reachability data to AS's. Nobody would 
suggest that all the effort that went into the design of BGP and the 
execution of BGP is warranted if propagation of bogus reachability 
data were the intent :-)

>I think you're saying that the manual configuration which
>(today) constitutes the authorization to advertise a given
>reachable destination is part of the routing protocol.
>
>Is that correct?

No. I think that my comments above clarify the distinction between a 
local assertion about authorization to advertise vs. an independent 
verification of that assertion.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 11:42:08 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07660
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 11:42:08 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADGiGx11593
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 11:44:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGiFv11590
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 11:44:15 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07638
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 11:41:37 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGi1v11578;
	Wed, 13 Nov 2002 11:44:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGh4v11498
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 11:43:04 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07562
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 11:40:12 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27666;
	Wed, 13 Nov 2002 11:41:11 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100302b9f82f65e80a@[128.89.88.34]>
In-Reply-To: 
 <Pine.GSO.4.21.0211122024370.28369-100000@ruwhite-u10.cisco.com>
References: 
 <Pine.GSO.4.21.0211122024370.28369-100000@ruwhite-u10.cisco.com>
Date: Wed, 13 Nov 2002 11:41:29 -0500
To: Russ White <riw@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Potential requirements
Cc: rpsec@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 8:26 PM -0500 11/12/02, Russ White wrote:
>  > >Okay, so let's say that BGP is a policy propogation mechanism, so
>>  >you _could_ stretch it in this case. But can you stretch it in
>>  >the case of OSPF, IS-IS, PIM, etc? In other words, as the same
>>  >question: Could the authorization to advertise a certain
>>  >destination as reachable through this device be a part of the
>>  >OSPF protocol itself?
>>
>>  Radia Perlman's work talks about how to protect this
>>  authorization assumption in link state protocols and RFC2154
>>  talks about how to do it for OSPF in particular.
>
>Actually, according to RFC2154:
>
>The basic idea of this proposal is to add digital signatures to
>OSPF LSA data, distribute certified router information and keys,
>and use a neighbor-to-neighbor authentication algorithm (like
>keyed MD5) to protect local protocol exchanges.
>
>Just because a device signs something as actually originating
>from the device itself, it doesn't prove the device is authorized
>to transmit that reachability information. In other words, my
>daughter can sign to use my credit card. I now know who used my
>credit card, but nothing in that signature indicates she is
>actually authorized to use it.
>
>:-)
>
>Russ

Signing is useful as means of detecting the source of bogus data when 
that data is broadcast, and one wants to rule out modification of the 
data by intermediaries. You are correct that this is different from 
signing data where authorization data is bound to the key used to 
verify signatures, and thus one can ascertain the authorization of 
the signer. However I think Sandy pointed out that in this case both 
apply.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 11:52:24 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07923
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 11:52:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADGsVY12094
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 11:54:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGsVv12091
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 11:54:31 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07901
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 11:51:53 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGsFv12081;
	Wed, 13 Nov 2002 11:54:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGm1v11770
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 11:48:01 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07729
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 11:45:23 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id LAA04429; Wed, 13 Nov 2002 11:48:03 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma004394; Wed, 13 Nov 02 11:47:30 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gADGlNM28372;
	Wed, 13 Nov 2002 11:47:23 -0500 (EST)
Date: Wed, 13 Nov 2002 11:47:23 -0500 (EST)
Message-Id: <200211131647.gADGlNM28372@raven.gw.tislabs.com>
To: michel@arneill-py.sacramento.ca.us, riw@cisco.com
Subject: RE: [RPSEC] Chrater Question
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>In other words, if I'm a protocol developer that works
>on a link-state protocol, I could care less about security requirements
>that are unique to distance vector protocols

It would actually be a very very interesting result to discover that
there were security requirements specific to distance vector protocols
that did not apply to link state protocols.    

>In the long
>run, the success of the work produced by this WG will be judged not by
>how consensual or good the requirement docs are, but how much of them
>will be included in the actual protocols.

Or just noted which requirements were judged impossible to meet and why.
(Presuming "included in" means "met by")  Nice to give people hints that
they're putting themselves at risk.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 11:58:14 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08329
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 11:58:14 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADH0Mf12759
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 12:00:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADH0Mv12756
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 12:00:22 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08317
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 11:57:43 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADH03v12676;
	Wed, 13 Nov 2002 12:00:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADGx3v12605
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 11:59:03 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08292
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 11:56:24 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05540;
	Wed, 13 Nov 2002 11:51:07 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100305b9f831916adb@[128.89.88.34]>
In-Reply-To: 
 <Pine.GSO.4.21.0211130833520.28539-100000@ruwhite-u10.cisco.com>
References: 
 <Pine.GSO.4.21.0211130833520.28539-100000@ruwhite-u10.cisco.com>
Date: Wed, 13 Nov 2002 11:51:57 -0500
To: Russ White <riw@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Re: Potential Requirements New Thread
Cc: sandy@tislabs.com, beardd@nortelnetworks.com, rpsec@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 8:38 AM -0500 11/13/02, Russ White wrote:
>  > >-- The ability to verify the path the update has taken.
>>
>>  This is important in BGP, since it's part of the protocol
>>  info used in making decisions.  But do you think it is
>>  important in all routing protocols?
>>
>>  In OSPF, for example, the flooding technique could
>>  conceivably make the same LSA reach you through lots of
>>  different paths and the path matters very little (not at all,
>>  except perhaps for timing issues?) in how the protocol or
>>  even subsequent forwarding behaves.
>>
>>  In wireless protocols, sometimes the path matters quite a bit
>>  in the protocol (e.g., DSR records the path) and in others it
>>  doesn't.
>
>Agreed.... I'm actually wondering how much of a difference
>knowing the path in BGP makes. The path of the update doesn't
>necessarily dictate the path of the packet following a given
>route, so it doesn't secure the path. And the path is used in the
>decision process only as a way to prevent loops (being a first
>level tie breaker is only incidental, really).
>
>The only part of the path that really seems to matter is:
>
>-- Knowing the origin
>-- Knowing that the origin actually originated this prefix
>
>The only time the entire path seems really useful is if you are
>certain the packets will be taking that same path, and since IP
>is a hop by hop protocol, I don't know that you can tie the two
>together.

I strongly disagree. If we only know the origin AS is authorized to 
advertise a prefix, then there are myriad ways for an AS that is not 
authorized to advertise a path for the prefix to hijack the route, 
e.g., merely by claiming that yes, eventually, this unauthorized AS 
promises to route the data to the correct origin. The fundamental 
requirement for making BGP routing UPDATEs secure is simple and 
directly derived from BGP semantics:

	for each prefix, you need to know that every AS along the 
path is authorized to advertise the prefix by the preceding AS, and 
that the origin AS was authorized to advertise the prefix by the owner

Any deviation from this basic model will result in vulnerabilities 
that can be exploited to cause black holes, etc.

I have not studied the soBGP documents in detail, but my impression 
is that the soBGP proposal would fail to protect against these sorts 
of attacks. (In part the confusion stems from the fact that the soBGP 
documents seem to be less than clear about exactly what will be 
protected other than the origin AS info.)

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 12:09:31 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08838
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 12:09:31 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADHBdN14228
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 12:11:39 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHBcv14225
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 12:11:39 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08807
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 12:09:00 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHBHv14210;
	Wed, 13 Nov 2002 12:11:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHAVv14164
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 12:10:31 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08763
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 12:07:52 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gADH9ep76172;
	Wed, 13 Nov 2002 18:09:40 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Wed, 13 Nov 2002 18:09:40 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Stephen Kent <kent@bbn.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <p05100301b9f82c0a1e3e@[128.89.88.34]>
Message-ID: <20021113180301.O73325-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, 13 Nov 2002, Stephen Kent wrote:

> >Advertisement of reachability is not tatamount to authorization
> >to advertise that reachability.

> You seem to be making a distinction between authorization via local
> assertion vs. authorization via a more formal structure. We know that
> the former is prone to error, and vulnerable to attack. So, I think
> we need to abandon the notion of implicit authorization via local
> assertion.

On the other hand, "more formal structures" tend to be very complex to
operate and manage and lead to a significant number of false positives
(to the extend that rejecting valid information can be called
"positive").

I don't think we can dismiss either option out of hand.

> Using your phrase from above, I would say that advertisement of
> reachability SHOULD be equivalent to authorization to advertise hat
> reachability

Who gets to issue this authorization? The internet is a decentralized
network. This is an important property.

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 12:45:11 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10107
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 12:45:10 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADHlJN16731
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 12:47:19 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHlJv16728
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 12:47:19 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10102
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 12:44:39 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHg3v16420;
	Wed, 13 Nov 2002 12:42:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHfSv16355
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 12:41:28 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09828
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 12:38:49 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04128;
	Wed, 13 Nov 2002 12:41:27 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100307b9f83b0aa494@[128.89.88.34]>
In-Reply-To: <20021113180301.O73325-100000@sequoia.muada.com>
References: <20021113180301.O73325-100000@sequoia.muada.com>
Date: Wed, 13 Nov 2002 12:41:13 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Potential requirements
Cc: <rpsec@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 6:09 PM +0100 11/13/02, Iljitsch van Beijnum wrote:
>On Wed, 13 Nov 2002, Stephen Kent wrote:
>
>>  >Advertisement of reachability is not tatamount to authorization
>>  >to advertise that reachability.
>
>>  You seem to be making a distinction between authorization via local
>>  assertion vs. authorization via a more formal structure. We know that
>>  the former is prone to error, and vulnerable to attack. So, I think
>>  we need to abandon the notion of implicit authorization via local
>>  assertion.
>
>On the other hand, "more formal structures" tend to be very complex to
>operate and manage and lead to a significant number of false positives
>(to the extend that rejecting valid information can be called
>"positive").

The formal structures exist for the data in question, and there in 
agreement that the allocation  of addresses and AS numbers must be a 
coordinated process using these sorts of structures.  (I'm not 
talking about routing registries, but the RIS here.) This makes them 
different from contexts in which people need to create such 
structures from scratch.

On what basis do you assert that the RIR data would lead to 
"significant numbers of false positives?" Yes, the legacy allocations 
for address blocks is not in great shape, but that is a problem that 
is already being worked.

>
>I don't think we can dismiss either option out of hand.
>
>>  Using your phrase from above, I would say that advertisement of
>>  reachability SHOULD be equivalent to authorization to advertise hat
>>  reachability
>
>Who gets to issue this authorization? The internet is a decentralized
>network. This is an important property.

As noted above, the RIRs are authoritative sources for who owns what 
AS numbers and what address blocks. In the case of S-BGP, we include 
provisions for owners of address blocks to attest to the 
sub-allocation of address blocks, consistent with the way such 
sub-allocations are managed. So, the tree structure that represents 
address allocation is captured by a PKI that parallels that 
structure, and that represents the authorization data one needs to 
verify advertised routes.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 12:48:07 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10271
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 12:48:07 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADHoGS16909
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 12:50:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHoFv16906
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 12:50:15 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10262
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 12:47:36 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHo2v16897;
	Wed, 13 Nov 2002 12:50:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADHnMv16842
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 12:49:22 -0500
Received: from shockwave.systems.pipex.net (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10213
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 12:46:42 -0500 (EST)
Received: from tom3 (userbf25.uk.uudial.com [62.188.142.46])
	by shockwave.systems.pipex.net (Postfix) with SMTP
	id 5B44516001718; Wed, 13 Nov 2002 17:49:13 +0000 (GMT)
Message-ID: <006201c28b3d$02321de0$0301a8c0@tom3>
Reply-To: "Tom Petch" <nwnetworks@dial.pipex.com>
From: "Tom Petch" <nwnetworks@dial.pipex.com>
To: "Iljitsch van Beijnum" <iljitsch@muada.com>, "Russ White" <riw@cisco.com>
Cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Chrater Question
Date: Wed, 13 Nov 2002 17:48:15 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Content-Transfer-Encoding: 7bit
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

I believe that to try and separate IGP and EGP, or OSPF and RIP, at
this stage is cart before horse, vague and nebulous.

A good threats document (perhaps culled from the legion threats
documents that security experts produce these days) would give us a
much clearer view of how much EGP and IGP, OSPF and RIP, have in
common in terms of threats and so guide how much we have to
differentiate subsequent
documents into various sub-categories.

Tom Petch
nwnetworks@dial.pipex.com

-----Original Message-----
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Russ White <riw@cisco.com>
Cc: Michel Py <michel@arneill-py.sacramento.ca.us>; rpsec@ietf.org
<rpsec@ietf.org>
Date: 13 November 2002 13:46
Subject: RE: [RPSEC] Chrater Question


>On Wed, 13 Nov 2002, Russ White wrote:
>
>> -- We should have one generic threats and one generic
>> requirements draft.
>> -- We should also have protocol specific recommendations (or
>> requirements?) drafts, as we can get them done.
>> -- We shouldn't have protocol specific requirements drafts, but
>> only one generic requirements draft.
>
>> Any other thoughts/issues/etc.? It's be nice to be able to wrap
>> this discussion up in Atlanta, with the AD's present, so we can
>> understand where we are going....
>
>I think it would be useful to separate IGP and EGP issues. Once again
>I'll risk getting ahead of things by naming instances of real-world
>routing protocols, but bear with me as I think it will make things
>clearer.
>
>IGPs such as OSPF or IS-IS (do we even want to look at RIP???)
yes!



_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 13:23:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11556
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 13:23:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADIPVB19403
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 13:25:31 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADIPVv19400
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 13:25:31 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11538
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 13:22:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADIPAv19334;
	Wed, 13 Nov 2002 13:25:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADIN1v19217
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 13:23:01 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11482
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 13:20:21 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gADIMHQ76326;
	Wed, 13 Nov 2002 19:22:17 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Wed, 13 Nov 2002 19:22:17 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Stephen Kent <kent@bbn.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Potential requirements
In-Reply-To: <p05100307b9f83b0aa494@[128.89.88.34]>
Message-ID: <20021113190904.R73325-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Wed, 13 Nov 2002, Stephen Kent wrote:

> >On the other hand, "more formal structures" tend to be very complex to
> >operate and manage and lead to a significant number of false positives
> >(to the extend that rejecting valid information can be called
> >"positive").

> The formal structures exist for the data in question, and there in
> agreement that the allocation  of addresses and AS numbers must be a
> coordinated process using these sorts of structures.  (I'm not
> talking about routing registries, but the RIS here.)

RIS?

> This makes them
> different from contexts in which people need to create such
> structures from scratch.

> On what basis do you assert that the RIR data would lead to
> "significant numbers of false positives?" Yes, the legacy allocations
> for address blocks is not in great shape, but that is a problem that
> is already being worked.

Very simple: very many people don't register their stuff, or don't do it
well. I'll take the time to evaluate a sample after Atlanta.

> >Who gets to issue this authorization? The internet is a decentralized
> >network. This is an important property.

> As noted above, the RIRs are authoritative sources for who owns what
> AS numbers and what address blocks.

Nobody "owns" address blocks. And the actual involvement of the RIRs
themselves is very limited: most of what's in their databases is put
there by ISPs. The very same people that as a group don't bother with
the BGP MD5 option.

> In the case of S-BGP, we include
> provisions for owners of address blocks to attest to the
> sub-allocation of address blocks, consistent with the way such
> sub-allocations are managed. So, the tree structure that represents
> address allocation is captured by a PKI that parallels that
> structure, and that represents the authorization data one needs to
> verify advertised routes.

Even if we can make a successful transition from what we have now to
what S-BGP requires, I'm still very uncomfortable with having just a
hand full of entities at the top level of the tree.

To quote Bassam Halabi in "Internet Routing Architectures" (use the
first edition, the quote is watered down in the second) (from memory):
"People are surprised when networks fail. I'm surprised when they
don't."

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 13:49:15 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12511
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 13:49:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADIpOu21538
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 13:51:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADIpOv21535
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 13:51:24 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12476
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 13:48:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADIpAv21520;
	Wed, 13 Nov 2002 13:51:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADIokv21424
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 13:50:46 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12455
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 13:48:06 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10217;
	Wed, 13 Nov 2002 13:50:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p0510030db9f84dba0859@[128.89.88.34]>
In-Reply-To: <20021113190904.R73325-100000@sequoia.muada.com>
References: <20021113190904.R73325-100000@sequoia.muada.com>
Date: Wed, 13 Nov 2002 13:49:00 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Potential requirements
Cc: <rpsec@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 7:22 PM +0100 11/13/02, Iljitsch van Beijnum wrote:
>On Wed, 13 Nov 2002, Stephen Kent wrote:
>
>>  >On the other hand, "more formal structures" tend to be very complex to
>>  >operate and manage and lead to a significant number of false positives
>>  >(to the extend that rejecting valid information can be called
>>  >"positive").
>
>>  The formal structures exist for the data in question, and there in
>>  agreement that the allocation  of addresses and AS numbers must be a
>>  coordinated process using these sorts of structures.  (I'm not
>>  talking about routing registries, but the RIS here.)
>
>RIS?

Sorry, RIR (Regional Internet Registry, e.g., ARIN, RIPE, APNIC)

>
>>  This makes them
>>  different from contexts in which people need to create such
>>  structures from scratch.
>
>>  On what basis do you assert that the RIR data would lead to
>>  "significant numbers of false positives?" Yes, the legacy allocations
>>  for address blocks is not in great shape, but that is a problem that
>>  is already being worked.
>
>Very simple: very many people don't register their stuff, or don't do it
>well. I'll take the time to evaluate a sample after Atlanta.

You don't get an allocation of address space from an RIR without 
being registered. if you get your block from an ISP and run BGP and 
want to run S-BGP, then the ISP would have to issue a cert to you to 
represent that sub-allocation, a local operation not involving the 
RIR.

>
>>  >Who gets to issue this authorization? The internet is a decentralized
>>  >network. This is an important property.
>
>>  As noted above, the RIRs are authoritative sources for who owns what
>>  AS numbers and what address blocks.
>
>Nobody "owns" address blocks. And the actual involvement of the RIRs
>themselves is very limited: most of what's in their databases is put
>there by ISPs. The very same people that as a group don't bother with
>the BGP MD5 option.

You are confusing different levels of allocation.  Rather than 
bothering the list with a tutorial on this, I suggest you look at the 
S-BGP papers at the URL I sent earlier, and then contact me privately 
if you have questions.

>
>>  In the case of S-BGP, we include
>>  provisions for owners of address blocks to attest to the
>>  sub-allocation of address blocks, consistent with the way such
>>  sub-allocations are managed. So, the tree structure that represents
>>  address allocation is captured by a PKI that parallels that
>>  structure, and that represents the authorization data one needs to
>>  verify advertised routes.
>
>Even if we can make a successful transition from what we have now to
>what S-BGP requires, I'm still very uncomfortable with having just a
>hand full of entities at the top level of the tree.
>
>To quote Bassam Halabi in "Internet Routing Architectures" (use the
>first edition, the quote is watered down in the second) (from memory):
>"People are surprised when networks fail. I'm surprised when they
>don't."

The people at the top of the address allocation tree have been there 
since 1996. They are not going away. The S-BGP architecture does not 
require interacting with them any more frequently than ISPs and 
multi-homed subscribers do today, and it does not rely on them to 
provide a high-availability service. Their role is the same as it is 
today, with the exception that they act as CAs to provide certs 
attesting to address allocation and AS ownership, so that these certs 
can be used in a distributed algorithm to verify assertions made by 
ISPs re paths.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 14:14:14 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13559
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 14:14:14 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADJGM423199
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 14:16:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADJGLv23196
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 14:16:21 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13541
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 14:13:43 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADJG6v23170;
	Wed, 13 Nov 2002 14:16:06 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADJFKv23140
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 14:15:20 -0500
Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13482
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 14:12:41 -0500 (EST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gADJFBO26312;
	Wed, 13 Nov 2002 14:15:12 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <TLKCSLK5>; Wed, 13 Nov 2002 14:15:12 -0500
Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6044FD77B@zcard0ke.ca.nortel.com>
From: "Dennis Beard" <beardd@nortelnetworks.com>
To: sandy@tislabs.com
Cc: rpsec@ietf.org
Subject: RE: [RPSEC] Chrater Question
Date: Wed, 13 Nov 2002 14:15:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28B48.FC2E37CE"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=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_01C28B48.FC2E37CE
Content-Type: text/plain

Thank you Sandy for bring this error to my attention.  "Principals" should
have been spelled "principles" as in adhering to the major points and
deliverables spelled out in the WG charter and restated by Russ.  

Regards,

Dennis

-----Original Message-----
From: sandy@tislabs.com [mailto:sandy@tislabs.com] 
Sent: Wednesday, November 13, 2002 10:13 AM
To: Beard, Dennis [CAR:0S03:EXCH]
Cc: sandy@tislabs.com
Subject: RE: [RPSEC] Chrater Question


>the best service you can provide is to nail down the charter principals 
>and ensure that any related drafts support the principal goals.

So you mean "principals" as in the primary people involved and "principal
goals" as in the chief and most important goals or do you mean "/principle
goals", as in the fundamentals and assumptions.

--Sandy

------_=_NextPart_001_01C28B48.FC2E37CE
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [RPSEC] Chrater Question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Thank you Sandy for bring this error to my =
attention.&nbsp; &quot;Principals&quot; should have been spelled =
&quot;principles&quot; as in adhering to the major points and =
deliverables spelled out in the WG charter and restated by Russ.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Dennis</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: sandy@tislabs.com [<A =
HREF=3D"mailto:sandy@tislabs.com">mailto:sandy@tislabs.com</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, November 13, 2002 10:13 AM</FONT>
<BR><FONT SIZE=3D2>To: Beard, Dennis [CAR:0S03:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: sandy@tislabs.com</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [RPSEC] Chrater Question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;the best service you can provide is to nail down =
the charter principals </FONT>
<BR><FONT SIZE=3D2>&gt;and ensure that any related drafts support the =
principal goals.</FONT>
</P>

<P><FONT SIZE=3D2>So you mean &quot;principals&quot; as in the primary =
people involved and &quot;principal goals&quot; as in the chief and =
most important goals or do you mean &quot;/principle goals&quot;, as in =
the fundamentals and assumptions.</FONT></P>

<P><FONT SIZE=3D2>--Sandy</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C28B48.FC2E37CE--
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 14:48:36 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14844
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 14:48:35 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADJohE25536
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 14:50:43 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADJohv25533
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 14:50:43 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14821
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 14:48:04 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADJoIv25509;
	Wed, 13 Nov 2002 14:50:18 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADJkMv25267
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 14:46:22 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14640
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 14:43:43 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id OAA13291; Wed, 13 Nov 2002 14:46:23 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma013267; Wed, 13 Nov 02 14:46:07 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gADJk0t14288;
	Wed, 13 Nov 2002 14:46:00 -0500 (EST)
Date: Wed, 13 Nov 2002 14:46:00 -0500 (EST)
Message-Id: <200211131946.gADJk0t14288@raven.gw.tislabs.com>
To: rpsec@ietf.org
Cc: sandy@tislabs.com
Subject: [RPSEC] just to prove it's not just BGP ...
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Here's a comment from a message on the nemo list that just arrived:

>> I don't understand the need to authorize which MR advertises which
>> prefix.  I was thinking that MRs are trusted by the HA because they
>> had that IPsec tunnel.  So if the MRs share keys with the HA then they
>> can also advertise routes through the HA?
>
>lets assume there are two MRs, MR1 and MR2. what prevents MR2 from
>disrupting traffic to MR1 by advertising routes for MR1's mobile
>network to point to itself? Both MR1 and MR2 have security 
>associations with the HA.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 13 15:59:25 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17322
	for <rpsec-archive@odin.ietf.org>; Wed, 13 Nov 2002 15:59:24 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gADL1XP29727
	for rpsec-archive@odin.ietf.org; Wed, 13 Nov 2002 16:01:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADL1Xv29724
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 13 Nov 2002 16:01:33 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17316
	for <rpsec-web-archive@ietf.org>; Wed, 13 Nov 2002 15:58:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADL1Bv29703;
	Wed, 13 Nov 2002 16:01:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADL0gv29656
	for <rpsec@optimus.ietf.org>; Wed, 13 Nov 2002 16:00:42 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17279
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 15:58:02 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08932;
	Wed, 13 Nov 2002 16:00:33 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100312b9f868ba606d@[128.89.88.34]>
In-Reply-To: <20021113160128.U73325-100000@sequoia.muada.com>
References: <20021113160128.U73325-100000@sequoia.muada.com>
Date: Wed, 13 Nov 2002 15:58:19 -0500
To: Iljitsch van Beijnum <iljitsch@muada.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] a link to my threat draft
Cc: <rpsec@ietf.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 4:12 PM +0100 11/13/02, Iljitsch van Beijnum wrote:
><SNIP>
>
>Also, something requiring sensitive private keys to be stored on a
>router is a risky proposition, given that routers aren't always easily
>physically secured: they must be present where the traffic is, and can't
>always be moved to places that are secure. So maybe the protocols should
>have provisions to be able to separate the location where forwarding
>happens from the location where signatures are generated. Or maybe not.
>But we should at least consider these questions.

security protocol designs often do not address the question of the 
level of assurance associated with an implementation, although this 
is an important system security issue. for example, the statement 
above re the dangers of storing private signature generation keys in 
routers is relevant to system security, but is also an observation 
based on a particular notion of an implementation. if one anticipated 
the need to store crypto keys in a router, it can be done very 
securely with current crypto chip technology, for example.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov 14 00:04:21 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00123
	for <rpsec-archive@odin.ietf.org>; Thu, 14 Nov 2002 00:04:21 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAE56YJ25049
	for rpsec-archive@odin.ietf.org; Thu, 14 Nov 2002 00:06:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAE56Yv25046
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 14 Nov 2002 00:06:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00118
	for <rpsec-web-archive@ietf.org>; Thu, 14 Nov 2002 00:03:50 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAE56Dv25038;
	Thu, 14 Nov 2002 00:06:13 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAE553v25010
	for <rpsec@optimus.ietf.org>; Thu, 14 Nov 2002 00:05:03 -0500
Received: from atpop.smtp.stsn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00086
	for <rpsec@ietf.org>; Thu, 14 Nov 2002 00:02:18 -0500 (EST)
Received: from sandelman.ottawa.on.ca ([10.0.173.132]) by atpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 14 Nov 2002 00:04:06 -0500
Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1])
	by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gAE4U2QI012881
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK)
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 23:30:15 -0500
Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost)
	by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gAE0bOUk009613
	for <rpsec@ietf.org>; Wed, 13 Nov 2002 19:38:25 -0500
Message-Id: <200211140038.gAE0bOUk009613@sandelman.ottawa.on.ca>
To: rpsec@ietf.org
Subject: Re: [RPSEC] Re: draft-convery-bgpattack-00 
In-reply-to: Your message of "Tue, 12 Nov 2002 11:19:27 PST."
             <r01050400-1021-B562A354F67311D69B890003939CDD90@[172.16.30.208]> 
Mime-Version: 1.0 (generated by tm-edit 1.8)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 13 Nov 2002 19:37:24 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
X-OriginalArrivalTime: 14 Nov 2002 05:04:06.0281 (UTC) FILETIME=[41F8C790:01C28B9B]
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Sean" == Sean Convery <sean@cisco.com> writes:
    Sean> You can send message causing a reset by 1. sending the message to the
    Sean> TCP stack, or 2. sending a BGP message.  But in both cases you need 3.
    Sean> the TCP sequence number attack.

    Sean> There shouldn't be any cases where an AND or OR is between two numbers.
    Sean> it should alway be on the same line as a goal on the tree.

  So, I can think of this as persistant prefix :-)
  Once I see "OR", I put OR between each clause (at that level) until I see
something else.

    Sean> We tried to explain the notation in the Intro section.  If you can
    Sean> provide some specific comments on how to make this better (short of

  I'll re-read the intro and see what I can tell.  
  I admit that I was in a rush to get to the meat. Maybe it would be good to
explain the first real instance out in detail. Maybe you already did that,
I'm not online to grab your draft again at the moment.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPdLwQoqHRg3pndX9AQHJewQAs4YrPjkObVHspiuG2WpTsVghr+gvRojI
0Dz20tUD97bY7vvLl/EBIFE+Aa1SG75Z4n/10FcPqjoTL7+j19t7c8fpMkxqzrsd
Wwkp+JJX/F42plMAIxa3RsjTzv2252GQZpVOKTVaJMnGzZxJkowbif9rFAMWnhhj
SXtVy9l/B+w=
=hcK2
-----END PGP SIGNATURE-----
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov 14 10:54:33 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22280
	for <rpsec-archive@odin.ietf.org>; Thu, 14 Nov 2002 10:54:33 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAEFuem04913
	for rpsec-archive@odin.ietf.org; Thu, 14 Nov 2002 10:56:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEFuev04910
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 14 Nov 2002 10:56:40 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22271
	for <rpsec-web-archive@ietf.org>; Thu, 14 Nov 2002 10:54:02 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEFqXv04761;
	Thu, 14 Nov 2002 10:52:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEFpev04699
	for <rpsec@optimus.ietf.org>; Thu, 14 Nov 2002 10:51:40 -0500
Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22134;
	Thu, 14 Nov 2002 10:49:01 -0500 (EST)
Received: from localhost (ttauber@localhost)
	by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id gAEFpZK21482;
	Thu, 14 Nov 2002 10:51:35 -0500 (EST)
X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs
Date: Thu, 14 Nov 2002 10:51:35 -0500 (EST)
From: Tony Tauber <ttauber@genuity.net>
X-X-Sender: ttauber@mesa.bbnplanet.com
To: agenda@ietf.org
cc: Russ White <riw@cisco.com>, <rpsec@ietf.org>
Message-ID: <Pine.GSO.4.40.0211141036330.7372-100000@mesa.bbnplanet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [RPSEC] RPSEC Agenda for Atlanta (IETF 55)
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Here's the agenda for Atlanta.

Thanks,

Tony

----
Routing Protocol Security Requirements WG (rpsec)

Wednesday, November 20 at 1530-1730
===================================

Chairs: Russ White <riw@cisco.com>
        Tony Tauber <ttauber@genuity.net>

Agenda:

 Agenda Bashing 					5

 Routing Protocols over IPSec (Dave Ward)		20

 Threat Analysis Drafts
	 draft-beard-rpsec-routing-threats-00.txt 	15

	 draft-murphy-threat-00.txt 			15

	 draft-convery-bgpattack-00.txt 		15

	 Discussion of next steps for threat drafts 	10

 S-BGP Workshop - Operator's Impressions (Randy Bush)	10

 so-BGP	(Dave Cook)					15
	 draft-ng-sobgp-bgp-extensions-00.txt
	 draft-white-sobgp-extensions-00.txt


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov 14 14:04:48 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27251
	for <rpsec-archive@odin.ietf.org>; Thu, 14 Nov 2002 14:04:48 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAEJ6v116308
	for rpsec-archive@odin.ietf.org; Thu, 14 Nov 2002 14:06:57 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEJ6vv16305
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 14 Nov 2002 14:06:57 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27223
	for <rpsec-web-archive@ietf.org>; Thu, 14 Nov 2002 14:04:17 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEJ6Ov16275;
	Thu, 14 Nov 2002 14:06:24 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEJ5Qv16233
	for <rpsec@optimus.ietf.org>; Thu, 14 Nov 2002 14:05:26 -0500
Received: from Princeton.EDU (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27163
	for <rpsec@ietf.org>; Thu, 14 Nov 2002 14:02:45 -0500 (EST)
Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65])
	by Princeton.EDU (8.12.6/8.12.6) with ESMTP id gAEJ5KDx011828
	for <rpsec@ietf.org>; Thu, 14 Nov 2002 14:05:20 -0500 (EST)
Received: from Princeton.EDU (mailserver2.Princeton.EDU [128.112.128.25])
	by smtpserver1.Princeton.EDU (8.12.2/8.12.2) with ESMTP id gAEJ5Jjn007840
	for <rpsec@ietf.org>; Thu, 14 Nov 2002 14:05:19 -0500 (EST)
From: "Ioannis C. Avramopoulos" <iavramop@Princeton.EDU>
Received: from mmp02.Princeton.EDU[128.112.129.54] by
 imap2.Princeton.EDU (mshttpd); Thu, 14 Nov 2002 14:05:19 -0500
To: rpsec@ietf.org
Message-ID: <756d9b75ae66.75ae66756d9b@Princeton.EDU>
Date: Thu, 14 Nov 2002 14:05:19 -0500
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.04 (built Oct 21 2002)
MIME-Version: 1.0
Content-Language: en
X-Accept-Language: en
Priority: normal
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [RPSEC] Definition of Routing Protocol - Routing System
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

 Dear Security Researchers,

 is the protection of data packet forwarding a 
 legitimate requirement within this working group?

 Does the term "routing protocol" refer only to the
 acquisition of topological information and the 
 building of forwarding tables? Or it includes
 the data plane as well? Are the terms "routing
 protocol" and "routing system" defined somewhere
 and if not should they be?

 Are "Byzantine Robustness" and "Byzantine
 Detection", as defined in Radia Perlman's thesis,
 legitimate requirements?

 Regards
 Yannis

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov 14 16:33:26 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01740
	for <rpsec-archive@odin.ietf.org>; Thu, 14 Nov 2002 16:33:26 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAELZab26765
	for rpsec-archive@odin.ietf.org; Thu, 14 Nov 2002 16:35:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAELZav26762
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 14 Nov 2002 16:35:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01733
	for <rpsec-web-archive@ietf.org>; Thu, 14 Nov 2002 16:32:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAELZ9v26741;
	Thu, 14 Nov 2002 16:35:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAELYfv26690
	for <rpsec@optimus.ietf.org>; Thu, 14 Nov 2002 16:34:41 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01710
	for <rpsec@ietf.org>; Thu, 14 Nov 2002 16:32:00 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA02555;
	Thu, 14 Nov 2002 16:34:34 -0500 (EST)
Date: Thu, 14 Nov 2002 16:34:34 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: "Ioannis C. Avramopoulos" <iavramop@Princeton.EDU>
cc: rpsec@ietf.org
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
In-Reply-To: <756d9b75ae66.75ae66756d9b@Princeton.EDU>
Message-ID: <Pine.GSO.4.21.0211141623090.29500-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


This working group really only covers the secuiryt of routing,
not forwarding traffic. I think for forwarding traffic, the
general concensus is to encrypt the data flows, through something
like IPsec.

Byzantine robustness for routing would be a valid requirement.

:-)

Russ

On Thu, 14 Nov 2002, Ioannis C. Avramopoulos wrote:

>  Dear Security Researchers,
> 
>  is the protection of data packet forwarding a 
>  legitimate requirement within this working group?
> 
>  Does the term "routing protocol" refer only to the
>  acquisition of topological information and the 
>  building of forwarding tables? Or it includes
>  the data plane as well? Are the terms "routing
>  protocol" and "routing system" defined somewhere
>  and if not should they be?
> 
>  Are "Byzantine Robustness" and "Byzantine
>  Detection", as defined in Radia Perlman's thesis,
>  legitimate requirements?
> 
>  Regards
>  Yannis
> 
> _______________________________________________
> RPSEC mailing list
> RPSEC@ietf.org
> https://www1.ietf.org/mailman/listinfo/rpsec
> 

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov 14 17:26:15 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03155
	for <rpsec-archive@odin.ietf.org>; Thu, 14 Nov 2002 17:26:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAEMSPh30062
	for rpsec-archive@odin.ietf.org; Thu, 14 Nov 2002 17:28:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEMSPv30059
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 14 Nov 2002 17:28:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03138
	for <rpsec-web-archive@ietf.org>; Thu, 14 Nov 2002 17:25:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEMNAv29848;
	Thu, 14 Nov 2002 17:23:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEMMxv29831
	for <rpsec@optimus.ietf.org>; Thu, 14 Nov 2002 17:22:59 -0500
Received: from Princeton.EDU (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03013
	for <rpsec@ietf.org>; Thu, 14 Nov 2002 17:20:18 -0500 (EST)
Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148])
	by Princeton.EDU (8.12.6/8.12.6) with ESMTP id gAEMMpDx022315
	for <rpsec@ietf.org>; Thu, 14 Nov 2002 17:22:52 -0500 (EST)
Received: from Princeton.EDU (mailserver2.Princeton.EDU [128.112.128.25])
	by smtpserver2.Princeton.EDU (8.12.2/8.12.2) with ESMTP id gAEMMkEA020956
	for <rpsec@ietf.org>; Thu, 14 Nov 2002 17:22:46 -0500 (EST)
From: "Ioannis C. Avramopoulos" <iavramop@Princeton.EDU>
Received: from mmp01.Princeton.EDU[128.112.128.133] by
 imap2.Princeton.EDU (mshttpd); Thu, 14 Nov 2002 17:22:46 -0500
To: rpsec@ietf.org
Message-ID: <783187785b35.785b35783187@Princeton.EDU>
Date: Thu, 14 Nov 2002 17:22:46 -0500
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.04 (built Oct 21 2002)
MIME-Version: 1.0
Content-Language: en
Subject: Fwd: Re: [RPSEC] Definition of Routing Protocol - Routing
 System
X-Accept-Language: en
Priority: normal
Content-Type: multipart/mixed; boundary="--219e78ba35b023db"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.
----219e78ba35b023db
Content-Type: message/rfc822
Content-Disposition: inline

Received: from mmp01.Princeton.EDU[128.112.128.133] by
 imap2.Princeton.EDU (mshttpd); Thu, 14 Nov 2002 17:04:39 -0500
From: <iavramop@Princeton.EDU>
To: Russ White <riw@cisco.com>
Message-ID: <77e9c87841d1.7841d177e9c8@Princeton.EDU>
Date: Thu, 14 Nov 2002 17:04:39 -0500
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.04 (built Oct 21 2002)
MIME-Version: 1.0
Content-Language: en
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
X-Accept-Language: en
Priority: normal
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

IPsec does not protect against a subverted router that drops the
traffic it receives. I am wondering why this aspect of routing is not
emphasized in the WG. Is it because it is not within the scope,
or because of its expected overhead?

How is Byzantine robustness for routing defined
(as opposed for example to Byzantine robustness
of the network layer)?

Yannis

----- Original Message -----
From: Russ White <ruwhite@cisco.com>
Date: Thursday, November 14, 2002 4:34 pm
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System

> 
> This working group really only covers the secuiryt of routing,
> not forwarding traffic. I think for forwarding traffic, the
> general concensus is to encrypt the data flows, through something
> like IPsec.
> 
> Byzantine robustness for routing would be a valid requirement.
> 
> :-)
> 
> Russ
> 
> On Thu, 14 Nov 2002, Ioannis C. Avramopoulos wrote:
> 
> >  Dear Security Researchers,
> > 
> >  is the protection of data packet forwarding a 
> >  legitimate requirement within this working group?
> > 
> >  Does the term "routing protocol" refer only to the
> >  acquisition of topological information and the 
> >  building of forwarding tables? Or it includes
> >  the data plane as well? Are the terms "routing
> >  protocol" and "routing system" defined somewhere
> >  and if not should they be?
> > 
> >  Are "Byzantine Robustness" and "Byzantine
> >  Detection", as defined in Radia Perlman's thesis,
> >  legitimate requirements?
> > 
> >  Regards
> >  Yannis
> > 
> > _______________________________________________
> > RPSEC mailing list
> > RPSEC@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rpsec
> > 
> 
> __________________________________
> riw@cisco.com CCIE <>< Grace Alone
> 
> 
> 

----219e78ba35b023db--

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov 14 19:13:20 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09622
	for <rpsec-archive@odin.ietf.org>; Thu, 14 Nov 2002 19:13:20 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAF0FW203469
	for rpsec-archive@odin.ietf.org; Thu, 14 Nov 2002 19:15:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF0FWv03466
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 14 Nov 2002 19:15:32 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09597
	for <rpsec-web-archive@ietf.org>; Thu, 14 Nov 2002 19:12:49 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF0FAv03456;
	Thu, 14 Nov 2002 19:15:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAF0B1v03321
	for <rpsec@optimus.ietf.org>; Thu, 14 Nov 2002 19:11:01 -0500
Received: from Princeton.EDU (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09469
	for <rpsec@ietf.org>; Thu, 14 Nov 2002 19:08:18 -0500 (EST)
Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65])
	by Princeton.EDU (8.12.6/8.12.6) with ESMTP id gAF0ApDx003139;
	Thu, 14 Nov 2002 19:10:51 -0500 (EST)
Received: from Princeton.EDU (mailserver2.Princeton.EDU [128.112.128.25])
	by smtpserver1.Princeton.EDU (8.12.2/8.12.2) with ESMTP id gAF0Aojn022426;
	Thu, 14 Nov 2002 19:10:50 -0500 (EST)
From: "Ioannis C. Avramopoulos" <iavramop@Princeton.EDU>
Received: from mmp02.Princeton.EDU[128.112.129.54] by
 imap2.Princeton.EDU (mshttpd); Thu, 14 Nov 2002 19:10:50 -0500
To: Russ White <riw@cisco.com>
Cc: rpsec@ietf.org
Message-ID: <795b5f7967c4.7967c4795b5f@Princeton.EDU>
Date: Thu, 14 Nov 2002 19:10:50 -0500
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.04 (built Oct 21 2002)
MIME-Version: 1.0
Content-Language: en
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
X-Accept-Language: en
Priority: normal
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


However data packet forwarding may provide feedback to 
topology discovery. As an example the AODV protocol
uses data packets to identify broken links and 
propagate Route Error messages. Route Error messages
are then fed into topological state. My point is that
there is no clear boundary between topology discovery
and data packet forwarding.

Thank you for kind response though.
Yannis


----- Original Message -----
From: Russ White <ruwhite@cisco.com>
Date: Thursday, November 14, 2002 5:49 pm
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System

> 
> > IPsec does not protect against a subverted router that drops
> > the traffic it receives. I am wondering why this aspect of
> > routing is not emphasized in the WG. Is it because it is not
> > within the scope, or because of its expected overhead?
> 
> Because it isn't in scope--we are dealing with building the
> topology, not with forwarding packets.
> 
> > How is Byzantine robustness for routing defined (as opposed
> > for example to Byzantine robustness of the network layer)?
> 
> Bynzantine robustness in the sense of devices injecting false or
> bad information in the routing domain.
> 
> :-)
> 
> Russ
> 
> 
> __________________________________
> riw@cisco.com CCIE <>< Grace Alone
> 
> 
> 

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov 15 14:58:51 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17220
	for <rpsec-archive@odin.ietf.org>; Fri, 15 Nov 2002 14:58:51 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAFK12O11516
	for rpsec-archive@odin.ietf.org; Fri, 15 Nov 2002 15:01:02 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFK12v11513
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 15 Nov 2002 15:01:02 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17199
	for <rpsec-web-archive@ietf.org>; Fri, 15 Nov 2002 14:58:20 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFK0Lv11476;
	Fri, 15 Nov 2002 15:00:22 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFJxTv11413
	for <rpsec@optimus.ietf.org>; Fri, 15 Nov 2002 14:59:29 -0500
Received: from pheriche.sun.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17179
	for <rpsec@ietf.org>; Fri, 15 Nov 2002 14:56:47 -0500 (EST)
Received: from sydney.East.Sun.COM ([129.148.9.16])
	by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08561;
	Fri, 15 Nov 2002 12:59:22 -0700 (MST)
Received: from sr1-ubur-05 (sr1-ubur-05 [129.148.9.84])
	by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id gAFJxMJ19653;
	Fri, 15 Nov 2002 14:59:22 -0500 (EST)
Message-Id: <200211151959.gAFJxMJ19653@sydney.East.Sun.COM>
Date: Fri, 15 Nov 2002 14:59:22 -0500 (EST)
From: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>
Reply-To: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
To: iavramop@Princeton.EDU, riw@cisco.com
Cc: rpsec@ietf.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ZwjrGhNF2fPPTFxXQbVNFg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc 
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Actually, I think that forwarding of data counts as "part of the routing
algorithm", since if we are concerned about a Byzantine failure of a router,
malicious behavior in forwarding can mess things up. For instance,
misforwarding packets and resetting the hop count. Or flooding the
network by generating bogus data. These sorts of things are
not solved by end-to-end encryption/integrity protection of data flows.

So I would have answered Yannis the opposite way on his first question...
that protection of forwarding *should* be a legitimate requirement.
What would NOT be a legitimate requirement is trying to keep routers
from snooping on the data...that would be
handled end-to-end. Modifying cryptographically protected data, although 
detectable end-to-end
would be something we should worry about, I think, because it is the
same as misrouting the data.
It's equivalent, more or less, to having the router drop the data. This
becomes especially annoying (to you) if a router behaves perfectly
well on the calculation of the forwarding tables, and behaves perfectly
well on forwarding everyone else's data, but mangles *your* data.

This even happens sometimes, where some link just doesn't like the
particular sequence of bits in your packet. So the link quality is great...
for everyone else, but for your packet, it never gets through. And
if the router has been maliciously programmed to discriminate against
you...

Firewalls of course do this on purpose...discriminating against some
packets based on whatever the firewall administrator configured.

So to summarize...our goal isn't to have routers calculate wonderful
forwarding tables, but rather to get the data to its destination. :-)

Radia

	From: Russ White <ruwhite@cisco.com>

	
	This working group really only covers the secuiryt of routing,
	not forwarding traffic. I think for forwarding traffic, the
	general concensus is to encrypt the data flows, through something
	like IPsec.
	
	Byzantine robustness for routing would be a valid requirement.
	
	:-)
	
	Russ
	
	On Thu, 14 Nov 2002, Ioannis C. Avramopoulos wrote:
	
	>  Dear Security Researchers,
	> 
	>  is the protection of data packet forwarding a 
	>  legitimate requirement within this working group?
	> 
	>  Does the term "routing protocol" refer only to the
	>  acquisition of topological information and the 
	>  building of forwarding tables? Or it includes
	>  the data plane as well? Are the terms "routing
	>  protocol" and "routing system" defined somewhere
	>  and if not should they be?
	> 
	>  Are "Byzantine Robustness" and "Byzantine
	>  Detection", as defined in Radia Perlman's thesis,
	>  legitimate requirements?
	> 
	>  Regards
	>  Yannis
	> 
	> _______________________________________________
	> 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 mailnull@www1.ietf.org  Fri Nov 15 15:24:25 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18159
	for <rpsec-archive@odin.ietf.org>; Fri, 15 Nov 2002 15:24:25 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAFKQak13849
	for rpsec-archive@odin.ietf.org; Fri, 15 Nov 2002 15:26:36 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFKQav13846
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 15 Nov 2002 15:26:36 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18128
	for <rpsec-web-archive@ietf.org>; Fri, 15 Nov 2002 15:23:54 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFKQFv13816;
	Fri, 15 Nov 2002 15:26:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFKPLv13605
	for <rpsec@optimus.ietf.org>; Fri, 15 Nov 2002 15:25:21 -0500
Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18076
	for <rpsec@ietf.org>; Fri, 15 Nov 2002 15:22:39 -0500 (EST)
Received: from localhost (ttauber@localhost)
	by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id gAFKP4g23874;
	Fri, 15 Nov 2002 15:25:05 -0500 (EST)
X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs
Date: Fri, 15 Nov 2002 15:25:04 -0500 (EST)
From: Tony Tauber <ttauber@genuity.net>
X-X-Sender: ttauber@mesa.bbnplanet.com
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>
cc: iavramop@Princeton.EDU, <riw@cisco.com>, <rpsec@ietf.org>
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
In-Reply-To: <200211151959.gAFJxMJ19653@sydney.East.Sun.COM>
Message-ID: <Pine.GSO.4.40.0211151505280.19351-100000@mesa.bbnplanet.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Fri, 15 Nov 2002, Radia Perlman - Boston Center for Networking wrote:

> So to summarize...our goal isn't to have routers calculate wonderful
> forwarding tables, but rather to get the data to its destination.
> :-)
>
> Radia

I agree and suspect that this kind of distinction dissolves when
considering threats.  The threat isn't really to the protocols but to
the service that the network provides by using those protocols.
In this case, advertising reachability and not delivering on that
promise is clearly one of the threats we're already considering.

My intutition is that keeping our eyes on the pragmatic ball will
help greatly in steering through inevitable semantic distractions.

Tony

> 	On Thu, 14 Nov 2002, Ioannis C. Avramopoulos wrote:
>
> 	>  Dear Security Researchers,
> 	>
> 	>  is the protection of data packet forwarding a
> 	>  legitimate requirement within this working group?
> 	>
> 	>  Does the term "routing protocol" refer only to the
> 	>  acquisition of topological information and the
> 	>  building of forwarding tables? Or it includes
> 	>  the data plane as well? Are the terms "routing
> 	>  protocol" and "routing system" defined somewhere
> 	>  and if not should they be?


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov 15 15:34:22 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18393
	for <rpsec-archive@odin.ietf.org>; Fri, 15 Nov 2002 15:34:22 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAFKaYJ14247
	for rpsec-archive@odin.ietf.org; Fri, 15 Nov 2002 15:36:34 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFKaYv14244
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 15 Nov 2002 15:36:34 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18386
	for <rpsec-web-archive@ietf.org>; Fri, 15 Nov 2002 15:33:51 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFKaFv14235;
	Fri, 15 Nov 2002 15:36:15 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFKZRv14207
	for <rpsec@optimus.ietf.org>; Fri, 15 Nov 2002 15:35:27 -0500
Received: from cisco.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18376
	for <rpsec@ietf.org>; Fri, 15 Nov 2002 15:32:45 -0500 (EST)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA19758;
	Fri, 15 Nov 2002 15:35:17 -0500 (EST)
Date: Fri, 15 Nov 2002 15:35:17 -0500 (EST)
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Tony Tauber <ttauber@genuity.net>
cc: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>,
        iavramop@Princeton.EDU, rpsec@ietf.org
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
In-Reply-To: <Pine.GSO.4.40.0211151505280.19351-100000@mesa.bbnplanet.com>
Message-ID: <Pine.GSO.4.21.0211151531180.29926-100000@ruwhite-u10.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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>


> > So to summarize...our goal isn't to have routers calculate wonderful
> > forwarding tables, but rather to get the data to its destination.
> > :-)
> >
> > Radia
> 
> I agree and suspect that this kind of distinction dissolves
> when considering threats.  The threat isn't really to the
> protocols but to the service that the network provides by
> using those protocols. In this case, advertising reachability
> and not delivering on that promise is clearly one of the
> threats we're already considering.

The problem is that routing is a hop by hop affair.... Just
because you've secured the generation of a routing table doesn't
mean you've secured the forwarding of the packet. If we are to go
further than being able to verify/validate the routing
information, and into validating the forwarding information, and
forwarding behaviour, of each device in a network, the problem
becomes much more complex, and, I would argue, outside the pervue
of the routing group at all, most likely.

You would then be delaing with how to secure the devices
themselves against having false routing information manually
installed on them, for instance, and how to prevent the
forwarding table from being attacked through icmp redirects,
etc. This, then, would take us into the territory of passwords on
devices, etc.

Do we really want to go there?

:-)

Russ

__________________________________
riw@cisco.com CCIE <>< Grace Alone


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov 15 16:30:41 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19877
	for <rpsec-archive@odin.ietf.org>; Fri, 15 Nov 2002 16:30:41 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAFLWq217843
	for rpsec-archive@odin.ietf.org; Fri, 15 Nov 2002 16:32:52 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFLWpv17840
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 15 Nov 2002 16:32:51 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19833
	for <rpsec-web-archive@ietf.org>; Fri, 15 Nov 2002 16:30:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFLWHv17635;
	Fri, 15 Nov 2002 16:32:17 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFKuhv15649
	for <rpsec@optimus.ietf.org>; Fri, 15 Nov 2002 15:56:43 -0500
Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18763
	for <rpsec@ietf.org>; Fri, 15 Nov 2002 15:54:02 -0500 (EST)
Received: from sydney.East.Sun.COM ([129.148.9.16])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07837
	for <rpsec@ietf.org>; Fri, 15 Nov 2002 12:56:36 -0800 (PST)
Received: from sr1-ubur-05 (sr1-ubur-05 [129.148.9.84])
	by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id gAFKuaJ26988
	for <rpsec@ietf.org>; Fri, 15 Nov 2002 15:56:36 -0500 (EST)
Message-Id: <200211152056.gAFKuaJ26988@sydney.East.Sun.COM>
Date: Fri, 15 Nov 2002 15:56:36 -0500 (EST)
From: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>
Reply-To: Radia Perlman - Boston Center for Networking <Radia.Perlman@Sun.COM>
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
To: rpsec@ietf.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: FHQ/xCKCVLmOsnIO/LeZMg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc 
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

Re: Russ's note, below

It's not so intractable. That's what my thesis did..how to get
the data there even if routers are being really obnoxious.
It was fairly straightforward to do with link state routing,
and source specified routing (at least as a backup if the "default"
computed route doesn't work for you). But without that, I couldn't
figure out how to do it (which doesn't mean it can't be done of course :-)  )

Radia
	
	The problem is that routing is a hop by hop affair.... Just
	because you've secured the generation of a routing table doesn't
	mean you've secured the forwarding of the packet. If we are to go
	further than being able to verify/validate the routing
	information, and into validating the forwarding information, and
	forwarding behaviour, of each device in a network, the problem
	becomes much more complex, and, I would argue, outside the pervue
	of the routing group at all, most likely.
	
	You would then be delaing with how to secure the devices
	themselves against having false routing information manually
	installed on them, for instance, and how to prevent the
	forwarding table from being attacked through icmp redirects,
	etc. This, then, would take us into the territory of passwords on
	devices, etc.
	
	Do we really want to go there?
	
	:-)
	
	Russ
	

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov 15 16:30:46 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19890
	for <rpsec-archive@odin.ietf.org>; Fri, 15 Nov 2002 16:30:46 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAFLWu317879
	for rpsec-archive@odin.ietf.org; Fri, 15 Nov 2002 16:32:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFLWuv17876
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 15 Nov 2002 16:32:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19842
	for <rpsec-web-archive@ietf.org>; Fri, 15 Nov 2002 16:30:15 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFLWSv17782;
	Fri, 15 Nov 2002 16:32:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFL8Cv16698
	for <rpsec@optimus.ietf.org>; Fri, 15 Nov 2002 16:08:12 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19091
	for <rpsec@ietf.org>; Fri, 15 Nov 2002 16:05:32 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id QAA12531; Fri, 15 Nov 2002 16:08:13 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma012442; Fri, 15 Nov 02 16:08:00 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gAFL7qC00611;
	Fri, 15 Nov 2002 16:07:52 -0500 (EST)
Date: Fri, 15 Nov 2002 16:07:52 -0500 (EST)
Message-Id: <200211152107.gAFL7qC00611@raven.gw.tislabs.com>
To: Radia.Perlman@sun.com, ttauber@genuity.net
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
Cc: iavramop@Princeton.EDU, riw@cisco.com, rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>In this case, advertising reachability and not delivering on that
>promise is clearly one of the threats we're already considering.

What would you envision being the requirement that we state to the
routing protocol designers?  "Whatever you do, make sure the router
follows the forwarding implied by the advertised reachability"?
Can you see the idr group taking that on as an additional requirement for the
next version of BGP?  Should DSR be rejected until it can meet that
requirement wrt the source routes it determines?

If this requirement is not a requirement the routing protocol designers
have to meet, whose responsibility is it?


--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov 15 16:30:46 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19895
	for <rpsec-archive@odin.ietf.org>; Fri, 15 Nov 2002 16:30:46 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAFLWu617894
	for rpsec-archive@odin.ietf.org; Fri, 15 Nov 2002 16:32:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFLWuv17891
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 15 Nov 2002 16:32:56 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19844
	for <rpsec-web-archive@ietf.org>; Fri, 15 Nov 2002 16:30:15 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFLWQv17718;
	Fri, 15 Nov 2002 16:32:26 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFL1wv15891
	for <rpsec@optimus.ietf.org>; Fri, 15 Nov 2002 16:01:58 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18926
	for <rpsec@ietf.org>; Fri, 15 Nov 2002 15:59:17 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id QAA12135; Fri, 15 Nov 2002 16:01:58 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma012095; Fri, 15 Nov 02 16:01:44 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gAFL1ZM00298;
	Fri, 15 Nov 2002 16:01:35 -0500 (EST)
Date: Fri, 15 Nov 2002 16:01:35 -0500 (EST)
Message-Id: <200211152101.gAFL1ZM00298@raven.gw.tislabs.com>
To: Radia.Perlman@sun.com, iavramop@Princeton.EDU, riw@cisco.com
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>Actually, I think that forwarding of data counts as "part of the routing
>algorithm", since if we are concerned about a Byzantine failure of a router,
>malicious behavior in forwarding can mess things up.

First, errors in forwarding have a much more localized effect than
errors in the routing protocol distribution of topology information.
One router can only mis-forward packets that come to it specifically.
One router can affect the flow of data traffic over a very wide area
if it makes errors in the routing protocol.

Second, (here I am on my soap box again), there's not a whole lot
we can advise routing protocol designers about the security of their
routing protocol that would prevent the routers from mis-forwarding
packets.  It's not a routing *protocol* security issue.

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Fri Nov 15 17:45:29 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22419
	for <rpsec-archive@odin.ietf.org>; Fri, 15 Nov 2002 17:45:29 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAFMleu23841
	for rpsec-archive@odin.ietf.org; Fri, 15 Nov 2002 17:47:40 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFMlev23838
	for <rpsec-web-archive@optimus.ietf.org>; Fri, 15 Nov 2002 17:47:40 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22415
	for <rpsec-web-archive@ietf.org>; Fri, 15 Nov 2002 17:44:58 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFMlGv23806;
	Fri, 15 Nov 2002 17:47:16 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFMemv23522
	for <rpsec@optimus.ietf.org>; Fri, 15 Nov 2002 17:40:48 -0500
Received: from sequoia.muada.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22227
	for <rpsec@ietf.org>; Fri, 15 Nov 2002 17:38:05 -0500 (EST)
Received: from localhost (iljitsch@localhost)
	by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gAFMeBM81306;
	Fri, 15 Nov 2002 23:40:11 +0100 (CET)
	(envelope-from iljitsch@muada.com)
Date: Fri, 15 Nov 2002 23:40:11 +0100 (CET)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>
cc: <rpsec@ietf.org>
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
In-Reply-To: <200211152056.gAFKuaJ26988@sydney.East.Sun.COM>
Message-ID: <20021115233322.M81174-100000@sequoia.muada.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

On Fri, 15 Nov 2002, Radia Perlman - Boston Center for Networking wrote:

> It's not so intractable. That's what my thesis did..how to get
> the data there even if routers are being really obnoxious.
> It was fairly straightforward to do with link state routing,
> and source specified routing (at least as a backup if the "default"
> computed route doesn't work for you). But without that, I couldn't
> figure out how to do it (which doesn't mean it can't be done of course :-)  )

As a BGP consultant, this is (part of) what I do for a living. Traffic
flows over a path that has an undesirable property. For instance, two
large ASes in the middle find it easier to peer on another continent.
For outgoing traffic, this is fairly easy to fix by lowering the
preference for a route if a certain combination of ASes shows up in the
path. For incoming traffic, this is harder. Fortunately, many of the
larger transit networks give their customers the option of influencing
how their routes are announced further upstream using BGP communities.

It would be better if there was a protocol to do this automatically,
though...

Iljitsch

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Sat Nov 16 14:24:30 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22984
	for <rpsec-archive@odin.ietf.org>; Sat, 16 Nov 2002 14:24:30 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAGJQfJ22808
	for rpsec-archive@odin.ietf.org; Sat, 16 Nov 2002 14:26:41 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAGJQfv22805
	for <rpsec-web-archive@optimus.ietf.org>; Sat, 16 Nov 2002 14:26:41 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22981
	for <rpsec-web-archive@ietf.org>; Sat, 16 Nov 2002 14:23:59 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAGJNCv22722;
	Sat, 16 Nov 2002 14:23:12 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAGJGov22566
	for <rpsec@optimus.ietf.org>; Sat, 16 Nov 2002 14:16:50 -0500
Received: from Princeton.EDU (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22827
	for <rpsec@ietf.org>; Sat, 16 Nov 2002 14:14:08 -0500 (EST)
Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65])
	by Princeton.EDU (8.12.6/8.12.6) with ESMTP id gAGJGhDx004781;
	Sat, 16 Nov 2002 14:16:44 -0500 (EST)
Received: from Princeton.EDU (mailserver2.Princeton.EDU [128.112.128.25])
	by smtpserver1.Princeton.EDU (8.12.2/8.12.2) with ESMTP id gAGJGhjn019672;
	Sat, 16 Nov 2002 14:16:43 -0500 (EST)
From: "Ioannis C. Avramopoulos" <iavramop@Princeton.EDU>
Received: from mmp01.Princeton.EDU[128.112.128.133] by
 imap2.Princeton.EDU (mshttpd); Sat, 16 Nov 2002 14:16:43 -0500
To: sandy@tislabs.com
Cc: rpsec@ietf.org
Message-ID: <8631c0861ca7.861ca78631c0@Princeton.EDU>
Date: Sat, 16 Nov 2002 14:16:43 -0500
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.04 (built Oct 21 2002)
MIME-Version: 1.0
Content-Language: en
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
X-Accept-Language: en
Priority: normal
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


> 
> First, errors in forwarding have a much more localized effect than
> errors in the routing protocol distribution of topology information.
> One router can only mis-forward packets that come to it specifically.
> One router can affect the flow of data traffic over a very wide area
> if it makes errors in the routing protocol.

There is a trade-off between automatic configuration and security.
If routers do topology discovery rather than be configured with a map
then subverted routers can inject a lot of false connectivity even
if routing updates are cryptographically protected. One possibility is
to prune false connectivity by using data packets. 

> 
> Second, (here I am on my soap box again), there's not a whole lot
> we can advise routing protocol designers about the security of their
> routing protocol that would prevent the routers from mis-forwarding
> packets.  It's not a routing *protocol* security issue.
 
The requirement can be to either be able to deliver packets despite
having routers that mis-forward packets and possibly detect those
routers.

Another requirement might be to provide different levels of assurance.

Yannis

PhD student
Electrical Engineering Department
Princeton University


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Sat Nov 16 14:26:14 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23007
	for <rpsec-archive@odin.ietf.org>; Sat, 16 Nov 2002 14:26:14 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAGJSP522853
	for rpsec-archive@odin.ietf.org; Sat, 16 Nov 2002 14:28:25 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAGJSPv22850
	for <rpsec-web-archive@optimus.ietf.org>; Sat, 16 Nov 2002 14:28:25 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23003
	for <rpsec-web-archive@ietf.org>; Sat, 16 Nov 2002 14:25:43 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAGJP1v22785;
	Sat, 16 Nov 2002 14:25:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAGJORv22749
	for <rpsec@optimus.ietf.org>; Sat, 16 Nov 2002 14:24:27 -0500
Received: from Princeton.EDU (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22923
	for <rpsec@ietf.org>; Sat, 16 Nov 2002 14:21:45 -0500 (EST)
Received: from smtpserver1.Princeton.EDU (smtpserver1.Princeton.EDU [128.112.129.65])
	by Princeton.EDU (8.12.6/8.12.6) with ESMTP id gAGJOLDx007566;
	Sat, 16 Nov 2002 14:24:21 -0500 (EST)
Received: from Princeton.EDU (mailserver2.Princeton.EDU [128.112.128.25])
	by smtpserver1.Princeton.EDU (8.12.2/8.12.2) with ESMTP id gAGJOLjn021232;
	Sat, 16 Nov 2002 14:24:21 -0500 (EST)
From: "Ioannis C. Avramopoulos" <iavramop@Princeton.EDU>
Received: from mmp01.Princeton.EDU[128.112.128.133] by
 imap2.Princeton.EDU (mshttpd); Sat, 16 Nov 2002 14:24:21 -0500
To: sandy@tislabs.com
Cc: rpsec@ietf.org
Message-ID: <86589e861cd1.861cd186589e@Princeton.EDU>
Date: Sat, 16 Nov 2002 14:24:21 -0500
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.04 (built Oct 21 2002)
MIME-Version: 1.0
Content-Language: en
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
X-Accept-Language: en
Priority: normal
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


The network can provide different levels of security. At one extreme
there can be no security. At the other extreme it will deliver packets
as long as a non-faulty path exists. Consumers of the infrastructure
should be able to choose. Performance is the driving factor for those
different levels.

> What would you envision being the requirement that we state to the
> routing protocol designers?  "Whatever you do, make sure the router
> follows the forwarding implied by the advertised reachability"?
> Can you see the idr group taking that on as an additional 
> requirement for the
> next version of BGP?  Should DSR be rejected until it can meet that
> requirement wrt the source routes it determines?
> 
> If this requirement is not a requirement the routing protocol 
> designershave to meet, whose responsibility is it?
> 

Yannis

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Sun Nov 17 15:36:53 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24938
	for <rpsec-archive@odin.ietf.org>; Sun, 17 Nov 2002 15:36:53 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAHKd5N03500
	for rpsec-archive@odin.ietf.org; Sun, 17 Nov 2002 15:39:05 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHKd5v03497
	for <rpsec-web-archive@optimus.ietf.org>; Sun, 17 Nov 2002 15:39:05 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24932
	for <rpsec-web-archive@ietf.org>; Sun, 17 Nov 2002 15:36:22 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHKcNv03456;
	Sun, 17 Nov 2002 15:38:23 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHKb0v02836
	for <rpsec@optimus.ietf.org>; Sun, 17 Nov 2002 15:37:00 -0500
Received: from sentry.gw.tislabs.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24911
	for <rpsec@ietf.org>; Sun, 17 Nov 2002 15:34:16 -0500 (EST)
From: sandy@tislabs.com
Received: by sentry.gw.tislabs.com; id PAA02718; Sun, 17 Nov 2002 15:37:00 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5)
	id xma002682; Sun, 17 Nov 02 15:36:57 -0500
Received: (from sandy@localhost)
	by raven.gw.tislabs.com (8.11.6/8.11.6) id gAHKamo22909;
	Sun, 17 Nov 2002 15:36:48 -0500 (EST)
Date: Sun, 17 Nov 2002 15:36:48 -0500 (EST)
Message-Id: <200211172036.gAHKamo22909@raven.gw.tislabs.com>
To: iavramop@Princeton.EDU, sandy@tislabs.com
Subject: Re: [RPSEC] Definition of Routing Protocol - Routing System
Cc: rpsec@ietf.org
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

>Consumers of the infrastructure
>should be able to choose. 

Trouble is, this is kind of like public health matters between countries.
If one country decides not to immunize its citizens, then the countries
around have to keep facilities in place for dealing with outbreaks.

Routing security decisions affect not only the ISP making them but the
ISP's that peer (or not).

--Sandy
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Tue Nov 19 17:10:06 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18704
	for <rpsec-archive@odin.ietf.org>; Tue, 19 Nov 2002 17:10:06 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAJMCKi19607
	for rpsec-archive@odin.ietf.org; Tue, 19 Nov 2002 17:12:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAJMCKv19604
	for <rpsec-web-archive@optimus.ietf.org>; Tue, 19 Nov 2002 17:12:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18688
	for <rpsec-web-archive@ietf.org>; Tue, 19 Nov 2002 17:09:35 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAJMBRv19569;
	Tue, 19 Nov 2002 17:11:27 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAJMB0v19544
	for <rpsec@optimus.ietf.org>; Tue, 19 Nov 2002 17:11:00 -0500
Received: from gto-mailer1.bbn.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18640
	for <rpsec@ietf.org>; Tue, 19 Nov 2002 17:08:10 -0500 (EST)
Received: from [204.42.67.13] (SSH.BBN.COM [192.1.50.70])
	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10900;
	Tue, 19 Nov 2002 17:10:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05111a00ba000b135995@[128.33.238.95]>
In-Reply-To: 
 <Pine.GSO.4.21.0211122026490.28369-100000@ruwhite-u10.cisco.com>
References: 
 <Pine.GSO.4.21.0211122026490.28369-100000@ruwhite-u10.cisco.com>
Date: Tue, 19 Nov 2002 17:11:16 -0500
To: Russ White <riw@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: [RPSEC] Re: Potential Requirements New Thread
Cc: Dennis Beard <beardd@nortelnetworks.com>, rpsec@ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>

At 8:30 PM -0500 11/12/02, Russ White wrote:
>  > Let's remain with a charter that deals with security of
>>  routing protocols and not the routing system per se.  Having
>>  said that, can we list specifically what is considered
>>  "protocol" and not discuss "system"?  Such a list would
>>  reinforce our charter statement.  These specifics can be
>>  shown to the WG with a proviso that our charter would be
>>  modified to clarify what we mean by routing protocol.
>
>>  Start the list here as the previous thread is getting too long.
>
>So, I'll use entity here, since I don't think that a "router" is
>a good term for this purpose--an entity could actually be a san
>network within the network, a redistribution router representing
>and entire network, an AS, or a single router.... Etc.
>
>-- The ability to verify that the entity advertising a particular
>destination as reachable is actually authorized to advertise that
>destination.
>
>-- The ability to verify that the entity claiming to be
>advertising a particular piece of information is actually the
>entity which is advertising it.
>
>-- The ability to verify the path the update has taken.
>
>Note there is a major problem with this last one--in that the
>path an update takes is no necessarily the path the traffic will
>take. In the end, after looking at this particular issue for a
>while, I'm not so certain that verifying the path of a routing
>update, particularly in a vector based protocol, is all that
>useful....

I also don't see why this is a requirement. Can anyone explain what 
fundamental routing property this requirement supports? Is it 
generic, or specific to a subset of routing protocols?

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 20 17:57:18 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04204
	for <rpsec-archive@odin.ietf.org>; Wed, 20 Nov 2002 17:57:17 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAKMxX622446
	for rpsec-archive@odin.ietf.org; Wed, 20 Nov 2002 17:59:33 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKMxXv22443
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 20 Nov 2002 17:59:33 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04174
	for <rpsec-web-archive@ietf.org>; Wed, 20 Nov 2002 17:56:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKMwtv22406;
	Wed, 20 Nov 2002 17:58:56 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAKMtHv22062
	for <rpsec@optimus.ietf.org>; Wed, 20 Nov 2002 17:55:17 -0500
Received: from shonan.sfc.wide.ad.jp (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04080
	for <rpsec@ietf.org>; Wed, 20 Nov 2002 17:52:31 -0500 (EST)
Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89])
	by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id AFF5C5D03A
	for <rpsec@ietf.org>; Thu, 21 Nov 2002 07:55:09 +0900 (JST)
Date: Thu, 21 Nov 2002 07:55:09 +0900 (JST)
Message-Id: <20021121.075509.39027618.yasu@sfc.wide.ad.jp>
To: rpsec@ietf.org
From: Yasuhiro Ohara <yasu@sfc.wide.ad.jp>
X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [RPSEC] (no subject)
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


The comment I made in today's meeting included some mistakes.

I said "OSPF wg seems to reject the congestion control draft" was
wrong, correct is "OSPFwg seems to reject the scalability
(and flooding optimizations) draft *to be included in WG charter*.

Big difference ;p) forgive me it's my language problem.

regards,
yasu

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Thu Nov 21 13:13:15 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13469
	for <rpsec-archive@odin.ietf.org>; Thu, 21 Nov 2002 13:13:15 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gALIFSA03802
	for rpsec-archive@odin.ietf.org; Thu, 21 Nov 2002 13:15:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALIFSv03799
	for <rpsec-web-archive@optimus.ietf.org>; Thu, 21 Nov 2002 13:15:28 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13421
	for <rpsec-web-archive@ietf.org>; Thu, 21 Nov 2002 13:12:44 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALIF7v03782;
	Thu, 21 Nov 2002 13:15:08 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALIEIv03715
	for <rpsec@optimus.ietf.org>; Thu, 21 Nov 2002 13:14:18 -0500
Received: from shonan.sfc.wide.ad.jp (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13337
	for <rpsec@ietf.org>; Thu, 21 Nov 2002 13:11:18 -0500 (EST)
Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89])
	by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 47DCF5D018
	for <rpsec@ietf.org>; Fri, 22 Nov 2002 03:13:57 +0900 (JST)
Date: Fri, 22 Nov 2002 03:13:56 +0900 (JST)
Message-Id: <20021122.031356.123560822.yasu@sfc.wide.ad.jp>
To: rpsec@ietf.org
Subject: Re: [RPSEC] (no subject)
From: Yasuhiro Ohara <yasu@sfc.wide.ad.jp>
In-Reply-To: <20021121.075509.39027618.yasu@sfc.wide.ad.jp>
References: <20021121.075509.39027618.yasu@sfc.wide.ad.jp>
X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Vishwas kindly pointed me out that scalability draft is in OSPF
charter already.

All I want to say is that it's unique if we going to save the case
where the root cause is inefficiency of implementation in this RPSEC
wg, and I think it is good.

regards,
yasu

yasu> 
yasu> The comment I made in today's meeting included some mistakes.
yasu> 
yasu> I said "OSPF wg seems to reject the congestion control draft" was
yasu> wrong, correct is "OSPFwg seems to reject the scalability
yasu> (and flooding optimizations) draft *to be included in WG charter*.
yasu> 
yasu> Big difference ;p) forgive me it's my language problem.
yasu> 
yasu> regards,
yasu> yasu
yasu> 
yasu> _______________________________________________
yasu> RPSEC mailing list
yasu> RPSEC@ietf.org
yasu> https://www1.ietf.org/mailman/listinfo/rpsec
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec



From mailnull@www1.ietf.org  Wed Nov 27 04:12:56 2002
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04044
	for <rpsec-archive@odin.ietf.org>; Wed, 27 Nov 2002 04:12:56 -0500 (EST)
Received: (from mailnull@localhost)
	by www1.ietf.org (8.11.6/8.11.6) id gAR9FKw10495
	for rpsec-archive@odin.ietf.org; Wed, 27 Nov 2002 04:15:20 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR9FKv10492
	for <rpsec-web-archive@optimus.ietf.org>; Wed, 27 Nov 2002 04:15:20 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04038
	for <rpsec-web-archive@ietf.org>; Wed, 27 Nov 2002 04:12:25 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR9ESv10468;
	Wed, 27 Nov 2002 04:14:28 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR9Dxv10440
	for <rpsec@optimus.ietf.org>; Wed, 27 Nov 2002 04:13:59 -0500
Received: from gawab.com (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04021
	for <rpsec@ietf.org>; Wed, 27 Nov 2002 04:11:03 -0500 (EST)
Received: (qmail 83292 invoked by uid 1004); 27 Nov 2002 08:38:29 -0000
Message-ID: <20021127083829.83291.qmail@gawab.com>
From: "Mohammed Hassan" <elgazzar@islamway.net>
To: "Routing Protocol Security" <rpsec@ietf.org>
Date: Wed, 27 Nov 2002 08:38:28 GMT
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [RPSEC] Research
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: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements  <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>,
	<mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


<HTML><DIV class=bgcolor STYLE="background-color: ;"><DIV>
<DIV>Dear researchers;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
My name is Mohammed Hassan. I'm a postgraduate student at the
faculty of computers and information, Computer Science
Department. I'm going to make the postgraduate research (Master
Degree) in the Network Security "ALLAH willing". I have been
refered to you as researchers in the Network Security (Routing
Protocol). I'm searching for a topic for the master. So,
<EM><STRONG>could you recommend me a hot topic for the master
degree?</STRONG></EM></DIV>
<DIV>&nbsp;</DIV>
<DIV>Mohammed El-Gazzar</DIV></DIV></DIV></HTML>
__________________________<br><br>Visit IslamWay Radio
Online<br>http://www.islamway.com<br>--------------------------------------<br>Get
your free email
@ISLAMWAY.NET<br>http://bareedy.islamway.com<br>-> 15 Mbytes
free space<br>-> POP & SMTP support<br>-> Full Arabic Support
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec