From rpsec-bounces@ietf.org Fri Jul 07 14:51:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyvPz-0000h5-H3; Fri, 07 Jul 2006 14:51:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyvPy-0000h0-L9 for rpsec@ietf.org; Fri, 07 Jul 2006 14:51:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyvPy-0001Kq-Jj for rpsec@ietf.org; Fri, 07 Jul 2006 14:51:10 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyvPx-0000bA-4g for rpsec@ietf.org; Fri, 07 Jul 2006 14:51:10 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k67Io1gt001728 for ; Fri, 7 Jul 2006 14:50:01 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAP5a4td; Fri, 7 Jul 06 14:49:52 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k67ImflF001709; Fri, 7 Jul 2006 14:48:41 -0400 (EDT) Date: Fri, 7 Jul 2006 14:48:41 -0400 (EDT) Message-Id: <200607071848.k67ImflF001709@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org X-Spam-Score: -2.6 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sandy@tislabs.com Subject: [RPSEC] about the meeting at IETF 66 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: , Errors-To: rpsec-bounces@ietf.org In the last month there have been discussions on the mailing list of the status of the milestone changes, and announcements of two new drafts, and a suggestion of looking at the draft-manral-rpsec-existing-crypto-02.txt draft. That sounds to me like we have some topics for discussion at the rpsec meeting. But no agenda was posted. I hope the lack of an agenda does not mean that we won't meet. Do the wg chairs have an agenda in mind? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 10 16:49:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02gy-0004nt-OY; Mon, 10 Jul 2006 16:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02gx-0004no-57 for rpsec@ietf.org; Mon, 10 Jul 2006 16:49:19 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G02gw-00071A-Lq for rpsec@ietf.org; Mon, 10 Jul 2006 16:49:19 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6AKtdFx003009; Mon, 10 Jul 2006 16:55:39 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607102055.k6AKtdFx003009@workhorse.brookfield.occnc.com> To: sandy@tislabs.com Subject: Re: [RPSEC] about the meeting at IETF 66 In-reply-to: Your message of "Fri, 07 Jul 2006 14:48:41 EDT." <200607071848.k67ImflF001709@tislabs.com> Date: Mon, 10 Jul 2006 16:55:39 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <200607071848.k67ImflF001709@tislabs.com> sandy@tislabs.com writes: > > In the last month there have been discussions on the mailing list of > the status of the milestone changes, and announcements of two new > drafts, and a suggestion of looking at the > draft-manral-rpsec-existing-crypto-02.txt draft. > > That sounds to me like we have some topics for discussion at the rpsec > meeting. > > But no agenda was posted. > > I hope the lack of an agenda does not mean that we won't meet. > > Do the wg chairs have an agenda in mind? > > --Sandy Sandy, When the topic of security has been discussed in IDR I and a few others had been reminding the WG that common provider practices provide a great deal of protection which makes up for weak cryptographic protection of MD5 and no amount of cryptographic protection prevents denail of service attacks which those provider practices very effectively prevent. Briefly, the practices are inbound filtering of BGP and OSPF and use of GTSM. IS-IS is not forwarded at all so not an issue. By not allowing OSPF and BGP from outside the network to be forwarded into the network, a perimeter is established, where inside denial of service and other attacks are not possible, so long as the perimeter is not seriously compromised. At the perimeter, BGP is spoken with the immediate peer router and GTSM can be used. An OSPF adjacency could be established but in practice rarely if ever is. GTSM provides protection against attacks from more than one hop away. If the immediate peer router is compromised. then a denial of service attack from the immediate peer is possible but for modern routers that denial of service would only affect the peering with the compromised router, which being compromised already is a more serious threat due to ability to inject false routing information with the peering up. Both protocol (OSPF) and port (BGP, TCP 179) packet filtering and GTSM's TTL based filtering can be performed by routers at full line rate making a denial of service attack against routing based on traffic levels impossible. This is not the case for cryptographic protection alone. ISPs have not been very concerned about the weakness in MD5 since any form of cryptographic protection is regarded as an additional redundant and only partially effective form of protection. The filtering capability and traffic attack hardenning on external peerings can be cited as a requirement for routers. In practice these are far more important requirements than good crypto for an ISP network. A caveat of the filtering based protection alone is that any compromise within the protected perimeter opens the possiblity of attack from within the perimeter. This is a house of cards problem. If a core router today often with many tens of OC192c interfaces were compromised, there are is very substantial potentials for denial of service attacks, not just against routing. There would also be the ability to inject false routing information. Any major provider today, being that they are attacked more or less constantly, does not allow routing peerings outside the set of infrastructure routers except route filtered peerings to customers at the network perimeter, route filtered or unfiltered peering with major peer providers, and one way peerings to their own NMS hosts or subnets. Of these the most credible threat is from NMS hosts, both on external subnets, and embedded within the infrastructure (the pizza box 1U server in the POP used by many providers, though often these are just 100baseT interfaces). Perhaps rpsec-existing-crypto is not the place for this information, but it would be useful for RPSEC to document this as BCP. I also recognize that there may be other applications of IP routing where traffic volume is not as much of an issue (adhoc wireless for example) and where either compromise of infrastructure hosts might be possible (physical compromise, for example) or where the channels cannot be assumed to be secure (wireless or other). In those situations, crypto security is needed and filtering is ineffective. Any BCP on this topic should recognize both types of situation and point out where each type of solution is applicable. And of course if fiber carrying bundles of OC192c or other 10Gb/s or higher encapsulations is compromised, there is no technology today that can protect agains the resulting denial of service attack. At that point the link (or set of logical links) has to be shut down. btw- If you really want to address lack of physical security better, promoting strong encryption on non-volitile storage would be a good idea. It was well known that telco personnel were stealing the flash cards from a certain type of router until the router was modified such that some minimal disassembly was required and logging and NM traps were added if the flash was removed. Those flash were being sold as PC hardware but also had complete router configurations on them. If you really wanted to be secure, the entire filesystem, not just access passwords, would be encrypted such that the operator would have to provide information if power were completely removed (not just across a reload). Physically removing hardware would do nothing initially until the crypto was cracked which would at least take time, and as long as the physical compromise was detected and acted on, keys elsewhere could be changed before cracking completed. Please let me know, on the WG list or offline, how and if this sort of thing might fit into RPSEC. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 10 18:23:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G049r-0000fs-TF; Mon, 10 Jul 2006 18:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G049q-0000fn-QZ for rpsec@ietf.org; Mon, 10 Jul 2006 18:23:14 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G049q-0005Df-D3 for rpsec@ietf.org; Mon, 10 Jul 2006 18:23:14 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6AMNAw8003322 for ; Tue, 11 Jul 2006 01:23:10 +0300 Date: Tue, 11 Jul 2006 01:23:10 +0300 (EEST) From: Pekka Savola To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1589/Fri Jul 7 17:37:51 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [RPSEC] generic routing security overview 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: , Errors-To: rpsec-bounces@ietf.org Hi, Based on recent discussion and checking the charter, it seems that RPSEC might be interested in: draft-savola-rtgwg-backbone-attacks-01.txt (it's reasonably short!) Abstract A number of countermeasures for attacks against service provider backbone network infrastructure have been specified or proposed, each of them usually targeting a subset of the problem space. There has never been a more generic analysis of the actual problems, and which countermeasures are even necessary (and where). This document tries to provide that higher-level view. Does this belong to RPSEC, OPSEC, or somewhere else? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 11 09:56:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ij6-0004vy-Vr; Tue, 11 Jul 2006 09:56:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ij5-0004vL-Vd for rpsec@ietf.org; Tue, 11 Jul 2006 09:56:35 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Ij4-0000gM-K1 for rpsec@ietf.org; Tue, 11 Jul 2006 09:56:35 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k6BDuOoJ013600; Tue, 11 Jul 2006 06:56:24 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) with ESMTP id k6BDuKK3013544; Tue, 11 Jul 2006 06:56:20 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Tue, 11 Jul 2006 06:56:20 -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: 9466e0365fc95844abaf7c3f15a05c7d Subject: [RPSEC] Agenda for IETF-66 (Montreal) 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: , Errors-To: rpsec-bounces@ietf.org Routing Protocol Security Requirements WG (rpsec) Tuesday, July 11 at 1740-1840 =================================== CHAIRS: Russ White Tony Tauber AGENDA: Agenda Bashing Old Document Status Generic Threats BGP Attack Tree BGP Security Requirements T. Tauber draft-ietf-rpsec-bgpsecrec-06 OSPF Vulnerabilities O. Le Moigne draft-ietf-rpsec-ospf-vuln-02 Backbone Infrastructure Attacks and Protections P. Savola draft-savola-rtgwg-backbone-attacks-01 Issues with existing Cryptographic Protection Methods for Routing draft-manral-rpsec-existing-crypto-02 R. White Charter update and futures discussion R. White _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 11 13:46:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MJJ-0000zY-1c; Tue, 11 Jul 2006 13:46:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MJH-0000zT-Lu for rpsec@ietf.org; Tue, 11 Jul 2006 13:46:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0MJG-00035c-Cs for rpsec@ietf.org; Tue, 11 Jul 2006 13:46:11 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 Jul 2006 10:46:11 -0700 X-IronPort-AV: i="4.06,230,1149490800"; d="scan'208"; a="328352518:sNHT31070104" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k6BHk9ha009463; Tue, 11 Jul 2006 10:46:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6BHk9TQ011492; Tue, 11 Jul 2006 10:46:09 -0700 (PDT) Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 10:46:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Agenda for IETF-66 (Montreal) Date: Tue, 11 Jul 2006 10:46:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RPSEC] Agenda for IETF-66 (Montreal) Thread-Index: Acak8dvjXH4C8+wtQzeA1ymlaBIoiwAHb33A From: "Barry Greene \(bgreene\)" To: "Tony Tauber" , X-OriginalArrivalTime: 11 Jul 2006 17:46:09.0483 (UTC) FILETIME=[E497F9B0:01C6A511] DKIM-Signature: a=rsa-sha1; q=dns; l=579; t=1152639969; x=1153503969; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bgreene@cisco.com; z=From:=22Barry=20Greene=20\(bgreene\)=22=20 |Subject:RE=3A=20[RPSEC]=20Agenda=20for=20IETF-66=20(Montreal); X=v=3Dcisco.com=3B=20h=3Dak9RDQ0agZiJ2z7NeYfLo8Sy+MQ=3D; b=FXKo1suMnc8EnaJg75PVbXmEAkPfYumC1FRGr09xoGezpru4Zq7+ebtyFXbxS3x1Bjp4gIQY 3GomO6mItRgITI/JQawxwdoEGF0MpBC+rB4OjGng8C/zEpgCK9X4q6sN; Authentication-Results: sj-dkim-3.cisco.com; header.From=bgreene@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: rpsec-bounces@ietf.org =20 > Old Document Status > Generic Threats > BGP Attack Tree Can you add for the record RFC791, RFC1349, RFC2474, RFC3168, RFC2697, and RFC2598 ... Which is the body of work which set prec 6 & 7 and DSCP 48 & 56. This is one of the primary tools to protect big routers today (internal queue structures that separates things like log messages from an ASIC from a BGP update - insuring the log is dropped in favor of pushing the BGP update up to the RP). Alternatively, plugging this reference into one of the requirements documents would work. =20 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 12 16:53:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0lho-0007yN-8r; Wed, 12 Jul 2006 16:53:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0lhm-0007xE-EA for rpsec@ietf.org; Wed, 12 Jul 2006 16:53:10 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0lhk-0000bw-2U for rpsec@ietf.org; Wed, 12 Jul 2006 16:53:10 -0400 Received: from [132.219.22.236] (h16ec-net84db.lab.risq.net [132.219.22.236] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6CKqtCe076082 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 12 Jul 2006 22:52:56 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: rpsec@ietf.org From: Iljitsch van Beijnum Date: Wed, 12 Jul 2006 16:53:07 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.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: , Errors-To: rpsec-bounces@ietf.org A comment on something in http://www.ietf.org/internet-drafts/draft- ietf-rpsec-bgpsecrec-06.txt o A BGP security mechanism MUST provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non- backward compatible fashion though care must be taken to ensure UPDATES can traverse intermediate routers which don't support the new format. What this says is that if I have routers A and C that support the new security stuff, and B in the middle, that doesn't, the new security stuff must be encoded such that it can pass router B in the middle without confusing it. That is quite a hard thing to do, and I don't think it's actually worth it. First, consider the case of iBGP. In traditional iBGP, there is a full mesh between all the routers, so there is never a need to communicate security information between two upgraded router through a non-upgraded router since all routers talk to all other routers directly. This gets more complex with confederations and route reflectors, but I think in those cases it's not an undue requirement to upgrade certain routers such as the route reflectors first in order to make the transition go smoothly without the capability indicated above. With eBGP, the situation where there is a non-upgraded router between two upgraded routers means that seen from at least one of the ASes involved, the BGP peer is a non-upgraded one in a different AS, so it's impossible to determine whether this router is propagating correct information and/or propagate information correctly, so the extra security that's supposed to be provided by the new mechanisms is reduced or even absent. In these cases, would prefer to see a situation where the upgraded parts of the network are contiguous. Not requiring backwards compatible encoding allows more flexibility in designing the security mechanisms. For instance, S-BGP fullfils the requirement and encodes all information in path attributes, while soBGP doesn't and puts the information in a new BGP message, which allows more flexibility. Iljitsch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 13 15:56:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17IC-0001eA-JN; Thu, 13 Jul 2006 15:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17IB-0001ds-2v for rpsec@ietf.org; Thu, 13 Jul 2006 15:56:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G17I9-0004Wo-Rm for rpsec@ietf.org; Thu, 13 Jul 2006 15:56:11 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2006 12:56:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="32154725:sNHT22545624" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DJu9pW018799; Thu, 13 Jul 2006 15:56:09 -0400 Received: from [10.82.208.189] (rtp-vpn4-189.cisco.com [10.82.208.189]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DJu87t018301; Thu, 13 Jul 2006 15:56:09 -0400 (EDT) Message-ID: <44B6A538.10904@cisco.com> Date: Thu, 13 Jul 2006 15:55:36 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [RPSEC] generic routing security overview References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1234; t=1152820569; x=1153684569; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20generic=20routing=20security=20overview |To:Pekka=20Savola=20; X=v=3Dcisco.com=3B=20h=3DUw7kQGY3WpO4CH0JefDaAf+7Skg=3D; b=HfAS46JgQWMeFxU+AuLtupSMpwCkYoM48IQ+1RmZc9RO6sKRMbliahatMhxnlBLHPnvmTTPn IqgovodpUc72NdMotBJXH3bbXkmolDw9ltJa8KYbQPhf5KLCVnI4TkYv; Authentication-Results: rtp-dkim-2.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This seems to overlap somewhat with draft-lewis-infrastructure-security-00, perhaps? I'll leave it up to the ADs to decide where it should be, but I think it would fit in rpsec okay. :-) Russ Pekka Savola wrote: > Hi, > > Based on recent discussion and checking the charter, it seems that RPSEC > might be interested in: > > draft-savola-rtgwg-backbone-attacks-01.txt (it's reasonably short!) > > Abstract > A number of countermeasures for attacks against service provider > backbone network infrastructure have been specified or proposed, each > of them usually targeting a subset of the problem space. There has > never been a more generic analysis of the actual problems, and which > countermeasures are even necessary (and where). This document tries > to provide that higher-level view. > > Does this belong to RPSEC, OPSEC, or somewhere else? > - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtqU4ER27sUhU9OQRAmqrAJ9g0O1SuNcOOvz186RUPI4Kcz+qgwCfVRsp oizIsMczJqAn5UsBWVjf3Ig= =08cu -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 13 21:18:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1CJv-0004l0-CZ; Thu, 13 Jul 2006 21:18:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1CJu-0004kv-3L for rpsec@ietf.org; Thu, 13 Jul 2006 21:18:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G17Nx-0004zG-CO for rpsec@ietf.org; Thu, 13 Jul 2006 16:02:09 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G17Fj-0005E2-SM for rpsec@ietf.org; Thu, 13 Jul 2006 15:53:45 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2006 12:53:32 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="32154526:sNHT25190932" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DJrWHQ018124; Thu, 13 Jul 2006 15:53:32 -0400 Received: from [10.82.208.189] (rtp-vpn4-189.cisco.com [10.82.208.189]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DJrV7t017748; Thu, 13 Jul 2006 15:53:32 -0400 (EDT) Message-ID: <44B6A49A.8010104@cisco.com> Date: Thu, 13 Jul 2006 15:52:58 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> In-Reply-To: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1407; t=1152820412; x=1153684412; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20draft-ietf-rpsec-bgpsecrec-06.txt |To:Iljitsch=20van=20Beijnum=20; X=v=3Dcisco.com=3B=20h=3D0tejfNEVO5iRnK0m+zxIeMtCR+8=3D; b=dGHmX5g4sZbvoYtjPbdXSqN6JKC29lg8yqgk1Xi1qSkockZo37TIZrUuh9rMBavhDOrVytdn qhSICzt5agQqGMHlHAYwxyU57+r1cU/iTMdp5pftNzTKCky677/8rPOW; Authentication-Results: rtp-dkim-2.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: -1.3 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-06.txt > > o A BGP security mechanism MUST provide backward compatibility in > the message formatting, transmission, and processing of routing > information carried through a mixed security environment. Message > formatting in a fully secured environment MAY be handled in a non- > backward compatible fashion though care must be taken to ensure > UPDATES can traverse intermediate routers which don't support the > new format. It may be more reasonable to say something like: "A BGP security mechanism MUST be designed such that it can be used in discontiguous sections of the network. A peer running any such such security mechanism MUST interoperate with a peer not running the mechanism so normal routing is not disrupted at the connection points between peers running the security mechanism and not running the security mechanism." It's not perfect, but it might express what the real reason is behind this requirement better? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEtqSaER27sUhU9OQRAlCuAKCYxxGVam9PzWx5zuTPWrR1GWwGEgCg7uli QYvOFZMoWyL7hICz/MqAnf0= =onsg -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 14 09:14:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NVO-0007s9-So; Fri, 14 Jul 2006 09:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NVF-0007ra-Vy for rpsec@ietf.org; Fri, 14 Jul 2006 09:14:45 -0400 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1NFq-00005e-Qt for rpsec@ietf.org; Fri, 14 Jul 2006 08:58:52 -0400 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k6ECwc92032535; Fri, 14 Jul 2006 22:58:41 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060714225317.02e41ee0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 14 Jul 2006 22:58:23 +1000 To: Russ White , Iljitsch van Beijnum From: Geoff Huston Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-Reply-To: <44B6A49A.8010104@cisco.com> References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: rpsec-bounces@ietf.org At 05:52 AM 14/07/2006, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > > http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-06.txt > > > > o A BGP security mechanism MUST provide backward compatibility in > > the message formatting, transmission, and processing of routing > > information carried through a mixed security environment. Message > > formatting in a fully secured environment MAY be handled in a non- > > backward compatible fashion though care must be taken to ensure > > UPDATES can traverse intermediate routers which don't support the > > new format. > >It may be more reasonable to say something like: > >"A BGP security mechanism MUST be designed such that it can be used in >discontiguous sections of the network. A peer running any such such >security mechanism MUST interoperate with a peer not running the >mechanism so normal routing is not disrupted at the connection points >between peers running the security mechanism and not running the >security mechanism." > >It's not perfect, but it might express what the real reason is behind >this requirement better? I'm not sure that your intent is clear - one way to meet your formulation of the requirement is to drop all security-extension material at the interface with the non-equipped peer. Is this an intentional option in your proposed wording? An alternative is that you want to express that security information should be preserved across non-equipped path sectors, and that the information and that when the information re-enters an equipped peer it can be 'revived' (with the knowledge that there has been a discontinuity in the security-aware path). regards, Geoff _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 14 11:46:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Ps8-0001cH-7h; Fri, 14 Jul 2006 11:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Ps6-0001YY-V0 for rpsec@ietf.org; Fri, 14 Jul 2006 11:46:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1PUy-0006co-9Y for rpsec@ietf.org; Fri, 14 Jul 2006 11:22:36 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1PEY-0007uA-FT for rpsec@ietf.org; Fri, 14 Jul 2006 11:05:41 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G1PEP-000324-3H; Fri, 14 Jul 2006 11:05:29 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <44B6A49A.8010104@cisco.com> References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> Date: Fri, 14 Jul 2006 11:05:28 -0400 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.6 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org, Iljitsch van Beijnum 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: , Errors-To: rpsec-bounces@ietf.org At 3:52 PM -0400 7/13/06, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >> http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-06.txt >> >> o A BGP security mechanism MUST provide backward compatibility in >> the message formatting, transmission, and processing of routing >> information carried through a mixed security environment. Message >> formatting in a fully secured environment MAY be handled in a non- >> backward compatible fashion though care must be taken to ensure >> UPDATES can traverse intermediate routers which don't support the >> new format. > >It may be more reasonable to say something like: > >"A BGP security mechanism MUST be designed such that it can be used in >discontiguous sections of the network. A peer running any such such >security mechanism MUST interoperate with a peer not running the >mechanism so normal routing is not disrupted at the connection points >between peers running the security mechanism and not running the >security mechanism." > >It's not perfect, but it might express what the real reason is behind >this requirement better? > >:-) > >Russ I think your reformulated text is clearer in terms of the need to be able to specify whether a given peer is or is not running the security mechanism. However, like Geoff, I am still bothered a bit by the first line, because there is no clear description of what one expects to get in the way of security services from discontinuous deployment. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 14 12:10:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QFC-0006sh-II; Fri, 14 Jul 2006 12:10:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1QFB-0006sP-5T for rpsec@ietf.org; Fri, 14 Jul 2006 12:10:21 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1PVB-0006co-Tu for rpsec@ietf.org; Fri, 14 Jul 2006 11:22:49 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1P3f-0007eq-3S for rpsec@ietf.org; Fri, 14 Jul 2006 10:54:24 -0400 Received: from [132.219.22.236] (h16ec-net84db.lab.risq.net [132.219.22.236] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6EEs1vt018523 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 14 Jul 2006 16:54:02 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <6.2.0.14.2.20060714225317.02e41ee0@localhost> References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> <6.2.0.14.2.20060714225317.02e41ee0@localhost> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89270232-C635-4CA7-94AA-3D2B25FAFA6A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Date: Fri, 14 Jul 2006 10:54:17 -0400 To: Geoff Huston X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.6 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Errors-To: rpsec-bounces@ietf.org On 14-jul-2006, at 8:58, Geoff Huston wrote: >> It may be more reasonable to say something like: >> "A BGP security mechanism MUST be designed such that it can be >> used in >> discontiguous sections of the network. A peer running any such such >> security mechanism MUST interoperate with a peer not running the >> mechanism so normal routing is not disrupted at the connection points >> between peers running the security mechanism and not running the >> security mechanism." >> It's not perfect, but it might express what the real reason is behind >> this requirement better? > I'm not sure that your intent is clear I agree, it's still possible to interpret this in different ways. > one way to meet your formulation > of the requirement is to drop all security-extension material at > the interface > with the non-equipped peer. Is this an intentional option in your > proposed > wording? An alternative is that you want to express that security > information > should be preserved across non-equipped path sectors, and that the > information and that when the information re-enters an equipped peer > it can be 'revived' (with the knowledge that there has been a > discontinuity > in the security-aware path). The latter option is exactly the one I find problematic because it assumes that the security information is carried in existing fields, i.e. path attributes, which I fear is a big burden on the BGP protocol. What we need to think about is when two parts of the network where the new security mechanisms are deployed are separated by un-upgraded routers, to what degree do we want security advantages to carry over from one secure part to the other? Obviously any kind of path security will be compromised but some kind of AS/prefix mapping security could be maintained. Maybe this is a good idea, but I would rather not require it without knowing the tradeoffs. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 14 15:29:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1TLW-0004Ww-60; Fri, 14 Jul 2006 15:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1TLU-0004Wr-PY for rpsec@ietf.org; Fri, 14 Jul 2006 15:29:04 -0400 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1TLU-0006bg-5T for rpsec@ietf.org; Fri, 14 Jul 2006 15:29:04 -0400 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k6EJSsKx009322; Sat, 15 Jul 2006 05:28:55 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060715052228.02d23f18@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 15 Jul 2006 05:27:22 +1000 To: Iljitsch van Beijnum From: Geoff Huston Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-Reply-To: <89270232-C635-4CA7-94AA-3D2B25FAFA6A@muada.com> References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> <6.2.0.14.2.20060714225317.02e41ee0@localhost> <89270232-C635-4CA7-94AA-3D2B25FAFA6A@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: rpsec-bounces@ietf.org >The latter option is exactly the one I find problematic because it >assumes that the security information is carried in existing fields, >i.e. path attributes, which I fear is a big burden on the BGP protocol. What I find problematic here is that the formulation I referred to assumed no such thing. >What we need to think about is when two parts of the network where >the new security mechanisms are deployed are separated by un-upgraded >routers, to what degree do we want security advantages to carry over >from one secure part to the other? You may care to read what I _actually_ posted. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 14 16:46:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1UYB-0001Dr-Q9; Fri, 14 Jul 2006 16:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1UYB-0001D7-7i for rpsec@ietf.org; Fri, 14 Jul 2006 16:46:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1UYA-0004Qz-03 for rpsec@ietf.org; Fri, 14 Jul 2006 16:46:15 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2006 13:46:13 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,245,1149490800"; d="scan'208"; a="32274869:sNHT22015468" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6EKkDN5023503; Fri, 14 Jul 2006 16:46:13 -0400 Received: from [10.82.208.189] (rtp-vpn4-189.cisco.com [10.82.208.189]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6EKkC7t015654; Fri, 14 Jul 2006 16:46:12 -0400 (EDT) Message-ID: <44B80271.7090709@cisco.com> Date: Fri, 14 Jul 2006 16:45:37 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1324; t=1152909973; x=1153773973; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20draft-ietf-rpsec-bgpsecrec-06.txt |To:Stephen=20Kent=20; X=v=3Dcisco.com=3B=20h=3D0tejfNEVO5iRnK0m+zxIeMtCR+8=3D; b=TLMqzmvdLC4EGbfhMTGSDvfNoudxTdYVbDjZ6yDSdAYAFESf2jKXI2Tl82Z2BJBJAquk3gBF CHBLyuxiTMq5zwuY2Giy6mNnAjm1vr/3chcF9v5ewPCr4dAXTUK1RJae; Authentication-Results: rtp-dkim-1.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org, Iljitsch van Beijnum 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I think your reformulated text is clearer in terms of the need to be > able to specify whether a given peer is or is not running the security > mechanism. However, like Geoff, I am still bothered a bit by the first > line, because there is no clear description of what one expects to get > in the way of security services from discontinuous deployment. Actually, I think there are actually two things going on in this section, and we might need to separate them, and consider them separately (?). They seem to be: - -- How a BGP speaker should react when running security mechanism x, and connecting to a BGP speaker that doesn't run that security mechanism. - -- Should a security mechanism be able to be deployed in a noncontiguous manner? Perhaps, if we split these two, we could come to some good wording for them separately? Since this is in the incremental deployment section, is the first sense really applicable in that area, or only the second? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEuAJxER27sUhU9OQRAiR/AKD1gz//yYrqPxLSlc8Ez601UJE1jACfcDL6 xXufCbj2n5KXwHehjej+27I= =ZiHp -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 14 17:50:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1VYO-0006ZU-0g; Fri, 14 Jul 2006 17:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1VYM-0006ZP-QV for rpsec@ietf.org; Fri, 14 Jul 2006 17:50:30 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1VYL-000463-Js for rpsec@ietf.org; Fri, 14 Jul 2006 17:50:30 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G1VYK-0003aU-4x; Fri, 14 Jul 2006 17:50:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <44B80271.7090709@cisco.com> References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> <44B80271.7090709@cisco.com> Date: Fri, 14 Jul 2006 17:26:01 -0400 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: rpsec@ietf.org, Iljitsch van Beijnum 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: , Errors-To: rpsec-bounces@ietf.org At 4:45 PM -0400 7/14/06, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >> I think your reformulated text is clearer in terms of the need to be >> able to specify whether a given peer is or is not running the security >> mechanism. However, like Geoff, I am still bothered a bit by the first >> line, because there is no clear description of what one expects to get >> in the way of security services from discontinuous deployment. > >Actually, I think there are actually two things going on in this >section, and we might need to separate them, and consider them >separately (?). They seem to be: > >- -- How a BGP speaker should react when running security mechanism x, and >connecting to a BGP speaker that doesn't run that security mechanism. > >- -- Should a security mechanism be able to be deployed in a noncontiguous >manner? > >Perhaps, if we split these two, we could come to some good wording for >them separately? Since this is in the incremental deployment section, is >the first sense really applicable in that area, or only the second? I think both are applicable here and should be split apart to increase clarity. For issue #2 there is the other question, one that I raised, i.e., what do we require of a solution that is deployed in a noncontiguous fashion? Do we have a way to characterize that or are we silent because it will be solution dependent? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Jul 15 09:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1jyU-0008OK-3G; Sat, 15 Jul 2006 09:14:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1jyT-0008OE-14 for rpsec@ietf.org; Sat, 15 Jul 2006 09:14:25 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1jyQ-0006U1-OV for rpsec@ietf.org; Sat, 15 Jul 2006 09:14:25 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2006 06:14:22 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,245,1149490800"; d="scan'208"; a="32308550:sNHT23963524" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6FDEMGC022987; Sat, 15 Jul 2006 09:14:22 -0400 Received: from [10.82.240.78] (rtp-vpn2-78.cisco.com [10.82.240.78]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6FDELdU002597; Sat, 15 Jul 2006 09:14:21 -0400 (EDT) Message-ID: <44B8EA09.5060201@cisco.com> Date: Sat, 15 Jul 2006 09:13:45 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> <44B80271.7090709@cisco.com> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2062; t=1152969262; x=1153833262; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20draft-ietf-rpsec-bgpsecrec-06.txt |To:Stephen=20Kent=20; X=v=3Dcisco.com=3B=20h=3D0tejfNEVO5iRnK0m+zxIeMtCR+8=3D; b=Z+/H4++5u27XtGXVuR5Cnk4qzSe6zzVH+KdHbmCqlyj4cYfT1ZvKfAxa7ItnrK7dV/mtDiQI 98c/yQjxy02qhv/aj6zgB6gxuXGjVFOYonWarY3qAzD0uZ55ZRWm4jrD; Authentication-Results: rtp-dkim-2.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: rpsec@ietf.org, Iljitsch van Beijnum 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> I think your reformulated text is clearer in terms of the need to be >>> able to specify whether a given peer is or is not running the security >>> mechanism. However, like Geoff, I am still bothered a bit by the first >>> line, because there is no clear description of what one expects to get >>> in the way of security services from discontinuous deployment. >> >> Actually, I think there are two things going on in this >> section, and we might need to separate them, and consider them >> separately (?). They seem to be: >> >> - -- How a BGP speaker should react when running security mechanism x, >> and >> connecting to a BGP speaker that doesn't run that security mechanism. >> >> - -- Should a security mechanism be able to be deployed in a >> noncontiguous >> manner? >> >> Perhaps, if we split these two, we could come to some good wording for >> them separately? Since this is in the incremental deployment section, is >> the first sense really applicable in that area, or only the second? > > I think both are applicable here and should be split apart to increase > clarity. For issue #2 there is the other question, one that I raised, > i.e., what do we require of a solution that is deployed in a > noncontiguous fashion? Do we have a way to characterize that or are we > silent because it will be solution dependent? That's a big issue--how do you characterize that? Maybe it's better to remain silent on it, but we should probably take a poll of the list, to see how folks think about it.... So, to the list: Do we want to try and craft language to talk about solutions being noncontiguously deployable, or should the draft remain silent on this point? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEuOoJER27sUhU9OQRAk+JAKDHZ00oUogarNgDMmixthlQLT/S2ACfWUzR Tw48J0JeIJ96vbFMGTQJNYE= =avS2 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 17 12:46:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2WEj-0000Jy-8D; Mon, 17 Jul 2006 12:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2WEg-0000EP-5n for rpsec@ietf.org; Mon, 17 Jul 2006 12:46:22 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2W3Q-0002r5-R0 for rpsec@ietf.org; Mon, 17 Jul 2006 12:34:46 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6HGXgJt002505 for ; Mon, 17 Jul 2006 12:33:42 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAaba44e; Mon, 17 Jul 06 12:33:39 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6HGWUvK004780; Mon, 17 Jul 2006 12:32:30 -0400 (EDT) Date: Mon, 17 Jul 2006 12:32:30 -0400 (EDT) Message-Id: <200607171632.k6HGWUvK004780@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org >- -- Should a security mechanism be able to be deployed in a noncontiguous >manner? > I don't know why the answer would be anything but a resounding YES! If a security mechanism could NOT be deployed in a noncontinguous manner, then I see only three possible deployment scenarios: (1) Never (2) Everywhere, all at the same time (3) Starting with the very first network to deploy, growing out from there, with any network interested in deploying the mechanism required to wait until the wave of deployment reached its peers. (And we won't mention the race condition of who goes first.) I don't view any of these as acceptable options. Am I interpreting the question too literally? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 17 19:42:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2cik-0002hi-8O; Mon, 17 Jul 2006 19:41:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2cij-0002hd-9u for rpsec@ietf.org; Mon, 17 Jul 2006 19:41:49 -0400 Received: from mxintern.kundenserver.de ([212.227.126.204] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2cih-00075R-Pc for rpsec@ietf.org; Mon, 17 Jul 2006 19:41:49 -0400 Received: from [85.115.9.178] (helo=[85.115.9.178]) by mxintern.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 4.34) id 1G2cif-0001Xe-9z; Tue, 18 Jul 2006 01:41:45 +0200 Message-ID: <44BC2031.7080804@schlund.net> Date: Tue, 18 Jul 2006 01:41:37 +0200 From: Stefan Mink User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Russ White Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> <44B80271.7090709@cisco.com> <44B8EA09.5060201@cisco.com> In-Reply-To: <44B8EA09.5060201@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rpsec@ietf.org, Iljitsch van Beijnum , 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: , Errors-To: rpsec-bounces@ietf.org Hi all, Russ White wrote: > So, to the list: Do we want to try and craft language to talk about > solutions being noncontiguously deployable, or should the draft remain > silent on this point? I hate the answer, but: it depends :] authentication data (e.g. authentication the path attribute or all the attribute of a route) is pretty much worthless from a security point of view when it traversed non-secured ASes (who changed what?). Somewhat or partially authenticated data doesn't help you.. origin authorization data is different here: it still helps although it travered non-secured ASes; (as long as we don't allow to symmetric signatures ala hash trees that depend on a contiguous application of the security mechanism). redistribution authorization data on the other hand is useless when its not contiguous. It doesn't really helps me to know that the penultimate AS was authorized to pass the route on the the last AS in the path if I can not check if that one is allowed to give me this route... In the end its rather a question of how puristic your standpoint is and what its worth to you in terms of money: do you only want to get informations that help you for sure in terms of security or are you in favor of a solution that may cost you initially more for unusable information, but it speeds up the global deployment process. My personal opinion: speed the process up. We'll be decades late anyway ;) Stefan _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 18 11:29:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rVR-0007lh-RK; Tue, 18 Jul 2006 11:29:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rVQ-0007l4-Fk for rpsec@ietf.org; Tue, 18 Jul 2006 11:29:04 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2rVP-0007em-38 for rpsec@ietf.org; Tue, 18 Jul 2006 11:29:04 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6IFS1oI027452 for ; Tue, 18 Jul 2006 11:28:01 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAABuayL1; Tue, 18 Jul 06 11:27:53 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6IFQlZ5014417; Tue, 18 Jul 2006 11:26:47 -0400 (EDT) Date: Tue, 18 Jul 2006 11:26:47 -0400 (EDT) Message-Id: <200607181526.k6IFQlZ5014417@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org >So, to the list: Do we want to try and craft language to talk about >solutions being noncontiguously deployable, or should the draft remain >silent on this point? The document does say that incremental deployment is a requirement. As I said in my message yesterday, I do not see any realistic plan for incremental deployment that was NOT noncontinguous. So I believe non-contiguous deployment is also a necessity. This seems so obvious to me that I don't understand why we are asking the question. If the necessity for noncontiguous deployment is not as obvious for others, I would vote for putting the language in. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 18 12:16:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2sFh-0000UF-PO; Tue, 18 Jul 2006 12:16:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2sFg-0000UA-Qh for rpsec@ietf.org; Tue, 18 Jul 2006 12:16:52 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2sFf-0003GO-L8 for rpsec@ietf.org; Tue, 18 Jul 2006 12:16:52 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G2sFe-0004qb-65; Tue, 18 Jul 2006 12:16:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200607181526.k6IFQlZ5014417@tislabs.com> References: <200607181526.k6IFQlZ5014417@tislabs.com> Date: Tue, 18 Jul 2006 12:15:34 -0400 To: sandy@tislabs.com From: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: rpsec@ietf.org, sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org Sandy, I think the question we are now asking is whether we can make any assertions about the security functionality that must provided in the context of incremental, non-contiguous deployment. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 18 18:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xuj-0001Zz-Lh; Tue, 18 Jul 2006 18:19:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2xui-0001Zp-AP for rpsec@ietf.org; Tue, 18 Jul 2006 18:19:36 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2xug-0005lt-UM for rpsec@ietf.org; Tue, 18 Jul 2006 18:19:36 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k6IMJPUp022098; Tue, 18 Jul 2006 15:19:25 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) with ESMTP id k6IMJJvA022090; Tue, 18 Jul 2006 15:19:19 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Tue, 18 Jul 2006 15:19:19 -0700 (PDT) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: Geoff Huston Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-Reply-To: <6.2.0.14.2.20060714225317.02e41ee0@localhost> Message-ID: References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> <6.2.0.14.2.20060714225317.02e41ee0@localhost> 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, Iljitsch van Beijnum , 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: , Errors-To: rpsec-bounces@ietf.org On Fri, 14 Jul 2006, Geoff Huston wrote: >> > http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-06.txt >> > >> > o A BGP security mechanism MUST provide backward compatibility in >> > the message formatting, transmission, and processing of routing >> > information carried through a mixed security environment. Message >> > formatting in a fully secured environment MAY be handled in a non- >> > backward compatible fashion though care must be taken to ensure >> > UPDATES can traverse intermediate routers which don't support the >> > new format. > you want to express that security information should be preserved > across non-equipped path sectors, and that the information and that > when the information re-enters an equipped peer it can be 'revived' > (with the knowledge that there has been a discontinuity in the > security-aware path). > > regards, > > Geoff I like this. How about: A BGP security mechanism MUST provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non- backward compatible fashion though care must be taken to ensure UPDATES can traverse intermediate routers which don't support the new format. Note that security information SHOULD be preserved across non-equipped path sectors, and when the information re-enters an equipped peer it can be 'revived' (with the knowledge that there has been a discontinuity in the security-aware path). Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 18 19:49:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2zIE-00056F-6m; Tue, 18 Jul 2006 19:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2zID-000569-D1 for rpsec@ietf.org; Tue, 18 Jul 2006 19:47:57 -0400 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2zI9-0001wi-ND for rpsec@ietf.org; Tue, 18 Jul 2006 19:47:57 -0400 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k6INlLqe028562; Wed, 19 Jul 2006 09:47:25 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060719094627.030b49f8@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 19 Jul 2006 09:47:19 +1000 To: Tony Tauber From: Geoff Huston Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: rpsec@ietf.org, Iljitsch van Beijnum , 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: , Errors-To: rpsec-bounces@ietf.org >> >>I like this. How about: >> >> A BGP security mechanism MUST provide backward compatibility in >> the message formatting, transmission, and processing of routing >> information carried through a mixed security environment. Message >> formatting in a fully secured environment MAY be handled in a non- >> backward compatible fashion though care must be taken to ensure >> UPDATES can traverse intermediate routers which don't support the >> new format. Note that security information SHOULD be preserved >> across non-equipped path sectors, and when the information re-enters >> an equipped peer it can be 'revived' (with the knowledge that there >> has been a discontinuity in the security-aware path). >> >>Tony works for me ! Geoff _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 19 14:26:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Gkb-0007Hx-Ly; Wed, 19 Jul 2006 14:26:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Gkb-0007Ha-3q for rpsec@ietf.org; Wed, 19 Jul 2006 14:26:25 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3GkZ-0006Rm-OS for rpsec@ietf.org; Wed, 19 Jul 2006 14:26:25 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6JIQ3Nx041163 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 19 Jul 2006 20:26:03 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <6.2.0.14.2.20060715052228.02d23f18@localhost> References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> <6.2.0.14.2.20060714225317.02e41ee0@localhost> <89270232-C635-4CA7-94AA-3D2B25FAFA6A@muada.com> <6.2.0.14.2.20060715052228.02d23f18@localhost> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <70F8C321-9D49-4DC8-B06E-CF813E1759C3@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Date: Wed, 19 Jul 2006 20:26:16 +0200 To: Geoff Huston X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: rpsec-bounces@ietf.org On 14-jul-2006, at 21:27, Geoff Huston wrote: >> The latter option is exactly the one I find problematic because it >> assumes that the security information is carried in existing fields, >> i.e. path attributes, which I fear is a big burden on the BGP >> protocol. > What I find problematic here is that the formulation I referred to > assumed no such thing. Well, if you know of a way to carry new information through an unupgraded router other than in existing fields (= path attributes in the case of a BGP update) then I'm all ears. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jul 19 14:45:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3H3B-0000Jz-Fz; Wed, 19 Jul 2006 14:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3H39-0000Ju-P0 for rpsec@ietf.org; Wed, 19 Jul 2006 14:45:35 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3H38-000107-AM for rpsec@ietf.org; Wed, 19 Jul 2006 14:45:35 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6JIjFLw041489 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 19 Jul 2006 20:45:15 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> <6.2.0.14.2.20060714225317.02e41ee0@localhost> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <546F649B-6D5C-4DAE-BF8F-9B8008AB8ADD@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Date: Wed, 19 Jul 2006 20:45:29 +0200 To: Tony Tauber X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Errors-To: rpsec-bounces@ietf.org On 19-jul-2006, at 0:19, Tony Tauber wrote: > A BGP security mechanism MUST provide backward compatibility in > the message formatting, transmission, and processing of routing > information carried through a mixed security environment. Message > formatting in a fully secured environment MAY be handled in a non- > backward compatible fashion If I were to nit pick I'd point out that what happens between A and B has no relation to what happens between B and C so this wording is not the greatest ever, but I guess it's good enough. > though care must be taken to ensure > UPDATES can traverse intermediate routers which don't support the > new format. Updates don't traverse intermediate routers. The BGP spec is very particular about how newly defined path attributes must be handled, so what we need is: If a BGP security mechanism provides new BGP messages, or new ways to interpret or handle existing BGP messages, the new messages and the new semantics for the existing messages MUST NOT be used towards a particular neighboring BGP speaker unless the capability to use the new mechanism has been mutually announced during the BGP capability negotiation at session establishment. And probably: The designers of a new BGP security mechanisms should carefully evaluate the tradeoffs of encoding security information in ways that allow it to be communicated from one BGP router implementing the mechanisms to another through an intermediate, non-upgraded router, versus dropping information on the borders between upgraded and non-upgraded parts of the network. The former is more appropriate when security benefits can be had even when intermediate routers are unaware of the new mechanism or part thereof (or even actively try to subvert them), while the latter is more appropriate when the mechanisms or a particular part thereof are rendered unusable when traversing an non-upgraded router. Another consideration is the amount of extra state that is injected into non-upgraded parts of the network by encoding security information in path attributes in Update messages, considering that many existing implementations do not support the capability to filter unknown path attributes. And maybe: An updated BGP speaker MAY be configured to not operate in a backward compatible manner. In this case, a suitable error condition SHOULD be indicated in a BGP Notification message and the session be terminated. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 11:56:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3asy-0005C4-D8; Thu, 20 Jul 2006 11:56:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3asw-0005B1-Cz for rpsec@ietf.org; Thu, 20 Jul 2006 11:56:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Y9e-0005QL-2l for rpsec@ietf.org; Thu, 20 Jul 2006 09:01:26 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3Y8p-0001z1-7G for rpsec@ietf.org; Thu, 20 Jul 2006 09:00:37 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2006 06:00:34 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,161,1151910000"; d="scan'208"; a="32757538:sNHT26345972" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6KD0YLI013494; Thu, 20 Jul 2006 09:00:34 -0400 Received: from [10.82.225.89] (rtp-vpn1-345.cisco.com [10.82.225.89]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6KD0XdU007178; Thu, 20 Jul 2006 09:00:33 -0400 (EDT) Message-ID: <44BF7E6B.70807@cisco.com> Date: Thu, 20 Jul 2006 09:00:27 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> <6.2.0.14.2.20060714225317.02e41ee0@localhost> <546F649B-6D5C-4DAE-BF8F-9B8008AB8ADD@muada.com> In-Reply-To: <546F649B-6D5C-4DAE-BF8F-9B8008AB8ADD@muada.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2480; t=1153400434; x=1154264434; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20draft-ietf-rpsec-bgpsecrec-06.txt |To:Iljitsch=20van=20Beijnum=20; X=v=3Dcisco.com=3B=20h=3D0tejfNEVO5iRnK0m+zxIeMtCR+8=3D; b=K6uYQHo+kEElV3Eadj0wYg9aNgwWALQ+k8RR1pVYrGj9oSc40NYJHQGCsrZNgtGwgxgbz2lL AYNYm2gfxRFAMknaSuORXHhtlAE9wIhdcf8Gw4W3WewCPNTmsDXRdWlc; Authentication-Results: rtp-dkim-2.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: -1.9 (-) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The designers of a new BGP security mechanisms should carefully > evaluate the tradeoffs of encoding security information in ways that > allow it to be communicated from one BGP router implementing the > mechanisms to another through an intermediate, non-upgraded router, > versus dropping information on the borders between upgraded and > non-upgraded parts of the network. The former is more appropriate > when security benefits can be had even when intermediate routers > are unaware of the new mechanism or part thereof (or even actively > try to subvert them), while the latter is more appropriate when the > mechanisms or a particular part thereof are rendered unusable when > traversing an non-upgraded router. Another consideration is the > amount of extra state that is injected into non-upgraded parts of > the network by encoding security information in path attributes > in Update messages, considering that many existing implementations > do not support the capability to filter unknown path attributes. I think the problem here is that the "sense of the list" is any proposed security mechanism must have the former property--that the information must be useful, in some way, even when it has passed through an AS and/or peer that doesn't understand it. At least that's my understanding.... I would say I like your initial paragraph wording, but the remainder of Tony's (?). Perhaps: If a BGP security mechanism provides new BGP messages, or new ways to interpret or handle existing BGP messages, the new messages and the new semantics for the existing messages MUST NOT be used towards a particular neighboring BGP speaker unless the capability to use the new mechanism has been mutually announced during the BGP capability negotiation at session establishment. Security information SHOULD be preserved across non-equipped path sectors, and when the information re-enters an equipped peer it can be 'revived' (with the knowledge that there has been a discontinuity in the security-aware path). Or something of that type? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEv35rER27sUhU9OQRAjCKAKDBrinJjqnpUujJSNt0w+RgrdDoRACeLQwX ZuJLKEaGG3RadRs//3brrgI= =sTHh -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 12:55:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3boR-0008NK-2r; Thu, 20 Jul 2006 12:55:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bns-0007vm-SL for rpsec@ietf.org; Thu, 20 Jul 2006 12:55:12 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3bbT-0003Nj-0e for rpsec@ietf.org; Thu, 20 Jul 2006 12:42:25 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6KGfLmD016208 for ; Thu, 20 Jul 2006 12:41:21 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAEdaiPF; Thu, 20 Jul 06 12:41:17 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6KGeCFn015253; Thu, 20 Jul 2006 12:40:12 -0400 (EDT) Date: Thu, 20 Jul 2006 12:40:12 -0400 (EDT) Message-Id: <200607201640.k6KGeCFn015253@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org > If a BGP security mechanism provides new BGP messages, or new ways > to interpret or handle existing BGP messages, the new messages and > the new semantics for the existing messages MUST NOT be used > towards a particular neighboring BGP speaker unless the capability > to use the new mechanism has been mutually announced during > the BGP capability negotiation at session establishment. If this is to be a requirement, I'd like to inquire as to the exact meaning here. By "new BGP messages", do we mean messages in the BGP definition of message types? So new attributes would not be considered new messages? BGP has a mechanism for dealing with new attributes without requiring negotiation of same - define the attribute as optional transitive and it can be passed along without being recognized. Are we setting a higher bar for security mechanisms, and if so, why? I'm also not sure what the "new ways to interpret or handle existing BGP messages" means and why it is of concern. "Drop bogus updates" could be a new way to interpret messages, but such interpretation should not even by seen by a clueless recipient, so I don't see why it would require negotiation. Yes, there could be handling of existing messages that would result in changes in what the recipient would see and so might affect the recipient, even if the recipient was going to ignore them (bandwidth, etc.). But making this a requirement that covers *all* changes in handling is too broad. The statement as made prohibits new security information from being carried through a clueless area to a clueful AS on the other side. Is that what is desired here? An AS might have reasons for believing that an AS that was not participating in a security mechanism might still be expected to retain the security properties the security mechanism was protecting. So it is not necessarily true that the security information is of no use whatsoever on the other side of a gap. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 13:54:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cj0-0008QA-Dh; Thu, 20 Jul 2006 13:54:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ciz-0008PL-5M for rpsec@ietf.org; Thu, 20 Jul 2006 13:54:13 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3cYH-0002G4-2I for rpsec@ietf.org; Thu, 20 Jul 2006 13:43:10 -0400 Received: from col-dhcp33-244-172.bbn.com ([128.33.244.172]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G3cYF-00085T-5z; Thu, 20 Jul 2006 13:43:08 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> <6.2.0.14.2.20060714225317.02e41ee0@localhost> Date: Thu, 20 Jul 2006 13:43:05 -0400 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rpsec@ietf.org, Iljitsch van Beijnum , Geoff Huston , 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: , Errors-To: rpsec-bounces@ietf.org At 3:19 PM -0700 7/18/06, Tony Tauber wrote: >... >I like this. How about: > > A BGP security mechanism MUST provide backward compatibility in > the message formatting, transmission, and processing of routing > information carried through a mixed security environment. Message > formatting in a fully secured environment MAY be handled in a non- > backward compatible fashion though care must be taken to ensure > UPDATES can traverse intermediate routers which don't support the > new format. Note that security information SHOULD be preserved > across non-equipped path sectors, and when the information re-enters > an equipped peer it can be 'revived' (with the knowledge that there > has been a discontinuity in the security-aware path). I think this is ambiguous in several places, and too specific in others. The allusion to "message formatting" seems ambiguous. It might mean that security data is sent via a new protocol on a new port, for example. An UPDATE should be able to traverse a router that is not cognizant of the security technology, especially if the UPDATE is not carrying security data, or if the data is carried in a fashion consistent with BGP extension mechanisms, etc. The notion of security info being "revived" seems to imply a specific implementation approach, which is inappropriate for a requirements document of this sort. I'm just noting how hard it is to generate good requirements text here, without imposing pre-conceptions on the solution space. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 13:54:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cj6-00009f-6I; Thu, 20 Jul 2006 13:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cj0-0008Q5-Jw for rpsec@ietf.org; Thu, 20 Jul 2006 13:54:14 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3cV6-0001tT-7Q for rpsec@ietf.org; Thu, 20 Jul 2006 13:39:52 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6KHk49C012649; Thu, 20 Jul 2006 13:46:04 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607201746.k6KHk49C012649@workhorse.brookfield.occnc.com> To: Russ White Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Thu, 20 Jul 2006 09:00:27 EDT." <44BF7E6B.70807@cisco.com> Date: Thu, 20 Jul 2006 13:46:04 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: rpsec@ietf.org, Tony Tauber , Iljitsch van Beijnum X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <44BF7E6B.70807@cisco.com> Russ White writes: > > > > The designers of a new BGP security mechanisms should carefully > > evaluate the tradeoffs of encoding security information in ways that > > allow it to be communicated from one BGP router implementing the > > mechanisms to another through an intermediate, non-upgraded router, > > versus dropping information on the borders between upgraded and > > non-upgraded parts of the network. The former is more appropriate > > when security benefits can be had even when intermediate routers > > are unaware of the new mechanism or part thereof (or even actively > > try to subvert them), while the latter is more appropriate when the > > mechanisms or a particular part thereof are rendered unusable when > > traversing an non-upgraded router. Another consideration is the > > amount of extra state that is injected into non-upgraded parts of > > the network by encoding security information in path attributes > > in Update messages, considering that many existing implementations > > do not support the capability to filter unknown path attributes. > > I think the problem here is that the "sense of the list" is any proposed > security mechanism must have the former property--that the information > must be useful, in some way, even when it has passed through an AS > and/or peer that doesn't understand it. > > At least that's my understanding.... > > I would say I like your initial paragraph wording, but the remainder of > Tony's (?). > > Perhaps: > > If a BGP security mechanism provides new BGP messages, or new ways > to interpret or handle existing BGP messages, the new messages and > the new semantics for the existing messages MUST NOT be used > towards a particular neighboring BGP speaker unless the capability > to use the new mechanism has been mutually announced during > the BGP capability negotiation at session establishment. > > Security information SHOULD be preserved > across non-equipped path sectors, and when the information re-enters > an equipped peer it can be 'revived' (with the knowledge that there > has been a discontinuity in the security-aware path). > > Or something of that type? > > :-) > > Russ Russ, Hope this helps... feel free to use this and further wordsmith as needed. BPG security mechanisms differ in the following ways. 1. The scope of key distribution may be local or global. a. A BGP security mechanism may use a transitive trust model, b. A BGP security mechanism may use a form of authentication where keys are globally available and provide authentication information which is globally verifiable. c. A BGP security mechanism may use both of the above using one scope for one type of information and another scope for another type of information. 2. A BGP security mechanisms may authenticate (or encrypte) different types of information including combination of the following. a. A BGP security mechanism may provide authentication of the origin or or information related to the origin. b. A BGP security mechanism may provide authentication of the BGP peer. c. A BGP security mechanism may provide authentication of each AS in the path. For example, a BGP security mechanism may provide authentication of origin based on a key that is global is scope and rely on a transitive authentication of the path using keys that are local in scope. Ideally a BPG security mechanism would have the following properties. 1. The security information would be passed intact but uninterpreted across routers that did not support the same security mechanism. 2. A router implementing the security mechanism could distinguish between the following levels of trust. a. A routing announcement was originated from a router that supported the same security mechanism, and traversed only routers that support the same security mechanism. b. A routing announcement that was originated from a router that supported the same security mechanism, but traversed some routers that did not supported the same security mechanism. c. A routing announcement that was originated from a router that did not supported the same security mechanism. Any BGP security mechanism that supports only authentication of the origin cannot distinguish between case "a" and "b" above. Given the above properties, a router could implement policy which considered the above levels of trust. This routing policy could determine whether to accept the route. This routing policy could modify the route selection. If the route selection is modified based on level of trust, an entire AS MUST implement the same route selection to avoid loops. Orderly transition of the AS must be considered. Note that one way to accomplish a transition that if free of persitant loops during the transition is to make the route selection change conditional on the absence of an intra-AS BGP community which is set on every route during the transition, then removed. The transition then occurs on a per route basis as the BGP community is removed. To accompish an orderly transition using this method, BGP community MUST be supported by the implementation in any policy that modifies the route selection. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 17:42:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gIF-0003qO-Eu; Thu, 20 Jul 2006 17:42:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gIB-0003nX-MF for rpsec@ietf.org; Thu, 20 Jul 2006 17:42:47 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3gCV-0001s5-S4 for rpsec@ietf.org; Thu, 20 Jul 2006 17:36:57 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6KLaU8e073718 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Jul 2006 23:36:31 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200607201746.k6KHk49C012649@workhorse.brookfield.occnc.com> References: <200607201746.k6KHk49C012649@workhorse.brookfield.occnc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Date: Thu, 20 Jul 2006 23:36:42 +0200 To: curtis@occnc.com X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: rpsec@ietf.org, Tony Tauber , 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: , Errors-To: rpsec-bounces@ietf.org On 20-jul-2006, at 19:46, Curtis Villamizar wrote: > 2. A BGP security mechanisms may authenticate (or encrypte) Encrypt? I wouldn't want my routers to carry information that I can't inspect... > Ideally a BPG security mechanism would have the following properties. > 1. The security information would be passed intact but > uninterpreted across routers that did not support the same > security mechanism. That is not necessarily an ideal situation. This means encoding the security information in path attributes, which means that BGP tables in existing routers will be inflated without benefit to those existing routers. I'm not saying this is necessarily unacceptable, but it is certainly not "ideal" and should only be done after careful considerations of the consequences and the benefits. It would certainly be a bad idea to carry information in path attributes that is invalidated as soon as it is relayed by a non- upgraded router. (This is just an example of a bad idea.) > If the route selection is modified based on level of trust, an entire > AS MUST implement the same route selection to avoid loops. This is not a requirement in existing BGP and I don't see how adding security imposes this as a requirement. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 17:47:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gMA-0007l1-QP; Thu, 20 Jul 2006 17:46:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gM9-0007kw-LW for rpsec@ietf.org; Thu, 20 Jul 2006 17:46:53 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3gM8-0003ZP-7W for rpsec@ietf.org; Thu, 20 Jul 2006 17:46:53 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6KLkX3H073859 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Jul 2006 23:46:33 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200607201640.k6KGeCFn015253@tislabs.com> References: <200607201640.k6KGeCFn015253@tislabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73A8430D-8116-41B9-807D-C766E08CD1E3@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Date: Thu, 20 Jul 2006 23:46:44 +0200 To: sandy@tislabs.com X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: , Errors-To: rpsec-bounces@ietf.org On 20-jul-2006, at 18:40, sandy@tislabs.com wrote: >> If a BGP security mechanism provides new BGP messages, or new ways >> to interpret or handle existing BGP messages, the new messages and >> the new semantics for the existing messages MUST NOT be used >> towards a particular neighboring BGP speaker unless the capability >> to use the new mechanism has been mutually announced during >> the BGP capability negotiation at session establishment. > If this is to be a requirement, I'd like to inquire as to the exact > meaning here. > By "new BGP messages", do we mean messages in the BGP definition > of message types? That's what I meant, yes. > So new attributes would not be considered new messages? No, new attributes would be considered new attributes. :-) > BGP has a mechanism for dealing with new attributes without requiring > negotiation of same - define the attribute as optional transitive and > it can be passed along without being recognized. Right. As I've tried to say before: we should only use this mechanism for information which is still useful after traversing one or more non- upgraded hops AND only if we can be reasonably sure that currently deployed routers won't run into trouble because of the extra memory required to store this information. > I'm also not sure what the "new ways to interpret or handle existing > BGP messages" means and why it is of concern. "Drop bogus updates" > could be a new way to interpret messages, but such interpretation > should > not even by seen by a clueless recipient, so I don't see why it would > require negotiation. Yes, there could be handling of existing > messages that > would result in changes in what the recipient would see and so might > affect the recipient, I mostly meant new message types, but I can imagine modifying existing message types or the behavior after receiving an existing message if the new security mechanisms are in use. For instance, it may be necessary to increase the BGP message size to accommodate the extra information that needs to be carried. Obviously, these larger messages shouldn't be sent to neighboring routers unless we're sure that they support those. > even if the recipient was going to ignore them > (bandwidth, etc.). ??? I don't think ignoring messages is valid behavior in BGP. > The statement as made prohibits new security information from > being carried through a clueless area to a clueful AS on the other > side. > Is that what is desired here? Only in new message types or modified current message types. This is certainly desired since sending this information to an unsuspecting router may lead to all kinds of upredictable results. Encoding the information in new path attributes is a different matter, existing implementations should handle those, but see above. > An AS might have reasons for believing that an AS that was not > participating > in a security mechanism might still be expected to retain the security > properties the security mechanism was protecting. So it is not > necessarily > true that the security information is of no use whatsoever on the > other > side of a gap. If I speak to you in a language you don't understand the relevance of the message is immaterial, you're not going to understand it. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 18:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ghY-0004e3-JE; Thu, 20 Jul 2006 18:09:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3get-0003V9-Dt for rpsec@ietf.org; Thu, 20 Jul 2006 18:06:15 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3gS0-0004G0-D4 for rpsec@ietf.org; Thu, 20 Jul 2006 17:52:57 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6KLqYQd073939 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Jul 2006 23:52:34 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <44BF7E6B.70807@cisco.com> References: <36B71480-9A2F-4BAB-B5C0-399562F7C200@muada.com> <44B6A49A.8010104@cisco.com> <6.2.0.14.2.20060714225317.02e41ee0@localhost> <546F649B-6D5C-4DAE-BF8F-9B8008AB8ADD@muada.com> <44BF7E6B.70807@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BB0B3B9-08B4-476B-8503-4423B633EA88@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Date: Thu, 20 Jul 2006 23:52:48 +0200 To: Russ White X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: rpsec-bounces@ietf.org On 20-jul-2006, at 15:00, Russ White wrote: > I think the problem here is that the "sense of the list" is any > proposed > security mechanism must have the former property--that the information > must be useful, in some way, even when it has passed through an AS > and/or peer that doesn't understand it. I strongly disagree with the notion that this should be a requirement. Some information can be useful after having passed through a non- upgraded part of the network, some, by its nature, can't. The latter, IMO, should NOT be communicated to non-upgraded routers as it only imposes storage requirements without benefits. For the former, it's a tradeoff that I think should be presented clearly in an architecture or protocol spec document. Ideally, (again, IMO) this should be configurable by the operator. (-: _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 18:26:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gxz-0000eZ-9s; Thu, 20 Jul 2006 18:25:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3gwV-00088A-Fj for rpsec@ietf.org; Thu, 20 Jul 2006 18:24:27 -0400 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3gin-0005UD-C0 for rpsec@ietf.org; Thu, 20 Jul 2006 18:10:19 -0400 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k6KMACwC064198 for ; Fri, 21 Jul 2006 08:10:12 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060721075854.0328d968@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 21 Jul 2006 08:01:22 +1000 To: rpsec@ietf.org From: Geoff Huston Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-Reply-To: <73A8430D-8116-41B9-807D-C766E08CD1E3@muada.com> References: <200607201640.k6KGeCFn015253@tislabs.com> <73A8430D-8116-41B9-807D-C766E08CD1E3@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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: , Errors-To: rpsec-bounces@ietf.org Is this really part of a _requirements_ discussion, or it is heading off into an _implementation considerations_ discussion? I thought the _requirement_ with respect to discontiguous security domains had already been identified. Regards, Geoff At 07:46 AM 21/07/2006, Iljitsch van Beijnum wrote: >On 20-jul-2006, at 18:40, sandy@tislabs.com wrote: > >>> If a BGP security mechanism provides new BGP messages, or new ways >>> to interpret or handle existing BGP messages, the new messages and >>> the new semantics for the existing messages MUST NOT be used >>> towards a particular neighboring BGP speaker unless the capability >>> to use the new mechanism has been mutually announced during >>> the BGP capability negotiation at session establishment. > >>If this is to be a requirement, I'd like to inquire as to the exact >>meaning here. > >>By "new BGP messages", do we mean messages in the BGP definition >>of message types? > >That's what I meant, yes. > >>So new attributes would not be considered new messages? > >No, new attributes would be considered new attributes. :-) > >>BGP has a mechanism for dealing with new attributes without requiring >>negotiation of same - define the attribute as optional transitive and >>it can be passed along without being recognized. > >Right. > >As I've tried to say before: we should only use this mechanism for >information which is still useful after traversing one or more non- >upgraded hops AND only if we can be reasonably sure that currently >deployed routers won't run into trouble because of the extra memory >required to store this information. > >>I'm also not sure what the "new ways to interpret or handle existing >>BGP messages" means and why it is of concern. "Drop bogus updates" >>could be a new way to interpret messages, but such interpretation >>should >>not even by seen by a clueless recipient, so I don't see why it would >>require negotiation. Yes, there could be handling of existing >>messages that >>would result in changes in what the recipient would see and so might >>affect the recipient, > >I mostly meant new message types, but I can imagine modifying >existing message types or the behavior after receiving an existing >message if the new security mechanisms are in use. For instance, it >may be necessary to increase the BGP message size to accommodate the >extra information that needs to be carried. Obviously, these larger >messages shouldn't be sent to neighboring routers unless we're sure >that they support those. > >>even if the recipient was going to ignore them >>(bandwidth, etc.). > >??? > >I don't think ignoring messages is valid behavior in BGP. > >>The statement as made prohibits new security information from >>being carried through a clueless area to a clueful AS on the other >>side. >>Is that what is desired here? > >Only in new message types or modified current message types. This is >certainly desired since sending this information to an unsuspecting >router may lead to all kinds of upredictable results. Encoding the >information in new path attributes is a different matter, existing >implementations should handle those, but see above. > >>An AS might have reasons for believing that an AS that was not >>participating >>in a security mechanism might still be expected to retain the security >>properties the security mechanism was protecting. So it is not >>necessarily >>true that the security information is of no use whatsoever on the >>other >>side of a gap. > >If I speak to you in a language you don't understand the relevance of >the message is immaterial, you're not going to understand it. > > > >_______________________________________________ >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 Jul 20 20:39:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3j2o-0005z8-Dd; Thu, 20 Jul 2006 20:39:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3j2k-0005sK-8Q for rpsec@ietf.org; Thu, 20 Jul 2006 20:39:02 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ipr-00007M-M6 for rpsec@ietf.org; Thu, 20 Jul 2006 20:25:44 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6L0VsY1018656; Thu, 20 Jul 2006 20:31:54 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607210031.k6L0VsY1018656@workhorse.brookfield.occnc.com> To: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Thu, 20 Jul 2006 23:52:48 +0200." <2BB0B3B9-08B4-476B-8503-4423B633EA88@muada.com> Date: Thu, 20 Jul 2006 20:31:54 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: rpsec@ietf.org, Tony Tauber , Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <2BB0B3B9-08B4-476B-8503-4423B633EA88@muada.com> Iljitsch van Beijnum writes: On 20-jul-2006, at 15:00, Russ White wrote: > > > I think the problem here is that the "sense of the list" is any > > proposed > > security mechanism must have the former property--that the information > > must be useful, in some way, even when it has passed through an AS > > and/or peer that doesn't understand it. > > I strongly disagree with the notion that this should be a requirement. > > Some information can be useful after having passed through a non- > upgraded part of the network, some, by its nature, can't. The latter, > IMO, should NOT be communicated to non-upgraded routers as it only > imposes storage requirements without benefits. For the former, it's a > tradeoff that I think should be presented clearly in an architecture > or protocol spec document. Ideally, (again, IMO) this should be > configurable by the operator. > > (-: I agree with the above paragraph. Is anyone taking notes on this conversation? [I hope its worth taking notes?] Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 20:39:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3j2m-0005uy-7B; Thu, 20 Jul 2006 20:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3j2g-0005pM-Va for rpsec@ietf.org; Thu, 20 Jul 2006 20:38:59 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3iyc-0000cm-Sg for rpsec@ietf.org; Thu, 20 Jul 2006 20:34:49 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6L0f2FP019098; Thu, 20 Jul 2006 20:41:02 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607210041.k6L0f2FP019098@workhorse.brookfield.occnc.com> To: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Thu, 20 Jul 2006 23:36:42 +0200." Date: Thu, 20 Jul 2006 20:41:02 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: rpsec@ietf.org, Tony Tauber , Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Iljitsch van Beijnum writes: > > On 20-jul-2006, at 19:46, Curtis Villamizar wrote: > > > 2. A BGP security mechanisms may authenticate (or encrypte) > > Encrypt? Not likely imho. Ask Sandy? :-) I was just trying not to exclude the possibility that some attribute of routing might be encrypted in the future, since I don't really know what people interested in very high security would like to do particularly in the future. You never know though. Approximate GPS location of a mobile router would be encrypted if anyone every decided they needed that. Location could be used in routing. [ I have no idea who might conceivably want that sort of feature or want to encrypt it if they added it. :) ] I know of no current requirement for this, just didn't want to exclude it. Did I really spell encrypt wrong. Oops. > I wouldn't want my routers to carry information that I can't inspect... Do you block IPSEC flows too? :-) How would you know its encrypted if it was in an optional transitive attribute that your router didn't understand? And why would you care if your big government customer needed it but you didn't? > > Ideally a BPG security mechanism would have the following properties. > > > 1. The security information would be passed intact but > > uninterpreted across routers that did not support the same > > security mechanism. > > That is not necessarily an ideal situation. This means encoding the > security information in path attributes, which means that BGP tables > in existing routers will be inflated without benefit to those > existing routers. You are right in a sense. But I disagree. It depends on the size of these extra attributes. Some of the proposals add so much information that I don't see it as feasible except in a small closed network. If people want to define protocols that no one will ever deploy and whose attributes will be tossed that's their business. They've been at it for a while though. > I'm not saying this is necessarily unacceptable, but it is certainly > not "ideal" and should only be done after careful considerations of > the consequences and the benefits. > > It would certainly be a bad idea to carry information in path > attributes that is invalidated as soon as it is relayed by a non- > upgraded router. (This is just an example of a bad idea.) If authentication information is all that is added to BGP then tossing *all* the authentication information is certainly a bad idea. What might make sense is to toss any per hop path authentication before advertising to a router that would not add its authentication. That would make sense if policy was based only on prefering a route with a completely authenticated path over one that is not complete but did not prefer paths with less hops not authenticated over ones with more hops not authenticated. OTOH if a completely authenticated path was not available a path with only AS from a small set of fairly well trusted AS in it might be preferred over one with more untrusted AS. Removing information because it won't be needed downstream could be considered a configurable space optimization. Sound like I need a SHOULD in that paragraph, making it. > > 1. The security information SHOULD be passed intact but > > uninterpreted across routers that did not support the same > > security mechanism. Is that better? > > If the route selection is modified based on level of trust, an entire > > AS MUST implement the same route selection to avoid loops. > > This is not a requirement in existing BGP and I don't see how adding > security imposes this as a requirement. All routers must implement the same route selection algorithm. That is a requirement of plain old BGP. The exact route selection algorithm is defined in RFC4271. This is stating that if within an AS the route selection defined in RFC4271 is not used, it has to be the same throughout the AS. Another way to implement this requirement is to set LOCAL_PREF based on the level of trust. You certainly want level of trust over AS Path length so it might be easier to put in a knob that if tweaked puts level of trust (fully authenticated vs partially authenticated). Note that the paragraph from which you pulled the first sentence starts with "If the route selection is modified". FYI -- What I had in mind as a "for example" was a military network being fully authenticated and maybe having a few attributes encrypted and passing them over the commercial internet. Commercial providers might be willing to carry the attributes but not support the encryption and the military willing to use the commercial internet paths for some traffic or in the event of outage. For example if a St Helens size volcano eruption occurred in Alaska (is there anything in Alaska like that? probably not) the military might like to use a commercial internet path if the volcanic dust blocked their wireless link or satelite communications (or took out their fiber laid down by dog driven sleds - or whatever). Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 20:39:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3j2o-0005x7-2G; Thu, 20 Jul 2006 20:39:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3j2j-0005rc-0Q for rpsec@ietf.org; Thu, 20 Jul 2006 20:39:01 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3itB-0000El-FY for rpsec@ietf.org; Thu, 20 Jul 2006 20:29:09 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6L0ZB3O018686; Thu, 20 Jul 2006 20:35:14 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607210035.k6L0ZB3O018686@workhorse.brookfield.occnc.com> To: Geoff Huston Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Fri, 21 Jul 2006 08:01:22 +1000." <6.2.0.14.2.20060721075854.0328d968@kahuna.telstra.net> Date: Thu, 20 Jul 2006 20:35:11 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <6.2.0.14.2.20060721075854.0328d968@kahuna.telstra.net> Geoff Huston writes: > > Is this really part of a _requirements_ discussion, or it is heading off > into an _implementation considerations_ discussion? I thought the > _requirement_ with respect to discontiguous security domains had already > been identified. > > Regards, > > Geoff Geoff, I think the requirements are underspecified. Apparently other do too and that is why there is a discussion. Curtis > At 07:46 AM 21/07/2006, Iljitsch van Beijnum wrote: > >On 20-jul-2006, at 18:40, sandy@tislabs.com wrote: > > > >>> If a BGP security mechanism provides new BGP messages, or new ways > >>> to interpret or handle existing BGP messages, the new messages and > >>> the new semantics for the existing messages MUST NOT be used > >>> towards a particular neighboring BGP speaker unless the capability > >>> to use the new mechanism has been mutually announced during > >>> the BGP capability negotiation at session establishment. > > > >>If this is to be a requirement, I'd like to inquire as to the exact > >>meaning here. > > > >>By "new BGP messages", do we mean messages in the BGP definition > >>of message types? > > > >That's what I meant, yes. > > > >>So new attributes would not be considered new messages? > > > >No, new attributes would be considered new attributes. :-) > > > >>BGP has a mechanism for dealing with new attributes without requiring > >>negotiation of same - define the attribute as optional transitive and > >>it can be passed along without being recognized. > > > >Right. > > > >As I've tried to say before: we should only use this mechanism for > >information which is still useful after traversing one or more non- > >upgraded hops AND only if we can be reasonably sure that currently > >deployed routers won't run into trouble because of the extra memory > >required to store this information. > > > >>I'm also not sure what the "new ways to interpret or handle existing > >>BGP messages" means and why it is of concern. "Drop bogus updates" > >>could be a new way to interpret messages, but such interpretation > >>should > >>not even by seen by a clueless recipient, so I don't see why it would > >>require negotiation. Yes, there could be handling of existing > >>messages that > >>would result in changes in what the recipient would see and so might > >>affect the recipient, > > > >I mostly meant new message types, but I can imagine modifying > >existing message types or the behavior after receiving an existing > >message if the new security mechanisms are in use. For instance, it > >may be necessary to increase the BGP message size to accommodate the > >extra information that needs to be carried. Obviously, these larger > >messages shouldn't be sent to neighboring routers unless we're sure > >that they support those. > > > >>even if the recipient was going to ignore them > >>(bandwidth, etc.). > > > >??? > > > >I don't think ignoring messages is valid behavior in BGP. > > > >>The statement as made prohibits new security information from > >>being carried through a clueless area to a clueful AS on the other > >>side. > >>Is that what is desired here? > > > >Only in new message types or modified current message types. This is > >certainly desired since sending this information to an unsuspecting > >router may lead to all kinds of upredictable results. Encoding the > >information in new path attributes is a different matter, existing > >implementations should handle those, but see above. > > > >>An AS might have reasons for believing that an AS that was not > >>participating > >>in a security mechanism might still be expected to retain the security > >>properties the security mechanism was protecting. So it is not > >>necessarily > >>true that the security information is of no use whatsoever on the > >>other > >>side of a gap. > > > >If I speak to you in a language you don't understand the relevance of > >the message is immaterial, you're not going to understand it. > > > > > > > >_______________________________________________ > >RPSEC mailing list > >RPSEC@ietf.org > >https://www1.ietf.org/mailman/listinfo/rpsec > > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 20:39:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3j2m-0005uy-7B; Thu, 20 Jul 2006 20:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3j2g-0005pM-Va for rpsec@ietf.org; Thu, 20 Jul 2006 20:38:59 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3iyc-0000cm-Sg for rpsec@ietf.org; Thu, 20 Jul 2006 20:34:49 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6L0f2FP019098; Thu, 20 Jul 2006 20:41:02 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607210041.k6L0f2FP019098@workhorse.brookfield.occnc.com> To: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Thu, 20 Jul 2006 23:36:42 +0200." Date: Thu, 20 Jul 2006 20:41:02 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: rpsec@ietf.org, Tony Tauber , Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Iljitsch van Beijnum writes: > > On 20-jul-2006, at 19:46, Curtis Villamizar wrote: > > > 2. A BGP security mechanisms may authenticate (or encrypte) > > Encrypt? Not likely imho. Ask Sandy? :-) I was just trying not to exclude the possibility that some attribute of routing might be encrypted in the future, since I don't really know what people interested in very high security would like to do particularly in the future. You never know though. Approximate GPS location of a mobile router would be encrypted if anyone every decided they needed that. Location could be used in routing. [ I have no idea who might conceivably want that sort of feature or want to encrypt it if they added it. :) ] I know of no current requirement for this, just didn't want to exclude it. Did I really spell encrypt wrong. Oops. > I wouldn't want my routers to carry information that I can't inspect... Do you block IPSEC flows too? :-) How would you know its encrypted if it was in an optional transitive attribute that your router didn't understand? And why would you care if your big government customer needed it but you didn't? > > Ideally a BPG security mechanism would have the following properties. > > > 1. The security information would be passed intact but > > uninterpreted across routers that did not support the same > > security mechanism. > > That is not necessarily an ideal situation. This means encoding the > security information in path attributes, which means that BGP tables > in existing routers will be inflated without benefit to those > existing routers. You are right in a sense. But I disagree. It depends on the size of these extra attributes. Some of the proposals add so much information that I don't see it as feasible except in a small closed network. If people want to define protocols that no one will ever deploy and whose attributes will be tossed that's their business. They've been at it for a while though. > I'm not saying this is necessarily unacceptable, but it is certainly > not "ideal" and should only be done after careful considerations of > the consequences and the benefits. > > It would certainly be a bad idea to carry information in path > attributes that is invalidated as soon as it is relayed by a non- > upgraded router. (This is just an example of a bad idea.) If authentication information is all that is added to BGP then tossing *all* the authentication information is certainly a bad idea. What might make sense is to toss any per hop path authentication before advertising to a router that would not add its authentication. That would make sense if policy was based only on prefering a route with a completely authenticated path over one that is not complete but did not prefer paths with less hops not authenticated over ones with more hops not authenticated. OTOH if a completely authenticated path was not available a path with only AS from a small set of fairly well trusted AS in it might be preferred over one with more untrusted AS. Removing information because it won't be needed downstream could be considered a configurable space optimization. Sound like I need a SHOULD in that paragraph, making it. > > 1. The security information SHOULD be passed intact but > > uninterpreted across routers that did not support the same > > security mechanism. Is that better? > > If the route selection is modified based on level of trust, an entire > > AS MUST implement the same route selection to avoid loops. > > This is not a requirement in existing BGP and I don't see how adding > security imposes this as a requirement. All routers must implement the same route selection algorithm. That is a requirement of plain old BGP. The exact route selection algorithm is defined in RFC4271. This is stating that if within an AS the route selection defined in RFC4271 is not used, it has to be the same throughout the AS. Another way to implement this requirement is to set LOCAL_PREF based on the level of trust. You certainly want level of trust over AS Path length so it might be easier to put in a knob that if tweaked puts level of trust (fully authenticated vs partially authenticated). Note that the paragraph from which you pulled the first sentence starts with "If the route selection is modified". FYI -- What I had in mind as a "for example" was a military network being fully authenticated and maybe having a few attributes encrypted and passing them over the commercial internet. Commercial providers might be willing to carry the attributes but not support the encryption and the military willing to use the commercial internet paths for some traffic or in the event of outage. For example if a St Helens size volcano eruption occurred in Alaska (is there anything in Alaska like that? probably not) the military might like to use a commercial internet path if the volcanic dust blocked their wireless link or satelite communications (or took out their fiber laid down by dog driven sleds - or whatever). Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 20:39:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3j2o-0005x7-2G; Thu, 20 Jul 2006 20:39:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3j2j-0005rc-0Q for rpsec@ietf.org; Thu, 20 Jul 2006 20:39:01 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3itB-0000El-FY for rpsec@ietf.org; Thu, 20 Jul 2006 20:29:09 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6L0ZB3O018686; Thu, 20 Jul 2006 20:35:14 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607210035.k6L0ZB3O018686@workhorse.brookfield.occnc.com> To: Geoff Huston Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Fri, 21 Jul 2006 08:01:22 +1000." <6.2.0.14.2.20060721075854.0328d968@kahuna.telstra.net> Date: Thu, 20 Jul 2006 20:35:11 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <6.2.0.14.2.20060721075854.0328d968@kahuna.telstra.net> Geoff Huston writes: > > Is this really part of a _requirements_ discussion, or it is heading off > into an _implementation considerations_ discussion? I thought the > _requirement_ with respect to discontiguous security domains had already > been identified. > > Regards, > > Geoff Geoff, I think the requirements are underspecified. Apparently other do too and that is why there is a discussion. Curtis > At 07:46 AM 21/07/2006, Iljitsch van Beijnum wrote: > >On 20-jul-2006, at 18:40, sandy@tislabs.com wrote: > > > >>> If a BGP security mechanism provides new BGP messages, or new ways > >>> to interpret or handle existing BGP messages, the new messages and > >>> the new semantics for the existing messages MUST NOT be used > >>> towards a particular neighboring BGP speaker unless the capability > >>> to use the new mechanism has been mutually announced during > >>> the BGP capability negotiation at session establishment. > > > >>If this is to be a requirement, I'd like to inquire as to the exact > >>meaning here. > > > >>By "new BGP messages", do we mean messages in the BGP definition > >>of message types? > > > >That's what I meant, yes. > > > >>So new attributes would not be considered new messages? > > > >No, new attributes would be considered new attributes. :-) > > > >>BGP has a mechanism for dealing with new attributes without requiring > >>negotiation of same - define the attribute as optional transitive and > >>it can be passed along without being recognized. > > > >Right. > > > >As I've tried to say before: we should only use this mechanism for > >information which is still useful after traversing one or more non- > >upgraded hops AND only if we can be reasonably sure that currently > >deployed routers won't run into trouble because of the extra memory > >required to store this information. > > > >>I'm also not sure what the "new ways to interpret or handle existing > >>BGP messages" means and why it is of concern. "Drop bogus updates" > >>could be a new way to interpret messages, but such interpretation > >>should > >>not even by seen by a clueless recipient, so I don't see why it would > >>require negotiation. Yes, there could be handling of existing > >>messages that > >>would result in changes in what the recipient would see and so might > >>affect the recipient, > > > >I mostly meant new message types, but I can imagine modifying > >existing message types or the behavior after receiving an existing > >message if the new security mechanisms are in use. For instance, it > >may be necessary to increase the BGP message size to accommodate the > >extra information that needs to be carried. Obviously, these larger > >messages shouldn't be sent to neighboring routers unless we're sure > >that they support those. > > > >>even if the recipient was going to ignore them > >>(bandwidth, etc.). > > > >??? > > > >I don't think ignoring messages is valid behavior in BGP. > > > >>The statement as made prohibits new security information from > >>being carried through a clueless area to a clueful AS on the other > >>side. > >>Is that what is desired here? > > > >Only in new message types or modified current message types. This is > >certainly desired since sending this information to an unsuspecting > >router may lead to all kinds of upredictable results. Encoding the > >information in new path attributes is a different matter, existing > >implementations should handle those, but see above. > > > >>An AS might have reasons for believing that an AS that was not > >>participating > >>in a security mechanism might still be expected to retain the security > >>properties the security mechanism was protecting. So it is not > >>necessarily > >>true that the security information is of no use whatsoever on the > >>other > >>side of a gap. > > > >If I speak to you in a language you don't understand the relevance of > >the message is immaterial, you're not going to understand it. > > > > > > > >_______________________________________________ > >RPSEC mailing list > >RPSEC@ietf.org > >https://www1.ietf.org/mailman/listinfo/rpsec > > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 20:51:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3jEW-00067X-8T; Thu, 20 Jul 2006 20:51:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3jEV-00067R-CI for rpsec@ietf.org; Thu, 20 Jul 2006 20:51:11 -0400 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3jET-0002w1-GS for rpsec@ietf.org; Thu, 20 Jul 2006 20:51:11 -0400 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k6L0oxAs066967; Fri, 21 Jul 2006 10:51:01 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060721104818.03029148@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 21 Jul 2006 10:50:40 +1000 To: curtis@occnc.com From: Geoff Huston Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-Reply-To: <200607210035.k6L0ZB3O018686@workhorse.brookfield.occnc.com > References: <200607210035.k6L0ZB3O018686@workhorse.brookfield.occnc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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: , Errors-To: rpsec-bounces@ietf.org My note was attempting to draw a distinction between specification of requirements and heading into topics that appear to be solution design. While I am personally of the view that the requirement has been adequately identified, I appreciate that this is not a common position within the context of this WG at this stage. Geoff At 10:35 AM 21/07/2006, Curtis Villamizar wrote: >In message <6.2.0.14.2.20060721075854.0328d968@kahuna.telstra.net> >Geoff Huston writes: > > > > Is this really part of a _requirements_ discussion, or it is heading off > > into an _implementation considerations_ discussion? I thought the > > _requirement_ with respect to discontiguous security domains had already > > been identified. > > > > Regards, > > > > Geoff > > >Geoff, > >I think the requirements are underspecified. Apparently other do too >and that is why there is a discussion. > >Curtis > > > > At 07:46 AM 21/07/2006, Iljitsch van Beijnum wrote: > > >On 20-jul-2006, at 18:40, sandy@tislabs.com wrote: > > > > > >>> If a BGP security mechanism provides new BGP messages, or new ways > > >>> to interpret or handle existing BGP messages, the new messages and > > >>> the new semantics for the existing messages MUST NOT be used > > >>> towards a particular neighboring BGP speaker unless the capability > > >>> to use the new mechanism has been mutually announced during > > >>> the BGP capability negotiation at session establishment. > > > > > >>If this is to be a requirement, I'd like to inquire as to the exact > > >>meaning here. > > > > > >>By "new BGP messages", do we mean messages in the BGP definition > > >>of message types? > > > > > >That's what I meant, yes. > > > > > >>So new attributes would not be considered new messages? > > > > > >No, new attributes would be considered new attributes. :-) > > > > > >>BGP has a mechanism for dealing with new attributes without requiring > > >>negotiation of same - define the attribute as optional transitive and > > >>it can be passed along without being recognized. > > > > > >Right. > > > > > >As I've tried to say before: we should only use this mechanism for > > >information which is still useful after traversing one or more non- > > >upgraded hops AND only if we can be reasonably sure that currently > > >deployed routers won't run into trouble because of the extra memory > > >required to store this information. > > > > > >>I'm also not sure what the "new ways to interpret or handle existing > > >>BGP messages" means and why it is of concern. "Drop bogus updates" > > >>could be a new way to interpret messages, but such interpretation > > >>should > > >>not even by seen by a clueless recipient, so I don't see why it would > > >>require negotiation. Yes, there could be handling of existing > > >>messages that > > >>would result in changes in what the recipient would see and so might > > >>affect the recipient, > > > > > >I mostly meant new message types, but I can imagine modifying > > >existing message types or the behavior after receiving an existing > > >message if the new security mechanisms are in use. For instance, it > > >may be necessary to increase the BGP message size to accommodate the > > >extra information that needs to be carried. Obviously, these larger > > >messages shouldn't be sent to neighboring routers unless we're sure > > >that they support those. > > > > > >>even if the recipient was going to ignore them > > >>(bandwidth, etc.). > > > > > >??? > > > > > >I don't think ignoring messages is valid behavior in BGP. > > > > > >>The statement as made prohibits new security information from > > >>being carried through a clueless area to a clueful AS on the other > > >>side. > > >>Is that what is desired here? > > > > > >Only in new message types or modified current message types. This is > > >certainly desired since sending this information to an unsuspecting > > >router may lead to all kinds of upredictable results. Encoding the > > >information in new path attributes is a different matter, existing > > >implementations should handle those, but see above. > > > > > >>An AS might have reasons for believing that an AS that was not > > >>participating > > >>in a security mechanism might still be expected to retain the security > > >>properties the security mechanism was protecting. So it is not > > >>necessarily > > >>true that the security information is of no use whatsoever on the > > >>other > > >>side of a gap. > > > > > >If I speak to you in a language you don't understand the relevance of > > >the message is immaterial, you're not going to understand it. > > > > > > > > > > > >_______________________________________________ > > >RPSEC mailing list > > >RPSEC@ietf.org > > >https://www1.ietf.org/mailman/listinfo/rpsec > > > > > > > > _______________________________________________ > > RPSEC mailing list > > RPSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/rpsec > > >_______________________________________________ >RPSEC mailing list >RPSEC@ietf.org >https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 22:18:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3kb1-00023S-0W; Thu, 20 Jul 2006 22:18:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3kay-00020X-NF for rpsec@ietf.org; Thu, 20 Jul 2006 22:18:28 -0400 Received: from webmail.tropos.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3kUH-0003J7-69 for rpsec@ietf.org; Thu, 20 Jul 2006 22:11:34 -0400 Received: (qmail 10787 invoked from network); 21 Jul 2006 02:05:51 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 21 Jul 2006 02:05:50 -0000 Received: from LIPC ([192.168.1.103]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 19:14:27 -0700 From: "Tony Li" To: "'Russ White'" , Subject: RE: [RPSEC] Discontiguous Deployment... Date: Thu, 20 Jul 2006 19:11:28 -0700 Message-ID: <002901c6ac6a$f9f28810$837d14ac@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44C02C17.1000708@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcasZitQOavvmBh5T7C3f+4ogjezIwABC+/Q X-OriginalArrivalTime: 21 Jul 2006 02:14:27.0538 (UTC) FILETIME=[64919B20:01C6AC6B] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org > Should there be a requirement that any proposed security > system must be > useful even if deployed in a noncontiguous way? Or should > this not be a > requirement? IMHO, the requirement should be that it be possible to have incremental deployment, with benefit at least proportional to the extent of the deployment. The very nature of BGP implies that you will end up with incremental noncontiguous deployments. If there are no benefits until contiguity is restored, then there will be no adoption, and hence no point in creating the solution in the first place. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 20 23:50:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3m1i-0005Bh-DO; Thu, 20 Jul 2006 23:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3m1g-00056i-TE for rpsec@ietf.org; Thu, 20 Jul 2006 23:50:08 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3m1f-00015W-G4 for rpsec@ietf.org; Thu, 20 Jul 2006 23:50:08 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6L3uNW8021446; Thu, 20 Jul 2006 23:56:23 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607210356.k6L3uNW8021446@workhorse.brookfield.occnc.com> To: rpsec@ietf.org Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt -- other comments Date: Thu, 20 Jul 2006 23:56:23 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org A few more comments inline. Curtis Christian & Tauber Expires October 3, 2006 [Page 2] 1. Introduction 1.1. System Description BGP is described in RFC1771 [4], and, more recently, in an updated specification, RFC4271 [1], as a path-vector routing protocol. BGP RFC4271 obsoletes RFC1771. It does not update RFC1771. There is no reason to mention RFC1771. Christian & Tauber Expires October 3, 2006 [Page 3] Because ASes are autonomous in their operation, it is not possible to mandate secure operation by all ASes, nor would it be advisable to assume such operation. Thus the primary goal of BGP security measures is to provide data to AS operators to enable BGP speakers to reject advertisements (UPDATE messages) that are not valid. For example, UPDATE messages that represent erroneous binding of prefixes to an origin AS, or that advertise invalid paths (as defined later in this document) should be rejected. Because BGP peering sessions take place in the context of TCP, the authentication and integrity guarantees usually association with TCP need to be provided in the face of possible active wiretapping attacks. Using the terminology established in RFC 3552 [3], these peering sessions should be afforded data origin and peer entity authentication and connection- oriented integrity. First sentence is fine. Second sentence is also mostly OK. Another goal would be to allow a BGP speaker to prefer a given route over another based on some measure of trust which is missed above. The rest is about securing TCP and could be said in simpler terms. Security for subscriber traffic is outside the scope of this document, and of BGP security in general. IETF standards for subscriber data security, e.g., IPsec, TLS, and S/MIME should be employed for such purposes. While adoption of BGP security measures may preclude certain classes of attacks on subscriber traffic, these measures are not a substitute for use of subscriber-based security mechanisms of the sort noted above. There is no such thing as "subscriber" traffic in BGP or anything IP. It really shows that a MSO author had a hand in writing this. Please just drop this paragraph. It is obvious to the intended audience that we are not securing IP services. Christian & Tauber Expires October 3, 2006 [Page 7] 3.2. Incremental deployment It will not be feasible to deploy a newly secured BGP protocol throughout the public Internet instantaneously. It also may not be possible to deploy a such a protocol to all routers in a large AS at one time. Because of this, there are several requirements that any proposed mechanism to secure BGP must consider. o A BGP security mechanism MUST enable each BGP speaker to configure use of the security mechanism on a per-peer basis. It may be a requirement to enable a security mechanism on routes which are originated with the security mechanism. For example. customer-AS-1 and customer-AS-2 might want some form of authentication. Other AS don't. These customer might transit providers with ASx, ASy, ASz. Within ASx, ASy, and ASz further path authentication might be needed but only for origin-AS that are using authentication. This has no relevance to enabling something at the ASx-ASy peering and the ASy-ASz peering. o A BGP security mechanism MUST provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment. Message formatting in a fully secured environment MAY be handled in a non- backward compatible fashion though care must be taken to ensure UPDATES can traverse intermediate routers which don't support the new format. o In an environment where both secured and non-secured systems are interoperating a mechanism MUST exist for secured systems to identify whether an originator intended the information to be secured. These two paragraphs are the topic of the current discussion on the list. At some point we have to go back here when the discussion settles down. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 00:39:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3mnK-0006tV-EF; Fri, 21 Jul 2006 00:39:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3mnI-0006tL-Hv for rpsec@ietf.org; Fri, 21 Jul 2006 00:39:20 -0400 Received: from static-71-121-225-117.sttlwa.dsl-w.verizon.net ([71.121.225.117] helo=woodin.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3mnH-0004LD-3i for rpsec@ietf.org; Fri, 21 Jul 2006 00:39:20 -0400 Received: from [10.0.0.16] ([10.0.0.16]) (authenticated bits=0) by woodin.blaines.net (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6L2huVx025669 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 20 Jul 2006 19:43:58 -0700 In-Reply-To: <002901c6ac6a$f9f28810$837d14ac@tropos.com> References: <002901c6ac6a$f9f28810$837d14ac@tropos.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58BE2EBD-C83E-4DCE-845C-AF8C58A1CA1B@blaines.net> Content-Transfer-Encoding: 7bit From: Blaine Christian Subject: Re: [RPSEC] Discontiguous Deployment... Date: Thu, 20 Jul 2006 21:40:04 -0700 To: tony.li@tony.li X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: rpsec-bounces@ietf.org On Jul 20, 2006, at 7:11 PM, Tony Li wrote: > > >> Should there be a requirement that any proposed security >> system must be >> useful even if deployed in a noncontiguous way? Or should >> this not be a >> requirement? > > > IMHO, the requirement should be that it be possible to have > incremental > deployment, with benefit at least proportional to the extent of the > deployment. > > The very nature of BGP implies that you will end up with incremental > noncontiguous deployments. If there are no benefits until > contiguity is > restored, then there will be no adoption, and hence no point in > creating > the solution in the first place. Agreed, A successful standard will allow for deployments that are not yet interconnected. Those folks doing BGP in support of the Internet will appreciate the ability to secure local sections of the Internet and at least offer a higher degree of probability that they will not have prefixes hijacked etc... BTW, we also discussed the likelihood of making the selection of a "secure" route part of the BGP path selection process. The specific paragraph that started this was intended to note the fact that we will be unable to have a "flag day" for BGP. It is highly unlikely we will have the entire Internet converted quickly. There will be pockets of "insecure" and areas that are "secure" that are connected to/through insecure networks. The folks "not" doing BGP for the Internet are likely to have some needs WRT partial deployment as well and I believe that most of us have seen or will see cases where a partial deployment aids in a full deployment later. Regards, Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 01:09:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3nGP-00032K-Ey; Fri, 21 Jul 2006 01:09:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3nGN-00030N-IQ for rpsec@ietf.org; Fri, 21 Jul 2006 01:09:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3lK1-0004WR-Fs for rpsec@ietf.org; Thu, 20 Jul 2006 23:05:01 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3krY-00055x-Tg for rpsec@ietf.org; Thu, 20 Jul 2006 22:35:38 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 20 Jul 2006 19:35:18 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 740CF2AF; Thu, 20 Jul 2006 19:35:18 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 510012AE; Thu, 20 Jul 2006 19:35:18 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DZU31465; Thu, 20 Jul 2006 19:35:16 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 8E37520507; Thu, 20 Jul 2006 19:35:16 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] Discontiguous Deployment... Date: Thu, 20 Jul 2006 19:34:03 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B36827EC0@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [RPSEC] Discontiguous Deployment... Thread-Index: AcasZjJ8y8YPFs2KTGGcNRMQ3elX/gAB9EnQ From: "Bora Akyol" To: "Russ White" , rpsec@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006072012; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230362E34344330334144392E303030462D412D; ENG=IBF; TS=20060721023521; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006072012_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68DEE2EC1OO6586739-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: rpsec-bounces@ietf.org =20 >From the beginning of the draft, incremental, non-contiguous deployment was a requirement. And IMHO, it should remain so. Bora > -----Original Message----- > From: Russ White [mailto:riw@cisco.com]=20 > Sent: Thursday, July 20, 2006 6:21 PM > To: rpsec@ietf.org > Subject: [RPSEC] Discontiguous Deployment... >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > Okay, before we get too far into wording, I want to check on=20 > list and see what everyone's opinion is.... >=20 > Should there be a requirement that any proposed security=20 > system must be useful even if deployed in a noncontiguous=20 > way? Or should this not be a requirement? >=20 > One we settle this, it should be easier to come to concensus=20 > on actual wording, I hope (?).... >=20 > :-) >=20 > Russ > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 01:40:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3nkI-0005W1-Ff; Fri, 21 Jul 2006 01:40:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3nh7-0004E6-4N for rpsec@ietf.org; Fri, 21 Jul 2006 01:37:01 -0400 Received: from skink.reptiles.org ([198.96.119.1] helo=mail.reptiles.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3nds-0008FI-28 for rpsec@ietf.org; Fri, 21 Jul 2006 01:33:42 -0400 Received: from www.reptiles.org([198.96.119.1] port=4932) (1650 bytes) by mail.reptiles.org([198.96.119.1] port=25) via TCP with esmtp (sender: ) id for ; (dest:remote)(R=bind_hosts)(T=inet_zone_bind_smtp) Fri, 21 Jul 2006 01:33:34 -0400 (EDT) (Smail-3.2.0.118 2004-May-31 #3 built 2004-Oct-14) Date: Fri, 21 Jul 2006 01:33:34 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@skink.reptiles.org To: tony.li@tony.li Subject: RE: [RPSEC] Discontiguous Deployment... In-Reply-To: <002901c6ac6a$f9f28810$837d14ac@tropos.com> Message-ID: <20060721013246.T23092@skink.reptiles.org> References: <002901c6ac6a$f9f28810$837d14ac@tropos.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rpsec@ietf.org, 'Russ White' X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cat Okita List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org On Thu, 20 Jul 2006, Tony Li wrote: > IMHO, the requirement should be that it be possible to have incremental > deployment, with benefit at least proportional to the extent of the > deployment. > > The very nature of BGP implies that you will end up with incremental > noncontiguous deployments. If there are no benefits until contiguity is > restored, then there will be no adoption, and hence no point in creating > the solution in the first place. Agreed - most of us can't get solutions rolled out across our employer in a short period of time, never mind across different administrative domains. cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 06:37:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3sO7-0002Mw-PO; Fri, 21 Jul 2006 06:37:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3sO5-0002Mr-PR for rpsec@ietf.org; Fri, 21 Jul 2006 06:37:41 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3sO4-0007Ml-G3 for rpsec@ietf.org; Fri, 21 Jul 2006 06:37:41 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6LAbFu7086278 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jul 2006 12:37:16 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <44C02C17.1000708@cisco.com> References: <44C02C17.1000708@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <206187F7-7EB6-49FA-97CF-8ED2B66161DE@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] Discontiguous Deployment... Date: Fri, 21 Jul 2006 12:37:29 +0200 To: Russ White X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: rpsec-bounces@ietf.org On 21-jul-2006, at 3:21, Russ White wrote: > Okay, before we get too far into wording, I want to check on list and > see what everyone's opinion is.... > Should there be a requirement that any proposed security system > must be > useful even if deployed in a noncontiguous way? Or should this not > be a > requirement? Obviously that would be useful, but what I'm afraid of is that making this a hard requirement may lead people to come up with solutions that are technically inferior in order to meet this requirement. Deployment only happens once, and it's reasonable to assume that when some kind of more secure BGP takes off the situation where two parts of the network that both implement the new stuff are separated by a part of the network that doesn't won't be a situation that is common and persists for a long time. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 10:20:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vrN-0006lq-EI; Fri, 21 Jul 2006 10:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vrI-0006dM-Ot for rpsec@ietf.org; Fri, 21 Jul 2006 10:20:04 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3vWP-0002pV-AH for rpsec@ietf.org; Fri, 21 Jul 2006 09:58:30 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G3vWO-0008Lr-6D; Fri, 21 Jul 2006 09:58:29 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200607201746.k6KHk49C012649@workhorse.brookfield.occnc.com> References: <200607201746.k6KHk49C012649@workhorse.brookfield.occnc.com> Date: Fri, 21 Jul 2006 09:41:09 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Iljitsch van Beijnum , rpsec@ietf.org, Tony Tauber , 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: , Errors-To: rpsec-bounces@ietf.org At 1:46 PM -0400 7/20/06, Curtis Villamizar wrote: >... > >BPG security mechanisms differ in the following ways. > > 1. The scope of key distribution may be local or global. > > a. A BGP security mechanism may use a transitive trust model, > > b. A BGP security mechanism may use a form of authentication > where keys are globally available and provide authentication > information which is globally verifiable. > > c. A BGP security mechanism may use both of the above using one > scope for one type of information and another scope for > another type of information. > > 2. A BGP security mechanisms may authenticate (or encrypte) > different types of information including combination of the > following. > > a. A BGP security mechanism may provide authentication of > the origin or or information related to the origin. > > b. A BGP security mechanism may provide authentication of the BGP > peer. > > c. A BGP security mechanism may provide authentication of each AS > in the path. > I think it is confusing to refer to "a BGP security mechanism" when referring to all of these security issues. For example, one might use different means of authenticating a BGP peer in different contexts and this choice may be completely independent of a mechanism used to verify route origination on a global basis. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 11:23:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wqJ-0007kO-9U; Fri, 21 Jul 2006 11:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wqI-0007kJ-8s for rpsec@ietf.org; Fri, 21 Jul 2006 11:23:06 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3vWN-0002pM-2K for rpsec@ietf.org; Fri, 21 Jul 2006 09:58:28 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G3vWM-0008Lr-4r; Fri, 21 Jul 2006 09:58:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <44C02C17.1000708@cisco.com> References: <44C02C17.1000708@cisco.com> Date: Fri, 21 Jul 2006 09:21:36 -0400 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Discontiguous Deployment... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: rpsec-bounces@ietf.org At 9:21 PM -0400 7/20/06, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >Okay, before we get too far into wording, I want to check on list and >see what everyone's opinion is.... > >Should there be a requirement that any proposed security system must be >useful even if deployed in a noncontiguous way? Or should this not be a >requirement? > >One we settle this, it should be easier to come to concensus on actual >wording, I hope (?).... > >:-) > >Russ > Russ, I think non-contiguous deployment of a BGP security system should yield some improvement in security over lack of deployment of that system. However, I also think it is reasonable to expect that non-contiguous deployment will yield less improvement vs. contiguous deployment. Trying to characterize the nature of the improvement, or the differences in security between contiguous and non-contiguous deployment is where I think we will get into trouble. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 13:26:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ylc-0006EX-8I; Fri, 21 Jul 2006 13:26:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3yla-0006Ds-M0 for rpsec@ietf.org; Fri, 21 Jul 2006 13:26:22 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3yjE-0001AT-My for rpsec@ietf.org; Fri, 21 Jul 2006 13:23:58 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6LHMr4v011788 for ; Fri, 21 Jul 2006 13:22:53 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAgcaGax; Fri, 21 Jul 06 13:22:48 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6LHLh1N010788; Fri, 21 Jul 2006 13:21:43 -0400 (EDT) Date: Fri, 21 Jul 2006 13:21:43 -0400 (EDT) Message-Id: <200607211721.k6LHLh1N010788@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org Iljitsch van Beijnum said: >> By "new BGP messages", do we mean messages in the BGP definition >> of message types? > >That's what I meant, yes. > >> So new attributes would not be considered new messages? > >No, new attributes would be considered new attributes. :-) If you are talking about new messages, you don't have to worry about negotiating the capability (i.e., in order to avoid overloading an unaware recipient) - if a recipient sees a message type it doesn't understand, the BGP spec says it drops the connection. >As I've tried to say before: we should only use this mechanism for >information which is still useful after traversing one or more non- >upgraded hops AND only if we can be reasonably sure that currently >deployed routers won't run into trouble because of the extra memory >required to store this information. A valid concern. But it is difficult to phrase into a requirement, since some mechanisms may be "still useful" or may not "run into trouble". It could be expressed in the requirement document as a warning to mechanism developers - "must consider the impact", etc. >> even if the recipient was going to ignore them >> (bandwidth, etc.). > >??? > >I don't think ignoring messages is valid behavior in BGP. BGP ignores (parts of) messages all the time. Optional non-transitive attributes are *required* to be ignored, if the recipient does not recognize them. That's all I meant. >Only in new message types or modified current message types. This is >certainly desired since sending this information to an unsuspecting >router may lead to all kinds of upredictable results. Encoding the >information in new path attributes is a different matter, existing >implementations should handle those, but see above. As I noted above, new message types lead to quite predictable behavior - the connection gets dropped by an unsuspecting router (oiy). Changes to existing messages, outside of adding new attributes like you said, would (almost certainly?) violate the existing requirement for incremental deployment, so I don't think that's something that requires stating a new requirement, either. >If I speak to you in a language you don't understand the relevance of >the message is immaterial, you're not going to understand it. Yes, but if I repeat it verbatim to someone who understands the language, they will get the message. (This analogy works better if it's a note you write and I pass on. :-) ) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 13:26:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3yli-0006Gq-Ho; Fri, 21 Jul 2006 13:26:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3ylh-0006Ec-C4 for rpsec@ietf.org; Fri, 21 Jul 2006 13:26:29 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3yfk-0000xI-AY for rpsec@ietf.org; Fri, 21 Jul 2006 13:20:23 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6LHJFj4011461 for ; Fri, 21 Jul 2006 13:19:15 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_9aWvw; Fri, 21 Jul 06 13:19:03 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6LHHuAO010693; Fri, 21 Jul 2006 13:17:56 -0400 (EDT) Date: Fri, 21 Jul 2006 13:17:56 -0400 (EDT) Message-Id: <200607211717.k6LHHuAO010693@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org Iljitsch van Beijnum said: >> I think the problem here is that the "sense of the list" is any >> proposed >> security mechanism must have the former property--that the information >> must be useful, in some way, even when it has passed through an AS >> and/or peer that doesn't understand it. > >I strongly disagree with the notion that this should be a requirement. I also disagree with making the statement a requirement. (And I sure don't know how to meet or judge a "useful, in some way" requirement. :-)) >Some information can be useful after having passed through a non- >upgraded part of the network, some, by its nature, can't. The latter, >IMO, should NOT be communicated to non-upgraded routers as it only >imposes storage requirements without benefits. For the former, it's a >tradeoff that I think should be presented clearly in an architecture >or protocol spec document. Ideally, (again, IMO) this should be >configurable by the operator. I agree with this paragraph, with one reservation - I believe that, for most mechanisms, it would be difficult to decide whether the information could never, ever be useful on the other side of a gap. There are always operational means of deciding trust outside of technological mechanisms. I agree that the tradeoff should be analyzed, considered, and expressed for any suggested mechanism. Certainly the likelihood of usefulness might influence the engineering decision at mechanism design time of whether to permit carrying the info through the gap. And - has there ever been anything that was NOT configurable by the operator? Note: even for optional transitive attributes, the BGP spec says that they SHOULD be propogated, not MUST. Probably for the same space/ bandwidth/etc concerns we're talking about here. I imagine that means that there are configuration options in implementations that permit the operator to indicate whether to drop such an option or not. So there may be no need to decide at design time whether a new mechanism should be carried across gaps - that decision is in the hands of the operator anyway. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 13:31:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3yqM-0002Fl-R7; Fri, 21 Jul 2006 13:31:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3yqL-0002F6-BL for rpsec@ietf.org; Fri, 21 Jul 2006 13:31:17 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3yqI-0002Cx-VV for rpsec@ietf.org; Fri, 21 Jul 2006 13:31:17 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6LHUBAx012589 for ; Fri, 21 Jul 2006 13:30:11 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAauaiLy; Fri, 21 Jul 06 13:30:08 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6LHT282011044; Fri, 21 Jul 2006 13:29:02 -0400 (EDT) Date: Fri, 21 Jul 2006 13:29:02 -0400 (EDT) Message-Id: <200607211729.k6LHT282011044@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: Re: [RPSEC] Discontiguous Deployment... X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org Russ White said: >Should there be a requirement that any proposed security system must be >useful even if deployed in a noncontiguous way? Or should this not be a >requirement? I do not agree that this should be a requirement. I also don't know how one would meet a requirement of "useful", or judge whether a mechanism met the requirement of "useful". Certainly, in each contiguous island of deployment, a mechanism could be "useful". --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 13:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3z9f-0001Ku-M2; Fri, 21 Jul 2006 13:51:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3z9d-0001Kb-RH for rpsec@ietf.org; Fri, 21 Jul 2006 13:51:13 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3z93-0004Sj-6Q for rpsec@ietf.org; Fri, 21 Jul 2006 13:50:39 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6LHnYYj014715 for ; Fri, 21 Jul 2006 13:49:34 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1_ayUC; Fri, 21 Jul 06 13:49:30 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6LHmJRp011663; Fri, 21 Jul 2006 13:48:19 -0400 (EDT) Date: Fri, 21 Jul 2006 13:48:19 -0400 (EDT) Message-Id: <200607211748.k6LHmJRp011663@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt X-Spam-Score: 0.2 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org Curtis Villamizar said: Iljitsch van Beijnum writes: >> > 2. A BGP security mechanisms may authenticate (or encrypte) >> >> Encrypt? > > >Not likely imho. Ask Sandy? :-) I don't know that I'm the right person to ask - Russ White or Sue Hares might have more data to give an answer based on facts. But I can speculate. I have heard people say that they do not want to reveal routing information to everyone. Usually this is motivated as not wanting to reveal the topology info of their infrastructure. I may not grok the need, but I have heard it expressed. >You never know though. Approximate GPS >location of a mobile router would be encrypted if anyone every decided >they needed that. Location could be used in routing. In my own blue-sky-ing, I was thinking of the presentation at the idr meeting about QoS needs in the GIG. Some QoS parameters might provide info the sender would not want revealed to just anyone. >> It would certainly be a bad idea to carry information in path >> attributes that is invalidated as soon as it is relayed by a non- >> upgraded router. (This is just an example of a bad idea.) > > >If authentication information is all that is added to BGP then tossing >*all* the authentication information is certainly a bad idea. > >What might make sense is to toss any per hop path authentication >before advertising to a router that would not add its authentication. >That would make sense if policy was based only on prefering a route >with a completely authenticated path over one that is not complete but >did not prefer paths with less hops not authenticated over ones with >more hops not authenticated. OTOH if a completely authenticated path >was not available a path with only AS from a small set of fairly well >trusted AS in it might be preferred over one with more untrusted AS. I agree with this, particularly if you mean preferring a *partially* authenticated path with a gap over fairly well trusted ASs. >Removing information because it won't be needed downstream could be >considered a configurable space optimization. Sound like I need a >SHOULD in that paragraph, making it. > >> > 1. The security information SHOULD be passed intact but >> > uninterpreted across routers that did not support the same >> > security mechanism. As I noted in another message, a mechanism carried in an optional transitive attribute is (likely?) configurable already, given the SHOULD status of propogating it in the BGP spec. So your SHOULD is implementable. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 14:35:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3zqN-0004Fp-3U; Fri, 21 Jul 2006 14:35:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3zqL-0004FT-Ov for rpsec@ietf.org; Fri, 21 Jul 2006 14:35:21 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3zqK-0003np-GI for rpsec@ietf.org; Fri, 21 Jul 2006 14:35:21 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6LIfK76024691; Fri, 21 Jul 2006 14:41:20 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607211841.k6LIfK76024691@workhorse.brookfield.occnc.com> To: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Wed, 19 Jul 2006 20:45:29 +0200." <546F649B-6D5C-4DAE-BF8F-9B8008AB8ADD@muada.com> Date: Fri, 21 Jul 2006 14:41:20 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Just noticed this in a prior message. In message <546F649B-6D5C-4DAE-BF8F-9B8008AB8ADD@muada.com> Iljitsch van Beijnum writes: > > > though care must be taken to ensure > > UPDATES can traverse intermediate routers which don't support the > > new format. > > Updates don't traverse intermediate routers. Substiture "advertisements" for "updates". Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 14:52:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G406X-0001CY-Bb; Fri, 21 Jul 2006 14:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G406V-00018I-9k for rpsec@ietf.org; Fri, 21 Jul 2006 14:52:03 -0400 Received: from iceblock01.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G402W-0007hu-IZ for rpsec@ietf.org; Fri, 21 Jul 2006 14:47:57 -0400 Received: (qmail 1506 invoked from network); 21 Jul 2006 18:42:13 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 21 Jul 2006 18:42:12 -0000 Received: from LIPC ([192.168.1.103]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 11:50:52 -0700 From: "Tony Li" To: , Subject: RE: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Date: Fri, 21 Jul 2006 11:47:52 -0700 Message-ID: <005f01c6acf6$2bb2aca0$837d14ac@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acas6tMPkkyq4VijQT2PBMPnvPI/pgACu7WA In-Reply-To: <200607211721.k6LHLh1N010788@tislabs.com> X-OriginalArrivalTime: 21 Jul 2006 18:50:52.0058 (UTC) FILETIME=[96EB67A0:01C6ACF6] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org > If you are talking about new messages, you don't have to worry about > negotiating the capability (i.e., in order to avoid overloading an > unaware recipient) - if a recipient sees a message type it doesn't > understand, the BGP spec says it drops the connection. Any solution that results in BGP peerings being dropped would be immediately undeployed. Thus, I think it's reasonable that we require that new BGP messages be first capability negotiated. There is no need for such a requirement for new path attributes. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 15:24:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40br-0000V5-Oy; Fri, 21 Jul 2006 15:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40bq-0000Um-R6 for rpsec@ietf.org; Fri, 21 Jul 2006 15:24:26 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G40ba-0007b5-2e for rpsec@ietf.org; Fri, 21 Jul 2006 15:24:11 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6LJNp0G096483 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Jul 2006 21:23:51 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200607211717.k6LHHuAO010693@tislabs.com> References: <200607211717.k6LHHuAO010693@tislabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93540A62-2BB8-4F69-9E13-F7BE6665B2FF@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Date: Fri, 21 Jul 2006 21:24:06 +0200 To: sandy@tislabs.com X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Errors-To: rpsec-bounces@ietf.org On 21-jul-2006, at 19:17, sandy@tislabs.com wrote: >> Some information can be useful after having passed through a non- >> upgraded part of the network, some, by its nature, can't. The latter, >> IMO, should NOT be communicated to non-upgraded routers as it only >> imposes storage requirements without benefits. For the former, it's a >> tradeoff that I think should be presented clearly in an architecture >> or protocol spec document. Ideally, (again, IMO) this should be >> configurable by the operator. > I agree with this paragraph, with one reservation - I believe that, > for > most mechanisms, it would be difficult to decide whether the > information > could never, ever be useful on the other side of a gap. There are > always operational means of deciding trust outside of technological > mechanisms. I agree that the tradeoff should be analyzed, considered, > and expressed for any suggested mechanism. Certainly the > likelihood of > usefulness might influence the engineering decision at mechanism > design > time of whether to permit carrying the info through the gap. I think we're moving towards the following set of choices: 1. Make the choice of backward/non-backward compatible encoding and/ or the dissemination of security information towards non-upgraded peers operator configurable, or 2. Defer the choice until later when, presumably, the tradeoffs will be better understood, or 3. Present an in-depth analysis of all the relevant factors to support the choice made Agree? > And - has there ever been anything that was NOT configurable by the > operator? Sure, lots of stuff. > Note: even for optional transitive attributes, the BGP spec says that > they SHOULD be propogated, not MUST. Probably for the same space/ > bandwidth/etc concerns we're talking about here. I imagine that means > that there are configuration options in implementations that permit > the > operator to indicate whether to drop such an option or not. I can't say that I've ever encountered such a mechanism, but I have to say that I never looked for it so I can't claim that it doesn't exist. But I think since there are only very few optional path attributes, there was never a great need to filter out unknown ones. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 15:24:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40c8-0001KA-Q7; Fri, 21 Jul 2006 15:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40c6-0001Eq-N7 for rpsec@ietf.org; Fri, 21 Jul 2006 15:24:42 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G40YW-0007UJ-Gi for rpsec@ietf.org; Fri, 21 Jul 2006 15:21:01 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6LJQshV024886; Fri, 21 Jul 2006 15:26:54 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607211926.k6LJQshV024886@workhorse.brookfield.occnc.com> To: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Fri, 21 Jul 2006 09:41:09 EDT." Date: Fri, 21 Jul 2006 15:26:54 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Iljitsch van Beijnum , rpsec@ietf.org, Tony Tauber , Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Stephen Kent writes: > > At 1:46 PM -0400 7/20/06, Curtis Villamizar wrote: > >... > > > >BPG security mechanisms differ in the following ways. > > > > 1. The scope of key distribution may be local or global. > > > > a. A BGP security mechanism may use a transitive trust model, > > > > b. A BGP security mechanism may use a form of authentication > > where keys are globally available and provide authentication > > information which is globally verifiable. > > > > c. A BGP security mechanism may use both of the above using one > > scope for one type of information and another scope for > > another type of information. > > > > 2. A BGP security mechanisms may authenticate (or encrypte) > > different types of information including combination of the > > following. > > > > a. A BGP security mechanism may provide authentication of > > the origin or or information related to the origin. > > > > b. A BGP security mechanism may provide authentication of the BGP > > peer. > > > > c. A BGP security mechanism may provide authentication of each AS > > in the path. > > > > I think it is confusing to refer to "a BGP security mechanism" when > referring to all of these security issues. For example, one might > use different means of authenticating a BGP peer in different > contexts and this choice may be completely independent of a mechanism > used to verify route origination on a global basis. > > Steve Steve, What term would you prefer? BTW. In a transitive trust model there is no implication that all the peers along the path used the same method to authenticate there peer, just that they used *some* authentication method and was convinced that the peer was who they claimed to be. It would be possible to add an optional non-transitive attribute indicating that a specific method was used on the entire path. If a router didn't understand that attribute it would be dropped. That functionality was not implied anywhere above. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 15:26:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40dm-0002mC-9F; Fri, 21 Jul 2006 15:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G40cm-0002Bq-0T for rpsec@ietf.org; Fri, 21 Jul 2006 15:25:24 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G40Rh-0006gk-Uv for rpsec@ietf.org; Fri, 21 Jul 2006 15:13:58 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6LJK6O6024851; Fri, 21 Jul 2006 15:20:06 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607211920.k6LJK6O6024851@workhorse.brookfield.occnc.com> To: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Fri, 21 Jul 2006 13:08:19 +0200." Date: Fri, 21 Jul 2006 15:20:06 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Iljitsch van Beijnum writes: > > On 21-jul-2006, at 2:41, Curtis Villamizar wrote: > > >> I wouldn't want my routers to carry information that I can't > >> inspect... > > > Do you block IPSEC flows too? :-) > > That's different. Either the packets are addressed at one of my > hosts, which will hopefully be able to decrypt them, or someone is > paying me to carry carry them and they don't want me to look inside, > which I don't find unreasonable. > > I'm not saying that encryption can have no place in inter-domain > routing ever under any circumstance, but the burden of proof of why > this would be a good thing is firmly on the people who may want this. > The possible argument that otherwise someone may see a private > routing policy utterly fails to convince me. I gave an example. > > How would you know its encrypted if it was in an optional transitive > > attribute that your router didn't understand? And why would you care > > if your big government customer needed it but you didn't? > > I would care if I peer with you and YOUR big government customer > injects the stuff and pays you good money for the privilege, but I > don't see any of that money but I do need to buy more memory to store > this stuff even though it's encrypted so by definition I have no use > for it. > > Things are different when we don't peer but you buy transit from > me. :-) > > [...] If provider A and C both had government customers and provider B didn't and had to carry 1 MB of extra attributes in their router with 1-4 GB or memory, I doubt they'd even notice. If the entire Internet carried lots of extra per hop authentication it would be a burden. We are dicsussing a hypothetical and getting off topic. If you don't mind leaving the "authenticated (or encrypted)" in the wording then we can move on. > >> That is not necessarily an ideal situation. This means encoding the > >> security information in path attributes, which means that BGP tables > >> in existing routers will be inflated without benefit to those > >> existing routers. > > > You are right in a sense. But I disagree. > > > It depends on the size of these extra attributes. Some of the > > proposals add so much information that I don't see it as feasible > > except in a small closed network. If people want to define protocols > > that no one will ever deploy and whose attributes will be tossed > > that's their business. They've been at it for a while though. > > "Anyone with a keyboard and time on their hands can write an internet > draft." Sure. But what we're trying to do here is come up with > something that is useful for wide deployment throughout the internet. We are coming up with a requirements document at this point. I'm trying to accomodate is that one set of security mechanisms will be appropriate for the Innternet at large. Another set of security mechanisms will be appropriate for applications requiring a higher degree of security. It might even come to a country by country or provider by provider mixed deployment. On that topic I suspect that the Internet will end up with a model of origin authentication and transitive trust. Some groups, notably government and military will want better security and require per hop authentication. The latter may be infeasible in the entire Internet due to its resource requirements. Currently we have a set of somewhat conflicting requirement. There really is no way to provide strong encryption with no impact on memory and CPU loading and no change in deployed equipment. RPSEC work needs to plan well for a partial deployment and mixed solutions. > >> It would certainly be a bad idea to carry information in path > >> attributes that is invalidated as soon as it is relayed by a non- > >> upgraded router. (This is just an example of a bad idea.) > > > If authentication information is all that is added to BGP then tossing > > *all* the authentication information is certainly a bad idea. > > That's not what I was saying. What I mean is: suppose a new system > includes a way to authenticate the AS path by requiring each AS/ > router to sign its changes to the AS path. Now there is a non- > upgraded AS in the middle. Obviously this makes it impossible to > authenticate the AS path in this manner. This makes it unnecessary > and therefore harmful to include the AS path authentication > information when sending an update to a non-upgraded router. I gave an example where it might be useful to not toss this information even if nothing is added to it. > > What might make sense is to toss any per hop path authentication > > before advertising to a router that would not add its authentication. > > Right! Except that you haven't read the next few paragraphs yet. > > That would make sense if policy was based only on prefering a route > > with a completely authenticated path over one that is not complete but > > did not prefer paths with less hops not authenticated over ones with > > more hops not authenticated. OTOH if a completely authenticated path > > was not available a path with only AS from a small set of fairly well > > trusted AS in it might be preferred over one with more untrusted AS. > > Sure. But we have to be careful about injecting huge amounts of > authentication data just in case someone somewhere might find it > marginally useful. Not sending what we know won't be useful is the > first step here, operator control should take care of the rest. > > > Removing information because it won't be needed downstream could be > > considered a configurable space optimization. Sound like I need a > > SHOULD in that paragraph, making it. > > >>> 1. The security information SHOULD be passed intact but > >>> uninterpreted across routers that did not support the same > >>> security mechanism. > > > Is that better? > > No, this requires stuff that may or may not be useful. SHOULD does not require anything. MUST would require it. This allows for the possibility of tossing the information if there was reason to do so, such as the information was too big to carry. > If it's a good idea to include the information, I think we can trust > the people designing solutions to make this happen. We shouldn't > require them to do it just because it _might_ be useful. That's why I used SHOULD. Would you like to suggest better wording? > >>> If the route selection is modified based on level of trust, an > >>> entire > >>> AS MUST implement the same route selection to avoid loops. > > >> This is not a requirement in existing BGP and I don't see how adding > >> security imposes this as a requirement. > > > All routers must implement the same route selection algorithm. That > > is a requirement of plain old BGP. The exact route selection > > algorithm is defined in RFC4271. > > Ah, but my routers still run RFC 1771. :-) But the route selection in RFC4271 reflects reality where the route selection defined in RFC1771 was too loosely defined and was deviated from in virtually *all* routers on the market. They all interoperated becasue they supported options that could make the route selection the same within an AS. They could be configured such that route selection differed and could create persistent route loops. > RFC 4271: > > If the route is learned from an internal peer, either the > value of > the LOCAL_PREF attribute is taken as the degree of preference, or > the local system computes the degree of preference of the route > based on preconfigured policy information. Note that the latter > may result in formation of persistent routing loops. > > So apparently having different route selection criteria inside the > same AS is allowed, even though the new RFC claims this can lead to > loops, which isn't true: this may lead to state where there is no > stable convergence, but (persistent) loops shouldn't happen. The route selection is exactly the same. The method of setting incoming LOCAL_PREF can differ. LOCAL_PREF is the first thing considered. Try reading section 9.1 in its entirety and carefully. LOCAL_PREF is used only in IBGP. One router sets LOCAL_PREF on any given route. All routers consider LOCAL_PREF first in route selection. Route selection is the same throughout the AS as described in "9.1.2. Phase 2: Route Selection". > > This is stating that if within an AS > > the route selection defined in RFC4271 is not used, it has to be the > > same throughout the AS. > > I don't think so. Where does it say this? If you change route selection, meaning what is described in "Phase 2: Route Selection", you have to do so with extreme care. Now if you reread what I wrote it might make a bit more sense to you. BGP terms can be a little non-obvious but "route selection" means what is written in "9.1.2. Phase 2: Route Selection". It does not mean setting LOCAL_PREF. Below is the original text that you took apart. Your point is taken and I added the sentence referencing LOCAL_PREF (third sentence) and added to the next sentence. Does it make more sense now? Given the above properties, a router could implement policy which considered the above levels of trust. This routing policy could determine whether to accept the route. This routing policy could impact the calculation of degree of preference (setting of BGP LOCAL_PREF) as described in RFC4271 in "9.1.1. Phase 1: Calculation of Degree of Preference". This routing policy could modify the route selection as described in RFC4271 in "9.1.2. Phase 2: Route Selection". If the route selection is modified based on level of trust, an entire AS MUST implement the same route selection to avoid loops. Orderly transition of the AS must be considered. Note that one way to accomplish a transition that if free of persitant loops during the transition is to make the route selection change conditional on the absence of an intra-AS BGP community which is set on every route during the transition, then removed. The transition then occurs on a per route basis as the BGP community is removed. To accompish an orderly transition using this method, BGP community MUST be supported by the implementation in any policy that modifies the route selection. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 16:40:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G41nH-0003Dl-Tj; Fri, 21 Jul 2006 16:40:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G41nG-0003De-PO for rpsec@ietf.org; Fri, 21 Jul 2006 16:40:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G40pf-00009E-9A for rpsec@ietf.org; Fri, 21 Jul 2006 15:38:43 -0400 Received: from m106.maoz.com ([205.167.76.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G40d0-0004VE-L4 for rpsec@ietf.org; Fri, 21 Jul 2006 15:25:40 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k6LJPRB6005927; Fri, 21 Jul 2006 12:25:27 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) with ESMTP id k6LJPRhm005924; Fri, 21 Jul 2006 12:25:27 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Fri, 21 Jul 2006 12:25:27 -0700 (PDT) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: Curtis Villamizar Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt -- other comments In-Reply-To: <200607210356.k6L3uNW8021446@workhorse.brookfield.occnc.com> Message-ID: References: <200607210356.k6L3uNW8021446@workhorse.brookfield.occnc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.6 (--) 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: , Errors-To: rpsec-bounces@ietf.org On Thu, 20 Jul 2006, Curtis Villamizar wrote: > While adoption of BGP security measures may preclude certain > classes of attacks on subscriber traffic, these measures are > not a substitute for use of subscriber-based security > mechanisms of the sort noted above. > > > There is no such thing as "subscriber" traffic in BGP or anything > IP. It really shows that a MSO author had a hand in writing this. No, it doesn't. It shows you spent a little time trying to guess people's biases. (Good deconsructionist methodology which I support.) At the time I took over _editing_ the document, I'd been at Comcast only a month or so. I guess my roots at NEARnet/BBN(Planet)/GTE/Genuity/Level3 weren't sufficiently on display. Gandering back a year to http://www1.ietf.org/mail-archive/web/rpsec/current/msg01310.html shows that Steve Kent was the one who introduced this term and described his usage of it. (Though I also hail from Cambridge, Steve Kent and I might as well have worked for different companies.) Thanks to all for the other comments, keep 'em coming and I'll try and sort out how to incorporate them after discussion dies down. Heading on vacation for a week, though. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 17:13:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G42Jc-00066v-Ts; Fri, 21 Jul 2006 17:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G42Ja-00064a-Ls for rpsec@ietf.org; Fri, 21 Jul 2006 17:13:42 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G42Fs-0008S6-Is for rpsec@ietf.org; Fri, 21 Jul 2006 17:09:53 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G42Fr-00057S-68; Fri, 21 Jul 2006 17:09:52 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200607211926.k6LJQshV024886@workhorse.brookfield.occnc.com> References: <200607211926.k6LJQshV024886@workhorse.brookfield.occnc.com> Date: Fri, 21 Jul 2006 16:54:46 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: rpsec@ietf.org, Tony Tauber , Iljitsch van Beijnum , 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: , Errors-To: rpsec-bounces@ietf.org At 3:26 PM -0400 7/21/06, Curtis Villamizar wrote: > >... > > >> I think it is confusing to refer to "a BGP security mechanism" when >> referring to all of these security issues. For example, one might >> use different means of authenticating a BGP peer in different >> contexts and this choice may be completely independent of a mechanism >> used to verify route origination on a global basis. >> >> Steve > > >Steve, > >What term would you prefer? > >BTW. In a transitive trust model there is no implication that all the >peers along the path used the same method to authenticate there peer, >just that they used *some* authentication method and was convinced >that the peer was who they claimed to be. It would be possible to add >an optional non-transitive attribute indicating that a specific method >was used on the entire path. If a router didn't understand that >attribute it would be dropped. That functionality was not implied >anywhere above. > What I objected to was the use of the term "BGP Security mechanism" to refer to what are a set of independent security mechanisms that need not be uniform and which may be largely independent of one another. I thought your example above was consistent with what I was trying to say, but then I saw the reference to a path attribute that attests to what form of authentication was used on each hop. The confusion arises because the peer authentication to which I was referring was what an (e)BGP router does to decide whether to accept an inbound UPDATE message as being from the indicated peer, at a low level. This is a purely local example of peer authentication. Your example is also a valid instance of peer authentication, but one that arises only if one assumes reliance on transitive trust to authenticate a path. It is an example that makes sense only under one set of assumptions, and that's what confused me. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 17:14:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G42KN-0006iy-9e; Fri, 21 Jul 2006 17:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G42KM-0006it-6m for rpsec@ietf.org; Fri, 21 Jul 2006 17:14:30 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G42KL-0001Cx-05 for rpsec@ietf.org; Fri, 21 Jul 2006 17:14:30 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G42KK-00059y-5g; Fri, 21 Jul 2006 17:14:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200607210356.k6L3uNW8021446@workhorse.brookfield.occnc.com> Date: Fri, 21 Jul 2006 17:14:27 -0400 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt -- other comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: rpsec-bounces@ietf.org At 12:25 PM -0700 7/21/06, Tony Tauber wrote: >On Thu, 20 Jul 2006, Curtis Villamizar wrote: > >> While adoption of BGP security measures may preclude certain >> classes of attacks on subscriber traffic, these measures are >> not a substitute for use of subscriber-based security >> mechanisms of the sort noted above. >> >> >>There is no such thing as "subscriber" traffic in BGP or anything >>IP. It really shows that a MSO author had a hand in writing this. IP networks transport traffic for subscribers (end users if you wish) and they transport traffic that is used by the networks for their own management purposes. This text was describing this distinction with regard to the scope of security offered by routing security measures. If you have other terms that you think do a better job of making this distinction by all means offer them, but the distinction is real and seems relevant to this document. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 17:15:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G42Jd-00067e-Iy; Fri, 21 Jul 2006 17:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G42Ja-00064C-Lx for rpsec@ietf.org; Fri, 21 Jul 2006 17:13:42 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G42Fr-0008S3-N6 for rpsec@ietf.org; Fri, 21 Jul 2006 17:09:52 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G42Fq-00057S-6J; Fri, 21 Jul 2006 17:09:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200607211920.k6LJK6O6024851@workhorse.brookfield.occnc.com> References: <200607211920.k6LJK6O6024851@workhorse.brookfield.occnc.com> Date: Fri, 21 Jul 2006 16:45:36 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rpsec@ietf.org, Iljitsch van Beijnum 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: , Errors-To: rpsec-bounces@ietf.org At 3:20 PM -0400 7/21/06, Curtis Villamizar wrote: >... >We are coming up with a requirements document at this point. I'm >trying to accomodate is that one set of security mechanisms will be >appropriate for the Innternet at large. Another set of security >mechanisms will be appropriate for applications requiring a higher >degree of security. It might even come to a country by country or >provider by provider mixed deployment. This WG has not come to consensus on what is "appropriate" for Internet at large, so trying to refine requirements based on one's perception of that is likely to cause us to fail to make progress. >On that topic I suspect that the Internet will end up with a model of >origin authentication and transitive trust. Some groups, notably >government and military will want better security and require per hop >authentication. The latter may be infeasible in the entire Internet >due to its resource requirements. And I would argue that since transitive trust is precisely what allows errors by one ISP to screw up routing by many other ISPs, we ought to outlaw solutions that rely on this notion. So, we have a simple example of two conflicting views of what represents "appropriate" security for the public Internet, which is why we have tried to avoid details like this in the requirements document. >Currently we have a set of somewhat conflicting requirement. There >really is no way to provide strong encryption with no impact on memory >and CPU loading and no change in deployed equipment. RPSEC work needs >to plan well for a partial deployment and mixed solutions. presumably you were envisioning to crypto operations other than "encryption" above, since the proposals that have been put forth do not make any use of encryption. > ... Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 18:01:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G433k-00041t-Hm; Fri, 21 Jul 2006 18:01:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G433j-00041o-B3 for rpsec@ietf.org; Fri, 21 Jul 2006 18:01:23 -0400 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G433h-0008LP-Uk for rpsec@ietf.org; Fri, 21 Jul 2006 18:01:23 -0400 Received: (qmail 19445 invoked from network); 21 Jul 2006 21:55:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 21 Jul 2006 21:55:38 -0000 Received: from LIPC ([192.168.1.103]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 15:04:18 -0700 From: "Tony Li" To: "'Stephen Kent'" , "'Tony Tauber'" Subject: RE: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt -- other comments Date: Fri, 21 Jul 2006 15:01:17 -0700 Message-ID: <002001c6ad11$30bed5a0$837d14ac@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcatCqjObz7qfBkKS/W2dqyBc/n2KQABcR9w X-OriginalArrivalTime: 21 Jul 2006 22:04:18.0023 (UTC) FILETIME=[9C9D1F70:01C6AD11] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org > >>There is no such thing as "subscriber" traffic in BGP or anything > >>IP. It really shows that a MSO author had a hand in writing this. > > IP networks transport traffic for subscribers (end users if you wish) > and they transport traffic that is used by the networks for their own > management purposes. This text was describing this distinction with > regard to the scope of security offered by routing security measures. > If you have other terms that you think do a better job of making this > distinction by all means offer them, but the distinction is real and > seems relevant to this document. Many of my IETFish conversations use the terms "control plane" and "data plane" for control traffic and transit traffic, respectively. The distinction can sometimes be important when considering control traffic (e.g., IBGP) that is being forwarded multiple IP hops between BGP speakers. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 18:20:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G43MO-0005QN-MK; Fri, 21 Jul 2006 18:20:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G43MN-0005Ke-D7 for rpsec@ietf.org; Fri, 21 Jul 2006 18:20:39 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G43ML-00028t-W2 for rpsec@ietf.org; Fri, 21 Jul 2006 18:20:39 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6LMQZbQ028036; Fri, 21 Jul 2006 18:26:35 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607212226.k6LMQZbQ028036@workhorse.brookfield.occnc.com> To: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Fri, 21 Jul 2006 16:54:46 EDT." Date: Fri, 21 Jul 2006 18:26:35 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Russ White , rpsec@ietf.org, Tony Tauber , Iljitsch van Beijnum X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Stephen Kent writes: > > At 3:26 PM -0400 7/21/06, Curtis Villamizar wrote: > > > >... > > > > >> I think it is confusing to refer to "a BGP security mechanism" when > >> referring to all of these security issues. For example, one might > >> use different means of authenticating a BGP peer in different > >> contexts and this choice may be completely independent of a mechanism > >> used to verify route origination on a global basis. > >> > >> Steve > > > > > >Steve, > > > >What term would you prefer? > > > >BTW. In a transitive trust model there is no implication that all the > >peers along the path used the same method to authenticate there peer, > >just that they used *some* authentication method and was convinced > >that the peer was who they claimed to be. It would be possible to add > >an optional non-transitive attribute indicating that a specific method > >was used on the entire path. If a router didn't understand that > >attribute it would be dropped. That functionality was not implied > >anywhere above. > > > > What I objected to was the use of the term "BGP Security mechanism" > to refer to what are a set of independent security mechanisms that > need not be uniform and which may be largely independent of one > another. I thought your example above was consistent with what I was > trying to say, but then I saw the reference to a path attribute that > attests to what form of authentication was used on each hop. > > The confusion arises because the peer authentication to which I was > referring was what an (e)BGP router does to decide whether to accept > an inbound UPDATE message as being from the indicated peer, at a low > level. This is a purely local example of peer authentication. Your > example is also a valid instance of peer authentication, but one that > arises only if one assumes reliance on transitive trust to > authenticate a path. It is an example that makes sense only under one > set of assumptions, and that's what confused me. > > Steve Maybe we need some definitions. origin authentication - crypto authentication of the route origination. peer authentication - crypto authentication which provides additional assurance that the peer is who the peer claims to be. transitive trust model - the assumption that if each peering is autheticated and the origination was authenticated that the path is valid. per hop authentication - any mechanism where every transfer from peer to peer adds additional information or makes modifications to information that can be used to verify authenticity of the path. Every hop reencrypting a token with their private key is not a transitive trust model. A transitive trust model is where if A trusts information from B and B trust information from C then A trusts information it got from B that B claims to have obtained from C, and so on. Reencrypting a token with a private key at each hop does insure that the path is valid. This insures that a rogue AS does not grab an originated route or partial path and add its AS and pass that along to disrupt routing. It does not protect against the most common problem. The origination was just plain "in error". It does protect against the accidental (or intentional) injection of something not even vaguely related to that AS but so would a means of supporting origin authentication and the use of transitive trust. Whether you need to protect against such a rogue AS may depend on who you are providing network service to - consumers, business, or DoD. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 18:30:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G43Vq-0003bq-G1; Fri, 21 Jul 2006 18:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G43Vo-0003a6-UX for rpsec@ietf.org; Fri, 21 Jul 2006 18:30:24 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G43Vn-000374-KT for rpsec@ietf.org; Fri, 21 Jul 2006 18:30:24 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6LMaKvS028086; Fri, 21 Jul 2006 18:36:20 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607212236.k6LMaKvS028086@workhorse.brookfield.occnc.com> To: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt -- other comments In-reply-to: Your message of "Fri, 21 Jul 2006 17:14:27 EDT." Date: Fri, 21 Jul 2006 18:36:20 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Stephen Kent writes: > > At 12:25 PM -0700 7/21/06, Tony Tauber wrote: > >On Thu, 20 Jul 2006, Curtis Villamizar wrote: > > > >> While adoption of BGP security measures may preclude certain > >> classes of attacks on subscriber traffic, these measures are > >> not a substitute for use of subscriber-based security > >> mechanisms of the sort noted above. > >> > >> > >>There is no such thing as "subscriber" traffic in BGP or anything > >>IP. It really shows that a MSO author had a hand in writing this. > > IP networks transport traffic for subscribers (end users if you wish) > and they transport traffic that is used by the networks for their own > management purposes. This text was describing this distinction with > regard to the scope of security offered by routing security measures. > If you have other terms that you think do a better job of making this > distinction by all means offer them, but the distinction is real and > seems relevant to this document. > > Steve IP traffic has been the term used throughout the Internet's history so why not stick with that. Subscriber makes no sense in all but recent contexts. Subscriber traffic or end user traffic would not include SNMP for example. Does a BPG security mechanism protect SNMP traffic? Of course my next pair of sentences were: Please just drop this paragraph. It is obvious to the intended audience that we are not securing IP services. Do you think it is not obvious to anyone that has any idea what BGP does that any BGP security mechanism does not do anything for end-user traffic carried by the router? If it is *that* obvious why say it. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 21 19:29:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G44QS-0003ZS-J7; Fri, 21 Jul 2006 19:28:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G44QR-0003UZ-0f for rpsec@ietf.org; Fri, 21 Jul 2006 19:28:55 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G44QP-0006Ms-DH for rpsec@ietf.org; Fri, 21 Jul 2006 19:28:54 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19jBiiG6MMbXm0oLBcfMfk0lvh412wWS5w@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.6/8.13.6) with ESMTP id k6LNSV2R004180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Jul 2006 00:28:44 +0100 Date: Sat, 22 Jul 2006 00:28:31 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Russ White Subject: Re: [RPSEC] Discontiguous Deployment... In-Reply-To: <44C02C17.1000708@cisco.com> Message-ID: References: <44C02C17.1000708@cisco.com> Mail-Copies-To: paul@jakma.org Mail-Followup-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1612/Thu Jul 20 20:41:45 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 20 Jul 2006, Russ White wrote: > Should there be a requirement that any proposed security system > must be useful even if deployed in a noncontiguous way? Or should > this not be a requirement? As a requirement: No, it would predispose the requirements towards certain solutions. However, it would obviously be highly desireable if a solution could provide partial security benefits even across speakers not capable of participating. regards, - -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Freedom begins when you tell Mrs. Grundy to go fly a kite. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (GNU/Linux) iHUEARECADUFAkTBYx8uGmh0dHA6Ly93d3cuamFrbWEub3JnL35wYXVsL3BncF9w b2xpY3ktMS4wLnR4dAAKCRDYa/eUZKL/ao3LAJ0TEg1/y1Z7OpT+SUYK7MGGYabp fQCg6Q6+b5mjaeRN2RebzplNgF/xk0o= =n17S -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 06:09:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4atT-0006lt-Ku; Sun, 23 Jul 2006 06:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4atS-0006ll-Qx for rpsec@ietf.org; Sun, 23 Jul 2006 06:09:02 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4atR-0002P0-Fv for rpsec@ietf.org; Sun, 23 Jul 2006 06:09:02 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6NA8eHM034601 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 23 Jul 2006 12:08:41 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <005e01c6acf5$a6c54930$837d14ac@tropos.com> References: <005e01c6acf5$a6c54930$837d14ac@tropos.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4BFA0FFF-D9E8-4049-908A-ED9BBE768DA0@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Date: Sun, 23 Jul 2006 12:08:56 +0200 To: X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: , Errors-To: rpsec-bounces@ietf.org On 21-jul-2006, at 20:44, Tony Li wrote: >> suppose a new system >> includes a way to authenticate the AS path by requiring each AS/ >> router to sign its changes to the AS path. Now there is a non- >> upgraded AS in the middle. Obviously this makes it impossible to >> authenticate the AS path in this manner. This makes it unnecessary >> and therefore harmful to include the AS path authentication >> information when sending an update to a non-upgraded router. > It seems to me that if path authentication information is carried > across > a non-upgraded AS, that the non-upgraded AS is always going to see > that > as useless and by your logic harmful information. I assumed the determination of usefulness to be wider than just a single AS. Others pointed out that path authentication could still work if there are non-upgraded, but trustworthy ASes in the middle of the path. I suppose the issue isn't a black/white one. This makes it harder to determine what to do in practice, but that doesn't alleviate my concern that some people may want to dump several hundred bytes of authentication data in the path attributes for each prefix they source since this data MAY be useful somewhere, and routers all over the internet start running out of memory. > If we prohibit a > solution from ever asking for opaque transport, then we lose out on > potential benefit. The greatest benefit of all is keeping the internet running. :-) Making it run securely is a secondary consideration. > Obviously, any solution needs to be cognizant of how it will behave > in a > non-contiguous deployment and make intelligent decisions as to how it > will operate. However, I'm unwilling to support a requirement that > says > that a solution may not use opaque transport of path attributes. > There's a possible benefit that we should not prohibit. Right. I wasn't saying that this should be prohibited, my problem is that some requirements indirectly (seem to) mandate this approach, rather than just allow it, even in cases where it is either harmful and/or has no benefits. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 06:51:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4bYJ-0006oG-I7; Sun, 23 Jul 2006 06:51:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4bYI-0006o5-7E for rpsec@ietf.org; Sun, 23 Jul 2006 06:51:14 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4bYG-0001TS-Mz for rpsec@ietf.org; Sun, 23 Jul 2006 06:51:14 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6NAop19035162 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 23 Jul 2006 12:50:51 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200607211920.k6LJK6O6024851@workhorse.brookfield.occnc.com> References: <200607211920.k6LJK6O6024851@workhorse.brookfield.occnc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1229BEB0-3E78-4FA2-A9EC-98D9464FE772@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Date: Sun, 23 Jul 2006 12:51:07 +0200 To: curtis@occnc.com X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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: , Errors-To: rpsec-bounces@ietf.org On 21-jul-2006, at 21:20, Curtis Villamizar wrote: > If provider A and C both had government customers and provider B > didn't and had to carry 1 MB of extra attributes in their router with > 1-4 GB or memory, I doubt they'd even notice. Guess what: not every router has a gigabyte or more memory. And some routers get two, three, four or even more views of the global routing table. We can't afford to be cavalier about this even though obviously the internet won't crash and burn at the first sign of some extra data in BGP path attributes. >> "Anyone with a keyboard and time on their hands can write an internet >> draft." Sure. But what we're trying to do here is come up with >> something that is useful for wide deployment throughout the internet. > We are coming up with a requirements document at this point. I'm > trying to accomodate is that one set of security mechanisms will be > appropriate for the Innternet at large. Another set of security > mechanisms will be appropriate for applications requiring a higher > degree of security. It might even come to a country by country or > provider by provider mixed deployment. Unless I'm seriously overlooking something, today, operators generally can't filter out unwanted unknown path attributes. I don't see how we can assume that those would be contained. >>>>> 1. The security information SHOULD be passed intact but >>>>> uninterpreted across routers that did not support the same >>>>> security mechanism. >>> Is that better? >> No, this requires stuff that may or may not be useful. > SHOULD does not require anything. MUST would require it. Semantics. SHOULD in a requirements document is a very strong statement. > But the route selection in RFC4271 reflects reality where the route > selection defined in RFC1771 was too loosely defined and was deviated > from in virtually *all* routers on the market. They all interoperated > becasue they supported options that could make the route selection the > same within an AS. They could be configured such that route selection > differed and could create persistent route loops. The way I understand it, RFC 4271 is supposed to reflect the way BGP is actually deployed (well, at least to a larger degree than RFC 1771 does) and all BGP implementations that I've worked with (6 in the last few years, some more exotic stuff longer ago) allow the user to tweak the way in which routes are selected such that different routers in the same AS make different choices. (They also have minor differences in the actual algorithm.) This is normal and doesn't lead to loops except for very short transient ones during convergence, even if you configure router A to prefer the path over router B and router B to prefer the path over router A. > The route selection is exactly the same. The method of setting > incoming LOCAL_PREF can differ. LOCAL_PREF is the first thing > considered. Try reading section 9.1 in its entirety and carefully. I'm happy with my understanding of the text. Please quote the specific sentence that supports your claims. > LOCAL_PREF is used only in IBGP. One router sets LOCAL_PREF on any > given route. All routers consider LOCAL_PREF first in route > selection. Route selection is the same throughout the AS as described > in "9.1.2. Phase 2: Route Selection". What is "used" supposed to mean here? Local preference is only _communicated_ through iBGP, but routers also consider the local preference in decisions about routes learned over eBGP. "All routers" apparently doesn't include Cisco routers: 1. Prefer the path with the highest WEIGHT. http://www.cisco.com/warp/public/459/25.shtml I have no idea what "route selection is the same throught the AS" is supposed to mean. Does it mean that throughout the AS, the highest local preference is preferred? That seems rather obvious. Or does it mean that throughout the AS, all routers must set the local preference in the same way? That's not how things work in practice, it's impossible to enforce and I'll be happy to argue why it's the wrong thing to want to happen in the first place but who cares. >>> This is stating that if within an AS >>> the route selection defined in RFC4271 is not used, it has to be the >>> same throughout the AS. >> I don't think so. Where does it say this? > If you change route selection, meaning what is described in "Phase 2: > Route Selection", you have to do so with extreme care. Now if you > reread what I wrote it might make a bit more sense to you. What this says is: a) the highest degree of preference of any route to the same set of destinations, or b) is the only route to that destination, or c) is selected as a result of the Phase 2 tie breaking rules specified in Section 9.1.2.2. What exactly would you want to change here? It makes much more sense to fold any new rules into a), which is left upto policy in the first place. > If the route selection is modified based on level of trust, an > entire AS MUST implement the same route selection to avoid loops. BGP doesn't support persistent loops because of the requirement that you only announce the route you use yourself to others. Any mentioning of the need to avoid loops therefore serves no purpose and only confuses matters. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 08:19:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4cvP-000637-MJ; Sun, 23 Jul 2006 08:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4cvO-000632-Jt for rpsec@ietf.org; Sun, 23 Jul 2006 08:19:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4cvN-0001wF-BH for rpsec@ietf.org; Sun, 23 Jul 2006 08:19:10 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2006 08:19:09 -0400 X-IronPort-AV: i="4.07,172,1151899200"; d="scan'208"; a="93600127:sNHT24041192" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6NCJ998027480; Sun, 23 Jul 2006 08:19:09 -0400 Received: from [10.82.224.44] (rtp-vpn1-44.cisco.com [10.82.224.44]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6NCJ7dU009956; Sun, 23 Jul 2006 08:19:07 -0400 (EDT) Message-ID: <44C36938.1050001@cisco.com> Date: Sun, 23 Jul 2006 08:19:04 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: curtis@occnc.com Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt References: <200607212226.k6LMQZbQ028036@workhorse.brookfield.occnc.com> In-Reply-To: <200607212226.k6LMQZbQ028036@workhorse.brookfield.occnc.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1995; t=1153657149; x=1154521149; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20draft-ietf-rpsec-bgpsecrec-06.txt |To:curtis@occnc.com; X=v=3Dcisco.com=3B=20h=3D0tejfNEVO5iRnK0m+zxIeMtCR+8=3D; b=b9vi9PIVOKQmaN99HCYzKmuf/SGo2r5MX+44DXRQunB5nctBvskefQrU3AsaMjBzrxpL1nHl qagGyX9Mq7U+sKw6+hyyJFe+8fTlvNmT/McfG/JF9XAO/l5LKQOI/Rrv; Authentication-Results: rtp-dkim-2.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: rpsec@ietf.org, Tony Tauber , Iljitsch van Beijnum , 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > origin authentication - crypto authentication of the route > origination. I'm not certain why it has to be "encrypted," or "crypto?" I think most all of the mechanisms currently proposed do use encryption based signatures (or some such) to do this, but I don't see it as a requirement, or part of the definition. Certainly there might be some other way to do this that no-one has thought of yet.... > peer authentication - crypto authentication which provides > additional assurance that the peer is who the peer claims to be. > > transitive trust model - the assumption that if each peering is > autheticated and the origination was authenticated that the path > is valid. You can't put "and the path is valid" in here. Transitive trust doesn't show anything about the path, at least as far as I can see. > per hop authentication - any mechanism where every transfer from > peer to peer adds additional information or makes modifications to > information that can be used to verify authenticity of the path. There are other ways to "validate a path" than "per hop authentication," - --at least two, and possibly, more, have been proposed. So, I don't think it's valid to put that in this definition. Of course, I don't know where you had planned on actually putting these definitions.... :-) Don't assume "one solution" or "one type of solution" in this discussion--we are talking about requirements, not solutions, here. While making some statement "x" about the AS Path may be desirable, saying: "Doing X provides us with this security, so we should require X," isn't. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEw2k4ER27sUhU9OQRArFlAJ9o/fbxyuNPKK/pI2rOrWiod9I9YgCg3ENe rOJwbEJrmqPIPL7cNW4i7iU= =QUBs -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 08:28:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4d4o-0003he-4H; Sun, 23 Jul 2006 08:28:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4d4m-0003hY-KJ for rpsec@ietf.org; Sun, 23 Jul 2006 08:28:52 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4d4l-0003Iz-Ce for rpsec@ietf.org; Sun, 23 Jul 2006 08:28:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2006 08:28:51 -0400 X-IronPort-AV: i="4.07,172,1151899200"; d="scan'208"; a="93600451:sNHT24077184" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6NCSpu7028211 for ; Sun, 23 Jul 2006 08:28:51 -0400 Received: from [10.82.224.44] (rtp-vpn1-44.cisco.com [10.82.224.44]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6NCSodU011180 for ; Sun, 23 Jul 2006 08:28:50 -0400 (EDT) Message-ID: <44C36B7F.5010908@cisco.com> Date: Sun, 23 Jul 2006 08:28:47 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: rpsec@ietf.org Subject: Re: [RPSEC] Discontiguous Deployment... References: <002901c6ac6a$f9f28810$837d14ac@tropos.com> In-Reply-To: <002901c6ac6a$f9f28810$837d14ac@tropos.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=883; t=1153657731; x=1154521731; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20Discontiguous=20Deployment... |To:rpsec@ietf.org; X=v=3Dcisco.com=3B=20h=3DvSS2UEGsTI2CkDYUkI4Y/LDTXf0=3D; b=LqXm7HevrdV3snxOS5yhp1l7Yi/bMsQjJ0uCnZCA5F3Ejr65fuJR36cub2f5WoxSMyv4FHVQ HaMwq8u0bQf2Yh5lw5Cqh2QmPHeNWzKOi62zDBk0RZQ1YGWBSwS+VMol; Authentication-Results: rtp-dkim-1.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Should there be a requirement that any proposed security >> system must be >> useful even if deployed in a noncontiguous way? Or should >> this not be a >> requirement? After waiting a couple of days for this to settle down, we have: o In favor: Tony Li, Bora, Blaine, Cat o Against: Sandy o Useful, but no definite way to characterize: Steve Kent o Useful, but could be too difficult/bias the mechanism choice: Iljitsch , Paul J Perhaps we should agree to make it a "SHOULD?," and figure how to word such a beast? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEw2t/ER27sUhU9OQRApuKAJ9SUX7DqjEDEfbfMKJXEcoDK1kaYACgnYdD Wx5tAW/CLezh7QPsrk1GGnw= =TF8e -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 09:00:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4dZE-0003ff-Fm; Sun, 23 Jul 2006 09:00:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4dZD-0003fa-Mp for rpsec@ietf.org; Sun, 23 Jul 2006 09:00:19 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4dZC-0000Ye-DU for rpsec@ietf.org; Sun, 23 Jul 2006 09:00:19 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6NCxuSh036890 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 23 Jul 2006 14:59:57 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <44C36B7F.5010908@cisco.com> References: <002901c6ac6a$f9f28810$837d14ac@tropos.com> <44C36B7F.5010908@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98A9817C-38EE-451F-94C2-3E7D9FC01816@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] Discontiguous Deployment... Date: Sun, 23 Jul 2006 15:00:05 +0200 To: Russ White X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: rpsec-bounces@ietf.org On 23-jul-2006, at 14:28, Russ White wrote: >>> Should there be a requirement that any proposed security >>> system must be >>> useful even if deployed in a noncontiguous way? Or should >>> this not be a >>> requirement? > Perhaps we should agree to make it a "SHOULD?," and figure how to word > such a beast? Why not explain that this is a desirable feature, but not make it a requirement? That way, we can see what kind of solutions people come up with, and then determine which are better, the ones with this feature or the ones without. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 13:35:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4hr5-0004eX-Rm; Sun, 23 Jul 2006 13:35:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4hr3-0004eS-Uw for rpsec@ietf.org; Sun, 23 Jul 2006 13:35:01 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4hr2-0003eY-3D for rpsec@ietf.org; Sun, 23 Jul 2006 13:35:01 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6NHfKTR010709; Sun, 23 Jul 2006 13:41:20 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607231741.k6NHfKTR010709@workhorse.brookfield.occnc.com> To: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Sun, 23 Jul 2006 12:51:07 +0200." <1229BEB0-3E78-4FA2-A9EC-98D9464FE772@muada.com> Date: Sun, 23 Jul 2006 13:41:20 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <1229BEB0-3E78-4FA2-A9EC-98D9464FE772@muada.com> Iljitsch van Beijnum writes: > > On 21-jul-2006, at 21:20, Curtis Villamizar wrote: > > > If provider A and C both had government customers and provider B > > didn't and had to carry 1 MB of extra attributes in their router with > > 1-4 GB or memory, I doubt they'd even notice. > > Guess what: not every router has a gigabyte or more memory. And some > routers get two, three, four or even more views of the global routing > table. We can't afford to be cavalier about this even though > obviously the internet won't crash and burn at the first sign of some > extra data in BGP path attributes. Most routers sold as core routers these days are upgradable to at least 1 GB of route processor memory. Plus you can change the route processor in most or all of them if you have an older route processor with 1/2 GB limit or less. Given the investment in core routers, a few RAM packages isn't much. It is more likely that the tier-1 providers will be asked to provide transport for those wanting very secure routing. The tier-1 providers tend to have big routers with adequate memory and 5 or more global views in not uncommon. > >> "Anyone with a keyboard and time on their hands can write an internet > >> draft." Sure. But what we're trying to do here is come up with > >> something that is useful for wide deployment throughout the internet. > > > We are coming up with a requirements document at this point. I'm > > trying to accomodate is that one set of security mechanisms will be > > appropriate for the Innternet at large. Another set of security > > mechanisms will be appropriate for applications requiring a higher > > degree of security. It might even come to a country by country or > > provider by provider mixed deployment. > > Unless I'm seriously overlooking something, today, operators > generally can't filter out unwanted unknown path attributes. I don't > see how we can assume that those would be contained. I guess that needs to be a requirement in this requirements document. Routers which understand the BGP attributes associated with a given security mechanism SHOULD be able to configure the security mechanism "off". Routers which have the security mechanism configured to "off" SHOULD be configurable such that they will drop any BGP attribute associated with the security mechanism or pass that attribute along. This makes it a choice available to each provider. Better? > >>>>> 1. The security information SHOULD be passed intact but > >>>>> uninterpreted across routers that did not support the same > >>>>> security mechanism. > > >>> Is that better? > > >> No, this requires stuff that may or may not be useful. > > > SHOULD does not require anything. MUST would require it. > > Semantics. SHOULD in a requirements document is a very strong statement. See above. If the router doesn't understand it, pass it on. If it does understand it there are three choices. 1. Perform any necessary signature and pass on the attribute(s). 2. Pass on the attributes unchanged or with indication that they were not signed depending on the recommendations of the protocol. 3. Drop one or more of the attributes associated with a given security mechanism. A small attribute may be added or substituted depending on the recommendations of the protocol. Again. Better? > > But the route selection in RFC4271 reflects reality where the route > > selection defined in RFC1771 was too loosely defined and was deviated > > from in virtually *all* routers on the market. They all interoperated > > becasue they supported options that could make the route selection the > > same within an AS. They could be configured such that route selection > > differed and could create persistent route loops. > > The way I understand it, RFC 4271 is supposed to reflect the way BGP > is actually deployed (well, at least to a larger degree than RFC 1771 > does) and all BGP implementations that I've worked with (6 in the > last few years, some more exotic stuff longer ago) allow the user to > tweak the way in which routes are selected such that different > routers in the same AS make different choices. (They also have minor > differences in the actual algorithm.) This is normal and doesn't lead > to loops except for very short transient ones during convergence, > even if you configure router A to prefer the path over router B and > router B to prefer the path over router A. Many routers allow you to deviate from the RFC4271 route selection and you do so at your own peril. If you configure routers for different route selections you almost certainly will get routing loops. A few routers have not been upgraded to make the default RFC4271 compliant. > > The route selection is exactly the same. The method of setting > > incoming LOCAL_PREF can differ. LOCAL_PREF is the first thing > > considered. Try reading section 9.1 in its entirety and carefully. > > I'm happy with my understanding of the text. Please quote the > specific sentence that supports your claims. 5.1.5. LOCAL_PREF LOCAL_PREF is a well-known attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers. A BGP speaker SHALL calculate the degree of preference for each external route based on the locally-configured policy, and include the degree of preference when advertising a route to its internal peers. The higher degree of preference MUST be preferred. A BGP speaker uses the degree of preference learned via LOCAL_PREF in its Decision Process (see Section 9.1.1). 9.1. Decision Process [...] Route selection then consists of the individual application of the degree of preference function to each feasible route, followed by the choice of the one with the highest degree of preference. [...] 9.1.1. Phase 1: Calculation of Degree of Preference The Phase 1 decision function is invoked whenever the local BGP speaker receives, from a peer, an UPDATE message that advertises a new route, a replacement route, or withdrawn routes. If the route is learned from an internal peer, either the value of the LOCAL_PREF attribute is taken as the degree of preference, or the local system computes the degree of preference of the route based on preconfigured policy information. Note that the latter may result in formation of persistent routing loops. If the route is learned from an external peer, then the local BGP speaker computes the degree of preference based on preconfigured policy information. If the return value indicates the route is ineligible, the route MAY NOT serve as an input to the next phase of route selection; otherwise, the return value MUST be used as the LOCAL_PREF value in any IBGP readvertisement. The exact nature of this policy information, and the computation involved, is a local matter. How to pick "degree of preference" is a local matter and done on an EBGP route. Then put that "degree of preference" into LOCAL_PREF. On an IBGP route take LOCAL_PREF and that is your "degree of preference". Don't change it. Note the text from the RFC. [...] or the local system computes the degree of preference of the route based on preconfigured policy information. Note that the latter may result in formation of persistent routing loops. LOCAL_PREF which is the same thing as "degree of preference" is the first thing considered. Note the text below. Route selection then consists of the individual application of the degree of preference function to each feasible route, followed by the choice of the one with the highest degree of preference. [...] 9.1.2. Phase 2: Route Selection [...] For each set of destinations for which a feasible route exists in the Adj-RIBs-In, the local BGP speaker identifies the route that has: a) the highest degree of preference of any route to the same set of destinations, or b) is the only route to that destination, or c) is selected as a result of the Phase 2 tie breaking rules specified in Section 9.1.2.2. The tie breaking rules in 9.1.2.2 only apply if LOCAL_PREF which is the same thing as "degree of preference" is the same. > > LOCAL_PREF is used only in IBGP. One router sets LOCAL_PREF on any > > given route. All routers consider LOCAL_PREF first in route > > selection. Route selection is the same throughout the AS as described > > in "9.1.2. Phase 2: Route Selection". > > What is "used" supposed to mean here? Local preference is only > _communicated_ through iBGP, but routers also consider the local > preference in decisions about routes learned over eBGP. The LOCAL_PREF attribute is only sent when advertising BGP routes. That is what "used" meant. Sorry to be unclear. Otherwise LOCAL_PREF and "degree of preference" are used somewhat interchangeably. If you learn an EBGP route the "degree of preference" is what you would be setting LOCAL_PREF to be if you advertised it into IBGP. > "All routers" apparently doesn't include Cisco routers: > > 1. Prefer the path with the highest WEIGHT. > > http://www.cisco.com/warp/public/459/25.shtml Also note very next sentence. Note: WEIGHT is a Cisco-specific parameter. It is local to the router on which it is configured. Weights are normally assigned to an entire protocol. You can really hurt yourself fooling around with weights. The next thing on the Cisco web page is LOCAL_PREF. > I have no idea what "route selection is the same throught the AS" is > supposed to mean. Does it mean that throughout the AS, the highest > local preference is preferred? That seems rather obvious. Or does it > mean that throughout the AS, all routers must set the local > preference in the same way? That's not how things work in practice, > it's impossible to enforce and I'll be happy to argue why it's the > wrong thing to want to happen in the first place but who cares. If you set Cisco weights randomly you will get route loops. You can set LOCAL_PREF to any value and not get route loops due to the way LOCAL_PREF is handled by routers. If you could configure one router to consider AS Path length before LOCAL_PREF and you used LOCAL_PREF (didn't set it the same everywhere), then you'd almost certainly get route loops. Changing the order in which LOCAL_PREF, AS Path length, MED, IGP cost, are considered would be a change in the route selection algorithm. Clear now? > >>> This is stating that if within an AS > >>> the route selection defined in RFC4271 is not used, it has to be the > >>> same throughout the AS. > > >> I don't think so. Where does it say this? > > > If you change route selection, meaning what is described in "Phase 2: > > Route Selection", you have to do so with extreme care. Now if you > > reread what I wrote it might make a bit more sense to you. > > What this says is: > > a) the highest degree of preference of any route to the same set > of destinations, or > > b) is the only route to that destination, or > > c) is selected as a result of the Phase 2 tie breaking rules > specified in Section 9.1.2.2. > > What exactly would you want to change here? It makes much more sense > to fold any new rules into a), which is left upto policy in the first > place. The route selection consists of the tie breaking rules in the rest of the section. This just says if there is more than one route with the same "degree of preference" then continue with the tie breaking rules in the remainder of Section 9.1.2.2, otherwise use the route with the "highest degree of preference". > > If the route selection is modified based on level of trust, an > > entire AS MUST implement the same route selection to avoid loops. > > BGP doesn't support persistent loops because of the requirement that > you only announce the route you use yourself to others. Any > mentioning of the need to avoid loops therefore serves no purpose and > only confuses matters. You obviously were not around or did not pay attention when there was controversy over whether higher MED was preferred or lower MED or a number of other cases where routers only advertised the routes they were using but difference in the route selection implemented by different vendors could cause route loops because the routers in the middle of the AS decided which was best based on a different set of rules. "Only advertise the routes you use" is necessary but not sufficient to prevent persistent routing loops. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 13:43:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4hzJ-0001YM-Ev; Sun, 23 Jul 2006 13:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4hzH-0001YH-M6 for rpsec@ietf.org; Sun, 23 Jul 2006 13:43:31 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4hzG-0005Tb-EJ for rpsec@ietf.org; Sun, 23 Jul 2006 13:43:31 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2006 13:43:30 -0400 X-IronPort-AV: i="4.07,173,1151899200"; d="scan'208"; a="93610562:sNHT25670848" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6NHhUZS008944; Sun, 23 Jul 2006 13:43:30 -0400 Received: from [10.82.224.44] (rtp-vpn1-44.cisco.com [10.82.224.44]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6NHhT7t008264; Sun, 23 Jul 2006 13:43:29 -0400 (EDT) Message-ID: <44C3B53E.7010303@cisco.com> Date: Sun, 23 Jul 2006 13:43:26 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: curtis@occnc.com Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt References: <200607231741.k6NHfKTR010709@workhorse.brookfield.occnc.com> In-Reply-To: <200607231741.k6NHfKTR010709@workhorse.brookfield.occnc.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1602; t=1153676610; x=1154540610; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20draft-ietf-rpsec-bgpsecrec-06.txt |To:curtis@occnc.com; X=v=3Dcisco.com=3B=20h=3D0tejfNEVO5iRnK0m+zxIeMtCR+8=3D; b=kE4dBOvEKwN2PmW+x0JCg/SH7/25rnOqEyKOvXEbbBrajt/pHlGHUFXhgsRJMhfRJsAPW9Py +0us6+QecjmgOkFoLGPmjLiaPxZ9hdjr/C/56a8HjyAKDBF5T0bsdjyX; Authentication-Results: rtp-dkim-2.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rpsec@ietf.org, Iljitsch van Beijnum 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Most routers sold as core routers these days are upgradable to at > least 1 GB of route processor memory. Plus you can change the route > processor in most or all of them if you have an older route processor > with 1/2 GB limit or less. Given the investment in core routers, a > few RAM packages isn't much. > > It is more likely that the tier-1 providers will be asked to provide > transport for those wanting very secure routing. The tier-1 providers > tend to have big routers with adequate memory and 5 or more global > views in not uncommon. IMHO, I wouldn't count on having X amount of memory, etc, in a requirements document. These sorts of things will vary at various times and in various networks. Things change. Don't count on them being the way they are in a specific network at this moment in time. I would consider the entire discussion on "holding encryption in router memory," or "additional attributes," completely out of scope from a requirements perspective. Let's come up with real requirements from a protocol/security standpoint, and then let the router vendors and operators decide how much they're willing to accept in memory upgrades, etc, when considering the various tradeoffs of the proposed systems. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEw7U9ER27sUhU9OQRAi6uAKCkTl6tdtutBNAZfkx8QKLcNydLbQCcDcPL QO+86ePotzCWHWCdXw6/tWs= =qVB0 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 14:07:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4iLt-0004JU-3V; Sun, 23 Jul 2006 14:06:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4iLs-0004JP-23 for rpsec@ietf.org; Sun, 23 Jul 2006 14:06:52 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4iLp-0002E3-L8 for rpsec@ietf.org; Sun, 23 Jul 2006 14:06:52 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6NICw2w010810; Sun, 23 Jul 2006 14:12:58 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607231812.k6NICw2w010810@workhorse.brookfield.occnc.com> To: Russ White Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Sun, 23 Jul 2006 08:19:04 EDT." <44C36938.1050001@cisco.com> Date: Sun, 23 Jul 2006 14:12:58 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: rpsec@ietf.org, Tony Tauber , Iljitsch van Beijnum , Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <44C36938.1050001@cisco.com> Russ White writes: > > > > origin authentication - crypto authentication of the route > > origination. > > I'm not certain why it has to be "encrypted," or "crypto?" I think most > all of the mechanisms currently proposed do use encryption based > signatures (or some such) to do this, but I don't see it as a > requirement, or part of the definition. Certainly there might be some > other way to do this that no-one has thought of yet.... This could say crypto or other authentication. A routing registry is out of band authentication (which itself may be protected by crypto to be of much use). > > peer authentication - crypto authentication which provides > > additional assurance that the peer is who the peer claims to be. > > > > transitive trust model - the assumption that if each peering is > > autheticated and the origination was authenticated that the path > > is valid. > > You can't put "and the path is valid" in here. Transitive trust doesn't > show anything about the path, at least as far as I can see. It does say "the assumption that ...". Transitive trust just means that if you heard it from a reliable source and they heard it from a reliable source, its reliable. It is not proven to be reliable, but assumed to be reliable enough to use it. Would you like to suggest better wording? > > per hop authentication - any mechanism where every transfer from > > peer to peer adds additional information or makes modifications to > > information that can be used to verify authenticity of the path. > > There are other ways to "validate a path" than "per hop authentication," > - --at least two, and possibly, more, have been proposed. So, I don't > think it's valid to put that in this definition. I consider anything in which each hop (or AS hop) further encrypts with their private key to be a form of adding or modifying information as a means for others to verify authenticity. > Of course, I don't know where you had planned on actually putting these > definitions.... :-) Neither do I. I just gave them so that Steve Kent and I could carry on a meaningful discussion. > Don't assume "one solution" or "one type of solution" in this > discussion--we are talking about requirements, not solutions, here. > While making some statement "x" about the AS Path may be desirable, > saying: "Doing X provides us with this security, so we should require > X," isn't. > > :-) > > Russ One way to see if the requirements are at all reasonable or complete is to see how well they capture the benefits (or perceived benefits) of various solutions proposed, under consideration, or in use. Since we know we have conflicting requirements it *should* seem obvious that we are going to have more than one solution and not all solutions can meet all requirements. If any two requirements are conflicting, then no one solution could meet both. Some providers or institutions are going to prefer low memory and CPU impact solutions. Others (Dod for example) are going to prefer stronger security. The goal is not to end up with the set of requirements that specifies our favorite solution. The goal is to capture all requirements so we can later figure out how to provide the best set of options in a set of security mechanisms, some of which might be deployed widely, others that might be deployed less widely but are still useful. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 14:16:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4iVA-0001IX-Mp; Sun, 23 Jul 2006 14:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4iVA-0001IS-6N for rpsec@ietf.org; Sun, 23 Jul 2006 14:16:28 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4iV8-0004Ej-T9 for rpsec@ietf.org; Sun, 23 Jul 2006 14:16:28 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k6NIMeus010866; Sun, 23 Jul 2006 14:22:40 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200607231822.k6NIMeus010866@workhorse.brookfield.occnc.com> To: Russ White Subject: Re: [RPSEC] Discontiguous Deployment... In-reply-to: Your message of "Sun, 23 Jul 2006 08:28:47 EDT." <44C36B7F.5010908@cisco.com> Date: Sun, 23 Jul 2006 14:22:40 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message <44C36B7F.5010908@cisco.com> Russ White writes: > > > >> Should there be a requirement that any proposed security > >> system must be > >> useful even if deployed in a noncontiguous way? Or should > >> this not be a > >> requirement? > > After waiting a couple of days for this to settle down, we have: > > o In favor: Tony Li, Bora, Blaine, Cat > o Against: Sandy > o Useful, but no definite way to characterize: Steve Kent > o Useful, but could be too difficult/bias the mechanism choice: > Iljitsch , Paul J > > Perhaps we should agree to make it a "SHOULD?," and figure how to word > such a beast? > > :-) > > Russ We have to deal with the fact that there are going to be conflicting requirements. A potential knee jerk reaction to a requirement that doesn't allow for one's favorite solution is to say that the requirement should not exist. Whenever there are conflicting requirements there is a tradeoff. Trying to force a decision one way when one large community is unwilling to drop a given requirement that favors another solution is usually futile. There are certain proposed solutions that will not any time soon get widely deployed. Stating that solutions SHOULD be useful in a noncontiguous deplyment just makes that sort of solution more useful. If a solution *can't* be made useful in a noncontiguous deplyment then it is just less useful, but not useless. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 15:59:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4k78-0008Sn-JE; Sun, 23 Jul 2006 15:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4k77-0008Si-24 for rpsec@ietf.org; Sun, 23 Jul 2006 15:59:45 -0400 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4k75-0007LD-OF for rpsec@ietf.org; Sun, 23 Jul 2006 15:59:45 -0400 Received: from pc6 (1Cust122.tnt6.lnd4.gbr.da.uu.net [62.188.135.122]) by blaster.systems.pipex.net (Postfix) with SMTP id 93EF3E000334; Sun, 23 Jul 2006 20:59:40 +0100 (BST) Message-ID: <000201c6ae89$8129f140$0601a8c0@pc6> From: "Tom Petch" To: "Russ White" , References: <44C02C17.1000708@cisco.com> Subject: Re: [RPSEC] Discontiguous Deployment... Date: Fri, 21 Jul 2006 21:16:40 +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.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 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: , Errors-To: rpsec-bounces@ietf.org Yes discontiguous deployment should provide improved security and should bea requirement. I am assuming that the 'unit' here it the AS, not an individual router. Tom Petch ----- Original Message ----- From: "Russ White" To: Sent: Friday, July 21, 2006 3:21 AM Subject: [RPSEC] Discontiguous Deployment... > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Okay, before we get too far into wording, I want to check on list and > see what everyone's opinion is.... > > Should there be a requirement that any proposed security system must be > useful even if deployed in a noncontiguous way? Or should this not be a > requirement? > > One we settle this, it should be easier to come to concensus on actual > wording, I hope (?).... > > :-) > > Russ > > - -- > riw@cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEwCwXER27sUhU9OQRAi7sAJ0QemwdRCmCc+/xOx8EtF8zuP4XyQCg96L5 > ouOX1IKuwrAXhuBJudmnRLc= > =e/0P > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 Jul 23 16:54:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4kyB-0001kJ-UD; Sun, 23 Jul 2006 16:54:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4kyA-0001kC-UI for rpsec@ietf.org; Sun, 23 Jul 2006 16:54:34 -0400 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4ky9-0007X5-86 for rpsec@ietf.org; Sun, 23 Jul 2006 16:54:34 -0400 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k6NKsMOt077061; Mon, 24 Jul 2006 06:54:27 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20060724065335.041eb3e8@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 24 Jul 2006 06:54:07 +1000 To: Russ White , rpsec@ietf.org From: Geoff Huston Subject: Re: [RPSEC] Discontiguous Deployment... In-Reply-To: <44C36B7F.5010908@cisco.com> References: <002901c6ac6a$f9f28810$837d14ac@tropos.com> <44C36B7F.5010908@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Errors-To: rpsec-bounces@ietf.org At 10:28 PM 23/07/2006, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >> Should there be a requirement that any proposed security > >> system must be > >> useful even if deployed in a noncontiguous way? Or should > >> this not be a > >> requirement? > >After waiting a couple of days for this to settle down, we have: > >o In favor: Tony Li, Bora, Blaine, Cat >o Against: Sandy >o Useful, but no definite way to characterize: Steve Kent >o Useful, but could be too difficult/bias the mechanism choice: > Iljitsch , Paul J > >Perhaps we should agree to make it a "SHOULD?," and figure how to word >such a beast? I am in favour of a SHOULD here Geoff _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 17:02:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4l5t-0006EI-OL; Sun, 23 Jul 2006 17:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4l5s-0006Db-6Z for rpsec@ietf.org; Sun, 23 Jul 2006 17:02:32 -0400 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4l5q-0001Cc-FW for rpsec@ietf.org; Sun, 23 Jul 2006 17:02:32 -0400 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k6NL2Ow0077438; Mon, 24 Jul 2006 07:02:25 +1000 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20060724065425.02c1d9e0@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 24 Jul 2006 06:55:22 +1000 To: Iljitsch van Beijnum , Russ White From: Geoff Huston Subject: Re: [RPSEC] Discontiguous Deployment... In-Reply-To: <98A9817C-38EE-451F-94C2-3E7D9FC01816@muada.com> References: <002901c6ac6a$f9f28810$837d14ac@tropos.com> <44C36B7F.5010908@cisco.com> <98A9817C-38EE-451F-94C2-3E7D9FC01816@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: rpsec-bounces@ietf.org > >Why not explain that this is a desirable feature, but not make it a >requirement? > >That way, we can see what kind of solutions people come up with, and >then determine which are better, the ones with this feature or the >ones without. Because this is a requirements WG, not a solutions WG Geoff _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 17:08:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4lBz-0001ED-Q8; Sun, 23 Jul 2006 17:08:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4lBy-0001E8-IH for rpsec@ietf.org; Sun, 23 Jul 2006 17:08:50 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4lBx-0002YP-94 for rpsec@ietf.org; Sun, 23 Jul 2006 17:08:50 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6NL8Smd043974 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 23 Jul 2006 23:08:28 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <000201c6ae89$8129f140$0601a8c0@pc6> References: <44C02C17.1000708@cisco.com> <000201c6ae89$8129f140$0601a8c0@pc6> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E1A477A-6B74-403E-BAF1-8DC243DF343A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] Discontiguous Deployment... Date: Sun, 23 Jul 2006 23:08:44 +0200 To: Tom Petch X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: rpsec-bounces@ietf.org On 21-jul-2006, at 21:16, Tom Petch wrote: > Yes discontiguous deployment should provide improved security and > should bea > requirement. Sigh. Don't you get that too many requirements makes for bad solutions?! We should reserve the word "requirement" only for those things that are so essential that without them, a solution isn't worth having. This doesn't qualify. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 19:28:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4nMU-0000VB-DW; Sun, 23 Jul 2006 19:27:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4nMT-0000V6-SM for rpsec@ietf.org; Sun, 23 Jul 2006 19:27:49 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4nMS-0003dN-G3 for rpsec@ietf.org; Sun, 23 Jul 2006 19:27:49 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6NNRRUZ046279 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 24 Jul 2006 01:27:28 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200607231741.k6NHfKTR010709@workhorse.brookfield.occnc.com> References: <200607231741.k6NHfKTR010709@workhorse.brookfield.occnc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Date: Mon, 24 Jul 2006 01:27:44 +0200 To: curtis@occnc.com X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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: , Errors-To: rpsec-bounces@ietf.org On 23-jul-2006, at 19:41, Curtis Villamizar wrote: > Most routers sold as core routers these days are upgradable to at > least 1 GB of route processor memory. Plus you can change the route > processor in most or all of them if you have an older route processor > with 1/2 GB limit or less. Given the investment in core routers, a > few RAM packages isn't much. This doesn't give you a license to inflate the state associated with the global routing table arbitrarily. >> Unless I'm seriously overlooking something, today, operators >> generally can't filter out unwanted unknown path attributes. I don't >> see how we can assume that those would be contained. > I guess that needs to be a requirement in this requirements document. > Routers which understand the BGP attributes associated with a given > security mechanism SHOULD be able to configure the security > mechanism "off". Routers which have the security mechanism > configured to "off" SHOULD be configurable such that they will drop > any BGP attribute associated with the security mechanism or pass > that attribute along. > This makes it a choice available to each provider. Better? You can't impose new requirements on existing protocols and implementations, so no, this doesn't help. >> "All routers" apparently doesn't include Cisco routers: >> 1. Prefer the path with the highest WEIGHT. > Also note very next sentence. > Note: WEIGHT is a Cisco-specific parameter. It is local to the > router on which it is configured. > Weights are normally assigned to an entire protocol. You can really > hurt yourself fooling around with weights. No, that's the (administrative) distance. Weight is used by Cisco to overrule the local preference to prefer locally sourced routes over all others. > You can set LOCAL_PREF to any value and not get route loops due to the > way LOCAL_PREF is handled by routers. > If you could configure one router to consider AS Path length before > LOCAL_PREF and you used LOCAL_PREF (didn't set it the same > everywhere), then you'd almost certainly get route loops. Changing > the order in which LOCAL_PREF, AS Path length, MED, IGP cost, are > considered would be a change in the route selection algorithm. > Clear now? No. :-) Actually, all of it is surprisingly un-clear. But I think I see what the point of all these dire warnings is now. Consider: A--B--C--D where A and D prefer external paths to a certain destination and B prefers the path over D and C over A. So C will send packets for this destination to B and B will send them to C. This problem is caused by the fact that iBGP has no loop detection but we knew that iBGP is broken for a long time. You can get around this by making sure that all the decision making rules between local preference and IGP path are the same on all routers, but that certainly wasn't true in practice in the past across different implementations (is a missing MED < 0, == 0, == MAXINT or > MAXINT?) or by observing some topology restrictions or by implementing a certain level of route reflection, and maybe in some other ways as well. Too bad the new RFC doesn't explain this stuff, although with RFC 4271 we now know that a missing MED is the lowest possible value, although2 in my book it says that the IETF mandates the opposite choice, too bad2 I didn't include a source for this little tidbit of information. (Also see RFC 4451.) > You obviously were not around or did not pay attention when there was > controversy over whether higher MED was preferred or lower MED or a > number of other cases I've never been on the IDR wg list because the day only has 24 hours and what happens there tends to be too detail-oriented for me to want to spend time on. Oh yes, the point: BGP and especially its operation is pretty complex as it is. We only need one requirement: don't break BGP! Everything else is a nice-to- have. Yes, this includes security! I'll take a not very secure network that works (the one we have now) over a secure one that doesn't any day of the week. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 23 22:06:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4ppq-00082U-9g; Sun, 23 Jul 2006 22:06:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4ppo-00082O-VE for rpsec@ietf.org; Sun, 23 Jul 2006 22:06:16 -0400 Received: from [69.37.59.174] (helo=laptoy770.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4ppo-0006U6-Fa for rpsec@ietf.org; Sun, 23 Jul 2006 22:06:16 -0400 Received: from laptoy770.brookfield.occnc.com (localhost [127.0.0.1]) by laptoy770.brookfield.occnc.com (8.13.1/8.13.1) with ESMTP id k6O29ITp004128; Sun, 23 Jul 2006 22:09:18 -0400 (EDT) (envelope-from curtis@laptoy770.brookfield.occnc.com) Message-Id: <200607240209.k6O29ITp004128@laptoy770.brookfield.occnc.com> To: Iljitsch van Beijnum Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt In-reply-to: Your message of "Mon, 24 Jul 2006 01:27:44 +0200." Date: Sun, 23 Jul 2006 22:09:18 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org In message Iljitsch van Beijnum writes: > > On 23-jul-2006, at 19:41, Curtis Villamizar wrote: > > > Most routers sold as core routers these days are upgradable to at > > least 1 GB of route processor memory. Plus you can change the route > > processor in most or all of them if you have an older route processor > > with 1/2 GB limit or less. Given the investment in core routers, a > > few RAM packages isn't much. > > This doesn't give you a license to inflate the state associated with > the global routing table arbitrarily. Quick to jump on me. Yes I agree with you here. Note that the very next paragraph gives a way to avoid carrying information. > >> Unless I'm seriously overlooking something, today, operators > >> generally can't filter out unwanted unknown path attributes. I don't > >> see how we can assume that those would be contained. > > > I guess that needs to be a requirement in this requirements document. > > > Routers which understand the BGP attributes associated with a given > > security mechanism SHOULD be able to configure the security > > mechanism "off". Routers which have the security mechanism > > configured to "off" SHOULD be configurable such that they will drop > > any BGP attribute associated with the security mechanism or pass > > that attribute along. > > > This makes it a choice available to each provider. Better? > > You can't impose new requirements on existing protocols and > implementations, so no, this doesn't help. This is imposing a new requirement on a new BGP attribute defined for a BGP security mechanism. It is not a new requirement for an old protocol. I think we already mentioned the possibility of tossing the attribute on the sender side. This just adds the ability to toss the attribute on the receiver side. There is no alternative. It doesn't seem like an option to require that "BGP security mechanisms will define no new BGP attributes". > >> "All routers" apparently doesn't include Cisco routers: > > >> 1. Prefer the path with the highest WEIGHT. > > > Also note very next sentence. > > > Note: WEIGHT is a Cisco-specific parameter. It is local to the > > router on which it is configured. > > > Weights are normally assigned to an entire protocol. You can really > > hurt yourself fooling around with weights. > > No, that's the (administrative) distance. Weight is used by Cisco to > overrule the local preference to prefer locally sourced routes over > all others. Or do anything else since it is available across protocols. > > You can set LOCAL_PREF to any value and not get route loops due to the > > way LOCAL_PREF is handled by routers. > > > If you could configure one router to consider AS Path length before > > LOCAL_PREF and you used LOCAL_PREF (didn't set it the same > > everywhere), then you'd almost certainly get route loops. Changing > > the order in which LOCAL_PREF, AS Path length, MED, IGP cost, are > > considered would be a change in the route selection algorithm. > > > Clear now? > > No. :-) I thought it would be. But OK. > Actually, all of it is surprisingly un-clear. But I think I see what > the point of all these dire warnings is now. Consider: > > A--B--C--D > > where A and D prefer external paths to a certain destination and B > prefers the path over D and C over A. So C will send packets for this > destination to B and B will send them to C. > > This problem is caused by the fact that iBGP has no loop detection > but we knew that iBGP is broken for a long time. You can get around > this by making sure that all the decision making rules between local > preference and IGP path are the same on all routers, but that > certainly wasn't true in practice in the past across different > implementations (is a missing MED < 0, == 0, == MAXINT or > MAXINT?) > or by observing some topology restrictions or by implementing a > certain level of route reflection, and maybe in some other ways as well. > > Too bad the new RFC doesn't explain this stuff, although with RFC > 4271 we now know that a missing MED is the lowest possible value, > although2 in my book it says that the IETF mandates the opposite > choice, too bad2 I didn't include a source for this little tidbit of > information. (Also see RFC 4451.) > > > You obviously were not around or did not pay attention when there was > > controversy over whether higher MED was preferred or lower MED or a > > number of other cases > > I've never been on the IDR wg list because the day only has 24 hours > and what happens there tends to be too detail-oriented for me to want > to spend time on. > > Oh yes, the point: > > BGP and especially its operation is pretty complex as it is. We only > need one requirement: don't break BGP! Everything else is a nice-to- > have. Yes, this includes security! I'll take a not very secure > network that works (the one we have now) over a secure one that > doesn't any day of the week. You are just going to have to accept that in BGP terminology setting LOCAL_PREF value is not part of the route selection algorithm and that the route selection algorithm can't be changed without changing it everywhere otherwise persistent route loops can be formed. Curtis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 24 08:15:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4zL1-0005Kl-LV; Mon, 24 Jul 2006 08:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4zL0-0005Kg-Nt for rpsec@ietf.org; Mon, 24 Jul 2006 08:15:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4zKz-0007BD-Ec for rpsec@ietf.org; Mon, 24 Jul 2006 08:15:06 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Jul 2006 08:15:05 -0400 X-IronPort-AV: i="4.07,175,1151899200"; d="scan'208"; a="93654170:sNHT48232676" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6OCF5Wg000367; Mon, 24 Jul 2006 08:15:05 -0400 Received: from [10.82.225.80] (rtp-vpn1-336.cisco.com [10.82.225.80]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6OCF47t008050; Mon, 24 Jul 2006 08:15:04 -0400 (EDT) Message-ID: <44C4B9C3.6090506@cisco.com> Date: Mon, 24 Jul 2006 08:14:59 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: curtis@occnc.com Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt References: <200607240209.k6O29ITp004128@laptoy770.brookfield.occnc.com> In-Reply-To: <200607240209.k6O29ITp004128@laptoy770.brookfield.occnc.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1587; t=1153743305; x=1154607305; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20draft-ietf-rpsec-bgpsecrec-06.txt |To:curtis@occnc.com; X=v=3Dcisco.com=3B=20h=3D0tejfNEVO5iRnK0m+zxIeMtCR+8=3D; b=ZWIV38OVWItlJ9FCjUs60fAkOpQJ1V6H1ANPbCaKceXkM19SJpuYHfNuYxAshH5vyvsgSYEI vjY1dPUbgbu8ju2znVjCH9caTcCLVWY60AMRfZv5wBcA46Jt/4ou+Kw6; Authentication-Results: rtp-dkim-1.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: rpsec@ietf.org, Iljitsch van Beijnum 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > There is no alternative. It doesn't seem like an option to require > that "BGP security mechanisms will define no new BGP attributes". But there are ways around defining new attributes, so assuming one must exist, or that it will be large, or cryptographic in nature, is also assuming a solution. Again, these are requirements, not solutions. How something is done has nothing to do with what is done, technically. Don't assume an attribute, don't assume not attribute. Don't assume anything, just consider what's important, and what's not, and work from there. >> No, that's the (administrative) distance. Weight is used by Cisco to >> overrule the local preference to prefer locally sourced routes over >> all others. > > Or do anything else since it is available across protocols. Weight is BGP specific. No other protocol has weight. It is before Local Preference in the decision process, and has nothing to do with administrative distance. Weight is local to the router, since it's not sent in any packet. The primary place where I see weight in use is to make certain uRPF works correctly for networks dual homed into to edges of a single peering AS, but there are other uses that are valid, as well. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFExLnDER27sUhU9OQRApQIAJsG+h7NwpGNsECBSKyHVNcmaBheZQCgm1Hg 23EJrs1yldbJGMaLtPTUqgE= =kNbv -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 24 11:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G52Sz-0007zM-8U; Mon, 24 Jul 2006 11:35:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G52Sx-0007zH-TM for rpsec@ietf.org; Mon, 24 Jul 2006 11:35:31 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G52Sv-00042R-Mk for rpsec@ietf.org; Mon, 24 Jul 2006 11:35:31 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 3D94C4E50A; Mon, 24 Jul 2006 11:35:27 -0400 (EDT) Date: Mon, 24 Jul 2006 11:35:27 -0400 From: Jeffrey Haas To: rpsec@ietf.org Subject: Re: [RPSEC] Discontiguous Deployment... Message-ID: <20060724153527.GB29195@scc.mi.org> References: <44C02C17.1000708@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C02C17.1000708@cisco.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: rpsec-bounces@ietf.org On Thu, Jul 20, 2006 at 09:21:27PM -0400, Russ White wrote: > Should there be a requirement that any proposed security system must be > useful even if deployed in a noncontiguous way? Or should this not be a > requirement? IMO, a mechanism that supports non-contiguous deployment SHOULD be a goal (in the RFC SHOULD sense). Also, IMO, a solution MUST discuss the implications of having or not having support for a non-contiguous security environment. The implementation will need this as part of its normative language for interoperating (or not) with a "standard" BGP implementation. -- Jeff _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 24 11:48:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G52ev-0006I5-LX; Mon, 24 Jul 2006 11:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G52eu-0006I0-UP for rpsec@ietf.org; Mon, 24 Jul 2006 11:47:52 -0400 Received: from manos.scc.mi.org ([204.11.140.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G52et-00083U-KQ for rpsec@ietf.org; Mon, 24 Jul 2006 11:47:52 -0400 Received: by manos.scc.mi.org (Postfix, from userid 1025) id 4BAA84E7CB; Mon, 24 Jul 2006 11:47:49 -0400 (EDT) Date: Mon, 24 Jul 2006 11:47:49 -0400 From: Jeffrey Haas To: sandy@tislabs.com Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Message-ID: <20060724154749.GC29195@scc.mi.org> References: <200607201640.k6KGeCFn015253@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607201640.k6KGeCFn015253@tislabs.com> User-Agent: Mutt/1.3.28i X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: , Errors-To: rpsec-bounces@ietf.org Not to pick on Sandy's message in particular, but it saves me from responding to many messages in this thread: On Thu, Jul 20, 2006 at 12:40:12PM -0400, sandy@tislabs.com wrote: > If this is to be a requirement, I'd like to inquire as to the exact > meaning here. > > By "new BGP messages", do we mean messages in the BGP definition > of message types? So new attributes would not be considered new messages? > > BGP has a mechanism for dealing with new attributes without requiring > negotiation of same - define the attribute as optional transitive and > it can be passed along without being recognized. Are we setting a higher > bar for security mechanisms, and if so, why? > > I'm also not sure what the "new ways to interpret or handle existing > BGP messages" means and why it is of concern. "Drop bogus updates" > could be a new way to interpret messages, but such interpretation should > not even by seen by a clueless recipient, so I don't see why it would > require negotiation. Yes, there could be handling of existing messages that > would result in changes in what the recipient would see and so might > affect the recipient, even if the recipient was going to ignore them > (bandwidth, etc.). But making this a requirement that covers *all* > changes in handling is too broad. > > The statement as made prohibits new security information from > being carried through a clueless area to a clueful AS on the other side. > Is that what is desired here? > > An AS might have reasons for believing that an AS that was not participating > in a security mechanism might still be expected to retain the security > properties the security mechanism was protecting. So it is not necessarily > true that the security information is of no use whatsoever on the other > side of a gap. A given implementation of a secure BGP routing system could do any number of these things. Which things it does will depend on exactly whether or not it is interfacing with the "public" BGP routing system and what level of backward compatibility with stock RFC 4271 style BGP we're doing. Our current requirements have us trending toward compatibility with existing BGP. This means that an implementation must discuss what it will do in order to inter-operate. There is a strong presumption that secure inter-domain routing will be built on BGP. While I think that's great since it'll leverage existing BGP code and operator experience, one could develop a mechanism that had BGP routing semantics that used completely different protocol transports. As long as the RFC 4271-facing portion of the secure implementation used existing BGP message formats and semantics, we're golden. We can speculate all day about what the internals of the routing system would look like, but that takes us away from requirements and moves us into implementation. ----- I'd like to spend a second talking about transport of the security information in an implementation. This has nothing to do with requirements. I believe everyone understands the concern of carrying excess per-path information in the global BGP. We've had this discussion as part of the BGP L3VPNs. That horse has been beaten enough. :-) It is certainly possible to carry security information in optional-transitive path information. The amount could vary: You can carry it all, or you could carry enough to let secure domains reconnect. As an example, within the secure domain, you could carry all of your information in the relevant non-transitive path attributes. At a border, you could append a optional-transitive attribute which served to identify the router (or some "security server") which could provide security information that may be dropped. My real point is that we should stress on these issues as an implementation issue, not a requirements issue. -- Jeff _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 24 14:27:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G559V-0006gE-KP; Mon, 24 Jul 2006 14:27:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G559U-0006g6-Si for rpsec@ietf.org; Mon, 24 Jul 2006 14:27:36 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G559S-0005gj-F5 for rpsec@ietf.org; Mon, 24 Jul 2006 14:27:36 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6OIQRK3021181 for ; Mon, 24 Jul 2006 14:26:27 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAX5aqiP; Mon, 24 Jul 06 14:25:43 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6OIOc7i011123; Mon, 24 Jul 2006 14:24:38 -0400 (EDT) Date: Mon, 24 Jul 2006 14:24:38 -0400 (EDT) Message-Id: <200607241824.k6OIOc7i011123@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: Re: [RPSEC] Discontiguous Deployment... X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org Russ White said: >>> Should there be a requirement that any proposed security >>> system must be >>> useful even if deployed in a noncontiguous way? Or should >>> this not be a >>> requirement? > >After waiting a couple of days for this to settle down, we have: > >o In favor: Tony Li, Bora, Blaine, Cat >o Against: Sandy I seem to have confused my message in too many words. I am DEFINITELY IN FAVOR of incremental, non-contiguous deployment. I am hoping to convince people that communicating security info through non-security-aware ASs should be allowed, i.e., no requirement against it. I am AGAINST stating a requirement for "useful"-ness of a solution, because I do not believe that we have any way to characterize "useful". Stating a requirement for something we can not measure is a bad idea. Furthermore, I read Tony's, Bora's, Blaine's and Cat's comments as supporting a requirement for incremental, non-continguous deployment, NOT as supporting a requirement for "useful"-ness in non-continguous deployment. (Perhaps they also saw no way to describe "useful" for a security solution.) Bora's one message in particular was short and sweet. >>From the beginning of the draft, incremental, non-contiguous >deployment was a requirement. > >And IMHO, it should remain so. > >Bora No mention of usefulness there. If Tony, Blaine, Bora and Cat intended to indicate support for requiring solutions be "useful" in non-contiguous deployment, they can/should say so now. I had noticed that some responses were not answering the question as stated. I guess I should have spoken up before. >Perhaps we should agree to make it a "SHOULD?," and figure how to word >such a beast? If the wording still says "useful", making it a SHOULD doesn't help. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 24 14:55:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G55ag-0001jF-W6; Mon, 24 Jul 2006 14:55:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G55af-0001j5-Sp for rpsec@ietf.org; Mon, 24 Jul 2006 14:55:41 -0400 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G55ae-0002y7-Gs for rpsec@ietf.org; Mon, 24 Jul 2006 14:55:41 -0400 Received: (qmail 3532 invoked from network); 24 Jul 2006 18:56:37 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 24 Jul 2006 18:56:36 -0000 Received: from LIPC ([192.168.1.119]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 11:58:41 -0700 From: "Tony Li" To: , Subject: RE: [RPSEC] Discontiguous Deployment... Date: Mon, 24 Jul 2006 11:55:29 -0700 Message-ID: <001501c6af52$bb500340$437d14ac@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200607241824.k6OIOc7i011123@tislabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcavTtrPMSSmQyiFQAqdkDFKlZQSqwAA23tg X-OriginalArrivalTime: 24 Jul 2006 18:58:41.0819 (UTC) FILETIME=[2E287EB0:01C6AF53] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org > Furthermore, I read Tony's, Bora's, Blaine's and Cat's comments as > supporting a requirement for incremental, non-continguous > deployment, NOT as supporting a requirement for "useful"-ness > in non-continguous deployment. (Perhaps they also saw no way > to describe "useful" for a security solution.) I'm very happy to have a requirement that a non-contiguous deployment be "useful" while simultaneously recognizing that "useful" is a matter of judgement and perspective. Any such requirement should definitely be a case of restating the obvious, since any 'solution' failing to meet the requirement would, by definition, be useless. ;-) Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 24 15:35:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56DE-0003y6-Sn; Mon, 24 Jul 2006 15:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56DD-0003y1-F8 for rpsec@ietf.org; Mon, 24 Jul 2006 15:35:31 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G56DC-0001cI-6g for rpsec@ietf.org; Mon, 24 Jul 2006 15:35:31 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6OJYRSk029954 for ; Mon, 24 Jul 2006 15:34:27 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAn7aOF6; Mon, 24 Jul 06 15:34:24 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6OJXKYU013997; Mon, 24 Jul 2006 15:33:20 -0400 (EDT) Date: Mon, 24 Jul 2006 15:33:20 -0400 (EDT) Message-Id: <200607241933.k6OJXKYU013997@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: RE: [RPSEC] Discontiguous Deployment... X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org >Any such requirement should definitely be a case of restating the >obvious, since any 'solution' failing to meet the requirement would, by >definition, be useless. ;-) So is it useful or useless to state a requirement that a solution be useful? :-) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 24 16:12:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56n5-0000Fb-J3; Mon, 24 Jul 2006 16:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56n4-0000DH-0y for rpsec@ietf.org; Mon, 24 Jul 2006 16:12:34 -0400 Received: from www.reptiles.org ([198.96.119.1] helo=mail.reptiles.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G56n2-0004Ml-Q4 for rpsec@ietf.org; Mon, 24 Jul 2006 16:12:33 -0400 Received: from mail.reptiles.org([198.96.119.1] port=2032) (1418 bytes) by mail.reptiles.org([198.96.119.1] port=25) via TCP with esmtp (sender: ) id for ; (dest:remote)(R=bind_hosts)(T=inet_zone_bind_smtp) Mon, 24 Jul 2006 16:12:30 -0400 (EDT) (Smail-3.2.0.118 2004-May-31 #3 built 2004-Oct-14) Date: Mon, 24 Jul 2006 16:12:30 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@skink.reptiles.org To: sandy@tislabs.com Subject: RE: [RPSEC] Discontiguous Deployment... In-Reply-To: <200607241933.k6OJXKYU013997@tislabs.com> Message-ID: <20060724161155.Y38754@skink.reptiles.org> References: <200607241933.k6OJXKYU013997@tislabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cat Okita List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org On Mon, 24 Jul 2006 sandy@tislabs.com wrote: >> Any such requirement should definitely be a case of restating the >> obvious, since any 'solution' failing to meet the requirement would, by >> definition, be useless. ;-) > > So is it useful or useless to state a requirement that a solution be useful? > :-) I think it's useful to suggest specific ways in which a solution should be useful, and otherwise useless ;> cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 24 17:12:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G57j9-0006C1-O2; Mon, 24 Jul 2006 17:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G57j8-0006AP-FZ for rpsec@ietf.org; Mon, 24 Jul 2006 17:12:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G56kw-0003ZH-HJ for rpsec@ietf.org; Mon, 24 Jul 2006 16:10:22 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G56h3-0007ZV-48 for rpsec@ietf.org; Mon, 24 Jul 2006 16:06:24 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6OK5w3j066004 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 24 Jul 2006 22:05:58 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200607241933.k6OJXKYU013997@tislabs.com> References: <200607241933.k6OJXKYU013997@tislabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <78EEC285-D931-4F0C-AB06-69AB4F2899C7@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] Discontiguous Deployment... Date: Mon, 24 Jul 2006 22:06:16 +0200 To: sandy@tislabs.com X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: rpsec-bounces@ietf.org On 24-jul-2006, at 21:33, sandy@tislabs.com wrote: >> Any such requirement should definitely be a case of restating the >> obvious, since any 'solution' failing to meet the requirement >> would, by >> definition, be useless. ;-) > So is it useful or useless to state a requirement that a solution > be useful? > :-) Based on the evidence you can argue in either direction: too many solutions aren't useful, so either the requirement of usefulness would be useful, or maybe the requirement was already there even though the solution turned out useless; in that case the requirement of usefulness is useless. :-( Seriously, though: it doesn't make much sense to require something that we don't know to be useful. Just adding more and more requirements in the hope that a solution will accommodate them all and be perfect is a road that leads nowhere, as the IRTF routing rg and especially the multi6 wg can attest to. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 25 02:35:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5GVL-0000Yt-F5; Tue, 25 Jul 2006 02:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5GVJ-0000Xv-TD for rpsec@ietf.org; Tue, 25 Jul 2006 02:34:53 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5GVG-0007ss-LB for rpsec@ietf.org; Tue, 25 Jul 2006 02:34:53 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.59.1.127]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G5GVD-0004Fm-4t; Tue, 25 Jul 2006 02:34:47 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200607212236.k6LMaKvS028086@workhorse.brookfield.occnc.com> References: <200607212236.k6LMaKvS028086@workhorse.brookfield.occnc.com> Date: Mon, 24 Jul 2006 14:13:35 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt -- other comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: rpsec-bounces@ietf.org >... > >IP traffic has been the term used throughout the Internet's history so >why not stick with that. Subscriber makes no sense in all but recent >contexts. Subscriber traffic or end user traffic would not include >SNMP for example. Does a BPG security mechanism protect SNMP traffic? I agree that the term "subscriber" is relatively recent, but the term "IP traffic" is not very useful, since network management traffic is often carried over IP anyway. When I began working with Internet technology in the late 70s I think the phrase we used was "user traffic" to distinguish it from net management traffic. However, as you noted, we are focusing on only a subset of net management traffic anyway. > >Of course my next pair of sentences were: > > Please just drop this paragraph. It is obvious to the intended > audience that we are not securing IP services. > >Do you think it is not obvious to anyone that has any idea what BGP >does that any BGP security mechanism does not do anything for end-user >traffic carried by the router? If it is *that* obvious why say it. The reason for including the text was to emphasize that while BGP security enhancement will benefit user traffic, it is not a substitute for crypto security applied by the end users. If everyone agrees that this is redundant, let's drop it. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jul 25 02:35:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5GVL-0000Yy-LX; Tue, 25 Jul 2006 02:34:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5GVJ-0000Xx-U5 for rpsec@ietf.org; Tue, 25 Jul 2006 02:34:53 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5GVI-0007sy-Jh for rpsec@ietf.org; Tue, 25 Jul 2006 02:34:53 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.59.1.127]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G5GVH-0004Fm-5f; Tue, 25 Jul 2006 02:34:52 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200607212226.k6LMQZbQ028036@workhorse.brookfield.occnc.com> References: <200607212226.k6LMQZbQ028036@workhorse.brookfield.occnc.com> Date: Tue, 25 Jul 2006 02:34:37 -0400 To: curtis@occnc.com From: Stephen Kent Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Russ White , rpsec@ietf.org, Tony Tauber , Iljitsch van Beijnum 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: , Errors-To: rpsec-bounces@ietf.org Curtis, I'm afraid I have some problems with every one of your proposed definitions. >... > >Maybe we need some definitions. > > origin authentication - crypto authentication of the route > origination. I'm not sure this is what all of us mean :-). If some AS sends an advertisement for a prefix for which it is not authorized to originated a route, one would not consider that advertisement "authentic." So I think "origin authentication" ought to encompass the broader notion of an AS being authorized to originate the route in question. > peer authentication - crypto authentication which provides > additional assurance that the peer is who the peer claims to be. typically this term is interpreted to mean that such assurance is provided only to the neighbors with whom the peer is in direct contact. is that also part of what you had in mind here? > transitive trust model - the assumption that if each peering is > autheticated and the origination was authenticated that the path > is valid. I think there are a lot of different views of what this term means. This WG has had trouble defining what a "valid" path is, so the conclusion is already problematic. Also, there is no mention of the prefixes being advertised. Routes are paths plus prefixes and we're really interested in routes, so this definition does not go far enough in that direction. > > per hop authentication - any mechanism where every transfer from > peer to peer adds additional information or makes modifications to > information that can be used to verify authenticity of the path. This is the opposite of what the security community generally means when the term "hop" is used in conjunction with the term "authentication." we usually contrast hop-by-hop or point-to-point with end-to-end when talking about security services. >Every hop reencrypting a token with their private key is not a >transitive trust model. A transitive trust model is where if A trusts >information from B and B trust information from C then A trusts >information it got from B that B claims to have obtained from C, and >so on. Again, we're talking about signatures, not encryption here. But I do get the gist of the argument you're making. >Reencrypting a token with a private key at each hop does insure that >the path is valid. This insures that a rogue AS does not grab an >originated route or partial path and add its AS and pass that along to >disrupt routing. It does not protect against the most common problem. >The origination was just plain "in error". It does protect against >the accidental (or intentional) injection of something not even >vaguely related to that AS but so would a means of supporting origin >authentication and the use of transitive trust. I suggest we avoid very specific references to solution techniques in our discussion, especially since the mechanism you described here does not correspond to any solution with which I am familiar :-). Route origin authorization (not authentication) is a key element as a starting point, which is why the SIDR WG has begun there. Transitive trust, as a general notion, allows errors or attacks by an AS along a path to generate bogus routes. Remember that the AS operations personnel may or may not be complicit. a router may have been compromised, or a management workstation, etc. So, what I think you are suggesting is that origin authorization combined with transitive trust would address this most common set of errors/attacks. I agree, but that does not mean that such a scheme is sufficient going forward. >Whether you need to protect against such a rogue AS may depend on who >you are providing network service to - consumers, business, or DoD. Because of the highly-connected nature of the public Internet, I'm not sure who the "you" is above. If I am an ISP and my customers want protection against rogue ASes (using the term broadly as I suggested in the previous paragraph), then I cannot provide such protection solely based on what I do as the ISP that serves these customers directly. Only of other ASes participate in the implementation of security measures can I meet the needs of my subscribers. That's why suggesting requirements that ignore such attacks ultimately restricts what any AS can do for its subscribers. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jul 27 22:46:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6IM8-00018p-KU; Thu, 27 Jul 2006 22:45:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6IM7-00018j-2H for rpsec@ietf.org; Thu, 27 Jul 2006 22:45:39 -0400 Received: from static-71-121-225-117.sttlwa.dsl-w.verizon.net ([71.121.225.117] helo=woodin.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6IM5-0008P3-KV for rpsec@ietf.org; Thu, 27 Jul 2006 22:45:39 -0400 Received: from [10.0.0.16] ([10.0.0.16]) (authenticated bits=0) by woodin.blaines.net (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6S0olvx003562 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 27 Jul 2006 17:50:49 -0700 In-Reply-To: <78EEC285-D931-4F0C-AB06-69AB4F2899C7@muada.com> References: <200607241933.k6OJXKYU013997@tislabs.com> <78EEC285-D931-4F0C-AB06-69AB4F2899C7@muada.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <908B6619-D17F-4EB0-BD0B-19123F543271@blaines.net> Content-Transfer-Encoding: 7bit From: Blaine Christian Subject: Re: [RPSEC] Discontiguous Deployment... Date: Thu, 27 Jul 2006 19:46:08 -0700 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: rpsec@ietf.org, sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org On Jul 24, 2006, at 1:06 PM, Iljitsch van Beijnum wrote: > On 24-jul-2006, at 21:33, sandy@tislabs.com wrote: > >>> Any such requirement should definitely be a case of restating the >>> obvious, since any 'solution' failing to meet the requirement >>> would, by >>> definition, be useless. ;-) > >> So is it useful or useless to state a requirement that a solution >> be useful? >> :-) > > Based on the evidence you can argue in either direction: too many > solutions aren't useful, so either the requirement of usefulness > would be useful, or maybe the requirement was already there even > though the solution turned out useless; in that case the > requirement of usefulness is useless. :-( > > Seriously, though: it doesn't make much sense to require something > that we don't know to be useful. Just adding more and more > requirements in the hope that a solution will accommodate them all > and be perfect is a road that leads nowhere, as the IRTF routing rg > and especially the multi6 wg can attest to. Just a thought (and no comment on your notes specifically Iljitsch) I have seen many notes on the term "useful". The word is very vague and should be avoided in the draft. When I agreed with Tony/Russ it was specifically regarding whether it was important to have the ability to deploy in a non-contiguous fashion. This ability is highly important and should show incremental improvement in our ability to identify and manage to the sources of prefixes on the Internet (speaking with an ISP hat on of course). Now, speaking with my enterprise hat. I would also believe strongly in the ability to deploy in a non-contiguous fashion and show some incremental improvement in my ability to ensure the veracity of announcements received in a secured system. For example, I could envision local pref'ing all inbound advertisements from secured AS's within my "insecure" AS and feeling like I have moved forward with my security by paying more attention to secured networks. As to whether we should carry information in "opaque" mode within the Internet backbone providers whether or not they are "secure". I am not so sure about this method. Again with ISP hat on I can say it is highly, very highly, annoying to find some new hack perpetrated on my routing process without my knowledge. This has caused rather major outages for me (and I suspect for many others) in the past. I would warn against involving networks that did not "plan" on an additional increase in memory utilization etc... Another note on useful. I do agree with Iljitsch that unless this thing show some sort of use from the first network that implements it there are very good odds it will never leave the ground. So yes! Please, let's make it useful . Regards, Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 28 06:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6PTt-0003x7-67; Fri, 28 Jul 2006 06:22:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6PTs-0003wy-Bq for rpsec@ietf.org; Fri, 28 Jul 2006 06:22:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Nu7-0006jJ-0p for rpsec@ietf.org; Fri, 28 Jul 2006 04:41:07 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G6Np8-00075o-Tf for rpsec@ietf.org; Fri, 28 Jul 2006 04:35:59 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6S8ZZTw050496 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Jul 2006 10:35:35 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <908B6619-D17F-4EB0-BD0B-19123F543271@blaines.net> References: <200607241933.k6OJXKYU013997@tislabs.com> <78EEC285-D931-4F0C-AB06-69AB4F2899C7@muada.com> <908B6619-D17F-4EB0-BD0B-19123F543271@blaines.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9DF347CD-7D4C-4E67-8F26-12DCE035B102@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] Discontiguous Deployment... Date: Fri, 28 Jul 2006 10:35:54 +0200 To: Blaine Christian X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: , Errors-To: rpsec-bounces@ietf.org On 28-jul-2006, at 4:46, Blaine Christian wrote: > Just a thought (and no comment on your notes specifically Iljitsch) > I have seen many notes on the term "useful". The word is very > vague and should be avoided in the draft. I don't think it's vague, the problem is that different people find different things useful... > When I agreed with Tony/Russ it was specifically regarding whether > it was important to have the ability to deploy in a non-contiguous > fashion. This ability is highly important and should show > incremental improvement in our ability to identify and manage to > the sources of prefixes on the Internet (speaking with an ISP hat > on of course). Maybe this whole "discontiguous" thing is a red herring. Suppose: A-B-C-D-E where everyone uses the new mechanisms except C. The assumption is that even though C is in the middle, A and B still find it useful to know security information about D and E. In the picture above the only way to accomplish that is to encode the security information such that C will carry it from D to B. But what if: A-B-C-D-E | | +---+ Assuming a model not unlike soBGP B and D could exchange security messages but not actual routing information over a multihop BGP session. This way, B and D can exchange security information directly without burdening C with it. This should be good enough to allow for cryptographically protecting the AS<->prefix mapping, for this particular feature it's not necessary that the security information and the routing information follow the same path. (Which is likely to be true for most mechanisms that are still "useful" with an unupgraded hop in the middle.) But is this "discountiguous"? I think it's possible to argue either way. It gets really interesting when you change this to: A-B-C-D-E | | SS SS where "SS" is a Security Server that imports AS<->prefix mappings and possibly other security information from the RIR databases etc. and injects it in our new secure inter-domain routing protocol. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 28 11:19:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6U7Y-00067r-0b; Fri, 28 Jul 2006 11:19:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6U7X-00067g-D4 for rpsec@ietf.org; Fri, 28 Jul 2006 11:19:23 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6U7W-0003iq-5H for rpsec@ietf.org; Fri, 28 Jul 2006 11:19:23 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6SFIIRI022517 for ; Fri, 28 Jul 2006 11:18:18 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1Iay9R; Fri, 28 Jul 06 11:18:14 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6SFHDim027629; Fri, 28 Jul 2006 11:17:13 -0400 (EDT) Date: Fri, 28 Jul 2006 11:17:13 -0400 (EDT) Message-Id: <200607281517.k6SFHDim027629@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: Re: [RPSEC] Discontiguous Deployment... X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org >A-B-C-D-E > | | > +---+ > >Assuming a model not unlike soBGP B and D could exchange security >messages but not actual routing information over a multihop BGP >session. Yes, a multihop session across the gap allows the security info to flow between islands of non-contiguous deployment. This can work if the gaps are relatively small and infrequent. But in initial deployment, that might not be the case, like: S1-A-B-C-D-E-S2-F-G-H-I-J-K-L-S3 where S1, S2, and S3 are security aware and the rest aren't. It would be hard for S1/S2/S3 to know of each others' existance to set up multi-hop sessions. You could say that in very sparce deployment we can create a central repository. But I don't think it is a good idea to create one means of distributing security info for use initially with a plan to change to another when deployment is more ubiquitous. And a central repository could be bad - not responsive enough for some security uses or when the deployment is widespread, etc. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 28 16:44:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ZBf-00017F-5Q; Fri, 28 Jul 2006 16:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ZBd-000179-HC for rpsec@ietf.org; Fri, 28 Jul 2006 16:43:57 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6ZBZ-0005zK-7I for rpsec@ietf.org; Fri, 28 Jul 2006 16:43:57 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2006 13:43:52 -0700 X-IronPort-AV: i="4.07,193,1151910000"; d="scan'208"; a="437346771:sNHT25407220" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6SKhqxe001912; Fri, 28 Jul 2006 13:43:52 -0700 Received: from [10.82.209.46] (rtp-vpn4-302.cisco.com [10.82.209.46]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k6SKhpYr017504; Fri, 28 Jul 2006 13:43:52 -0700 (PDT) Message-ID: <44CA76FB.3030400@cisco.com> Date: Fri, 28 Jul 2006 16:43:39 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: sandy@tislabs.com Subject: Re: [RPSEC] Discontiguous Deployment... References: <200607281517.k6SFHDim027629@tislabs.com> In-Reply-To: <200607281517.k6SFHDim027629@tislabs.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1011; t=1154119432; x=1154983432; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20Discontiguous=20Deployment...; X=v=3Dcisco.com=3B=20h=3DvSS2UEGsTI2CkDYUkI4Y/LDTXf0=3D; b=LDnoBhrm+wgy82Vz0IK6wa68jGK7eIqBk638HG/0HMvbnj8g4NYKGt7GOIqvjEBrZv6II2yl KBvWVOZM2A/zJ79bnAVM2q8k8+4yzBwicpXnhG5PtljquWbFpIQq9lRa; Authentication-Results: sj-dkim-2.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > But in initial deployment, that might not be the case, like: > > S1-A-B-C-D-E-S2-F-G-H-I-J-K-L-S3 The average hop length in the Internet, today, is about 4. I don't think many of the gov't networks I'm working on will be much longer than that, and I can't think of any enterprise network much longer than that, either (?). I suppose my point is that the usefulness of different mechanisms for discontiguous deployment are also going to depend on the actual network involved. That doesn't mean discontiguous deployment isn't useful, it's just that you have to consider the model provided against the networks the mechanism is likely to run in.... :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEynb7ER27sUhU9OQRAjUxAKCuZxW6vLLOwHbaumQ3oCtYHONsHACggz0i OfG2m5ADTy+gtybfJndVwQ0= =nj7F -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 28 17:04:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ZUu-0004s8-Sl; Fri, 28 Jul 2006 17:03:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6ZUt-0004pw-4J for rpsec@ietf.org; Fri, 28 Jul 2006 17:03:51 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6ZUr-0001vX-Sa for rpsec@ietf.org; Fri, 28 Jul 2006 17:03:51 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6SL2kPW008127 for ; Fri, 28 Jul 2006 17:02:46 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAFHaG3p; Fri, 28 Jul 06 17:02:42 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6SL1g2W010093; Fri, 28 Jul 2006 17:01:42 -0400 (EDT) Date: Fri, 28 Jul 2006 17:01:42 -0400 (EDT) Message-Id: <200607282101.k6SL1g2W010093@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: Re: [RPSEC] Discontiguous Deployment... X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org >I suppose my point is that the usefulness of different mechanisms for >discontiguous deployment are also going to depend on the actual network >involved. Certainly true. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 28 17:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6aEm-0003lU-8E; Fri, 28 Jul 2006 17:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6aEl-0003lP-3h for rpsec@ietf.org; Fri, 28 Jul 2006 17:51:15 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6aEi-0000X5-SL for rpsec@ietf.org; Fri, 28 Jul 2006 17:51:15 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2006 14:51:13 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,193,1151910000"; d="scan'208"; a="33771827:sNHT23651296" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6SLpC2d008964; Fri, 28 Jul 2006 17:51:12 -0400 Received: from [10.82.209.46] (rtp-vpn4-302.cisco.com [10.82.209.46]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6SLpBYh004977; Fri, 28 Jul 2006 17:51:12 -0400 (EDT) Message-ID: <44CA86C3.1030403@cisco.com> Date: Fri, 28 Jul 2006 17:50:59 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: sandy@tislabs.com Subject: Re: [RPSEC] Discontiguous Deployment... References: <200607282101.k6SL1g2W010093@tislabs.com> In-Reply-To: <200607282101.k6SL1g2W010093@tislabs.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=746; t=1154123472; x=1154987472; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20Discontiguous=20Deployment... |To:sandy@tislabs.com; X=v=3Dcisco.com=3B=20h=3DvSS2UEGsTI2CkDYUkI4Y/LDTXf0=3D; b=hV3vRsTSj+YeMwtj2LMNQ8IAvLC9tmdqFoKskl94K8TmAzMjGvXJL/EIVI4BGu6mf2f5GR8b KbQxQYb7ddjqNMR0l/KKgZ5jofLHF35PSxnrw/6XMJ5fzj8ha/Z7TFWy; Authentication-Results: rtp-dkim-2.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I suppose my point is that the usefulness of different mechanisms for >> discontiguous deployment are also going to depend on the actual network >> involved. So, does this mean we've come to a concensus on whether we should include discontiguous deployment as a requirement? Could we try another show of hands, here, to see what everyone thinks? I'll send out another email in a sec.... :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEyobCER27sUhU9OQRAkS3AKCyGmMdcOazdoNDfjdDeXUqyr/XmgCfadOS PFc72QDzR5/d06obzD3fQ4g= =gr6E -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 28 17:56:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6aJv-0004Rp-1N; Fri, 28 Jul 2006 17:56:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6aJu-0004RC-0O for rpsec@ietf.org; Fri, 28 Jul 2006 17:56:34 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6aJs-0001wm-P7 for rpsec@ietf.org; Fri, 28 Jul 2006 17:56:33 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Jul 2006 14:56:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,193,1151910000"; d="scan'208"; a="33772236:sNHT21365512" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6SLuWmp010421 for ; Fri, 28 Jul 2006 17:56:32 -0400 Received: from [10.82.209.46] (rtp-vpn4-302.cisco.com [10.82.209.46]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6SLuWdU010847 for ; Fri, 28 Jul 2006 17:56:32 -0400 (EDT) Message-ID: <44CA8803.1010807@cisco.com> Date: Fri, 28 Jul 2006 17:56:19 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: rpsec@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1020; t=1154123792; x=1154987792; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Discontiguous=20Deployment=20(Show=20of=20Hands).... |To:rpsec@ietf.org; X=v=3Dcisco.com=3B=20h=3DsfwwX+2qSPeLB69cUYiuupqsUl8=3D; b=qaEwpHdhfNJzgsnWUdShepyy+/EreYtd1+0SvcBekngqYZyNTYmwMJhqo8nX3JEcieTet3oO 0Rw/hsLUjMg1TUsmu8xj8Rfo5GclobMFPqIPfzm2yyi+9hX3ZI2jiMlG; Authentication-Results: rtp-dkim-2.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [RPSEC] Discontiguous Deployment (Show of Hands).... 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would call for a hum, but we can't hear it, of course, on email, so.... Please state your answer to the following: o Discontiguous deployment should be included as a capability any proposed mechanism SHOULD have. o Discontiguous deployment should be included as a capability any proposed mechanism MUST have. o We should say something about discontiguous deployment, but we shouldn't attach any requirements to that statement. o Discontiguous deployment should not be included in the requirements at all. I'd just like to settle where we are, so we can actually work on wording with a common understanding of what it is we are trying to actually word. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEyogDER27sUhU9OQRAkITAKD7SxEGvZ9R50wwNRqS+pDHnqmJnACglE8k W8Q1XNI71l188RuaFDFfIcY= =NilE -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 28 18:35:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6av2-00032p-Gi; Fri, 28 Jul 2006 18:34:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6av1-00032T-4i for rpsec@ietf.org; Fri, 28 Jul 2006 18:34:55 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6auy-0001XT-OF for rpsec@ietf.org; Fri, 28 Jul 2006 18:34:55 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6SMYQ4e064775 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 29 Jul 2006 00:34:26 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200607281517.k6SFHDim027629@tislabs.com> References: <200607281517.k6SFHDim027629@tislabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F1F47AD-1C0C-40D7-89E7-0C42723A83E1@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] Discontiguous Deployment... Date: Fri, 28 Jul 2006 23:27:18 +0200 To: sandy@tislabs.com X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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: , Errors-To: rpsec-bounces@ietf.org [Apologies in advance for venturing into solution space] On 28-jul-2006, at 17:17, sandy@tislabs.com wrote: >> A-B-C-D-E >> | | >> +---+ >> Assuming a model not unlike soBGP B and D could exchange security >> messages but not actual routing information over a multihop BGP >> session. > Yes, a multihop session across the gap allows the security info > to flow between islands of non-contiguous deployment. > This can work if the gaps are relatively small and infrequent. I don't think it's limited to that. If you look at the PGP web of trust and identify interconnected islands where there is a path from one key to another, you'll see that there is one huge set of interconnected keys and the next biggest one is orders of magnitude smaller. As islands grow, the chance of it interconnecting with a bigger one approach certainty, with the likelihood of hitting any particular island being relative to that island's size. With secure inter-domain routing the same dynamic will exist to some degree, and additionally, people will find it beneficial to identify and interconnect with the largest islands. (And the most relevant ones too, of course.) Only at the very beginning things will be harder. > But in initial deployment, that might not be the case, like: > S1-A-B-C-D-E-S2-F-G-H-I-J-K-L-S3 > where S1, S2, and S3 are security aware and the rest aren't. > It would be hard for S1/S2/S3 to know of each others' existance > to set up multi-hop sessions. I guess that's true a little after the very beginning when secure ASes start popping up more or less randomly, after some coordinated testing at the very beginning. There are several ways to solve this, including having a small new path attribute that signals the new securit capability and maybe points to a rendezvous point where the security information can be obtained. > You could say that in very sparce deployment we can create a > central repository. But I don't think it is a good idea to create > one means of distributing security info for use initially with a > plan to change to another when deployment is more ubiquitous. > And a central repository could be bad - not responsive enough for > some security uses or when the deployment is widespread, etc. The RIRs are apparently working on a distributed database for prefix<- >AS mappings. It would make sense to import this information and then somehow inject it into the secure inter-domain routing protocol. I think an intermediate system would be beneficial here, in order to pre-process the information as much as possible. Also, having a small number of "idr security servers" could make it possible to not have secret keys with inter-AS significance in routers. (See the key rollover issues with TCP MD5. As long as you still have a secret key in the router you're vulnerable and as long as you can't roll it over unilaterally key rollover is too painful to do on a regular basis.) At the same time, IDR shouldn't be dependent on external services, so it SHOULD be possible for the inter-domain routing system to operate autonomously as soon as the security information has been injected into the system. Last but not least: I expect that if the new security stuff is any good, it will be deployed within large ISP networks fairly quickly (relative to how fast changes happen in such networks) because that way they can much more easily filter their customers and peers than they can today. So I expect it will mostly be the smaller networks / end-users that will take a wait-and-see approach because they often don't filter today and have less IDR expertise and less beefy hardware. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 28 19:35:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6brf-0006z2-74; Fri, 28 Jul 2006 19:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6brd-0006yx-GX for rpsec@ietf.org; Fri, 28 Jul 2006 19:35:29 -0400 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6brc-0003Gx-4i for rpsec@ietf.org; Fri, 28 Jul 2006 19:35:29 -0400 Received: (qmail 1971 invoked from network); 28 Jul 2006 23:36:18 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 28 Jul 2006 23:36:17 -0000 Received: from LIPC ([192.168.1.119]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 16:38:38 -0700 From: "Tony Li" To: "'Russ White'" , Subject: RE: [RPSEC] Discontiguous Deployment (Show of Hands).... Date: Fri, 28 Jul 2006 16:35:23 -0700 Message-ID: <000001c6b29e$7f384990$437d14ac@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcaykNLm6ialx7uVReuL0WlkQKUkKAAAI6ng In-Reply-To: <44CA8803.1010807@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-OriginalArrivalTime: 28 Jul 2006 23:38:38.0287 (UTC) FILETIME=[F3491DF0:01C6B29E] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org > o Discontiguous deployment should be included as a capability any > proposed mechanism SHOULD have. > > o Discontiguous deployment should be included as a capability any > proposed mechanism MUST have. > > o We should say something about discontiguous deployment, but we > shouldn't attach any requirements to that statement. > > o Discontiguous deployment should not be included in the > requirements at > all. > > I'd just like to settle where we are, so we can actually work > on wording > with a common understanding of what it is we are trying to > actually word. One more time... Discontiguous deployment is simply going to be a fact of life. Might as well deal with it. Make it a MUST, because it's a practical necessity anyway. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jul 28 19:37:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6btp-000334-LO; Fri, 28 Jul 2006 19:37:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6btn-00032z-Kk for rpsec@ietf.org; Fri, 28 Jul 2006 19:37:43 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6btm-0003a2-8A for rpsec@ietf.org; Fri, 28 Jul 2006 19:37:43 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6SNbdc11483; Fri, 28 Jul 2006 19:37:39 -0400 (EDT) Received: from [47.248.126.241] ([47.248.126.241] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 19:37:34 -0400 Message-ID: <44CA9FBF.2090307@nortel.com> Date: Fri, 28 Jul 2006 19:37:35 -0400 From: "Marcus Leech" User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: tony.li@tony.li, rpsec@ietf.org Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... References: <000001c6b29e$7f384990$437d14ac@tropos.com> In-Reply-To: <000001c6b29e$7f384990$437d14ac@tropos.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2006 23:37:35.0071 (UTC) FILETIME=[CD9B1EF0:01C6B29E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: rpsec-bounces@ietf.org Tony Li wrote: > > > One more time... > > Discontiguous deployment is simply going to be a fact of life. Might as > well deal with it. Make it a MUST, because it's a practical necessity > anyway. > > Tony > > Completely agree with this. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Jul 29 05:36:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6lEN-0007bv-Sx; Sat, 29 Jul 2006 05:35:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6lEM-0007bb-CO for rpsec@ietf.org; Sat, 29 Jul 2006 05:35:34 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6lEL-0003yt-2I for rpsec@ietf.org; Sat, 29 Jul 2006 05:35:34 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6T9Z5vx076196 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 29 Jul 2006 11:35:06 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <44CA8803.1010807@cisco.com> References: <44CA8803.1010807@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... Date: Sat, 29 Jul 2006 11:35:24 +0200 To: Russ White X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: rpsec-bounces@ietf.org On 28-jul-2006, at 23:56, Russ White wrote: > o Discontiguous deployment should be included as a capability any > proposed mechanism SHOULD have. > o Discontiguous deployment should be included as a capability any > proposed mechanism MUST have. I think someone else already said this, but it bears repeating: It's unclear what discontiguous deployment means here. Obviously, a solution that requires that AS N+1 can't deploy without being required to interact with AS N directly isn't going to fly. But the opposite situation, where a solution is unacceptable unless the full security benefits are also available regardless of whether any ASes in a path do or don't support the new mechanisms is completely unrealistic. So people in favor of one of the options above should first define what level of discontiguous deployment we're talking about. > o We should say something about discontiguous deployment, but we > shouldn't attach any requirements to that statement. This would be my choice. Iljitsch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Jul 29 11:08:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6qPy-0003Qf-Gn; Sat, 29 Jul 2006 11:07:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6qPx-0003QX-ES for rpsec@ietf.org; Sat, 29 Jul 2006 11:07:53 -0400 Received: from static-71-121-225-117.sttlwa.dsl-w.verizon.net ([71.121.225.117] helo=woodin.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6qPw-0000lz-08 for rpsec@ietf.org; Sat, 29 Jul 2006 11:07:53 -0400 Received: from [10.0.0.16] ([10.0.0.16]) (authenticated bits=0) by woodin.blaines.net (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6TD4bR6005160 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 29 Jul 2006 06:04:39 -0700 In-Reply-To: <44CA8803.1010807@cisco.com> References: <44CA8803.1010807@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Blaine Christian Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... Date: Sat, 29 Jul 2006 07:59:48 -0700 To: Russ White X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: , Errors-To: rpsec-bounces@ietf.org On Jul 28, 2006, at 2:56 PM, Russ White wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I would call for a hum, but we can't hear it, of course, on email, > so.... Please state your answer to the following: > > o Discontiguous deployment should be included as a capability any > proposed mechanism SHOULD have. > No > o Discontiguous deployment should be included as a capability any > proposed mechanism MUST have. Yes, but, to Iljitsch's point. It may require a bit of definition. I would like to put a "MUST" around forcing uninvolved players to participate in new memory requirements etc... In fact, I thought we already had that in the draft. > o We should say something about discontiguous deployment, but we > shouldn't attach any requirements to that statement. > No > o Discontiguous deployment should not be included in the > requirements at > all. > No > I'd just like to settle where we are, so we can actually work on > wording > with a common understanding of what it is we are trying to actually > word. > Yes > :-) > > Russ > > - -- > riw@cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEyogDER27sUhU9OQRAkITAKD7SxEGvZ9R50wwNRqS+pDHnqmJnACglE8k > W8Q1XNI71l188RuaFDFfIcY= > =NilE > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 Sat Jul 29 12:50:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6s1I-0001WG-QD; Sat, 29 Jul 2006 12:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6s1G-0001W6-C1 for rpsec@ietf.org; Sat, 29 Jul 2006 12:50:30 -0400 Received: from iceblock01.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6s1E-0005Zl-WA for rpsec@ietf.org; Sat, 29 Jul 2006 12:50:30 -0400 Received: (qmail 24455 invoked from network); 29 Jul 2006 16:43:56 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 29 Jul 2006 16:43:56 -0000 Received: from LIPC ([192.168.1.152]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Jul 2006 09:46:19 -0700 From: "Tony Li" To: "'Iljitsch van Beijnum'" , "'Russ White'" Subject: RE: [RPSEC] Discontiguous Deployment (Show of Hands).... Date: Sat, 29 Jul 2006 09:43:02 -0700 Message-ID: <000101c6b32e$0eb665e0$9801a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: Acay8n8MWJEJ/NryTeaZyeBTe0vZtAAOwnwQ X-OriginalArrivalTime: 29 Jul 2006 16:46:19.0538 (UTC) FILETIME=[84415720:01C6B32E] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org > It's unclear what discontiguous deployment means here. Obviously, a > solution that requires that AS N+1 can't deploy without being > required to interact with AS N directly isn't going to fly. But the > opposite situation, where a solution is unacceptable unless the full > security benefits are also available regardless of whether any ASes > in a path do or don't support the new mechanisms is completely > unrealistic. > > So people in favor of one of the options above should first define > what level of discontiguous deployment we're talking about. Iljitsch, I don't believe that this is actually relevant to a requirements discussion. Given that partial, discontiguous deployment is a necessity, the solutions will be evaluated on the amount of benefit that they provide. Since contiguous paths will be in the minority, solutions should seriously consider what benefits that they can provide in discontiguous partial paths. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Jul 29 14:30:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6tZZ-0003Ei-2I; Sat, 29 Jul 2006 14:30:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6tZX-0003Ed-4V for rpsec@ietf.org; Sat, 29 Jul 2006 14:29:59 -0400 Received: from www.reptiles.org ([198.96.119.1] helo=mail.reptiles.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6tZV-0004YR-Te for rpsec@ietf.org; Sat, 29 Jul 2006 14:29:59 -0400 Received: from mail.reptiles.org([198.96.119.1] port=4867) (1811 bytes) by mail.reptiles.org([198.96.119.1] port=25) via TCP with esmtp (sender: ) id for ; (dest:remote)(R=bind_hosts)(T=inet_zone_bind_smtp) Sat, 29 Jul 2006 14:29:53 -0400 (EDT) (Smail-3.2.0.118 2004-May-31 #3 built 2004-Oct-14) Date: Sat, 29 Jul 2006 14:29:53 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@skink.reptiles.org To: Russ White Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... In-Reply-To: <44CA8803.1010807@cisco.com> Message-ID: <20060729142722.W38754@skink.reptiles.org> References: <44CA8803.1010807@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cat Okita List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org On Fri, 28 Jul 2006, Russ White wrote: > o Discontiguous deployment should be included as a capability any > proposed mechanism SHOULD have. > > o Discontiguous deployment should be included as a capability any > proposed mechanism MUST have. Yes. We can wrangle about what exactly 'discontiguous' means, but I can't picture a sane way to deploy a solution that doesn't allow for a staggered/graduated/limited deployment. > o We should say something about discontiguous deployment, but we > shouldn't attach any requirements to that statement. > > o Discontiguous deployment should not be included in the requirements at > all. > > I'd just like to settle where we are, so we can actually work on wording > with a common understanding of what it is we are trying to actually word. s/common/closer to common/ ? cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Jul 29 16:23:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6vLb-0007K5-Ne; Sat, 29 Jul 2006 16:23:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6vLZ-0007Jx-6Q for rpsec@ietf.org; Sat, 29 Jul 2006 16:23:41 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6vLX-0002MZ-T4 for rpsec@ietf.org; Sat, 29 Jul 2006 16:23:41 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k6TKNE37085368 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 29 Jul 2006 22:23:14 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <000101c6b32e$0eb665e0$9801a8c0@tropos.com> References: <000101c6b32e$0eb665e0$9801a8c0@tropos.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B99DB12-569A-4EE7-8B19-99B89761E577@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... Date: Sat, 29 Jul 2006 22:23:27 +0200 To: X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Errors-To: rpsec-bounces@ietf.org On 29-jul-2006, at 18:43, Tony Li wrote: > I don't believe that this is actually relevant to a requirements > discussion. > Given that partial, discontiguous deployment is a necessity, the > solutions will be evaluated on the amount of benefit that they > provide. I strongly believe that any words that don't make a (potential) material difference in the real world are meaningless and are therefore best not uttered in written or spoken language. So if we say that we require discontiguous deployment while at the same time we know that discontiguous deployment is a certainty, that's a waste of electrons. Worse, this invites speculation about the meaning of the requirement down the road. On the other hand, we can say that we require dicontiguous deployment and then say what we take that to mean, or we can say that discontiguous deployment is important and invite people who come up with solutions to offer insights in the types of discontiguous deployment they feel should/shouldn't and can/can't be supported by their solution. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jul 30 05:47:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G77t8-00078X-Ig; Sun, 30 Jul 2006 05:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G77t6-00078O-P6 for rpsec@ietf.org; Sun, 30 Jul 2006 05:47:08 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G77t5-0002Mr-Ek for rpsec@ietf.org; Sun, 30 Jul 2006 05:47:08 -0400 Received: from pc6 (1Cust10.tnt108.lnd4.gbr.da.uu.net [62.188.170.10]) by ranger.systems.pipex.net (Postfix) with SMTP id B69DAE000343; Sun, 30 Jul 2006 10:47:04 +0100 (BST) Message-ID: <005701c6b3b4$0fe3a460$0601a8c0@pc6> From: "Tom Petch" To: "Russ White" , References: <44CA8803.1010807@cisco.com> Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... Date: Sat, 29 Jul 2006 22:09:31 +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.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 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: , Errors-To: rpsec-bounces@ietf.org MUST, no other alternative Tom Petch ----- Original Message ----- From: "Russ White" To: Sent: Friday, July 28, 2006 11:56 PM Subject: [RPSEC] Discontiguous Deployment (Show of Hands).... > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I would call for a hum, but we can't hear it, of course, on email, > so.... Please state your answer to the following: > > o Discontiguous deployment should be included as a capability any > proposed mechanism SHOULD have. > > o Discontiguous deployment should be included as a capability any > proposed mechanism MUST have. > > o We should say something about discontiguous deployment, but we > shouldn't attach any requirements to that statement. > > o Discontiguous deployment should not be included in the requirements at > all. > > I'd just like to settle where we are, so we can actually work on wording > with a common understanding of what it is we are trying to actually word. > > :-) > > Russ > > - -- > riw@cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFEyogDER27sUhU9OQRAkITAKD7SxEGvZ9R50wwNRqS+pDHnqmJnACglE8k > W8Q1XNI71l188RuaFDFfIcY= > =NilE > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 Jul 30 08:26:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7AMc-0004Fj-0A; Sun, 30 Jul 2006 08:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7AMa-0004Fe-92 for rpsec@ietf.org; Sun, 30 Jul 2006 08:25:44 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7AMY-0008OZ-14 for rpsec@ietf.org; Sun, 30 Jul 2006 08:25:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Jul 2006 08:25:42 -0400 X-IronPort-AV: i="4.07,195,1151899200"; d="scan'208"; a="94412562:sNHT24834276" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6UCPfGj010474; Sun, 30 Jul 2006 08:25:41 -0400 Received: from [10.82.208.161] (rtp-vpn4-161.cisco.com [10.82.208.161]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6UCPfdU016255; Sun, 30 Jul 2006 08:25:41 -0400 (EDT) Message-ID: <44CCA544.2090307@cisco.com> Date: Sun, 30 Jul 2006 08:25:40 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Blaine Christian Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... References: <44CA8803.1010807@cisco.com> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1197; t=1154262341; x=1155126341; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[RPSEC]=20Discontiguous=20Deployment=20(Show=20of=20Hands).... |To:Blaine=20Christian=20; X=v=3Dcisco.com=3B=20h=3D0Oee9iTyKQCzMw+E//TMPugBxQE=3D; b=sFAmITviW9XoKyW4j/OhV9UgEJFMLNww3SY+z/zqyPfpU6HNyKQd11/0vEtK+y/yn9Cd1uCP otdTa7MN0HQIBzYyekjMIGbWhuGFarObe/J2mMD39mVWar7ldLh8HANN; Authentication-Results: rtp-dkim-1.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); 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: , Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > o Discontiguous deployment should be included as a capability any > proposed mechanism MUST have. > >> Yes, but, to Iljitsch's point. It may require a bit of definition. I >> would like to put a "MUST" around forcing uninvolved players to >> participate in new memory requirements etc... In fact, I thought we >> already had that in the draft. It looks like the list pretty much thinks MUST is the right way to go, and we're just to discussing what that MUST means (?). It seems to me that building the specific wording for the draft would take this question in.... I tend to agree with Tony that it's going to mean different things for different proposals, so we might just require that any proposal discuss how discontiguous deployments would work, and what the tradeoffs are for that specific proposal (?).... Thoughts? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEzKVDER27sUhU9OQRAoZ9AJ0S/UAkV4f7CZI1WbY8EzLcTsRb9wCbBLPo gEIrwX56dO/DRNe1rWBeIVo= =a57p -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 31 09:10:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7XWv-000488-LY; Mon, 31 Jul 2006 09:09:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7XWu-000482-9M for rpsec@ietf.org; Mon, 31 Jul 2006 09:09:56 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7XWs-0006QS-6u for rpsec@ietf.org; Mon, 31 Jul 2006 09:09:56 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6VD8mFY023472 for ; Mon, 31 Jul 2006 09:08:48 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAJ3aO1T; Mon, 31 Jul 06 09:08:44 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6VD7gSe014196; Mon, 31 Jul 2006 09:07:42 -0400 (EDT) Date: Mon, 31 Jul 2006 09:07:42 -0400 (EDT) Message-Id: <200607311307.k6VD7gSe014196@tislabs.com> From: sandy@tislabs.com To: rpsec@ietf.org Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... X-Spam-Score: 0.2 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: sandy@tislabs.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: , Errors-To: rpsec-bounces@ietf.org > o Discontiguous deployment should be included as a capability any > proposed mechanism MUST have. I vote for this. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 31 10:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YKY-0002a2-0r; Mon, 31 Jul 2006 10:01:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YKX-0002Zx-2f for rpsec@ietf.org; Mon, 31 Jul 2006 10:01:13 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7YKV-0005dZ-Qk for rpsec@ietf.org; Mon, 31 Jul 2006 10:01:13 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6VE08pk029772 for ; Mon, 31 Jul 2006 10:00:08 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3WaGi6; Mon, 31 Jul 06 10:00:04 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6VDwvPj016076; Mon, 31 Jul 2006 09:58:57 -0400 (EDT) Date: Mon, 31 Jul 2006 09:58:57 -0400 (EDT) Message-Id: <200607311358.k6VDwvPj016076@tislabs.com> From: sandy@tislabs.com To: iljitsch@muada.com, tony.li@tony.li Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: rpsec-bounces@ietf.org >So if we say that we require discontiguous deployment while at the >same time we know that discontiguous deployment is a certainty, >that's a waste of electrons. Worse, this invites speculation about >the meaning of the requirement down the road. What is certain is that non-contiguous deployment will happen. What is not certain is that solutions will support non-contiguous deployment. We are stating a requirement that solutions must be able to be deployed in a non-contiguous deployment. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 31 10:17:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YaR-0001Ts-8R; Mon, 31 Jul 2006 10:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YaQ-0001Tn-JY for rpsec@ietf.org; Mon, 31 Jul 2006 10:17:38 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7YaP-0007gP-AH for rpsec@ietf.org; Mon, 31 Jul 2006 10:17:38 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6VEGXBj002070 for ; Mon, 31 Jul 2006 10:16:33 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAUuaiYd; Mon, 31 Jul 06 10:15:40 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6VEEcoT016904; Mon, 31 Jul 2006 10:14:38 -0400 (EDT) Date: Mon, 31 Jul 2006 10:14:38 -0400 (EDT) Message-Id: <200607311414.k6VEEcoT016904@tislabs.com> From: sandy@tislabs.com To: iljitsch@muada.com Subject: Re: [RPSEC] Discontiguous Deployment... X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: rpsec-bounces@ietf.org Iljitsch said: >There are several ways to solve this, including having a small new >path attribute that signals the new securit capability and maybe >points to a rendezvous point where the security information can be >obtained. >... >At the same time, IDR shouldn't be dependent on external services So it sounds like you are arguing against yourself, here. I understand the issues with carrying security info in-band through the unaware gaps. I also understand the issues with necessitating BGP contact external (aka out of band) services in order to function. I don't see an easy resolution. Do you? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 31 10:37:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YtV-0002vz-PV; Mon, 31 Jul 2006 10:37:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7YtU-0002ve-3H for rpsec@ietf.org; Mon, 31 Jul 2006 10:37:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7YtU-0000bp-1M for rpsec@ietf.org; Mon, 31 Jul 2006 10:37:20 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7YtS-0000yz-9D for rpsec@ietf.org; Mon, 31 Jul 2006 10:37:19 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G7YtP-0002Go-5N; Mon, 31 Jul 2006 10:37:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <44CA8803.1010807@cisco.com> References: <44CA8803.1010807@cisco.com> Date: Mon, 31 Jul 2006 10:32:18 -0400 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.6 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: rpsec-bounces@ietf.org At 5:56 PM -0400 7/28/06, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >I would call for a hum, but we can't hear it, of course, on email, >so.... Please state your answer to the following: > >o Discontiguous deployment should be included as a capability any >proposed mechanism SHOULD have. > >o Discontiguous deployment should be included as a capability any >proposed mechanism MUST have. The current text requires (MUST) support for incremental deployment, and requires the ability to configure a router for use of a security mechanism on a oer-peer basis. Thus it makes sense to mandate support for non-contiguous deployment. I didn't think that was at issue/ >o We should say something about discontiguous deployment, but we >shouldn't attach any requirements to that statement. This is the point I raised a week or so ago, i.e., it is not easy to establish requirements for the security provided by a mechanism in a non-contiguous deployment scenario, in a mechanism-independent fashion. So far our discussion on the list has not indicated otherwise. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 31 15:34:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7dWf-0004wb-1C; Mon, 31 Jul 2006 15:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7dWd-0004wR-R8 for rpsec@ietf.org; Mon, 31 Jul 2006 15:34:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Z9F-0002I3-7X for rpsec@ietf.org; Mon, 31 Jul 2006 10:53:37 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7YwH-0001G0-Lv for rpsec@ietf.org; Mon, 31 Jul 2006 10:40:15 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k6VEd8Rc004686 for ; Mon, 31 Jul 2006 10:39:08 -0400 (EDT) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAf_aqhj; Mon, 31 Jul 06 10:38:55 -0400 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k6VEbhA9017789; Mon, 31 Jul 2006 10:37:43 -0400 (EDT) Date: Mon, 31 Jul 2006 10:37:43 -0400 (EDT) Message-Id: <200607311437.k6VEbhA9017789@tislabs.com> From: sandy@tislabs.com To: blaine@netartifex.com, riw@cisco.com Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... X-Spam-Score: -2.6 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: , Errors-To: rpsec-bounces@ietf.org >I tend to agree with Tony that it's going to mean different things for >different proposals, so we might just require that any proposal discuss >how discontiguous deployments would work, and what the tradeoffs are for >that specific proposal (?).... Even if we require a "MUST be deployable in non-contiguous deployment", I think there is value in requiring certain analysis for any proposed solution. Is that an OK thing to do in a protocol requirements document - require that the solution description discuss certain things? If it was OK, I'd like to have the solution discuss: - the benefit to each island of non-continguous deployment to knowing security info related to another island of deployment (in some cases of security info, this will be obvious, in others it may require discussion of deployment scenarios, etc.) - how security info would be communicated between islands - if in-band, the in-band mechanism and cost in terms of b/w, memory, processing, latency, yada, yada - if out-of-band, the out-of-band protocol and the intended operational use with particular focus on start-up conditions for router and for ISP peerings. - a discussion of the dynamics of the system - how changes in security info or base routing information get communicated (that's kinda vague, but it is something I look for in solutions - and it's an issue more related to the communications than to non-contiguous deployment). --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 31 16:22:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eHq-0003ki-4p; Mon, 31 Jul 2006 16:22:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7eHo-0003kc-HD for rpsec@ietf.org; Mon, 31 Jul 2006 16:22:48 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7eHn-0002HG-Ar for rpsec@ietf.org; Mon, 31 Jul 2006 16:22:48 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G7eHm-0007Jn-4P; Mon, 31 Jul 2006 16:22:46 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200607311437.k6VEbhA9017789@tislabs.com> References: <200607311437.k6VEbhA9017789@tislabs.com> Date: Mon, 31 Jul 2006 16:17:47 -0400 To: sandy@tislabs.com From: Stephen Kent Subject: Re: [RPSEC] Discontiguous Deployment (Show of Hands).... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: rpsec@ietf.org, 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: , Errors-To: rpsec-bounces@ietf.org I agree with Sandy's suggestions re requiring an analysis of the benefits of non-contiguous deployment. I would add that we should look at the costs as well, and the issue of configuration complexity. For example, if configuration of routers to take advantage of non-contiguous deployment is very complex, then are we better off with non-contiguous deployment that causes the "islands" Sandy noted to just act as islands, vs. creating management-induced vulnerabilities? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jul 31 20:51:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7iTN-0003q0-5m; Mon, 31 Jul 2006 20:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7iTL-0003pv-J4 for rpsec@ietf.org; Mon, 31 Jul 2006 20:50:59 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7iTK-0008AY-87 for rpsec@ietf.org; Mon, 31 Jul 2006 20:50:59 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 31 Jul 2006 17:50:44 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id DC6002AF; Mon, 31 Jul 2006 17:50:43 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id B95312AE; Mon, 31 Jul 2006 17:50:43 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EBG41842; Mon, 31 Jul 2006 17:50:43 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 35CA620501; Mon, 31 Jul 2006 17:50:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] Discontiguous Deployment (Show of Hands).... Date: Mon, 31 Jul 2006 17:50:43 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B368AEC16@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <44CA8803.1010807@cisco.com> Thread-Topic: [RPSEC] Discontiguous Deployment (Show of Hands).... Thread-Index: AcaykLlW3HGmu45HTr6+Nsd6Ln7CLQCc764g From: "Bora Akyol" To: "Russ White" , rpsec@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006073112; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230332E34344345413530332E303031362D412D; ENG=IBF; TS=20060801005047; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006073112_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68D07AEE3VK2637295-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Errors-To: rpsec-bounces@ietf.org MUST HAVE > -----Original Message----- > From: Russ White [mailto:riw@cisco.com]=20 > Sent: Friday, July 28, 2006 2:56 PM > To: rpsec@ietf.org > Subject: [RPSEC] Discontiguous Deployment (Show of Hands).... >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > I would call for a hum, but we can't hear it, of course, on=20 > email, so.... Please state your answer to the following: >=20 > o Discontiguous deployment should be included as a capability=20 > any proposed mechanism SHOULD have. >=20 > o Discontiguous deployment should be included as a capability=20 > any proposed mechanism MUST have. >=20 > o We should say something about discontiguous deployment, but=20 > we shouldn't attach any requirements to that statement. >=20 > o Discontiguous deployment should not be included in the=20 > requirements at all. >=20 > I'd just like to settle where we are, so we can actually work=20 > on wording with a common understanding of what it is we are=20 > trying to actually word. >=20 > :-) >=20 > Russ > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec