From rpsec-bounces@ietf.org Sat Oct 01 02:26:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELap8-0003DX-EF; Sat, 01 Oct 2005 02:26:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELap3-0003DS-VM for rpsec@megatron.ietf.org; Sat, 01 Oct 2005 02:26:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26544 for ; Sat, 1 Oct 2005 02:26:12 -0400 (EDT) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELax3-0003DA-WA for rpsec@ietf.org; Sat, 01 Oct 2005 02:34:31 -0400 Received: from [84.56.245.65] (helo=[192.168.0.104]) by mxintern.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1ELap1-0001m1-Dv; Sat, 01 Oct 2005 08:26:11 +0200 Message-ID: <433E2BDA.6000202@schlund.net> Date: Sat, 01 Oct 2005 08:25:30 +0200 From: Stefan Mink User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Tony Li Subject: Re: [RPSEC] Basis of Requirements? References: <200509281238.j8SCc438011883@tislabs.com> <433A9118.3020808@cisco.com> <337CB25A-5FD5-4A66-9533-BB3BF85A5448@tony.li> <18D2DBF4-F162-4811-B8A2-F94513DA1F5B@tony.li> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Warning: 84.56.245.65 is listed at dialup.bl.kundenserver.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Hi Tony, Tony Li wrote: > I agree that we can devote some resources to protecting the control > plane. In fact, we must, otherwise we can make no progress at all, as > one subsystem must be in advance of the other. However, just as with > your vault door analogy, we should not be installing 3ft. of titanium on > the front door at this point: it's not cost effective. I would welcome > a solid core door and Schlage lock. That would be a cost that is > proportional to the threat that will be directed to the control plane. > If we have other resources at our disposal, we should focus them on the > forwarding plane. I think its much more important to secure the control plane than the forwarding plane, as attacks involving the forwarding plane are locally: I can only the forwarding plane of *my* devices directly; if I want to temper with other peoples forwarding planes, I have to attack control plane or hack their systems to get "local" access :] We will never get to the point that we can keep people from messing around with their networks, but we need to give the neighboring networks means, to detect this: this is probably only possible by comparing ongoings on the forwarding plane with the status of the control plane. The result is: we need to first secure the control plane... Concerning the 3ft titanium front door I agree: we must not only secure origin authorization (front door) but also redistribution authorization (backdoor) ;) tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Oct 01 06:47:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELetX-0004Er-Tp; Sat, 01 Oct 2005 06:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELetV-0004Dg-Gr for rpsec@megatron.ietf.org; Sat, 01 Oct 2005 06:47:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25644 for ; Sat, 1 Oct 2005 06:47:02 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELf1X-0002L1-KQ for rpsec@ietf.org; Sat, 01 Oct 2005 06:55:24 -0400 Received: from pc6 (1Cust168.tnt4.lnd4.gbr.da.uu.net [62.188.133.168]) by blaster.systems.pipex.net (Postfix) with SMTP id 7462EE0000DA; Sat, 1 Oct 2005 11:46:44 +0100 (BST) Message-ID: <001e01c5c66c$f536bce0$0601a8c0@pc6> From: "Tom Petch" To: "Tony Li" , "Tony Tauber" References: <43390B42.2090101@cisco.com><4339673A.9070802@cisco.com> <050901c5c5ca$f0dce040$0601a8c0@pc6> <433D60F6.5000903@cisco.com> <1371150831.20050930122912@psg.com> <8DA84182-F285-4F20-B51B-875A0D3D652B@tony.li> Date: Sat, 1 Oct 2005 11:46:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org Subject: [RPSEC] Scope was Re: Please vote X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org I was fishing for something more than a change from RFC1771 to RFC4271. Have the editors actually read the later BGP specification and used it in this draft or is the draft based on BGP as specified in RFC1771? The reference to RFC1771 suggested the latter to me, in which case just changing the reference I do not see as enough. Tom Petch ----- Original Message ----- From: "Tony Li" To: "Alex Zinin" Cc: "Russ White" ; ; "Tony Tauber" ; "Tom Petch" Sent: Friday, September 30, 2005 10:20 PM Subject: Re: [RPSEC] Re: Please vote > > On Sep 30, 2005, at 12:29 PM, Alex Zinin wrote: > > > > > Russ wrote: > > > >> The new draft is a valid point, but I believe this would be > >> updated in > >> the iesg process, so we could give the current bgp draft a chance to > >> become rfc'd before referencing it. Maybe Alex or Bill would have > >> more > >> to say on the process. > >> > > > > The BGP spec update is on its way out of the RFC-Ed queue--we got a > > msg > > from them yesterday asking about RFC number preferences. You can > > either > > wait, or put "RFC ????" in the refs and it'll be fixed during the RFC > > editor process. > > > The update will be RFC 4271. > > Tony > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Oct 01 13:11:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELktA-00008c-G5; Sat, 01 Oct 2005 13:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELkt8-00007J-Bb for rpsec@megatron.ietf.org; Sat, 01 Oct 2005 13:11:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10607 for ; Sat, 1 Oct 2005 13:11:02 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELl1E-0002yY-4o for rpsec@ietf.org; Sat, 01 Oct 2005 13:19:29 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 01 Oct 2005 10:10:56 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,164,1125903600"; d="scan'208"; a="12037263:sNHT23375120" Received: from russpc (rtp-vpn4-321.cisco.com [10.82.209.65]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j91HApT7010278; Sat, 1 Oct 2005 13:10:54 -0400 (EDT) Received: from [10.82.209.65] by russpc (PGP Universal service); Sat, 01 Oct 2005 13:10:53 -0500 X-PGP-Universal: processed; by russpc on Sat, 01 Oct 2005 13:10:53 -0500 Message-ID: <433EC315.9030406@cisco.com> Date: Sat, 01 Oct 2005 13:10:45 -0400 From: Russ White User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Petch Subject: Re: [RPSEC] Scope was Re: Please vote References: <43390B42.2090101@cisco.com><4339673A.9070802@cisco.com> <050901c5c5ca$f0dce040$0601a8c0@pc6> <433D60F6.5000903@cisco.com> <1371150831.20050930122912@psg.com> <8DA84182-F285-4F20-B51B-875A0D3D652B@tony.li> <001e01c5c66c$f536bce0$0601a8c0@pc6> In-Reply-To: <001e01c5c66c$f536bce0$0601a8c0@pc6> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The current draft is based on the current BGP specification, not on the older one. It's generally easier to reference an RFC than a draft, and since the new version was already making it's way through, it just seemed easier to reference the older draft, and switch to the new one, than to reference the draft, and then switch to the RFC number when it was given a number. I hope that makes sense. :-) Russ Tom Petch wrote: > I was fishing for something more than a change from RFC1771 to RFC4271. Have > the editors actually read the later BGP specification and used it in this draft > or is the draft based on BGP as specified in RFC1771? > > The reference to RFC1771 suggested the latter to me, in which case just changing > the reference I do not see as enough. > > Tom Petch > > ----- Original Message ----- > From: "Tony Li" > To: "Alex Zinin" > Cc: "Russ White" ; ; "Tony Tauber" > ; "Tom Petch" > Sent: Friday, September 30, 2005 10:20 PM > Subject: Re: [RPSEC] Re: Please vote > > > >>On Sep 30, 2005, at 12:29 PM, Alex Zinin wrote: >> >> >>>Russ wrote: >>> >>> >>>>The new draft is a valid point, but I believe this would be >>>>updated in >>>>the iesg process, so we could give the current bgp draft a chance to >>>>become rfc'd before referencing it. Maybe Alex or Bill would have >>>>more >>>>to say on the process. >>>> >>> >>>The BGP spec update is on its way out of the RFC-Ed queue--we got a >>>msg >>>from them yesterday asking about RFC number preferences. You can >>>either >>>wait, or put "RFC ????" in the refs and it'll be fixed during the RFC >>>editor process. >> >> >>The update will be RFC 4271. >> >>Tony >> > > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBQz7DHREdu7FIVPTkEQIKPwCg6mAxaC00ByFPTcttfHOIRD1k8jgAoOMK beoCCb0/py2QcbSr31MhXGA0 =9u4H -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Oct 01 15:20:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmun-0006N9-1H; Sat, 01 Oct 2005 15:20:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmul-0006N4-Fi for rpsec@megatron.ietf.org; Sat, 01 Oct 2005 15:20:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15708 for ; Sat, 1 Oct 2005 15:20:51 -0400 (EDT) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19WnCirdg50+7QLLt1cdHOJ8xpc4oPXaDE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELn2r-0005r6-6p for rpsec@ietf.org; Sat, 01 Oct 2005 15:29:19 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j91JKa13004856; Sat, 1 Oct 2005 20:20:39 +0100 Date: Sat, 1 Oct 2005 20:20:36 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Stefan Mink Subject: Re: [RPSEC] Basis of Requirements? In-Reply-To: <433E2BDA.6000202@schlund.net> Message-ID: References: <200509281238.j8SCc438011883@tislabs.com> <433A9118.3020808@cisco.com> <337CB25A-5FD5-4A66-9533-BB3BF85A5448@tony.li> <18D2DBF4-F162-4811-B8A2-F94513DA1F5B@tony.li> <433E2BDA.6000202@schlund.net> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Sat, 1 Oct 2005, Stefan Mink wrote: > I think its much more important to secure the control plane than > the forwarding plane, as attacks involving the forwarding plane are > locally: I can only the forwarding plane of *my* devices directly; > We will never get to the point that we can keep people from messing > around with their networks, but we need to give the neighboring > networks means, to detect this: this is probably only possible by > comparing ongoings on the forwarding plane with the status of the > control plane. > > The result is: we need to first secure the control plane... The forwarding-plane problem isn't that *your* forwarding plane could be attacked, but that, even if you have a way to determine which of your neighbour's control planes appear trustworthy (in terms of what they're telling you about the state of their routing), it says nothing about your *neighbour's* forwarding-planes. It is your neighbour who may be subverting their own forwarding-plane (so it would not matter a jot if they could not subvert the inter-domain protocol without you noticing). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Fry: Ooh, Big Pink. It's the only gum with the breath freshening power of ham. Bender: And it pinkens your teeth while you chew. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Oct 02 17:04:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMB0F-0007k5-I6; Sun, 02 Oct 2005 17:04:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMB0B-0007gS-1b for rpsec@megatron.ietf.org; Sun, 02 Oct 2005 17:04:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02748 for ; Sun, 2 Oct 2005 17:04:04 -0400 (EDT) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMB8U-0002c3-Sv for rpsec@ietf.org; Sun, 02 Oct 2005 17:12:44 -0400 Received: from [84.56.249.153] (helo=[192.168.0.100]) by mxintern.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1EMB03-0002Fy-4c; Sun, 02 Oct 2005 23:03:59 +0200 Message-ID: <43404B13.8010901@schlund.net> Date: Sun, 02 Oct 2005 23:03:15 +0200 From: Stefan Mink User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: paul@hibernia.jakma.org, rpsec@ietf.org Subject: Re: [RPSEC] Basis of Requirements? References: <200509281238.j8SCc438011883@tislabs.com> <433A9118.3020808@cisco.com> <337CB25A-5FD5-4A66-9533-BB3BF85A5448@tony.li> <18D2DBF4-F162-4811-B8A2-F94513DA1F5B@tony.li> <433E2BDA.6000202@schlund.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Warning: 84.56.249.153 is listed at dialup.bl.kundenserver.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Hi Paul, Paul Jakma wrote: > The forwarding-plane problem isn't that *your* forwarding plane could be > attacked, but that, even if you have a way to determine which of your > neighbour's control planes appear trustworthy (in terms of what they're > telling you about the state of their routing), it says nothing about > your *neighbour's* forwarding-planes. oh, thats exactly what I wanted to say :) (I was putting myself into the role of the attacker...) An attacker can only use the devices he has control over to manipulate the forwarding plane in a way not corresponding to the control plane state. (this is my definition of a "forwarding plane attack"). So since you can not *prevent* attacks on the forwarding plane in other networks, the only defense we have here is *detection*. We nead means to check whether events on the forwarding plane correlate with state on the control plane. This already happens today somewhat via reverse path forwarding (RPF), which checks whether a packet has a source that corresponds to a route pointing in that direction. There are many szenarios where you can use RPF only partially or in a weakened form (e.g. due to asymmetric routing), but its a start. What's still missing in my opinion is, that on a packet not only the reverse path is being checked, but also the "forward path": did the neighboring AS that sent the packet really got a route from you for the destination address in the packet . I'm not aware of any comparable check so far. With such a check you could recognize if somebody installs static routes on his devices to send traffic via you he is not meant to. Anyway: such checks use the control plane (what is the other party allowed to do on the forwarding plane?) and as long as we can not rely on the data in the control plane, we can not secure the forwarding plane. I don't think this working group can to all the work in one step, so securing the front door via securing the control plane makes it at least harder for the attacker, since the effects on attacks on the forwarding plane are much more limited: an attacker can only attack traffic flowing "naturally" through his network. He can not attack traffic in other parts of the internet where he is not involved in the packet transport. tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Oct 02 18:08:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMC0o-0001q0-SM; Sun, 02 Oct 2005 18:08:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMC0o-0001pv-0U for rpsec@megatron.ietf.org; Sun, 02 Oct 2005 18:08:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05095 for ; Sun, 2 Oct 2005 18:08:47 -0400 (EDT) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/2tmM1pSPBYxnxzuORtkcTZzkRdWbPOLQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMC97-0003xs-NF for rpsec@ietf.org; Sun, 02 Oct 2005 18:17:28 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j92M8Mrp026173; Sun, 2 Oct 2005 23:08:26 +0100 Date: Sun, 2 Oct 2005 23:08:22 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Stefan Mink Subject: Re: [RPSEC] Basis of Requirements? In-Reply-To: <43404B13.8010901@schlund.net> Message-ID: References: <200509281238.j8SCc438011883@tislabs.com> <433A9118.3020808@cisco.com> <337CB25A-5FD5-4A66-9533-BB3BF85A5448@tony.li> <18D2DBF4-F162-4811-B8A2-F94513DA1F5B@tony.li> <433E2BDA.6000202@schlund.net> <43404B13.8010901@schlund.net> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Sun, 2 Oct 2005, Stefan Mink wrote: > An attacker can only use the devices he has control over to > manipulate the forwarding plane in a way not corresponding to the > control plane state. (this is my definition of a "forwarding plane > attack"). > So since you can not *prevent* attacks on the forwarding plane in > other networks, the only defense we have here is *detection*. ACK. Note that even with the most secure of systems, you still will not be able to detect attacks, if they are sufficiently well co-ordinated. You can only /try/ detect them. > What's still missing in my opinion is, that on a packet not only > the reverse path is being checked, but also the "forward path": did > the neighboring AS that sent the packet really got a route from you > for the destination address in the packet . I'm not aware of any > comparable check so far. With such a check you could recognize if > somebody installs static routes on his devices to send traffic via > you he is not meant to. Right, you could introduce some kind of probing mechanism with which to verify the claims of UPDATEs received. Not sure how well this would scale though (probes would have to be ongoing..). ;) > Anyway: such checks use the control plane (what is the other party > allowed to do on the forwarding plane?) and as long as we can not > rely on the data in the control plane, we can not secure the > forwarding plane. Personally, I think this /might/ be the wrong way around. For so long as the integrity of the forwarding plane can not be verified, integrity-assurance mechanisms in the control-plane, even if 'perfect', will remain easily subverted. Susan Hares comment regarding profiles of users is really interesting too. A secure control plane on top of an unassured forwarding-plane may be useful security to some, useless to others. That's not to say there wouldn't be value in such mechanisms, eg: > I don't think this working group can to all the work in one step, > so securing the front door via securing the control plane makes it > at least harder for the attacker, since the effects on attacks on > the forwarding plane are much more limited: an attacker can only > attack traffic flowing "naturally" through his network. He can not > attack traffic in other parts of the internet where he is not > involved in the packet transport. Right, narrowing scope of attacks down from "any BGP speaker" to "MITM AS" would have value, at least in an internet context. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "Bachelor Chow. Now with flavor." -announcer _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Oct 02 20:11:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMDvM-0002pb-PS; Sun, 02 Oct 2005 20:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMDvK-0002nk-VX for rpsec@megatron.ietf.org; Sun, 02 Oct 2005 20:11:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10112 for ; Sun, 2 Oct 2005 20:11:17 -0400 (EDT) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EME3h-00067F-2L for rpsec@ietf.org; Sun, 02 Oct 2005 20:19:58 -0400 Received: from [84.56.249.153] (helo=[192.168.0.100]) by mxintern.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1EMDvI-0002fs-Df; Mon, 03 Oct 2005 02:11:16 +0200 Message-ID: <434076FB.9010203@schlund.net> Date: Mon, 03 Oct 2005 02:10:35 +0200 From: Stefan Mink User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: paul@hibernia.jakma.org, rpsec@ietf.org Subject: Re: [RPSEC] Basis of Requirements? References: <200509281238.j8SCc438011883@tislabs.com> <433A9118.3020808@cisco.com> <337CB25A-5FD5-4A66-9533-BB3BF85A5448@tony.li> <18D2DBF4-F162-4811-B8A2-F94513DA1F5B@tony.li> <433E2BDA.6000202@schlund.net> <43404B13.8010901@schlund.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Warning: 84.56.249.153 is listed at dialup.bl.kundenserver.de X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Paul Jakma wrote: > Note that even with the most secure of systems, you still will not be > able to detect attacks, if they are sufficiently well co-ordinated. You > can only /try/ detect them. can you give me an example, which attacks are not detectable? Maybe we should first agree on a definition on "forwarding plane attack" and collect types of attack. I fear that there is no common sense yet. This already starts with the scope of "forwarding plane": Do we talk about the forwarding plane of an entire AS, or is it the forwarding plane of one specific router? Does the differentiation matter? >> What's still missing in my opinion is, that on a packet not only the >> reverse path is being checked, but also the "forward path": did the >> neighboring AS that sent the packet really got a route from you for >> the destination address in the packet . I'm not aware of any >> comparable check so far. With such a check you could recognize if >> somebody installs static routes on his devices to send traffic via you >> he is not meant to. > > Right, you could introduce some kind of probing mechanism with which to > verify the claims of UPDATEs received. Not sure how well this would > scale though (probes would have to be ongoing..). ;) lets solve a problem first and then optimize, ok? ;) tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Oct 02 23:56:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMHQm-0002cK-Qh; Sun, 02 Oct 2005 23:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMHQi-0002Zo-GG for rpsec@megatron.ietf.org; Sun, 02 Oct 2005 23:55:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16170 for ; Sun, 2 Oct 2005 23:55:54 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMHZ6-0001SK-Fw for rpsec@ietf.org; Mon, 03 Oct 2005 00:04:37 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j933tTEw010916; Sun, 2 Oct 2005 20:55:29 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) with ESMTP id j933tNMJ010913; Sun, 2 Oct 2005 20:55:24 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Sun, 2 Oct 2005 20:55:23 -0700 (PDT) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: Tom Petch Subject: Re: [RPSEC] Scope was Re: Please vote In-Reply-To: <001e01c5c66c$f536bce0$0601a8c0@pc6> Message-ID: References: <43390B42.2090101@cisco.com><4339673A.9070802@cisco.com> <050901c5c5ca$f0dce040$0601a8c0@pc6> <433D60F6.5000903@cisco.com> <1371150831.20050930122912@psg.com> <8DA84182-F285-4F20-B51B-875A0D3D652B@tony.li> <001e01c5c66c$f536bce0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Sat, 1 Oct 2005, Tom Petch wrote: > I was fishing for something more than a change from RFC1771 to > RFC4271. Have the editors actually read the later BGP specification > and used it in this draft or is the draft based on BGP as specified > in RFC1771? > > The reference to RFC1771 suggested the latter to me, in which case > just changing the reference I do not see as enough. > > Tom Petch Hi Tom, I plead guilty for only having sounded off on one of your questions/suggestions and somewhat glibly at that. I can take only some of credit/blame for the draft having come in to do the more recent and minor revisions, mostly with input from others. However, my take, and I went back to review some of the relevant bits of the two docs at hand, is that the parts which inform the BGP Security Requirements doc don't differ substantially in the two BGP specs. If others have different assessments, I'm hope they'll share their thoughts. As for your comments on TLS, it seems to have been seconded and can be dropped. The words on key management are also well taken, I can integrate that as well. Regarding the "other attributes" question: In the case of communities, since they can be added, modified, or removed by any AS, they should considered suspect, IMHO. As for other features or attributes, I don't think we've heard clearly from the WG. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Oct 03 04:55:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMM6f-0003r9-N2; Mon, 03 Oct 2005 04:55:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMM6d-0003pv-QP for rpsec@megatron.ietf.org; Mon, 03 Oct 2005 04:55:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13154 for ; Mon, 3 Oct 2005 04:55:26 -0400 (EDT) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/GMkhUN6VcyMeWczqOe8dMr+ezGllhZAE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMMEy-0000IP-Ts for rpsec@ietf.org; Mon, 03 Oct 2005 05:04:12 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j938tH08031297; Mon, 3 Oct 2005 09:55:20 +0100 Date: Mon, 3 Oct 2005 09:55:16 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Stefan Mink Subject: Re: [RPSEC] Basis of Requirements? In-Reply-To: <434076FB.9010203@schlund.net> Message-ID: References: <200509281238.j8SCc438011883@tislabs.com> <433A9118.3020808@cisco.com> <337CB25A-5FD5-4A66-9533-BB3BF85A5448@tony.li> <18D2DBF4-F162-4811-B8A2-F94513DA1F5B@tony.li> <433E2BDA.6000202@schlund.net> <43404B13.8010901@schlund.net> <434076FB.9010203@schlund.net> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Mon, 3 Oct 2005, Stefan Mink wrote: > can you give me an example, which attacks are not detectable? The obvious case would be where all your neighbours conspire against you :). (Though, with sufficient higher-level security, such evil neighbours at least should not be able to trick you into thinking everything is still ok - you would think things had failed, but you wouldn't be able to distinguish between failure and an attack). > Maybe we should first agree on a definition on "forwarding plane > attack" and collect types of attack. I fear that there is no common > sense yet. This already starts with the scope of "forwarding > plane": Do we talk about the forwarding plane of an entire AS, or > is it the forwarding plane of one specific router? Does the > differentiation matter? I don't think so, I think a per-AS model is fine. > lets solve a problem first and then optimize, ok? ;) Sure. Actually, I suspect a part of identifying acceptable requirements is to agree also on the acceptable costs. Security/cost tends to be an inevitable trade-off. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: There is brutality and there is honesty. There is no such thing as brutal honesty. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Oct 03 11:19:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMS5r-0004r9-7R; Mon, 03 Oct 2005 11:19:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMS5p-0004qg-Aj for rpsec@megatron.ietf.org; Mon, 03 Oct 2005 11:19:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11852 for ; Mon, 3 Oct 2005 11:19:03 -0400 (EDT) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMSEH-0002fQ-7v for rpsec@ietf.org; Mon, 03 Oct 2005 11:27:52 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j93FEbD9003611 for ; Mon, 3 Oct 2005 11:14:37 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2uaqdh; Mon, 3 Oct 05 11:14:34 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j93FGFe3006222; Mon, 3 Oct 2005 11:16:15 -0400 (EDT) Date: Mon, 3 Oct 2005 11:16:15 -0400 (EDT) From: Sandy Murphy Message-Id: <200510031516.j93FGFe3006222@tislabs.com> To: sandy@tislabs.com, tony.li@tony.li Subject: Re: [RPSEC] Basis of Requirements? X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: rpsec@ietf.org, kent@bbn.com, riw@cisco.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org >> The idea is trying to remove the ability for the bad guys to inject >> deliberate routing anomalies into the system as much as possible. > >No, that's definitely NOT the goal. In particular, the "as much as >possible" part is way over the top. The "as much as possible" was a recognition that the bad guys can not be perfectly stopped, whatever we do. So the "as much as possible" is tuned to the recognizable engineering imperative, with the understanding that a solution that leaves us just as open to the bad guys as before isn't helping. >p.s. I vote 'no'. ;-) To what question are you voting? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Oct 03 11:26:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSD1-0006GK-BM; Mon, 03 Oct 2005 11:26:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSD0-0006GF-Br for rpsec@megatron.ietf.org; Mon, 03 Oct 2005 11:26:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12368 for ; Mon, 3 Oct 2005 11:26:28 -0400 (EDT) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMSLU-0002t4-4T for rpsec@ietf.org; Mon, 03 Oct 2005 11:35:17 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j93FM63H004291 for ; Mon, 3 Oct 2005 11:22:06 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAJaaqyi; Mon, 3 Oct 05 11:22:03 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j93FO0mx006459; Mon, 3 Oct 2005 11:24:00 -0400 (EDT) Date: Mon, 3 Oct 2005 11:24:00 -0400 (EDT) From: Sandy Murphy Message-Id: <200510031524.j93FO0mx006459@tislabs.com> To: kent@bbn.com, tony.li@tony.li Subject: Re: [RPSEC] Basis of Requirements? X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org >This WG was established with a scope that includes security for >routing, but not forwarding. >... >However, it certainly makes sense to >develop countermeasures to routing attacks if these countermeasures >preclude attacks that can not be effected by the same parties solely >through forwarding attacks. I would second this. A router can mis-forward any traffic that happens to come its way. Given the condition of the FIB's in other routers, it might be able to mis-forward so as to make a routing loop. But the ability to affect the routing protocol might make it possible to *make* traffic go through specific routers, whether to that router's gain or pain, and to *make* the FIB's in other routers suitable for the creation of a routing loop. It's the deterministic ability to create a situation to the bad guy's benefit that makes routing attacks different from forwarding attacks. At the last NANOG, there was a discussion of AS9121's announcement of 100K+ routes. No amount of mis-forwarding could have had the same ill-effect. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Oct 03 11:31:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSHQ-0006sN-2a; Mon, 03 Oct 2005 11:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSHO-0006rS-Pn for rpsec@megatron.ietf.org; Mon, 03 Oct 2005 11:31:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12657 for ; Mon, 3 Oct 2005 11:31:00 -0400 (EDT) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMSPs-000321-62 for rpsec@ietf.org; Mon, 03 Oct 2005 11:39:50 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j93FQbXK004608 for ; Mon, 3 Oct 2005 11:26:37 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAACra4_i; Mon, 3 Oct 05 11:26:35 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j93FSUwd006589; Mon, 3 Oct 2005 11:28:30 -0400 (EDT) Date: Mon, 3 Oct 2005 11:28:30 -0400 (EDT) From: Sandy Murphy Message-Id: <200510031528.j93FSUwd006589@tislabs.com> To: kent@bbn.com, tony.li@tony.li Subject: Re: [RPSEC] Basis of Requirements? X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org >I think that you will agree that the Black Hats will exploit the >attack of least difficulty first. >... >If we have other resources at our disposal, we should >focus them on the forwarding plane. Do you know of attacks that are directly solely through the forwarding plane? Do they have the same spread of damage as attacks in the routing protoocl? Do you have ideas about protecting the forwarding plane? (The only ones I know of were Radia Perlman's suggestion of doing forwarding on multiple paths to make sure data did arrive, and one that did some anomaly detection to route packets around a spot that did not seem to be forwarding properly.) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Oct 03 12:13:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSwQ-00089B-UT; Mon, 03 Oct 2005 12:13:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSwO-00088y-PY for rpsec@megatron.ietf.org; Mon, 03 Oct 2005 12:13:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15453 for ; Mon, 3 Oct 2005 12:13:22 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMT4t-0004SJ-9i for rpsec@ietf.org; Mon, 03 Oct 2005 12:22:12 -0400 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j93GCkDd019123; Mon, 3 Oct 2005 12:12:46 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <43390B42.2090101@cisco.com><433967 3A.9070802@cisco.com> <050901c5c5ca$f0dce040$0601a8c0@pc6> <433D60F6.5000903@cisco.com> <1371150831.20050930122912@psg.com> <8DA84182-F285-4F20-B51B-875A0D3D652B@tony.li> <001e01c5c66c$f536bce0$0601a8c0@pc6> Date: Mon, 3 Oct 2005 10:37:35 -0400 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] Scope was Re: Please vote Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: rpsec@ietf.org, Tom Petch X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 8:55 PM -0700 10/2/05, Tony Tauber wrote: >On Sat, 1 Oct 2005, Tom Petch wrote: > >>I was fishing for something more than a change from RFC1771 to >>RFC4271. Have the editors actually read the later BGP specification >>and used it in this draft or is the draft based on BGP as specified >>in RFC1771? >> >>The reference to RFC1771 suggested the latter to me, in which case >>just changing the reference I do not see as enough. >> >>Tom Petch > >Hi Tom, > >I plead guilty for only having sounded off on one of your >questions/suggestions and somewhat glibly at that. > >I can take only some of credit/blame for the draft having come in to >do the more recent and minor revisions, mostly with input from others. > >However, my take, and I went back to review some of the relevant bits >of the two docs at hand, is that the parts which inform the BGP >Security Requirements doc don't differ substantially in the two BGP >specs. > >If others have different assessments, I'm hope they'll share their >thoughts. The latest spec, now in the RFC editor's queue, explicitly acknowledges the legitimacy of an AS adding multiple instances of its own AS to the path, something we discuss, so I think this is the spec to reference. >As for your comments on TLS, it seems to have been seconded and can be >dropped. The words on key management are also well taken, I can >integrate that as well. > >Regarding the "other attributes" question: >In the case of communities, since they can be added, modified, or >removed by any AS, they should considered suspect, IMHO. As for other >features or attributes, I don't think we've heard clearly from the WG. The fact that communities are subject to a wide range of legitimate modification does not mean that they are unable to be protected. No-export is a prime example of a community that has significant semantics and should be covered. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Oct 03 12:24:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMT7O-0001cs-Pn; Mon, 03 Oct 2005 12:24:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMT7N-0001b0-5h for rpsec@megatron.ietf.org; Mon, 03 Oct 2005 12:24:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15979 for ; Mon, 3 Oct 2005 12:24:42 -0400 (EDT) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/Qug29q+Cm4BUURxyCjOHHqS+zFQEhvCE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMTFr-0004m8-Bl for rpsec@ietf.org; Mon, 03 Oct 2005 12:33:32 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j93GOSSk004308; Mon, 3 Oct 2005 17:24:30 +0100 Date: Mon, 3 Oct 2005 17:24:28 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Sandy Murphy Subject: Re: [RPSEC] Basis of Requirements? In-Reply-To: <200510031524.j93FO0mx006459@tislabs.com> Message-ID: References: <200510031524.j93FO0mx006459@tislabs.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Mon, 3 Oct 2005, Sandy Murphy wrote: > At the last NANOG, there was a discussion of AS9121's announcement > of 100K+ routes. No amount of mis-forwarding could have had the > same ill-effect. Indeed. And it's not the first time that kind of thing has happened. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: The price of greatness is responsibility. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Oct 03 14:43:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVHK-0000ao-6N; Mon, 03 Oct 2005 14:43:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVHI-0000aK-Hf for rpsec@megatron.ietf.org; Mon, 03 Oct 2005 14:43:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24079 for ; Mon, 3 Oct 2005 14:43:07 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMVPm-0000VO-5i for rpsec@ietf.org; Mon, 03 Oct 2005 14:51:57 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j93IgijV026350; Mon, 3 Oct 2005 11:42:44 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) with ESMTP id j93Igd1W026342; Mon, 3 Oct 2005 11:42:44 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Mon, 3 Oct 2005 11:42:39 -0700 (PDT) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: Stephen Kent Subject: Re: [RPSEC] Scope was Re: Please vote In-Reply-To: Message-ID: References: <43390B42.2090101@cisco.com><433967 3A.9070802@cisco.com> <050901c5c5ca$f0dce040$0601a8c0@pc6> <433D60F6.5000903@cisco.com> <1371150831.20050930122912@psg.com> <8DA84182-F285-4F20-B51B-875A0D3D652B@tony.li> <001e01c5c66c$f536bce0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rpsec@ietf.org, Tom Petch X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Mon, 3 Oct 2005, Stephen Kent wrote: >> However, my take, and I went back to review some of the relevant bits >> of the two docs at hand, is that the parts which inform the BGP >> Security Requirements doc don't differ substantially in the two BGP >> specs. > > The latest spec, now in the RFC editor's queue, explicitly > acknowledges the legitimacy of an AS adding multiple instances of > its own AS to the path, something we discuss, so I think this is the > spec to reference. Right, I noticed that, too. >> Regarding the "other attributes" question: In the case of >> communities, since they can be added, modified, or removed by any >> AS, they should considered suspect, IMHO. As for other features or >> attributes, I don't think we've heard clearly from the WG. > > The fact that communities are subject to a wide range of legitimate > modification does not mean that they are unable to be protected. > No-export is a prime example of a community that has significant > semantics and should be covered. > > Steve It does have significant semantics, but can validly be modified by any AS or node, though a "rogue node" w/in an AS shouldn't be able to do so. I'm guessing you might be suggesting we stipulate that one be able to detect when it's been removed or when an UPDATE that had it set by some upstream AS is still getting propagated. Can any BGP implementors give some indication of whether or not they implicitly don't propagate UPDATEs which are received with NO_EXPORT set? Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Oct 03 15:09:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVgR-0004oX-6H; Mon, 03 Oct 2005 15:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVgQ-0004oS-11 for rpsec@megatron.ietf.org; Mon, 03 Oct 2005 15:09:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25513 for ; Mon, 3 Oct 2005 15:09:04 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMVow-00018H-01 for rpsec@ietf.org; Mon, 03 Oct 2005 15:17:55 -0400 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j93J8cDf029645; Mon, 3 Oct 2005 15:08:40 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <43390B42.2090101@cisco.com><433967 3A.9070802@cisco.com> <050901c5c5ca$f0dce040$0601a8c0@pc6> <433D60F6.5000903@cisco.com> <1371150831.20050930122912@psg.com> <8DA84182-F285-4F20-B51B-875A0D3D652B@tony.li> <001e01c5c66c$f536bce0$0601a8c0@pc6> Date: Mon, 3 Oct 2005 15:01:30 -0400 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] Scope was Re: Please vote Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 11:42 AM -0700 10/3/05, Tony Tauber wrote: >On Mon, 3 Oct 2005, Stephen Kent wrote: > >>>However, my take, and I went back to review some of the relevant bits >>>of the two docs at hand, is that the parts which inform the BGP >>>Security Requirements doc don't differ substantially in the two BGP >>>specs. >> >>The latest spec, now in the RFC editor's queue, explicitly >>acknowledges the legitimacy of an AS adding multiple instances of >>its own AS to the path, something we discuss, so I think this is the >>spec to reference. > >Right, I noticed that, too. > >>>Regarding the "other attributes" question: In the case of >>>communities, since they can be added, modified, or removed by any >>>AS, they should considered suspect, IMHO. As for other features or >>>attributes, I don't think we've heard clearly from the WG. >> >>The fact that communities are subject to a wide range of legitimate >>modification does not mean that they are unable to be protected. >>No-export is a prime example of a community that has significant >>semantics and should be covered. >> >>Steve > >It does have significant semantics, but can validly be modified by any >AS or node, though a "rogue node" w/in an AS shouldn't be able to do so. >I'm guessing you might be suggesting we stipulate that one be able to >detect when it's been removed or when an UPDATE that had it set by >some upstream AS is still getting propagated. yes, that's one obvious example. also the ability to determine which AS in a path added a community seems like a desirable feature. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Oct 05 14:48:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENEJt-0000Br-3n; Wed, 05 Oct 2005 14:48:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENAw5-0006Cx-79 for rpsec@megatron.ietf.org; Wed, 05 Oct 2005 11:12:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29456 for ; Wed, 5 Oct 2005 11:11:58 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENB4y-0006be-C8 for rpsec@ietf.org; Wed, 05 Oct 2005 11:21:13 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j95FBoY1028574 for ; Wed, 5 Oct 2005 08:11:50 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) with ESMTP id j95FBow4028571 for ; Wed, 5 Oct 2005 08:11:50 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Wed, 5 Oct 2005 08:11:50 -0700 (PDT) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: rpsec@ietf.org In-Reply-To: Message-ID: References: <43390B42.2090101@cisco.com> <4339673A.9070802@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [RPSEC] Voting Tally so far X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org A week has passed and I believe the voting thus far has been: Russ White, Blaine Christian, and Stefan Mink have voted that the document should progress. Tom Petch, Sue Hares, and Steve Kent have voted that the document is not ready but have suggested places they'd like to see modifications, though the particulars need to be worked out. Tony Li believes that this document goes in entirely the wrong direction. Any other voices who'd like to sound off? There are a few others who've been vocal but for whom I couldn't seem to find clear votes expressed. I'll give it until COB this Friday. Tony On Tue, 27 Sep 2005, Tony Tauber wrote: > Folks, > > Since it seems we're going around and around on the latest vibrant > set of comments, let's work on a clear vote on the document as it > stands. > > Please convey your opinion on whether this document should progress. > If an unqualified "yes" or "no" doesn't represent your view, please > try and _succinctly_ relate what would need to be changed for the > document to meet with your approval. > > Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Oct 09 15:30:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOgs8-0007Wp-Bz; Sun, 09 Oct 2005 15:30:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOgs7-0007Wb-3G for rpsec@megatron.ietf.org; Sun, 09 Oct 2005 15:30:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05118 for ; Sun, 9 Oct 2005 15:30:09 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOh1p-0003xu-4T for rpsec@ietf.org; Sun, 09 Oct 2005 15:40:16 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j99JTl5x002392 for ; Sun, 9 Oct 2005 12:29:47 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) with ESMTP id j99JTlJU002389 for ; Sun, 9 Oct 2005 12:29:47 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Sun, 9 Oct 2005 12:29:47 -0700 (PDT) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [RPSEC] Agenda items for LA (IETF-64) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Folks, Please reply as soon as possible with Agenda items you'd like to suggest for our meeting in Los Angeles (IETF-64). For instance, anyone want to discuss some routing protocols besides BGP? Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Oct 09 20:53:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOlv1-0001BA-TD; Sun, 09 Oct 2005 20:53:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOluz-0001AZ-Pj for rpsec@megatron.ietf.org; Sun, 09 Oct 2005 20:53:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21823 for ; Sun, 9 Oct 2005 20:53:28 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOm4m-0003X8-No for rpsec@ietf.org; Sun, 09 Oct 2005 21:03:38 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9A0rJPf005580 for ; Sun, 9 Oct 2005 17:53:19 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) with ESMTP id j9A0rJfN005577 for ; Sun, 9 Oct 2005 17:53:19 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Sun, 9 Oct 2005 17:53:19 -0700 (PDT) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: rpsec@ietf.org Subject: Re: [RPSEC] Agenda items for Vancouver (IETF-64) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Sun, 9 Oct 2005, Tony Tauber wrote: > Folks, > > Please reply as soon as possible with Agenda items you'd like to > suggest for our meeting in Los Angeles (IETF-64). Make that Vancouver. Sorry about the mix up. Tony > For instance, anyone want to discuss some routing protocols besides BGP? > > Thanks, > > Tony > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Oct 16 23:40:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLrd-0002uj-Fa; Sun, 16 Oct 2005 23:40:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLrb-0002sd-S6 for rpsec@megatron.ietf.org; Sun, 16 Oct 2005 23:40:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11914 for ; Sun, 16 Oct 2005 23:40:32 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERM2q-0006Po-HH for rpsec@ietf.org; Sun, 16 Oct 2005 23:52:17 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9H3eSqc020525; Sun, 16 Oct 2005 20:40:28 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) with ESMTP id j9H3eOri020522; Sun, 16 Oct 2005 20:40:28 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Sun, 16 Oct 2005 20:40:24 -0700 (PDT) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: Susan Hares Subject: RE: [RPSEC] Re: Please vote In-Reply-To: <6F44D7F6B24A8F4DA0AB46C9BE924F020169E339@VS4.EXCHPROD.USA.NET> Message-ID: References: <6F44D7F6B24A8F4DA0AB46C9BE924F020169E339@VS4.EXCHPROD.USA.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Thu, 29 Sep 2005, Susan Hares wrote: > No-move-forward: = 1 > > Should add stronger language on profiles of users (military versus > normal"). > > Sue Hi Sue, I'd been thinking I'd attempt to revise the document based on the feedback gleaned during this round. Could you or someone else familiar with the requirements of these users/environments please supply text? I was in touch with the military world briefly but could not represent well the requirements/concerns in the BGP arena. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Oct 16 23:45:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLwW-0004bb-2x; Sun, 16 Oct 2005 23:45:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERLwS-0004aV-Qp for rpsec@megatron.ietf.org; Sun, 16 Oct 2005 23:45:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12233 for ; Sun, 16 Oct 2005 23:45:32 -0400 (EDT) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERM7g-0006ZK-Tf for rpsec@ietf.org; Sun, 16 Oct 2005 23:57:18 -0400 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with SMTP id DFEAE12D3E1; Mon, 17 Oct 2005 03:45:13 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 999JJqDtL0061Mo1; Mon, 17 Oct 2005 03:45:12 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 998JJqDtk0217Mo1; Mon, 17 Oct 2005 03:45:10 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw4.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.26F); Mon, 17 Oct 2005 03:45:10 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com gw4.EXCHPROD.USA.NET X-USANET-MsgId: XID262JJqDtk1970Xo1 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.141]) by gw4.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211); Sun, 16 Oct 2005 21:45:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] Re: Please vote Date: Sun, 16 Oct 2005 21:44:55 -0600 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F02019AA6BD@VS4.EXCHPROD.USA.NET> Thread-Topic: [RPSEC] Re: Please vote Thread-Index: AcXSzJA5pBwdLz+dTzu6o4OrVtuhdwAAH9vw From: "Susan Hares" To: "Tony Tauber" X-OriginalArrivalTime: 17 Oct 2005 03:45:09.0875 (UTC) FILETIME=[2C079430:01C5D2CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Tony: I will supply text by Wed Pm. Glad to contact my cohorts in military applications on this one. Sue -----Original Message----- From: Tony Tauber [mailto:ttauber@1-4-5.net]=20 Sent: Sunday, October 16, 2005 11:40 PM To: Susan Hares Cc: Russ White; rpsec@ietf.org Subject: RE: [RPSEC] Re: Please vote On Thu, 29 Sep 2005, Susan Hares wrote: > No-move-forward: =3D 1 > > Should add stronger language on profiles of users (military versus > normal"). > > Sue Hi Sue, I'd been thinking I'd attempt to revise the document based on the feedback gleaned during this round. Could you or someone else familiar with the requirements of these users/environments please supply text? I was in touch with the military world briefly but could not=20 represent well the requirements/concerns in the BGP arena. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Oct 17 11:22:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWoZ-00024W-Jt; Mon, 17 Oct 2005 11:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERWoY-00024R-1p for rpsec@megatron.ietf.org; Mon, 17 Oct 2005 11:22:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19081 for ; Mon, 17 Oct 2005 11:22:06 -0400 (EDT) Received: from rimp2.nist.gov ([129.6.16.227] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERWzs-0001Ai-Vh for rpsec@ietf.org; Mon, 17 Oct 2005 11:33:58 -0400 Received: from [127.0.0.1] (dougm-lt-50.antd.nist.gov [129.6.50.3]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j9HFLpQd006006; Mon, 17 Oct 2005 11:21:56 -0400 Message-ID: <4353C18F.5020306@nist.gov> Date: Mon, 17 Oct 2005 11:21:51 -0400 From: Doug Montgomery Organization: http://www.antd.nist.gov/ User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Tony Tauber Subject: Re: [RPSEC] Re: Please vote References: <6F44D7F6B24A8F4DA0AB46C9BE924F020169E339@VS4.EXCHPROD.USA.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: dougm@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Susan Hares , rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Victor Chao (chao_victor@bah.com) heads the DoD GIG Routing Security sub-group. They have a draft paper addressing requirements/status for routing security in future DoD networks. The paper discusses options based upon what the IETF might/might not do. Victor would be a good starting point. dougm Tony Tauber wrote: > On Thu, 29 Sep 2005, Susan Hares wrote: > >> No-move-forward: = 1 >> >> Should add stronger language on profiles of users (military versus >> normal"). >> >> Sue > > Hi Sue, > > I'd been thinking I'd attempt to revise the document based on the > feedback gleaned during this round. > > Could you or someone else familiar with the requirements of these > users/environments please supply text? > > I was in touch with the military world briefly but could not represent > well the requirements/concerns in the BGP arena. > > Thanks, > > Tony > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec -- +----------------------------------------------------------------------------+ | Doug Montgomery Manager, Internetworking Technologies Group | | Advanced Network Technologies Division WWW: http://www.antd.nist.gov/ | | National Institute of Standards and Technology Email: dougm@nist.gov | | 100 Bureau Drive Voice: +1-301-975-3630 | | Gaithersburg, MD 20899-8920 USA Fax: +1-301-590-0932 | +----------------------------------------------------------------------------+ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Oct 20 00:33:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESS7q-0004OO-Gk; Thu, 20 Oct 2005 00:33:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESS7o-0004O6-WE for rpsec@megatron.ietf.org; Thu, 20 Oct 2005 00:33:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09605 for ; Thu, 20 Oct 2005 00:33:47 -0400 (EDT) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESSJf-0007is-5U for rpsec@ietf.org; Thu, 20 Oct 2005 00:46:12 -0400 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with SMTP id 375901639BB; Thu, 20 Oct 2005 04:33:24 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 797JJTehX0027Mo2; Thu, 20 Oct 2005 04:33:24 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.25R) with ESMTP id 796JJTehV0044Mo2; Thu, 20 Oct 2005 04:33:21 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.26F); Thu, 20 Oct 2005 04:33:21 GMT X-USANET-Source: 165.212.116.254 IN skh@nexthop.com gw3.EXCHPROD.USA.NET X-USANET-MsgId: XID526JJTehV2639Xo2 Received: from VS4.EXCHPROD.USA.NET ([10.116.208.142]) by gw3.EXCHPROD.USA.NET with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Oct 2005 22:33:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] Re: Please vote Date: Wed, 19 Oct 2005 22:33:25 -0600 Message-ID: <6F44D7F6B24A8F4DA0AB46C9BE924F0201ADCACA@VS4.EXCHPROD.USA.NET> Thread-Topic: [RPSEC] Re: Please vote Thread-Index: AcXSzJA5pBwdLz+dTzu6o4OrVtuhdwAAH9vwAJiQ8dA= From: "Susan Hares" To: "Susan Hares" , "Tony Tauber" X-OriginalArrivalTime: 20 Oct 2005 04:33:20.0939 (UTC) FILETIME=[667A2FB0:01C5D52F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Tony: I will need to delay my response to your query until Friday pm. Please advise how much trouble this will cause you. Sue -----Original Message----- From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] On Behalf Of Susan Hares Sent: Sunday, October 16, 2005 11:45 PM To: Tony Tauber Cc: rpsec@ietf.org; Russ White Subject: RE: [RPSEC] Re: Please vote Tony: I will supply text by Wed Pm. Glad to contact my cohorts in military applications on this one. Sue -----Original Message----- From: Tony Tauber [mailto:ttauber@1-4-5.net]=20 Sent: Sunday, October 16, 2005 11:40 PM To: Susan Hares Cc: Russ White; rpsec@ietf.org Subject: RE: [RPSEC] Re: Please vote On Thu, 29 Sep 2005, Susan Hares wrote: > No-move-forward: =3D 1 > > Should add stronger language on profiles of users (military versus > normal"). > > Sue Hi Sue, I'd been thinking I'd attempt to revise the document based on the feedback gleaned during this round. Could you or someone else familiar with the requirements of these users/environments please supply text? I was in touch with the military world briefly but could not=20 represent well the requirements/concerns in the BGP arena. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Oct 20 14:10:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESero-0002Ld-Vv; Thu, 20 Oct 2005 14:10:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESerm-0002LT-L2 for rpsec@megatron.ietf.org; Thu, 20 Oct 2005 14:10:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04408 for ; Thu, 20 Oct 2005 14:10:04 -0400 (EDT) Received: from portola.portolanetworks.tv ([66.121.157.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESf3j-0003Bh-RD for rpsec@ietf.org; Thu, 20 Oct 2005 14:22:38 -0400 Received: from [192.168.2.22] ([66.121.157.194]) by portola.portolanetworks.tv with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 11:05:25 -0700 In-Reply-To: <200510031516.j93FGFe3006222@tislabs.com> References: <200510031516.j93FGFe3006222@tislabs.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E1D45A1-5783-4A65-8D9A-0E55952ACC0F@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RPSEC] Basis of Requirements? Date: Thu, 20 Oct 2005 11:09:49 -0700 To: Sandy Murphy X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 20 Oct 2005 18:05:25.0515 (UTC) FILETIME=[D89675B0:01C5D5A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, kent@bbn.com, riw@cisco.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org >>> The idea is trying to remove the ability for the bad guys to inject >>> deliberate routing anomalies into the system as much as possible. >>> >>> > > The "as much as possible" was a recognition that the bad guys can > not be perfectly stopped, whatever we do. So the "as much as > possible" > is tuned to the recognizable engineering imperative, with the > understanding > that a solution that leaves us just as open to the bad guys as before > isn't helping. > > Ok, so maybe we're disagreeing at the wordsmithing level only. >> p.s. I vote 'no'. ;-) >> >> > > To what question are you voting? > > Whether or not the requirements should ship. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Oct 26 18:52:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu80-0001HF-GQ; Wed, 26 Oct 2005 18:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUu60-0000Wn-06; Wed, 26 Oct 2005 18:50:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02387; Wed, 26 Oct 2005 18:49:55 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUuJ5-0008GW-M0; Wed, 26 Oct 2005 19:03:47 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EUu5p-0005Yx-DR; Wed, 26 Oct 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 26 Oct 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: rpsec@ietf.org Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-bgpsecrec-03.txt X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF. Title : BGP Security Requirements Author(s) : B. Christian, T. Tauber Filename : draft-ietf-rpsec-bgpsecrec-03.txt Pages : 23 Date : 2005-10-26 The security of BGP, the Border Gateway Protocol, is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routing system, is more complex. This document describes a set of requirements for securing BGP, including securing peering relationships between BGP speakers, and authenticating the routing information carried within BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rpsec-bgpsecrec-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-26154705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-bgpsecrec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-26154705.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --NextPart-- From rpsec-bounces@ietf.org Thu Oct 27 14:55:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCu8-0003Wr-WD; Thu, 27 Oct 2005 14:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCu6-0003Wm-Sk for rpsec@megatron.ietf.org; Thu, 27 Oct 2005 14:55:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22394 for ; Thu, 27 Oct 2005 14:54:53 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVD7W-0007O2-LV for rpsec@ietf.org; Thu, 27 Oct 2005 15:09:03 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9RIt1Ht011200 for ; Thu, 27 Oct 2005 11:55:01 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) with ESMTP id j9RIt1VJ011197 for ; Thu, 27 Oct 2005 11:55:01 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Thu, 27 Oct 2005 11:55:01 -0700 (PDT) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [RPSEC] No RPSEC meeting in Vancouver (IETF64) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Hi All, Since no one has brought forth new agenda items and other things can be effectively worked on through the mailing list, RPSEC will not be meeting at IETF64 in Vancouver. I'd like to call people's attention, however, to the SIDR (Secure Inter-Domain Routing) BOF which is scheduled for Thursday morning. The thought on the part of the Routing ADs is to start a parallel effort on possible protocol changes even while some details of the requirements are being ironed out. The focus for now will consider points where there does appear to be clear consensus for possible work. RPSEC isn't chartered with protocol changes and IDR has much other work to keep it busy. For these reasons, the new BOF is being spun up. See detailed BOF announcement below. Cheers, Tony ---- Name of the BOF: Secure Interdomain Routing (SIDR) Area: Routing Chairs: Geoff Houston Sponsoring ADs: Alex Zinin, Bill Fenner The RPSEC WG has been working on security requirements for the Internet routing system in general and the BGP routing protocol in particular. While some progress has been made, formulation of the complete set of requirements can take some time. At the same time, there's a shared understanding in the IETF community that work on securing interdomain routing needs to start, as it will take time to develop implementations and see first deployments. The goal of this BOF is to discuss creation of an extensible interdomain routing security architecture that would allow to incrementally define security features to BGP as the discussion on requirements progresses and new mechanisms become necessary. The expected outcome is an agreement on the initial set of security features that such an architecture would provide. It is not a goal of this BOF to choose between SBGP and SoBGP. Agenda: 1. Introduction and current status [15m] 2. Brief overview of currently proposed solutions [30m] 3. Description of proposed work [15m] 4. Discussion [60m] Mailing list: sidr@ietf.org To subscribe: sidr-request@ietf.org Reading material: Requirements: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-07.txt http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-02.txt SoBGP: http://www.ietf.org/internet-drafts/draft-white-sobgp-architecture-01.txt http://www.ietf.org/internet-drafts/draft-ng-sobgp-bgp-extensions-01.txt http://www.ietf.org/internet-drafts/draft-weis-sobgp-certificates-01.txt SBGP: SBGP web page: http://www.net-tech.bbn.com/sbgp/sbgp-index.html _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Oct 27 18:00:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVFnt-000882-Cq; Thu, 27 Oct 2005 18:00:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVFnr-00087t-NG for rpsec@megatron.ietf.org; Thu, 27 Oct 2005 18:00:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20173 for ; Thu, 27 Oct 2005 18:00:39 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVG1I-0002L0-6I for rpsec@ietf.org; Thu, 27 Oct 2005 18:14:49 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9RM0idw015109 for ; Thu, 27 Oct 2005 15:00:44 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) with ESMTP id j9RM0ioA015106 for ; Thu, 27 Oct 2005 15:00:44 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs X-Return-Path: X-Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9RLjQ5B014279 for ; Thu, 27 Oct 2005 14:45:26 -0700 X-Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVFTA-0002Ul-3m for rtg-chairs@optimus.ietf.org; Thu, 27 Oct 2005 17:39:32 -0400 X-Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19048; Thu, 27 Oct 2005 17:39:15 -0400 (EDT) X-Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVFga-0001fw-Dr; Thu, 27 Oct 2005 17:53:25 -0400 X-Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EVFT4-000LBP-Jz; Thu, 27 Oct 2005 21:39:26 +0000 Date: Thu, 27 Oct 2005 14:39:12 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <393302246.20051027143912@psg.com> To: routing-discussion@ietf.org, saag@mit.edu, idr@ietf.org, rtg-dir@ietf.org, rtg-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit ReSent-Date: Thu, 27 Oct 2005 14:58:21 -0700 (PDT) ReSent-From: Tony Tauber ReSent-To: rpsec@ietf.org ReSent-Subject: Secure Interdomain Routing BOF ReSent-Message-ID: X-Spam-Score: 0.8 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: Subject: [RPSEC] Secure Interdomain Routing BOF X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Folks- We're going to have a BOF in Vancouver to discuss mechanisms for securing Internet inter-domain routing. Please subscribe to the list, and mark you calendars. Information below. It is currently scheduled on Thur, 9:00-11:30am. -- Alex http://www.psg.com/~zinin Name of the BOF: Secure Interdomain Routing (SIDR) Area: Routing Chairs: Geoff Huston Sponsoring ADs: Alex Zinin, Bill Fenner The RPSEC WG has been working on security requirements for the Internet routing system in general and the BGP routing protocol in particular. While considerable progress has been made so far, formulation of the complete set of requirements can take some time. At the same time, there's a shared understanding in the IETF community that architectural and protocol work on securing interdomain routing needs to start, as it will take time to formulate an architectural approach and associated protocol interactions, develop implementations and see first deployments. The goal of this BOF is to discuss creation of an extensible interdomain routing security architecture that would form the foundation of an approach that incrementally defines security features for BGP, while the discussion on requirements progresses. The expected outcome is an agreement on the initial set of security features that such an architecture would provide. It is not a goal of this BOF to choose between SBGP and SoBGP. Agenda: 1. Introduction and current status [15m] 2. Brief overview of currently proposed solutions [30m] 3. Description of proposed work [15m] 4. Discussion [60m] Mailing list: sidr@ietf.org To subscribe: sidr-request@ietf.org Reading material: Requirements: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-07.txt http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-02.txt SoBGP: http://www.ietf.org/internet-drafts/draft-white-sobgp-architecture-01.txt http://www.ietf.org/internet-drafts/draft-ng-sobgp-bgp-extensions-01.txt http://www.ietf.org/internet-drafts/draft-weis-sobgp-certificates-01.txt SBGP: SBGP web page: http://www.net-tech.bbn.com/sbgp/sbgp-index.html _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec