From rpsec-bounces@ietf.org Tue Jan 03 00:06:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EteNR-0005ls-QK; Tue, 03 Jan 2006 00:06:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EteNQ-0005ju-4t for rpsec@megatron.ietf.org; Tue, 03 Jan 2006 00:06:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28488 for ; Tue, 3 Jan 2006 00:05:13 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EteSc-000364-IJ for rpsec@ietf.org; Tue, 03 Jan 2006 00:11:51 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k035621E017577; Mon, 2 Jan 2006 21:06:02 -0800 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) with ESMTP id k035616E017574; Mon, 2 Jan 2006 21:06:01 -0800 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Mon, 2 Jan 2006 21:06:01 -0800 (PST) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: Pekka Savola Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Mon, 14 Nov 2005, Pekka Savola wrote: > Hi, > > I've read the security requirements document, now that it has a bit > more detail. There are a couple of high-level omissions which IMHO > need to be fixed; there are also some more minor issues in the > details. See the comments below. Hi Pekka, Your close and thoughtful reading is appreciated, as always. Sorry it has taken until now to respond and incorporate. Comments below. > ..... > > The most serious shortcoming of this doc is that it does not address > "economic" realities which is a must for any serious deployment. In > particular, you could add for example the following requirements: Done for both of these. > > X. No Heavy Processing on Routers > > Having specialized hardware to deal with cryptography in order to > get acceptable processing speed is unacceptable in general. The > solution cannot be deployed if it requires significant financial > investment. > > In particular, the solution must not require that heavy processing > is required on all the BGP routers. Even heavy processing on all > routers originating a prefix seems very undesirable, as well as > requiring such in all eBGP routers. Thus, requiring heavy > processing in anything except separate network components or one or > two routers would strongly discourage deployment. > > On the other hand, while "low processing on routers" security model > must be supported, it would be acceptable to have extensions for the > "basic" support, which could be locally deployed by those parties > which find it necessary or economically justifiable. > > ... > > Maybe also something a bit more explicit about the amount of configuration? > > X+1. No Heavy Configuration on Routers > > It is undesirable to have long or very detailed configuration on the > routers, especially it needs to be synchronized on all of them. > Long configuration makes operating the device more difficult, and > having to do very detailed configuration may hinder the adoption of > the security solution; it should be possible to "just start using > it" if possible. > > > substantial > ----------- > > o Contents of the UPDATE message SHOULD be authenticated in real- > time as the UPDATE message is processed. > ... > > All BGP implementations that implement security MUST utilize at least > one of the above methods for validating routing information. Real > time verification is preferred in order to prevent transitive > failures based on periodic or event-driven scan intervals. > > ==> you only discuss UPDATEs; you should also mention WITHDRAWs. > Regardless of whether it's UPDATE or WITHDRAW, you should also > consider the impact of delaying legitimate routing update (e.g., the > path went down and the packets will be discarded unless a new path > is selected ASAP). > > (After later reading, some of this is discussed in section 3.4, but an > appropriate amount of text and a pointer should be added here as well.) > > The AS_PATH for specific prefixes may be protected in any proposed > security system in four ways: > ... > All of these checks SHOULD be made available to network operators. > Each network operator will decide, on a local basis, which of these > checks to enable. > > ==> this requirement is not spelled out properly. At least the last > one (maybe the second-to-last as well) require mechanisms based on > the path, i.e., cannot be enabled by local checks. Are you > requiring that the transit ASes must implement all of these checks? No, the requirement that benefit be seen even w/o universal deployment trumps any suggestion that transit ASes must implement. If some iteration through the solution space demonstrates an incongruity, we can deal with it then. > Transport protection is an important aspect of BGP routing > protocol security. The potential to create a linked > transport/NLRI/AS_PATH authentication mechanism should not be > overlooked and may provide for the accelerated deployment of a BGP > security system. Current security mechanisms for BGP transport > (e.g. TCP-MD5 [4] and GTSM [6]) are inadequate and require > significant operator interaction to maintain a respectable level > of security. > ... > Any proposed security mechanism MUST include provisions for securing > both internal BGP and external BGP peering sessions. > > ==> this is not accurate; TCP-MD5 and GTSM are very well adequate. > That is, > > 1) iBGP sessions are prevented if the AS applies source address > spoofing prevention (or alternatively, blocks access to the select > parts of the infrastructure components) at its borders; there is no > need to use TCP-MD5 or GTSM. > > 2) eBGP sessions are protected using GTSM when the peer(s) are > sufficiently trustable. > > That leaves only the case when the peering mesh is not > point-to-point, i.e., ethernet-based internet exchanges. TCP-MD5 is > typically used there to protect from session resets by other members > of the exchange. The operational pain of TCP-MD5 comes from having > to agree on static keys on a per-peer basis, but the situation may > not be much better in terms of config required in any solution. > > There are still ICMP attacks to consider > (draft-gont-tcpm-icmp-attacks-05.txt) but IPsec does not protect > from those by better. > > In any case, the text should be a lot more accurate and realistic, > and the 'MUST' requirement seems too strong; this might be something > that should be optional to implement, and certainly optional to > enable. We could use a stronger sense of the authenticity of the neighbor, I'd argue. > .... > > Key maintenance can be especially onerous for operators. The > number of keys required and the maintenance of keys > (update/withdraw/renew) has had an additive effect as a barrier to > deployment. Thus automated means of managing keys, to reduce > operational burdens, MUST be available throughout BGP security > systems. These security systems MUST be resistant to compromise > of session-level or device-level keys, i.e., the security > implications of such compromises MUST be limited. > > ==> what are (update/withdraw/renew) keys? These are not separate > keys. Just one key is required. These are actions which one might do with keys. I'll re-word so that they don't appear to use the same nomenclature as BGP actions. Now it reads ..."(issue/revoke/renew)...". > ==> it might be worth separating the discussion of transport > protection keys and the route origination (etc.) keys. These are > two very different animals with very different security properties. > For the former, the MUST requirement is way too strong, as you can > only reset one peering session (and even that only if you get on the > link) -- hardly a huge problem. Well, if we just keep on using TCP-MD5 and re-use keys in multiple places, the implications of compromise can be more widespread. > semi-editorial > -------------- > > ==> the use of upper-case keywords is not appropriate in a > requirements document like this; please make them lower-case. > > ==> section 1.3 does not mention Withdraws? > > Update > messages are sent between AS peers with the implicit assumption > that those messages will be forwarded to others. > > ==> this leaves out an important detail: only the best path is > forwarded (and even then it's only forwarded to those where it's by > policy configured to be forwarded). Changed to "...the tacit authorization for those messages to be forwarded to others" > While the AS_PATH information is typically transitive it is, > currently, not clearly mandated and many times is removed for > various utilitarian reasons. > > ==> what do you mean with this? This sounds as if some operators > would rewrite long AS paths to shorter one which is (I hope) not > true... Reword? s/removed/modified/ > Specifications state that the AS routing graph MUST be loop > free. This indicates that UPDATES received from an external > peer which contain the local AS will be rejected. > > ==> on idr list, maybe about a year ago, this topic came up, and at > least some people seemed to think that such routes need not be > rejected, but it is sufficient that they are of lower preference > than anything else. The "valid" case for these was during certain > network partitions. Not that I personally bought it, but that's a > separate story.... > > Prepending a peer AS number on inbound UPDATEs is employed for > biasing internal routing and forwarding management while > prepending one's own AS number on outbound advertisement is > typically used to bias forwarding and routing changes in > external networks. The latter practice is explicitly permitted > by the BGP specification while the former is not. > > ==> please add an explicit reference which states how the former is > not permitted. It's not explicitly permitted, so, by definition, no reference exists to say so. > Some operators, insert a remote AS number in an UPDATE, in > order to cause the UPDATE to be dropped by that AS so that > traffic will not traverse a given path. > > ==> remove the commas; reference (a nanog presentation/posts, a > paper, ...) would be useful here. I agree, but regretably I haven't been able to find anything "on the record". > Attributes such as LOCAL_PREF are not transitive and, > as such, are protected by BGP session security. > > ==> local_pref is only passed between iBGP, so if you want to be > more generic, I'd use MED as an example. Done. > o AS_PATH Feasibility Check: The AS_PATH list MUST correspond to a > valid list of autonomous systems according to the first > verification category listed in the "Areas to Secure" Section > above. > > o Update Transit Check: Routing information carried through BGP > SHOULD include information that can be used to verify the > readvertisement or modification by each autonomous system through > which the UPDATE has passed. This check is somewhat more rigorous > than the "verifiable list of autonomous systems" above. > > ==> you don't list the "verifiable list of autonomous system"; did > you mean the feasibility check or something else? Changed to make the wording agree. > o A BGP speaker and listener have chosen to restrict the number of > received prefixes for the listener. The listener has chosen to > honor route announcements sent in a summary fashion by the > speaker. > > ==> it's not clear what you're trying to say here, and it's no clear > who is the "speaker" and who is the "listener". please reword. > > 12. References > > ==> split to informative and normative. Done. > editorial > --------- Did all of these. Thanks! See the revision: http://www.1-4-5.net/~ttauber/draft-ietf-rpsec-bgpsecrec-04.txt and, for diffs between the two versions: http://www.1-4-5.net/~ttauber/draft-ietf-rpsec-bgpsecrec-03-04-diff.html Tony > ==> you should add ToC as the draft is over 15 pages. > > ==> you should maybe use > > ==> slightly trimming the abstract would allow it to be on the cover page:) > > specification,RFC4271 [7], as a path-vector routing protocol. BGP > > ==> s/,R/, R/ > > The session between two BGP speakers can be secured such that the BGP > data received by the BGP speakers can by cryptographically verified > to have been transmitted by the peer BGP speaker and not a replay of > previously transmitted legitimate data. > > ==> s/by/be/ > > orignation information is removed (i.e. the more-specific > > ==> s/orig/origi/ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jan 03 20:33:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtxWZ-0003ux-Tv; Tue, 03 Jan 2006 20:33:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtxWX-0003uo-Ra for rpsec@megatron.ietf.org; Tue, 03 Jan 2006 20:33:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17594 for ; Tue, 3 Jan 2006 20:31:54 -0500 (EST) Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etxbv-00018j-2D for rpsec@ietf.org; Tue, 03 Jan 2006 20:38:44 -0500 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 03 Jan 2006 17:32:42 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 4D54B67424; Tue, 3 Jan 2006 17:32:42 -0800 (PST) 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.5.6-GR) with ESMTP id CNS91831; Tue, 3 Jan 2006 17:32:32 -0800 (PST) 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 BDA5C20501; Tue, 3 Jan 2006 17:32:32 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 3 Jan 2006 17:32:30 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B362A81F3@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 thread-index: AcYQI5+gwLbtT5/4SIqJRe3NtP/AmAAqW/Dg From: "Bora Akyol" To: "Tony Tauber" , "Pekka Savola" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006010310; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230312E34334242323446452E303031332D412D; ENG=IBF; TS=20060104013246; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006010310_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FA5FA301JW3487009-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Pekka, Tony I remember specifically discussing X (no heavy processing) and X+1 (no heavy configuration) during the early stages of this draft. Without defining what "heavy processing" is, I find that this particular requirement is not implementable. Is it heavy processing on an AGS+, or is it heavy processing on a high end router of today? What about latest gen. embedded processors with built-in crypto capability? I would reword this as a requirement based on the incoming number of UPDATES/WITHDRAWS per second, and the number of information units that are actually processed. For example something like this: -- X. Processing Requirements for Securing BGP on Network Elements All security solutions for securing BGP, MUST be able to process at least 90% of the offered message rate for the incoming UPDATE/WITHDRAW etc. BGP messages; and the solutions MUST be able degrade gracefully when the backlog of unprocessed messages exceeds the storage capabilities of the network elements. Degrading gracefully may be construed as dropping earlier messages from the same peer in favor of the later messages, or stop reading packets from the incoming TCP sockets, etc. -- Clearly, "degrading gracefully" part needs more work in definition ;-) Bora _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 04 05:21:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu5lw-0006xL-4a; Wed, 04 Jan 2006 05:21:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu5lu-0006xD-9K for rpsec@megatron.ietf.org; Wed, 04 Jan 2006 05:21:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08962 for ; Wed, 4 Jan 2006 05:20:19 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu5rJ-0001Wx-Mv for rpsec@ietf.org; Wed, 04 Jan 2006 05:27:13 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id k04AKxe09617; Wed, 4 Jan 2006 12:20:59 +0200 Date: Wed, 4 Jan 2006 12:20:58 +0200 (EET) From: Pekka Savola To: Bora Akyol Subject: RE: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 In-Reply-To: <03235919BBDE634289BB6A0758A20B362A81F3@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: References: <03235919BBDE634289BB6A0758A20B362A81F3@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Tue, 3 Jan 2006, Bora Akyol wrote: > I remember specifically discussing X (no heavy processing) and X+1 (no > heavy configuration) during the early stages of this draft. > > Without defining what "heavy processing" is, I find that this particular > requirement is not implementable. Is it heavy processing on an AGS+, or > is it heavy processing on a high end router of today? What about latest > gen. embedded processors with built-in crypto capability? We probably can't assume the presence of latest gen. embedded processors w/ built-in crypto, if we want to get significant deployment in the next 5-7 years from now.. > I would reword this as a requirement based on the incoming number of > UPDATES/WITHDRAWS per second, and the number of information units that > are actually processed. Do we know what the metrics are? Certainly, there may be some absolute requirements ("full routing table sync must not take more than xxx seconds"), but I'd expect the folks considering secure BGP solutions would also be evaluating the performance against the current BGP. While at some point (e.g., if full table sync took less than 5 seconds) it might not matter if the convergence speed doubled, I'm not sure what kind of confort thresholds the operators would have. Given that we don't really have good metrics on what are the exact requirements, it might be best to leave the text a bit more generic. (btw, I spotted a typo in the text I proposed, in section 3.6 s/especially if/especially if it/ -- 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 Wed Jan 11 10:33:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwhyX-0006d1-N2; Wed, 11 Jan 2006 10:33:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwhyW-0006cw-JD for rpsec@megatron.ietf.org; Wed, 11 Jan 2006 10:33:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20439 for ; Wed, 11 Jan 2006 10:32:02 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewi5P-0006UT-VU for rpsec@ietf.org; Wed, 11 Jan 2006 10:40:34 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0BFWjIC004282; Wed, 11 Jan 2006 10:32:46 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 11 Jan 2006 10:32:23 -0500 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Tony, I have some comments on your response to Pekka's comments. Since I saw no response to Pekka's original message I did not bother addressing all of his comments when they first appears around the holidays. But, if you plan on making changes to the document in response to these comments ... >... >> >>X. No Heavy Processing on Routers >> >>Having specialized hardware to deal with cryptography in order to >>get acceptable processing speed is unacceptable in general. The >>solution cannot be deployed if it requires significant financial >>investment. In what time frame? If we said that no changes that require "significant" financial investments can ever be made, then we would have to declare many changes, security or otherwise, to be unacceptable. >>In particular, the solution must not require that heavy processing >>is required on all the BGP routers. Even heavy processing on all >>routers originating a prefix seems very undesirable, as well as >>requiring such in all eBGP routers. Thus, requiring heavy >>processing in anything except separate network components or one or >>two routers would strongly discourage deployment. "heavy processing" is a vague term. I realize that it's hard to be precise when discussing these issues, but vague wording only leads to later arguments. Also, different ISPs probably have deployed different routers for eBGP, so what may be heavy processing for one ISP may not be for another, or may not be for a different eBGP router within the same ISP. >>On the other hand, while "low processing on routers" security model >>must be supported, it would be acceptable to have extensions for the >>"basic" support, which could be locally deployed by those parties >>which find it necessary or economically justifiable. This notion sounds attractive in the abstract, but there is no indication that it is achievable, at the level of abstraction used to describe it. Routing security is a distributed function. While we all agree that incremental deployment is a requirement, it is not clear that support of different security "models" by different ISPs yields coherent solution. >> >>X+1. No Heavy Configuration on Routers >> >>It is undesirable to have long or very detailed configuration on the >>routers, especially it needs to be synchronized on all of them. >>Long configuration makes operating the device more difficult, and >>having to do very detailed configuration may hinder the adoption of >>the security solution; it should be possible to "just start using >>it" if possible. I agree that it is desirable to minimize the additional configuration that a router will require for security purposes. On the other hand, auto-configuration is not likely to be a realistic option here, just as it has not been achieved in any context where secure, externally-imposed identification is required. Also, depending on the availability of configuration tools, even very detailed configuration data may be manageable, especially if that data is derivable from other data already used for router config. >>... >>==> you only discuss UPDATEs; you should also mention WITHDRAWs. >>Regardless of whether it's UPDATE or WITHDRAW, you should also >>consider the impact of delaying legitimate routing update (e.g., the >>path went down and the packets will be discarded unless a new path >>is selected ASAP). Explicit route withdrawal is effected through an UPDATE message, so I am a bit puzzled by your comment here. >... > >> Transport protection is an important aspect of BGP routing >> protocol security. The potential to create a linked >> transport/NLRI/AS_PATH authentication mechanism should not be >> overlooked and may provide for the accelerated deployment of a BGP >> security system. Current security mechanisms for BGP transport >> (e.g. TCP-MD5 [4] and GTSM [6]) are inadequate and require >> significant operator interaction to maintain a respectable level >> of security. >>... >> Any proposed security mechanism MUST include provisions for securing >> both internal BGP and external BGP peering sessions. >> >>==> this is not accurate; TCP-MD5 and GTSM are very well adequate. >>That is, TCPMD5 is not adequate in several ways. The specific crypto method employed is poor, relative to modern techniques. Also the lack of automated key management makes it likely that the keys are rarely changed and thus increasingly vulnerable. >> >>1) iBGP sessions are prevented if the AS applies source address >>spoofing prevention (or alternatively, blocks access to the select >>parts of the infrastructure components) at its borders; there is no >>need to use TCP-MD5 or GTSM. "iBGP session are prevented?" what does that mean in this context? >> >>2) eBGP sessions are protected using GTSM when the peer(s) are >>sufficiently trustable. this statement ignores the possibility of active wiretapping, so it is not just the peers that need to be trusted, it is also the communication media context. >>That leaves only the case when the peering mesh is not >>point-to-point, i.e., ethernet-based internet exchanges. TCP-MD5 is >>typically used there to protect from session resets by other members >>of the exchange. The operational pain of TCP-MD5 comes from having >>to agree on static keys on a per-peer basis, but the situation may >>not be much better in terms of config required in any solution. not true. if, for example, one were to use IPsec and IKE, then each router would have to be configured with one cert, not one secret key per peer. >>There are still ICMP attacks to consider >>(draft-gont-tcpm-icmp-attacks-05.txt) but IPsec does not protect >>from those by better. IPsec offers specific access control measures for dealing with ICMP traffic, so I am not sure what you mean here. >>.... >> >> Key maintenance can be especially onerous for operators. The >> number of keys required and the maintenance of keys >> (update/withdraw/renew) has had an additive effect as a barrier to >> deployment. Thus automated means of managing keys, to reduce >> operational burdens, MUST be available throughout BGP security >> systems. These security systems MUST be resistant to compromise >> of session-level or device-level keys, i.e., the security >> implications of such compromises MUST be limited. >> >>==> what are (update/withdraw/renew) keys? These are not separate >>keys. Just one key is required. > >These are actions which one might do with keys. I'll re-word so that >they don't appear to use the same nomenclature as BGP actions. >Now it reads ..."(issue/revoke/renew)...". I agree with Pekka that the wording above is confusing. > >>==> it might be worth separating the discussion of transport >>protection keys and the route origination (etc.) keys. These are >>two very different animals with very different security properties. >>For the former, the MUST requirement is way too strong, as you can >>only reset one peering session (and even that only if you get on the >>link) -- hardly a huge problem. > >Well, if we just keep on using TCP-MD5 and re-use keys in multiple >places, the implications of compromise can be more widespread. I agree with Pekka that we need to discuss keys used for point-to-point session protection separately from keys used for transitive route (UPDATE) protection. In a detailed sense, the former will usually be symmetric keys, perhaps derived from a DH exchange, but in any case of only local significance. The latter are probably asymmetric key pairs with global significance. >... >> Specifications state that the AS routing graph MUST be loop >> free. This indicates that UPDATES received from an external >> peer which contain the local AS will be rejected. >> >>==> on idr list, maybe about a year ago, this topic came up, and at >>least some people seemed to think that such routes need not be >>rejected, but it is sufficient that they are of lower preference >>than anything else. The "valid" case for these was during certain >>network partitions. Not that I personally bought it, but that's a >>separate story.... the current BGP spec (in the RFC editor's queue) does not relax the loop-free requirement, so I think it still belongs here. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 11 14:37:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewlmf-00071B-Va; Wed, 11 Jan 2006 14:37:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewlmd-0006zm-II for rpsec@megatron.ietf.org; Wed, 11 Jan 2006 14:37:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05826 for ; Wed, 11 Jan 2006 14:36:02 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewlta-000579-PT for rpsec@ietf.org; Wed, 11 Jan 2006 14:44:35 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0BJapYG010284; Wed, 11 Jan 2006 21:36:51 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0BJakbj010281; Wed, 11 Jan 2006 21:36:51 +0200 Date: Wed, 11 Jan 2006 21:36:46 +0200 (EET) From: Pekka Savola To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1237/Tue Jan 10 17:53:20 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Wed, 11 Jan 2006, Stephen Kent wrote: >>> >>> X. No Heavy Processing on Routers >>> >>> Having specialized hardware to deal with cryptography in order to >>> get acceptable processing speed is unacceptable in general. The >>> solution cannot be deployed if it requires significant financial >>> investment. > > In what time frame? If we said that no changes that require "significant" > financial investments can ever be made, then we would have to declare many > changes, security or otherwise, to be unacceptable. One could rephrase, ".. investment that would not be otherwise required." Routers do get replaced with newer versions over time for various reasons, and if the newer versions support cryptography to sufficient degree out to the box without significant extra investment compared to non-cryptographic hardware, that's fine. We just shouldn't be requiring fork-lift upgrades to get crypto. >>> In particular, the solution must not require that heavy processing >>> is required on all the BGP routers. Even heavy processing on all >>> routers originating a prefix seems very undesirable, as well as >>> requiring such in all eBGP routers. Thus, requiring heavy >>> processing in anything except separate network components or one or >>> two routers would strongly discourage deployment. > > "heavy processing" is a vague term. I realize that it's hard to be precise > when discussing these issues, but vague wording only leads to later > arguments. Also, different ISPs probably have deployed different routers for > eBGP, so what may be heavy processing for one ISP may not be for another, or > may not be for a different eBGP router within the same ISP. All this is very true, of course. But I'm not sure if we could draw up precise requirements .. the only way I can personally see here is leave it somewhat vague and when we're evaluating the solution(s) as a whole (considering all the requirements) make a decision whether it seems too heavy or not given the processing power situation at that point in time. Maybe some metrics could be included, but I fear that would be a nice rathole for lengthy and oft-revised discussions if we did so.. >>> On the other hand, while "low processing on routers" security model >>> must be supported, it would be acceptable to have extensions for the >>> "basic" support, which could be locally deployed by those parties >>> which find it necessary or economically justifiable. > > This notion sounds attractive in the abstract, but there is no indication > that it is achievable, at the level of abstraction used to describe it. > Routing security is a distributed function. While we all agree that > incremental deployment is a requirement, it is not clear that support of > different security "models" by different ISPs yields coherent solution. Certainly, I'm doubtful that any reasonable solution could fulfill all the requirements we place forward (because then it would be too complex ;-), therefore I'd like to call them "goals" and try to make it clear enough which ones are more important than others. I'm rather sure that solutions for the aforementioned model could exist though -- the question just is which current requirements would need to be bent to accommodate that. We just don't know this before we know this direction has been suitably well explored. >>> X+1. No Heavy Configuration on Routers >>> >>> It is undesirable to have long or very detailed configuration on the >>> routers, especially it needs to be synchronized on all of them. >>> Long configuration makes operating the device more difficult, and >>> having to do very detailed configuration may hinder the adoption of >>> the security solution; it should be possible to "just start using >>> it" if possible. > > I agree that it is desirable to minimize the additional > configuration that a router will require for security purposes. On > the other hand, auto-configuration is not likely to be a realistic > option here, just as it has not been achieved in any context where > secure, externally-imposed identification is required. Also, > depending on the availability of configuration tools, even very > detailed configuration data may be manageable, especially if that > data is derivable from other data already used for router config. I agree that it's unfeasible to look for complete auto-configuration. Maybe the last sentence could be toned down a bit -- e.g., by removing everything after ";" or rewording it in some way to not be over-optimistic. I just want to avoid the situation where a lot of configuration (like over a couple of dozen of lines, multiplied by the number of routers) would need to be maintained, especially if the information is highly dynamic. Analogue: a reason why RPS hasn't been easily deployable is that the prefix list (or even AS path list) config on routers takes hundreds, thousands or tens of thousands of lines of config and is highly dynamic. We don't want to go anywhere near that kind of situation. >>> ... >>> ==> you only discuss UPDATEs; you should also mention WITHDRAWs. >>> Regardless of whether it's UPDATE or WITHDRAW, you should also >>> consider the impact of delaying legitimate routing update (e.g., the >>> path went down and the packets will be discarded unless a new path >>> is selected ASAP). > > Explicit route withdrawal is effected through an UPDATE message, so I am a > bit puzzled by your comment here. True, apparently I was confused here, and was thinking too much ahead of "BGP Update - Withdraw" vs "BGP Update - advertise the next best path". >> ... >> >>> Transport protection is an important aspect of BGP routing >>> protocol security. The potential to create a linked >>> transport/NLRI/AS_PATH authentication mechanism should not be >>> overlooked and may provide for the accelerated deployment of a BGP >>> security system. Current security mechanisms for BGP transport >>> (e.g. TCP-MD5 [4] and GTSM [6]) are inadequate and require >>> significant operator interaction to maintain a respectable level >>> of security. >>> ... >>> Any proposed security mechanism MUST include provisions for securing >>> both internal BGP and external BGP peering sessions. >>> >>> ==> this is not accurate; TCP-MD5 and GTSM are very well adequate. >>> That is, > > TCPMD5 is not adequate in several ways. The specific crypto method employed > is poor, relative to modern techniques. Also the lack of automated key > management makes it likely that the keys are rarely changed and thus > increasingly vulnerable. This depends a lot on your trust model, as discussed below. Maybe this needs to be spelled out better, so the readers can make their own judgment based on their own assumptions. >>> 1) iBGP sessions are prevented if the AS applies source address >>> spoofing prevention (or alternatively, blocks access to the select >>> parts of the infrastructure components) at its borders; there is no >>> need to use TCP-MD5 or GTSM. > > "iBGP session are prevented?" what does that mean in this context? _Disrupting_ iBGP sessions, sorry that I missed the word :) >>> 2) eBGP sessions are protected using GTSM when the peer(s) are >>> sufficiently trustable. > > this statement ignores the possibility of active wiretapping, so it is not > just the peers that need to be trusted, it is also the communication media > context. Correct, but this depends a lot on your trust model. I don't consider this a major threat in our network for example. If lower layer attacks are deemed to be a problem, I think most attacks can be carried out much more easily without BGP at all just. In any case, maybe it would make sense to try to break out the text a bit depending on what kind of threat model you have beyond BGP. (It's obvious that there are easy solutions to this problem, but my point is that many people may not want to mandate them because they don't see the point.) >>> That leaves only the case when the peering mesh is not >>> point-to-point, i.e., ethernet-based internet exchanges. TCP-MD5 is >>> typically used there to protect from session resets by other members >>> of the exchange. The operational pain of TCP-MD5 comes from having >>> to agree on static keys on a per-peer basis, but the situation may >>> not be much better in terms of config required in any solution. > > not true. if, for example, one were to use IPsec and IKE, then each router > would have to be configured with one cert, not one secret key per peer. One cert would be enough for your own routers. What about N peer routers in other administrative domain which you have BGP session to? Would you also need to certify those under that cert? >>> There are still ICMP attacks to consider >>> (draft-gont-tcpm-icmp-attacks-05.txt) but IPsec does not protect >>> from those by better. > > IPsec offers specific access control measures for dealing with ICMP traffic, > so I am not sure what you mean here. Valid ICMP messages can be originated by parties which you don't share security associations with. IPsec does not deal with this situation very well. AFAICT, it's either "ignore everything that you haven't established an SA for" (which I argue is unrealistic in most scenarios) or accept everything. >> ... >>> Specifications state that the AS routing graph MUST be loop >>> free. This indicates that UPDATES received from an external >>> peer which contain the local AS will be rejected. >>> >>> ==> on idr list, maybe about a year ago, this topic came up, and at >>> least some people seemed to think that such routes need not be >>> rejected, but it is sufficient that they are of lower preference >>> than anything else. The "valid" case for these was during certain >>> network partitions. Not that I personally bought it, but that's a >>> separate story.... > > the current BGP spec (in the RFC editor's queue) does not relax the loop-free > requirement, so I think it still belongs here. Agreed. (It seems the new BGP spec strengthened the language around this, so now section 9.1.2 forbids considering these routes. In RFC1771, this was described in section 9.3 in a more liberal manner like I mention above.) -- 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 Wed Jan 11 18:24:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwpKm-0003GI-SS; Wed, 11 Jan 2006 18:24:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwpKl-0003GD-Pg for rpsec@megatron.ietf.org; Wed, 11 Jan 2006 18:24:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23635 for ; Wed, 11 Jan 2006 18:23:31 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwpRk-00049L-PK for rpsec@ietf.org; Wed, 11 Jan 2006 18:32:06 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0BNOOIE002066; Wed, 11 Jan 2006 18:24:26 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 11 Jan 2006 18:24:22 -0500 To: Pekka Savola From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Pekka, >>... > >One could rephrase, ".. investment that would not be otherwise required." > >Routers do get replaced with newer versions over time for various >reasons, and if the newer versions support cryptography to >sufficient degree out to the box without significant extra >investment compared to non-cryptographic hardware, that's fine. We >just shouldn't be requiring fork-lift upgrades to get crypto. I understand your reasoning, but even this seems tricky. What if some routers can support crypto using software because the UPDATE frequency is low enough for where they are used, but other routers cannot? Is the criteria that if any router anywhere in the Internet has to be replaced in order support a proposed security technology then that technology is unsuitable? >>... > >All this is very true, of course. But I'm not sure if we could draw >up precise requirements .. the only way I can personally see here is >leave it somewhat vague and when we're evaluating the solution(s) as >a whole (considering all the requirements) make a decision whether >it seems too heavy or not given the processing power situation at >that point in time. > >Maybe some metrics could be included, but I fear that would be a >nice rathole for lengthy and oft-revised discussions if we did so.. yes, I think this is hard to quantify. by making it a (vague) requirement we create a basis for endless debate :-) > >>>>On the other hand, while "low processing on routers" security model >>>>must be supported, it would be acceptable to have extensions for the >>>>"basic" support, which could be locally deployed by those parties >>>>which find it necessary or economically justifiable. >> >>This notion sounds attractive in the abstract, but there is no >>indication that it is achievable, at the level of abstraction used >>to describe it. Routing security is a distributed function. While >>we all agree that incremental deployment is a requirement, it is >>not clear that support of different security "models" by different >>ISPs yields coherent solution. > >Certainly, I'm doubtful that any reasonable solution could fulfill >all the requirements we place forward (because then it would be too >complex ;-), therefore I'd like to call them "goals" and try to make >it clear enough which ones are more important than others. I think it does make sense to distinguish between goals and requirements when we agree on which things fall into which category. >>... > >I agree that it's unfeasible to look for complete >auto-configuration. Maybe the last sentence could be toned down a >bit -- e.g., by removing everything after ";" or rewording it in >some way to not be over-optimistic. > >I just want to avoid the situation where a lot of configuration >(like over a couple of dozen of lines, multiplied by the number of >routers) would need to be maintained, especially if the information >is highly dynamic. agreed. config info needs to be "manageable" and that requires paying attention to what is fairly static and what changes often. >Analogue: a reason why RPS hasn't been easily deployable is that the >prefix list (or even AS path list) config on routers takes hundreds, >thousands or tens of thousands of lines of config and is highly >dynamic. We don't want to go anywhere near that kind of situation. good example. >>... > >True, apparently I was confused here, and was thinking too much >ahead of "BGP Update - Withdraw" vs "BGP Update - advertise the next >best path". OK. >>... > >This depends a lot on your trust model, as discussed below. Maybe >this needs to be spelled out better, so the readers can make their >own judgment based on their own assumptions. I personally hate the term "trust model" in general, and in this case it's not applicable. the issue is the threat model, i.e., what do you believe your adversaries want to accomplish and what attacks are they capable of launching to achieve their goals. >... >Correct, but this depends a lot on your trust model. I don't >consider this a major threat in our network for example. If lower >layer attacks are deemed to be a problem, I think most attacks can >be carried out much more easily without BGP at all just. > >In any case, maybe it would make sense to try to break out the text >a bit depending on what kind of threat model you have beyond BGP. right, threat model, not trust model. >>... > >One cert would be enough for your own routers. What about N peer >routers in other administrative domain which you have BGP session >to? Would you also need to certify those under that cert? you would not certify routers with which you peer. you validate their certs, which they can pass to you, or which are download to you by your NOC. for example, if one uses IPsec for session security, IKE typically passes certs at the time of security association establishment, to allow each peer to authenticate the identity of the other. In this context it is probably less important to know a router's ID in an authentic fashion, and more important to know what AS is represents (getting back to your minimizing config info point). >>... > >Valid ICMP messages can be originated by parties which you don't >share security associations with. IPsec does not deal with this >situation very well. AFAICT, it's either "ignore everything that >you haven't established an SA for" (which I argue is unrealistic in >most scenarios) or accept everything. Not quite true. IPsec (as of RFC 4301) has special provisions for ICMP, especially ICMP error messages. >... > >(It seems the new BGP spec strengthened the language around this, so >now section 9.1.2 forbids considering these routes. In RFC1771, >this was described in section 9.3 in a more liberal manner like I >mention above.) > OK. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 11 19:45:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewqaf-0003ZU-Vb; Wed, 11 Jan 2006 19:45:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewqad-0003Z4-1B for rpsec@megatron.ietf.org; Wed, 11 Jan 2006 19:45:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00938 for ; Wed, 11 Jan 2006 19:43:58 -0500 (EST) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewqhd-0007GG-2k for rpsec@ietf.org; Wed, 11 Jan 2006 19:52:33 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 11 Jan 2006 16:44:53 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id C36F867420; Wed, 11 Jan 2006 16:44:53 -0800 (PST) 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.5.6-GR) with ESMTP id CQU57088; Wed, 11 Jan 2006 16:43:10 -0800 (PST) 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 9E5F420501; Wed, 11 Jan 2006 16:43:10 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Date: Wed, 11 Jan 2006 16:43:11 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B362A8B10@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Thread-Index: AcYXBoaI0OeRk5GbTeyUk5iQvShYJwACjpdQ From: "Bora Akyol" To: "Pekka Savola" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006011109; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230342E34334335413538382E303030332D452D5046786C33494E497A33445631553653544639524F673D3D; ENG=IBF; TS=20060112004455; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006011109_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FDB790F11C2467269-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org I think we need to define what constitutes an unreasonably heavy load in terms of a load metric (as in queueing theory). I presume a simple definition of offered load vs goodput may suffice. If the router BGP processing goodput drops significantly due to added crypto load, then this constitutes a "heavy load" IMHO. As far as built-in crypto in router CPUs, there are already several chips on the market from many vendors available, so it is just a matter of the box builder putting this in the router. Bora > -----Original Message----- > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org]=20 > On Behalf Of Stephen Kent > Sent: Wednesday, January 11, 2006 3:24 PM > To: Pekka Savola > Cc: rpsec@ietf.org; Tony Tauber > Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 >=20 > Pekka, >=20 > >>... > > > >One could rephrase, ".. investment that would not be=20 > otherwise required." > > > >Routers do get replaced with newer versions over time for various=20 > >reasons, and if the newer versions support cryptography to=20 > sufficient=20 > >degree out to the box without significant extra investment=20 > compared to=20 > >non-cryptographic hardware, that's fine. We just shouldn't be=20 > >requiring fork-lift upgrades to get crypto. >=20 > I understand your reasoning, but even this seems tricky. What=20 > if some routers can support crypto using software because the=20 > UPDATE frequency is low enough for where they are used, but=20 > other routers cannot? Is the criteria that if any router=20 > anywhere in the Internet has to be replaced in order support=20 > a proposed security technology then that technology is unsuitable? >=20 > >>... > > > >All this is very true, of course. But I'm not sure if we=20 > could draw up=20 > >precise requirements .. the only way I can personally see=20 > here is leave=20 > >it somewhat vague and when we're evaluating the solution(s)=20 > as a whole=20 > >(considering all the requirements) make a decision whether=20 > it seems too=20 > >heavy or not given the processing power situation at that point in=20 > >time. > > > >Maybe some metrics could be included, but I fear that would=20 > be a nice=20 > >rathole for lengthy and oft-revised discussions if we did so.. >=20 > yes, I think this is hard to quantify. by making it a (vague)=20 > requirement we create a basis for endless debate :-) >=20 > > > >>>>On the other hand, while "low processing on routers"=20 > security model=20 > >>>>must be supported, it would be acceptable to have=20 > extensions for the=20 > >>>>"basic" support, which could be locally deployed by those parties=20 > >>>>which find it necessary or economically justifiable. > >> > >>This notion sounds attractive in the abstract, but there is no=20 > >>indication that it is achievable, at the level of=20 > abstraction used to=20 > >>describe it. Routing security is a distributed function.=20 > While we all=20 > >>agree that incremental deployment is a requirement, it is not clear=20 > >>that support of different security "models" by different=20 > ISPs yields=20 > >>coherent solution. > > > >Certainly, I'm doubtful that any reasonable solution could=20 > fulfill all=20 > >the requirements we place forward (because then it would be=20 > too complex=20 > >;-), therefore I'd like to call them "goals" and try to make=20 > it clear=20 > >enough which ones are more important than others. >=20 > I think it does make sense to distinguish between goals and=20 > requirements when we agree on which things fall into which category. >=20 > >>... > > > >I agree that it's unfeasible to look for complete=20 > auto-configuration.=20 > >Maybe the last sentence could be toned down a bit -- e.g.,=20 > by removing=20 > >everything after ";" or rewording it in some way to not be=20 > >over-optimistic. > > > >I just want to avoid the situation where a lot of=20 > configuration (like=20 > >over a couple of dozen of lines, multiplied by the number of > >routers) would need to be maintained, especially if the=20 > information is=20 > >highly dynamic. >=20 > agreed. config info needs to be "manageable" and that=20 > requires paying attention to what is fairly static and what=20 > changes often. >=20 > >Analogue: a reason why RPS hasn't been easily deployable is that the=20 > >prefix list (or even AS path list) config on routers takes hundreds,=20 > >thousands or tens of thousands of lines of config and is highly=20 > >dynamic. We don't want to go anywhere near that kind of situation. >=20 > good example. >=20 > >>... > > > >True, apparently I was confused here, and was thinking too=20 > much ahead=20 > >of "BGP Update - Withdraw" vs "BGP Update - advertise the next best=20 > >path". >=20 > OK. >=20 > >>... > > > >This depends a lot on your trust model, as discussed below. =20 > Maybe this=20 > >needs to be spelled out better, so the readers can make their own=20 > >judgment based on their own assumptions. >=20 > I personally hate the term "trust model" in general, and in=20 > this case it's not applicable. the issue is the threat model,=20 > i.e., what do you believe your adversaries want to accomplish=20 > and what attacks are they capable of launching to achieve their goals. >=20 > >... > >Correct, but this depends a lot on your trust model. I don't=20 > consider=20 > >this a major threat in our network for example. If lower=20 > layer attacks=20 > >are deemed to be a problem, I think most attacks can be carried out=20 > >much more easily without BGP at all just. > > > >In any case, maybe it would make sense to try to break out=20 > the text a=20 > >bit depending on what kind of threat model you have beyond BGP. >=20 > right, threat model, not trust model. >=20 > >>... > > > >One cert would be enough for your own routers. What about N peer=20 > >routers in other administrative domain which you have BGP=20 > session to?=20 > >Would you also need to certify those under that cert? >=20 > you would not certify routers with which you peer. you=20 > validate their certs, which they can pass to you, or which=20 > are download to you by your NOC. for example, if one uses=20 > IPsec for session security, IKE typically passes certs at the=20 > time of security association establishment, to allow each=20 > peer to authenticate the identity of the other. In this=20 > context it is probably less important to know a router's ID=20 > in an authentic fashion, and more important to know what AS=20 > is represents (getting back to your minimizing config info point). >=20 > >>... > > > >Valid ICMP messages can be originated by parties which you=20 > don't share=20 > >security associations with. IPsec does not deal with this situation=20 > >very well. AFAICT, it's either "ignore everything that you haven't=20 > >established an SA for" (which I argue is unrealistic in most=20 > scenarios)=20 > >or accept everything. >=20 > Not quite true. IPsec (as of RFC 4301) has special provisions=20 > for ICMP, especially ICMP error messages. >=20 > >... > > > >(It seems the new BGP spec strengthened the language around this, so=20 > >now section 9.1.2 forbids considering these routes. In=20 > RFC1771, this=20 > >was described in section 9.3 in a more liberal manner like I mention=20 > >above.) > > >=20 > OK. >=20 > Steve >=20 > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec >=20 >=20 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 12 08:20:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex2Ns-0003bq-HY; Thu, 12 Jan 2006 08:20:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex2Nq-0003XK-5G for rpsec@megatron.ietf.org; Thu, 12 Jan 2006 08:20:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17034 for ; Thu, 12 Jan 2006 08:19:33 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex2Uv-0003gC-Hl for rpsec@ietf.org; Thu, 12 Jan 2006 08:28:15 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Jan 2006 05:20:43 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,360,1131350400"; d="scan'208"; a="19583827:sNHT27739908" Received: from RussPC (rtp-vpn2-211.cisco.com [10.82.240.211]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0CDKd6I024223; Thu, 12 Jan 2006 08:20:40 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 12 Jan 2006 08:20:38 -0500 X-PGP-Universal: processed; by RussPC on Thu, 12 Jan 2006 08:20:38 -0500 Message-ID: <43C6579F.3070509@cisco.com> Date: Thu, 12 Jan 2006 08:20:31 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> Having specialized hardware to deal with cryptography in order to >>> get acceptable processing speed is unacceptable in general. The >>> solution cannot be deployed if it requires significant financial >>> investment. > In what time frame? If we said that no changes that require > "significant" financial investments can ever be made, then we would have > to declare many changes, security or otherwise, to be unacceptable. Typical rollout time, today, is about 7 years, for any new equipment. I believe that time is getting longer, however, and we will probably see times in the ten to fifteen year range in the next 7 years--in other words, I suspect that at least some of the equipment currently running for three to four years will not be replaced until 8 to 9 years from now. As for the remainder--I don't know how to define "low processing requirements" and "high processing requirements." I tend to prefer the wording "should be able to process on existing midrange equipment, or offloaded to some outside box," myself. But, for some reason, I seem to remember the WG rejecting "offloading" at some point. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8ZXphEdu7FIVPTkEQISIQCfXI33+1nIfslj/kEqMpQRlt+l8ewAoKxZ iamrhJaDzqaS9werJ3ej3/UJ =/fd0 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 12 08:22:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex2Pq-0004Cp-N4; Thu, 12 Jan 2006 08:22:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex2Pp-0004Cc-0o for rpsec@megatron.ietf.org; Thu, 12 Jan 2006 08:22:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17142 for ; Thu, 12 Jan 2006 08:21:35 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex2Wv-0003jO-B5 for rpsec@ietf.org; Thu, 12 Jan 2006 08:30:18 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Jan 2006 05:22:47 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,360,1131350400"; d="scan'208"; a="19583974:sNHT22036048" Received: from RussPC (rtp-vpn2-211.cisco.com [10.82.240.211]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0CDMh6I024566; Thu, 12 Jan 2006 08:22:44 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 12 Jan 2006 08:22:42 -0500 X-PGP-Universal: processed; by RussPC on Thu, 12 Jan 2006 08:22:42 -0500 Message-ID: <43C6581B.9000000@cisco.com> Date: Thu, 12 Jan 2006 08:22:35 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] Charter Update References: <438F3F9F.30907@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for taking so long to get back to this.... Normal workflow nonsense. :-) > I think the charter text looks OK, although the introductory sentence of > you message had an amusing "s" -> "d: typo :-). :-) > One comment about your suggestion for an additional work item: > > "Mar 06 Submit initial document discussing requirements for peering > relationship authorization and authentication mechanisms." > > I think it would be appropriate to focus on the authentication and > integrity requirements here, rather than authorization. Presumably any > authorization concerns can be addressed by using the authentication data > for lookup in a local database, the exact nature of which might not > require standardization. But, if other folks think the authorization > aspects of these peering relationships should be in scope, I'm OK with > that too. Anyone else have an opinion? I'm fine with either wording, so we should just make certain we don't get some sort of "strong objection" from the rest of the list (?). :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8ZYIhEdu7FIVPTkEQK4/ACgjmSdagWv4xq3HdefX6oDiWdn6s4AoPac coFFW1swzbg+SePMtHYJjO5N =FIB3 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 12 10:00:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex3wJ-0004ZJ-QL; Thu, 12 Jan 2006 10:00:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex3wI-0004ZD-Nb for rpsec@megatron.ietf.org; Thu, 12 Jan 2006 10:00:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22994 for ; Thu, 12 Jan 2006 09:59:13 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex43O-0006bY-PZ for rpsec@ietf.org; Thu, 12 Jan 2006 10:07:57 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 8072218E2; Thu, 12 Jan 2006 15:00:05 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 174kaLPac0047Mo2; Thu, 12 Jan 2006 15:00:03 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 171kaLPaa0047Mo2; Thu, 12 Jan 2006 15:00:00 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Thu, 12 Jan 2006 15:00:00 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID792kaLPaa4993Xo2 Received: from localhost ([65.247.36.31]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 07:59:57 -0700 Date: Thu, 12 Jan 2006 09:59:57 -0500 From: Jeffrey Haas To: Russ White Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Message-ID: <20060112145957.GP22020@nexthop.com> References: <43C6579F.3070509@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43C6579F.3070509@cisco.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 12 Jan 2006 14:59:57.0955 (UTC) FILETIME=[DABE8D30:01C61788] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: rpsec@ietf.org, Tony Tauber , Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Thu, Jan 12, 2006 at 08:20:31AM -0500, Russ White wrote: > But, for some reason, I seem to > remember the WG rejecting "offloading" at some point. I don't actually remember that. For some types of operations, I think it is an interesting idea. > Russ -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jan 15 10:29:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9ii-0004FG-PI; Sun, 15 Jan 2006 10:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9ih-0004EF-24 for rpsec@megatron.ietf.org; Sun, 15 Jan 2006 10:23:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04902 for ; Sun, 15 Jan 2006 10:21:38 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ey5oZ-0002wO-M7 for rpsec@ietf.org; Sun, 15 Jan 2006 06:12:52 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0FB4NYG000369; Sun, 15 Jan 2006 13:04:23 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0FB4MYG000366; Sun, 15 Jan 2006 13:04:22 +0200 Date: Sun, 15 Jan 2006 13:04:22 +0200 (EET) From: Pekka Savola To: Russ White Subject: Re: [RPSEC] Charter Update In-Reply-To: <43C6581B.9000000@cisco.com> Message-ID: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1242/Sun Jan 15 02:00:41 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org I wasn't participating in earlier, but I didn't find more information in the archives, so.. First off, could you clarify a bit what you mean by "requirements for peering relationship authorization and authentication mechanisms" in practice? Which layer(s) are we talking about -- anything from L1 to L9, or..? For example, are the administrative processes for establishing peering relationship in scope? It'd very useful if you could expand on this a bit as I think there hasn't been a personal I-D to look at yet. Nonetheless, a few doubts about adding integrity below. On Thu, 12 Jan 2006, Russ White wrote: >> One comment about your suggestion for an additional work item: >> >> "Mar 06 Submit initial document discussing requirements for peering >> relationship authorization and authentication mechanisms." >> >> I think it would be appropriate to focus on the authentication and >> integrity requirements here, rather than authorization. Presumably any >> authorization concerns can be addressed by using the authentication data >> for lookup in a local database, the exact nature of which might not >> require standardization. But, if other folks think the authorization >> aspects of these peering relationships should be in scope, I'm OK with >> that too. > > Anyone else have an opinion? I'm fine with either wording, so we should > just make certain we don't get some sort of "strong objection" from the > rest of the list (?). I'm a bit hesitant to make this change, at least without additional qualifiers. That is, authorization/authentication of peering relationship tries to answer the questions, like "which prefixes are you allowed to advertise on a session?" and "how do I know who you are?" On the other hand, integrity would change the focus the question on "how do you ensure that the advertisement received is the same as the one sent?" Ensuring integrity seems to mainly give the benefit to the advertiser *). Auth* give significant benefit to the receiver. In my opinion, these solutions seem sufficiently different that the requirements may be very different. Different folks require one but not necessarily the other. These approaches should not be fate-sharing -- as an operator, I'm not so worried about integrity at this point (though I wouldn't mind getting it if I wouldn't need to make significant compromises in other tradeoffs). *) that's because the receiver just processes the information it receives: if a MITM attacker removed a prefix, the receiver wouldn't care and would just route to that prefix via a different path; if a MITM attacker added a prefix, the receiver would just discard the added prefix as non-authorized. -- 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 Sun Jan 15 11:49:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyB4C-0005Uo-NL; Sun, 15 Jan 2006 11:49:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyB1x-0004b6-VA for rpsec@megatron.ietf.org; Sun, 15 Jan 2006 11:47:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06402 for ; Sun, 15 Jan 2006 11:45:23 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyB9F-0006yF-Bn for rpsec@ietf.org; Sun, 15 Jan 2006 11:54:34 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0FGjkYG007888; Sun, 15 Jan 2006 18:45:46 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0FGjdj5007885; Sun, 15 Jan 2006 18:45:41 +0200 Date: Sun, 15 Jan 2006 18:45:39 +0200 (EET) From: Pekka Savola To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1242/Sun Jan 15 02:00:41 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org (I have cut off parts inline where I we agree or otherwise I don't think more needs to be said.) On Wed, 11 Jan 2006, Stephen Kent wrote: >> One could rephrase, ".. investment that would not be otherwise required." >> >> Routers do get replaced with newer versions over time for various reasons, >> and if the newer versions support cryptography to sufficient degree out to >> the box without significant extra investment compared to non-cryptographic >> hardware, that's fine. We just shouldn't be requiring fork-lift upgrades >> to get crypto. > > I understand your reasoning, but even this seems tricky. What if some routers > can support crypto using software because the UPDATE frequency is low enough > for where they are used, but other routers cannot? Is the criteria that if > any router anywhere in the Internet has to be replaced in order support a > proposed security technology then that technology is unsuitable? This would need to be left as a judgment call when evaluating the tradeoffs a solution makes, I think. FWIW, it's clear that in some topologies, (e.g., when talking about the number of prefixes in hundreds), S/W approaches would be acceptable, but in most of those scenarios, the existing mechanisms (e.g., prefix filtering) are also applicable. UPDATE frequency as such doesn't help much. You need to consider the protential update frequency -- e.g., what would happen if the session was reset or flapping and basically all the prefixes would need to be processed at once one or more times. So, if you think that'd help, one could rephrase this for example as follows: ======= X. No Heavy Processing on Routers Having specialized hardware to deal with cryptography in order to get acceptable processing speed is unacceptable in general. The solution cannot be deployed if it requires significant financial investment that would not be otherwise required. While software mechanisms may be sufficient when the number of prefixes a router needs to process is not much higher than O(100), it's unprobable that such approaches could scale with richer interconnection of at least O(10,000) prefixes. ======= >>> ... >> >> All this is very true, of course. But I'm not sure if we could draw up >> precise requirements .. the only way I can personally see here is leave it >> somewhat vague and when we're evaluating the solution(s) as a whole >> (considering all the requirements) make a decision whether it seems too >> heavy or not given the processing power situation at that point in time. >> >> Maybe some metrics could be included, but I fear that would be a nice >> rathole for lengthy and oft-revised discussions if we did so.. > > yes, I think this is hard to quantify. by making it a (vague) requirement we > create a basis for endless debate :-) Endless debate will ensue in any case if the group(s) cannot get to rough consensus. If the group can, this shouldn't be too big a problem. I'm more concerned about an endless debate that could ensue from trying to fine-tune the metrics :) >> I agree that it's unfeasible to look for complete auto-configuration. Maybe >> the last sentence could be toned down a bit -- e.g., by removing everything >> after ";" or rewording it in some way to not be over-optimistic. >> >> I just want to avoid the situation where a lot of configuration (like over >> a couple of dozen of lines, multiplied by the number of routers) would need >> to be maintained, especially if the information is highly dynamic. > > agreed. config info needs to be "manageable" and that requires paying > attention to what is fairly static and what changes often. No disagreement here. Maybe some of that should be reflected in the text somehow. >>> ... >> >> One cert would be enough for your own routers. What about N peer routers >> in other administrative domain which you have BGP session to? Would you >> also need to certify those under that cert? > > you would not certify routers with which you peer. you validate their certs, > which they can pass to you, or which are download to you by your NOC. for > example, if one uses IPsec for session security, IKE typically passes certs > at the time of security association establishment, to allow each peer to > authenticate the identity of the other. In this context it is probably less > important to know a router's ID in an authentic fashion, and more important > to know what AS is represents (getting back to your minimizing config info > point). But assuming you don't have a common trust anchor with your and all your peers' certificates, you'll need to keep at least some (local) data on which certs you find acceptable. I don't know well enough what's needed, whether there would be issues with rollovers, whether you'd need deal with CRL-like situations, etc. -- but with N peers (where N is a non-trivial number), this seems somewhat comparable administrative complexity to managing TCP-MD5 keys if the MD5 keys are never changed. I'd like to emphasize that I wouldn't want to keep that information on the routers, at least if the operator doesn't want to do that. AFAICT, you'll need to set up something on a per-peer basis. >>> ... >> >> Valid ICMP messages can be originated by parties which you don't share >> security associations with. IPsec does not deal with this situation very >> well. AFAICT, it's either "ignore everything that you haven't established >> an SA for" (which I argue is unrealistic in most scenarios) or accept >> everything. > > Not quite true. IPsec (as of RFC 4301) has special provisions for ICMP, > especially ICMP error messages. My point was that vanilla TCP and TCP-MD5 as written are almost equally vulnerable to ICMP error message attacks. Draft-gont-tcpm-icmp-attacks-05 (soon under draft-ietf-tcpm) provides methods to make them more robust. IPsec does not really seem to provide even the same level of verification of ICMP error messages as that draft. RFC 4301 mainly focuses on requiring that the implementations must have configurable options which type/code etc ICMPs to listen to and which to discard. This is my reading of section 6.1 of RFC 4301. Section 6.2 (which provides a bit more checking) doesn't seem to apply in this situation very well assuming you don't configure an ICMP SAs for all the peers and ignore other ICMP errors. Hence, I don't see how IPsec would give additional protection against ICMP errors compared to non-IPsec TCP (w/ draft-gont-tcpm-icmp-attacks-05 checks). The protection might very well be even worse by default. .... So, if you're not worried about threats on the transmission media the BGP session runs over, GTSM, draft-gont-tcpm-icmp-attacks-05, and to a lesser degree TCP-MD5 -like techniques may very well be very close to satisfying the security requirements of the peering sessions themselves. Thus the main focus should be on the authentication/authorization aspects of the contents of the advertisements. But we likely disagree on this. -- 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 Mon Jan 16 12:55:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyYa6-0006GO-AJ; Mon, 16 Jan 2006 12:55:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyYa4-0006CS-Id for rpsec@megatron.ietf.org; Mon, 16 Jan 2006 12:55:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02001 for ; Mon, 16 Jan 2006 12:54:23 -0500 (EST) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyYi1-0003UI-Ie for rpsec@ietf.org; Mon, 16 Jan 2006 13:04:02 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 16 Jan 2006 09:55:22 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 9E13B67420; Mon, 16 Jan 2006 09:55:22 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id D577B67420; Mon, 16 Jan 2006 09:55:21 -0800 (PST) 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.5.6-GR) with ESMTP id CSF28486; Mon, 16 Jan 2006 09:55:20 -0800 (PST) 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 CFB7E20502; Mon, 16 Jan 2006 09:55:20 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Date: Mon, 16 Jan 2006 09:55:20 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36306917@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Thread-Index: AcYZ9DcS5yuiavHTSr2ecUZXqLoGAwA0WgnQ From: "Bora Akyol" To: "Pekka Savola" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006011605; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230332E34334342444345362E303031312D412D; ENG=IBF; TS=20060116175523; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006011605_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FD5018041W1488318-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org I think adding a statement such as: While the network elements transition from software-based cryptographic processing to hardware-based processing, solutions that allow offload of security processing to another device may be preferred. Bora =20 > =3D=3D=3D=3D=3D=3D=3D > X. No Heavy Processing on Routers >=20 > Having specialized hardware to deal with cryptography in=20 > order to get acceptable processing speed is unacceptable in=20 > general. The solution cannot be deployed if it requires=20 > significant financial investment that would not be otherwise required. >=20 > While software mechanisms may be sufficient when the number=20 > of prefixes a router needs to process is not much higher than=20 > O(100), it's unprobable that such approaches could scale with=20 > richer interconnection of at least O(10,000) prefixes. > =3D=3D=3D=3D=3D=3D=3D > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 18 03:19:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez8X5-0005wD-SJ; Wed, 18 Jan 2006 03:19:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez8X4-0005w7-Eq for rpsec@megatron.ietf.org; Wed, 18 Jan 2006 03:19:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16438 for ; Wed, 18 Jan 2006 03:17:40 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez8fL-0007Hf-9P for rpsec@ietf.org; Wed, 18 Jan 2006 03:27:40 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1Ez8Wa-0000OY-4n; Wed, 18 Jan 2006 09:18:36 +0100 Message-ID: <43CDF9DB.6000502@schlund.net> Date: Wed, 18 Jan 2006 09:18:35 +0100 From: Stefan Mink User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [RPSEC] Charter Update References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> In-Reply-To: X-Enigmail-Version: 0.91.0.0 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org, Stephen Kent , 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: , Content-Type: multipart/mixed; boundary="===============0568534268==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0568534268== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB41FA0AF0FDA50640929FBB4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB41FA0AF0FDA50640929FBB4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Pekka, Pekka Savola wrote: > care and would just route to that prefix via a different path; if a MITM > attacker added a prefix, the receiver would just discard the added > prefix as non-authorized. this is true if there were an authorization scheme. Since there isn't one at the moment (and I don't see one coming, this issue was discussed at length), the receiver at least should be able to check, if the data was indeed received as sent (i.e. data authentication - which includes data integrity - should be used) tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigB41FA0AF0FDA50640929FBB4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDzfneehvPYvDU0roRAo4NAKDEtFc4ZSN9eaDf2BPTYzsyWo0b+QCfZZiN 4/DHxaY6oQd9JN6huo5RGrg= =rLSe -----END PGP SIGNATURE----- --------------enigB41FA0AF0FDA50640929FBB4-- --===============0568534268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0568534268==-- From rpsec-bounces@ietf.org Wed Jan 18 04:05:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez9GQ-0000XJ-Ae; Wed, 18 Jan 2006 04:05:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez9GO-0000Uo-Ds for rpsec@megatron.ietf.org; Wed, 18 Jan 2006 04:05:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20410 for ; Wed, 18 Jan 2006 04:04:30 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez9Og-0000d9-Sd for rpsec@ietf.org; Wed, 18 Jan 2006 04:14:31 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0I95SHa005834; Wed, 18 Jan 2006 11:05:28 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0I95SRa005831; Wed, 18 Jan 2006 11:05:28 +0200 Date: Wed, 18 Jan 2006 11:05:28 +0200 (EET) From: Pekka Savola To: Stefan Mink Subject: Re: [RPSEC] Charter Update In-Reply-To: <43CDF9DB.6000502@schlund.net> Message-ID: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CDF9DB.6000502@schlund.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: rpsec@ietf.org, Stephen Kent , Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Wed, 18 Jan 2006, Stefan Mink wrote: > Pekka Savola wrote: >> care and would just route to that prefix via a different path; if a MITM >> attacker added a prefix, the receiver would just discard the added >> prefix as non-authorized. > > this is true if there were an authorization scheme. Since there isn't one > at the moment (and I don't see one coming, this issue was discussed at > length), the receiver at least should be able to check, if the data > was indeed received as sent (i.e. data authentication - which includes > data integrity - should be used) If I get what you're arguing, I think this was my point. If we developed an authorization scheme, we might not necessarily need an integrity mechanism. We can't develop integrity without auth* at any rate. -- 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 Wed Jan 18 04:22:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez9Wa-0004cD-Se; Wed, 18 Jan 2006 04:22:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez9WY-0004c7-He for rpsec@megatron.ietf.org; Wed, 18 Jan 2006 04:22:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21675 for ; Wed, 18 Jan 2006 04:21:12 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.204] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ez9eo-0001Ah-Cd for rpsec@ietf.org; Wed, 18 Jan 2006 04:31:13 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1Ez9WH-0000FK-2c; Wed, 18 Jan 2006 10:22:21 +0100 Message-ID: <43CE08CC.50705@schlund.net> Date: Wed, 18 Jan 2006 10:22:20 +0100 From: Stefan Mink User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [RPSEC] Charter Update References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CDF9DB.6000502@schlund.net> In-Reply-To: X-Enigmail-Version: 0.91.0.0 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rpsec@ietf.org, Stephen Kent , 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: , Content-Type: multipart/mixed; boundary="===============1009962763==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1009962763== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBE08322BAB510A93FB699A81" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBE08322BAB510A93FB699A81 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > If I get what you're arguing, I think this was my point. If we > developed an authorization scheme, we might not necessarily need an > integrity mechanism. We can't develop integrity without auth* at any rate. exactly! My emphasize was just that the authorization issue is so much harder to solve, that I wouldn't loosen the integrity requirement at the moment. People will misunderstand and think that integrity is not an issue... tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigBE08322BAB510A93FB699A81 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDzgjPehvPYvDU0roRAlo0AJ0T72iKEnf3am1/C91kmvRB1VW8lQCgtuJB YKvUl0zJkldAT6PoLgjt+9M= =secf -----END PGP SIGNATURE----- --------------enigBE08322BAB510A93FB699A81-- --===============1009962763== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1009962763==-- From rpsec-bounces@ietf.org Wed Jan 18 10:05:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzErz-0004MN-8P; Wed, 18 Jan 2006 10:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzEry-0004MC-Me for rpsec@megatron.ietf.org; Wed, 18 Jan 2006 10:05:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21283 for ; Wed, 18 Jan 2006 10:03:40 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzF0I-00056n-A7 for rpsec@ietf.org; Wed, 18 Jan 2006 10:13:44 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0IF4hIE012821; Wed, 18 Jan 2006 10:04:44 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CDF9DB.6000502@schlund.net> Date: Wed, 18 Jan 2006 09:54:29 -0500 To: Pekka Savola From: Stephen Kent Subject: Re: [RPSEC] Charter Update X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Stefan Mink , 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: , Content-Type: multipart/mixed; boundary="===============0651760762==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org --===============0651760762== Content-Type: multipart/alternative; boundary="============_-1074525802==_ma============" --============_-1074525802==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 11:05 AM +0200 1/18/06, Pekka Savola wrote: >On Wed, 18 Jan 2006, Stefan Mink wrote: >>Pekka Savola wrote: >>>care and would just route to that prefix via a different path; if a MITM >>>attacker added a prefix, the receiver would just discard the added >>>prefix as non-authorized. >> >>this is true if there were an authorization scheme. Since there isn't one >>at the moment (and I don't see one coming, this issue was discussed at >>length), the receiver at least should be able to check, if the data >>was indeed received as sent (i.e. data authentication - which includes >>data integrity - should be used) > >If I get what you're arguing, I think this was my point. If we >developed an authorization scheme, we might not necessarily need an >integrity mechanism. We can't develop integrity without auth* at >any rate. Pekka, Which "auth" are you referring to above: authentication or authorization? Integrity is generally useless without some form of authentication; it generally is equivalent to saying " the message I received has not been modified since it was sent by the sender, but I have no idea who the sender is." In contrast, integrity w/o authorization is OK; it is analogous to saying "the message is intact, I know the source (authentication), and now I can decide what to do with it based on whatever policy I (locally) choose." Steve --============_-1074525802==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] Charter Update
At 11:05 AM +0200 1/18/06, Pekka Savola wrote:
On Wed, 18 Jan 2006, Stefan Mink wrote:
Pekka Savola wrote:
care and would just route to that prefix via a different path; if a MITM
attacker added a prefix, the receiver would just discard the added
prefix as non-authorized.

this is true if there were an authorization scheme. Since there isn't one
at the moment (and I don't see one coming, this issue was discussed at
length), the receiver at least should be able to check, if the data
was indeed received as sent (i.e. data authentication - which includes
data integrity - should be used)

If I get what you're arguing, I think this was my point.  If we developed an authorization scheme, we might not necessarily need an integrity mechanism.  We can't develop integrity without auth* at any rate.

Pekka,
Which "auth" are you referring to above: authentication or authorization?

Integrity is generally useless without some form of authentication; it generally is equivalent to saying " the message I received has not been modified since it was sent by the sender, but I have no idea who the sender is."

In contrast, integrity w/o authorization is OK; it is analogous to saying "the message is intact, I know the source (authentication), and now I can decide what to do with it based on whatever policy I (locally) choose."

Steve
--============_-1074525802==_ma============-- --===============0651760762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0651760762==-- From rpsec-bounces@ietf.org Wed Jan 18 13:56:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzITe-0003rE-RG; Wed, 18 Jan 2006 13:56:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzITd-0003r3-03 for rpsec@megatron.ietf.org; Wed, 18 Jan 2006 13:56:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12986 for ; Wed, 18 Jan 2006 13:54:47 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzIc0-0005KK-LH for rpsec@ietf.org; Wed, 18 Jan 2006 14:04:53 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0IItlIE028199; Wed, 18 Jan 2006 13:55:49 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 18 Jan 2006 13:55:52 -0500 To: Pekka Savola From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.5 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Pekka, >>>... >> >>I understand your reasoning, but even this seems tricky. What if >>some routers can support crypto using software because the UPDATE >>frequency is low enough for where they are used, but other routers >>cannot? Is the criteria that if any router anywhere in the Internet >>has to be replaced in order support a proposed security technology >>then that technology is unsuitable? > >This would need to be left as a judgment call when evaluating the >tradeoffs a solution makes, I think. agreed, which is why I think it makes sense to consider these (necessarily) vague considerations as goals, but not requirements. >FWIW, it's clear that in some topologies, (e.g., when talking about >the number of prefixes in hundreds), S/W approaches would be >acceptable, but in most of those scenarios, the existing mechanisms >(e.g., prefix filtering) are also applicable. I would characterize the issue differently. In some topologies one can use prefix filters because the range of prefixes that should be accepted from some peers is fairly static and thus there is no need to expend energy on crypto verification of the signatures. This is true no matter how many prefixes are involved. This does, however, require good tools to manage the prefix filter generation. The cost of signature verification does not grow as the number or prefixes in an UPDATE grows. It grows based on the number of hops in the path being validated. >UPDATE frequency as such doesn't help much. You need to consider >the protential update frequency -- e.g., what would happen if the >session was reset or flapping and basically all the prefixes would >need to be processed at once one or more times. When I said UPDATE frequency I was considering this as well. When a session is reset and one receives a lot of UPDATEs from a peer, it is not necessary to verify the signatures on all of them, if one uses a mechanism based on signed UPDATEs. One shoud look at each UPDATE and ask "if this UPDATE is authentic, does it cause me to change my LocRIB?" If the answer is no, then there is no need to peform crypto verification on the UPDATE at that time. > >So, if you think that'd help, one could rephrase this for example as follows: > >======= >X. No Heavy Processing on Routers > >Having specialized hardware to deal with cryptography in order to >get acceptable processing speed is unacceptable in general. The >solution cannot be deployed if it requires significant financial >investment that would not be otherwise required. > >While software mechanisms may be sufficient when the number of >prefixes a router needs to process is not much higher than O(100), >it's unprobable that such approaches could scale with richer >interconnection of at least O(10,000) prefixes. >======= As I noted above, the number of prefixes is not, per se, the determining factor. Thus the second paragraph is not a good way to characterize the issue. >... >Endless debate will ensue in any case if the group(s) cannot get to >rough consensus. If the group can, this shouldn't be too big a >problem. I'm more concerned about an endless debate that could >ensue from trying to fine-tune the metrics :) but introducing these metrics is already a source of such debate, and it creates the need to refine them if we're going to put them into the document, especially as requirements. > >>... > >But assuming you don't have a common trust anchor with your and all >your peers' certificates, you'll need to keep at least some (local) >data on which certs you find acceptable. I don't know well enough >what's needed, whether there would be issues with rollovers, whether >you'd need deal with CRL-like situations, etc. -- but with N peers >(where N is a non-trivial number), this seems somewhat comparable >administrative complexity to managing TCP-MD5 keys if the MD5 keys >are never changed. If you don't have a PKI to manage certs, then certs are not appropriate for this sort of context. Note that efforts are now beginning to establish a PKI for address and AS number allocation, starting at the RIR level. (The proposed PKI uses RFC 3779 extensions to represent address blocks and AS numbers.) The AS number part is much easier than the address allocation part, because there are fewer discrete allocations, and they are effected only by registries. With certs issued by the registries to AS number holders, ISPs can issue certs to routers and it is easy to tell if a router is authorized to represent a specific AS. That PKI, if it is successful, would address the trust anchor concern you cite above. >I'd like to emphasize that I wouldn't want to keep that information >on the routers, at least if the operator doesn't want to do that. >AFAICT, you'll need to set up something on a per-peer basis. Well, if the PKI I mentioned is deployed, a router with access to the root public key could verify the cert chain that terminates with a given router's cert. Such a chain would be fairly short: root->RIR->ISP or root->RIR->NIR/LIR->ISP. But, an operator could choose other ways to deal with this, e.g., distribute the CA cert for a each AS to the routers that are configured to peer with that AS, to create a 1-step chain for router cert verification, for example. >>... > >My point was that vanilla TCP and TCP-MD5 as written are almost >equally vulnerable to ICMP error message attacks. >Draft-gont-tcpm-icmp-attacks-05 (soon under draft-ietf-tcpm) >provides methods to make them more robust. > >IPsec does not really seem to provide even the same level of >verification of ICMP error messages as that draft. RFC 4301 mainly >focuses on requiring that the implementations must have configurable >options which type/code etc ICMPs to listen to and which to discard. >This is my reading of section 6.1 of RFC 4301. Section 6.2 (which >provides a bit more checking) doesn't seem to apply in this >situation very well assuming you don't configure an ICMP SAs for all >the peers and ignore other ICMP errors. Yes, these are the relevant sections of 4301, but they have to be read in the context of the access control mechanisms that IPsec already provides. IPsec allows you to filter ICMP error messages, to make sure that they come from a source consistent with the claimed address to which they refer in the payload. It also suggests controls to allow you to reject ICMP messages that try to set a PMTU to a size below a threshold established for a peer (6.1.1, top of page 64). >Hence, I don't see how IPsec would give additional protection >against ICMP errors compared to non-IPsec TCP (w/ >draft-gont-tcpm-icmp-attacks-05 checks). The protection might very >well be even worse by default. When IPsec is introduced, it create a barrier that ALL traffic must traverse. In a router, this barrier could be established around the router's management host and thus would process any traffic, including ICMP traffic, directed to that internal host. In the typical, not-multi-hop BGP peering case, you would accept ICMP error messages relevant to the BGP TCP session to come only from the peer router, and thus they can be authenticated, and filtered. >.... > >So, if you're not worried about threats on the transmission media >the BGP session runs over, GTSM, draft-gont-tcpm-icmp-attacks-05, >and to a lesser degree TCP-MD5 -like techniques may very well be >very close to satisfying the security requirements of the peering >sessions themselves. Thus the main focus should be on the >authentication/authorization aspects of the contents of the >advertisements. > >But we likely disagree on this. I would disagree that it is safe, in general, to ignore attacks against links between routers. GTSM is clever, but fails in the context of such attacks. The existing TCP-MD5 checksum is poor cryptographically, but the bigger problem is the lack of automated key management capability. I think it is reasonable to start by addressing peering session security, on a point-to-point basis, the move on to the harder, transitive security issues associated with advertisements. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 18 13:56:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzITj-0003sh-7Y; Wed, 18 Jan 2006 13:56:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzITh-0003ro-Gd for rpsec@megatron.ietf.org; Wed, 18 Jan 2006 13:56:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12998 for ; Wed, 18 Jan 2006 13:54:51 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzIc0-0005KC-LM for rpsec@ietf.org; Wed, 18 Jan 2006 14:04:57 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0IItlIC028199; Wed, 18 Jan 2006 13:55:48 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> Date: Wed, 18 Jan 2006 13:25:24 -0500 To: Pekka Savola From: Stephen Kent Subject: Re: [RPSEC] Charter Update Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 1:04 PM +0200 1/15/06, Pekka Savola wrote: >I wasn't participating in earlier, but I didn't find more >information in the archives, so.. > >First off, could you clarify a bit what you mean by "requirements >for peering relationship authorization and authentication >mechanisms" in practice? Which layer(s) are we talking about -- >anything from L1 to L9, or..? For example, are the administrative >processes for establishing peering relationship in scope? It'd very >useful if you could expand on this a bit as I think there hasn't >been a personal I-D to look at yet. These are fair questions to ask, at least up to L7 :-). I would assume that there is always an administrative process for deciding which ASes with which one peers, so it does not seem like an appropriate topic for a technical standards WG like ours. I expect Russ was referring to technical security controls to enforce policies devised by AS operators. In that context, we are talking about authentication mechanisms that allow routers to (securely) identify one another, either as specific routers or as routers that are authorized representatives of a specified AS. Then the routers use that ID info as input to to an authorization (access control) mechanism, i.e., to decide if they want to peer with one another, based on locally configured access control policy. >Nonetheless, a few doubts about adding integrity below. > >On Thu, 12 Jan 2006, Russ White wrote: >>>One comment about your suggestion for an additional work item: >>> >>>"Mar 06 Submit initial document discussing requirements for peering >>>relationship authorization and authentication mechanisms." >>> >>>I think it would be appropriate to focus on the authentication and >>>integrity requirements here, rather than authorization. Presumably any >>>authorization concerns can be addressed by using the authentication data >>>for lookup in a local database, the exact nature of which might not >>>require standardization. But, if other folks think the authorization >>>aspects of these peering relationships should be in scope, I'm OK with >>>that too. >> >>Anyone else have an opinion? I'm fine with either wording, so we should >>just make certain we don't get some sort of "strong objection" from the >>rest of the list (?). > >I'm a bit hesitant to make this change, at least without additional >qualifiers. > >That is, authorization/authentication of peering relationship tries >to answer the questions, like "which prefixes are you allowed to >advertise on a session?" and "how do I know who you are?" It need not do that, but it could. At a minimum a router needs to know whether it should establish a BGP session with another router. Once that decision has been made, one could use ID info from the authentication process to filter route advertisements, but that is a secondary security function. >On the other hand, integrity would change the focus the question on >"how do you ensure that the advertisement received is the same as >the one sent?" yes, integrity does address this question, on either a pairwise basis (just point-to-point for the session) or on a transitive basis. I think in this context only the former is on the table, since the text focuses on the peering session. >Ensuring integrity seems to mainly give the benefit to the >advertiser *). Auth* give significant benefit to the receiver. Integrity is a security service that is made possible by an action on the part of the sender, but requires verification by the receiver. That is not what you suggest above. >In my opinion, these solutions seem sufficiently different that the >requirements may be very different. Different folks require one but >not necessarily the other. These approaches should not be >fate-sharing -- as an operator, I'm not so worried about integrity >at this point (though I wouldn't mind getting it if I wouldn't need >to make significant compromises in other tradeoffs). Note that integrity, absent authentication, is generally not useful, as I explained in a previous message. Authorization is separable from integrity and authentication, in principle. However, we typically perform authentication so that we can use the results as input to an authorization (access control) decision. if we fail to provide continuous integrity and authenticity for a session, after an initial authentication and authorization step, then we leave ourselves open to active wiretapping attacks on the session, which undermines the rationale for conducting the authentication and authorization in the first place. >*) that's because the receiver just processes the information it >receives: if a MITM attacker removed a prefix, the receiver wouldn't >care and would just route to that prefix via a different path; if a >MITM attacker added a prefix, the receiver would just discard the >added prefix as non-authorized. I don't follow your analysis of an attack scenario above. If a MITM modifies an UPDATE, it influences the routing and forwarding decisions made by the receiver of the UPDATE. That is an attack on the security of the router that received the bogus UPDATE. It may cause traffic to no longer flow to the peer whose UPDATE was modified, or it may cause more traffic to flow to that peer. Whether this is good or bad for the peer depends on the nature of the business relationship between the affected ASes. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 18 15:15:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJi8-0002xU-FD; Wed, 18 Jan 2006 15:15:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJi7-0002xP-3o for rpsec@megatron.ietf.org; Wed, 18 Jan 2006 15:15:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19837 for ; Wed, 18 Jan 2006 15:13:46 -0500 (EST) From: sandy@tislabs.com Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzJqS-0008HD-If for rpsec@ietf.org; Wed, 18 Jan 2006 15:23:53 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0IKEgmi025345 for ; Wed, 18 Jan 2006 15:14:42 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAArEaaeX; Wed, 18 Jan 06 15:13:38 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0IKG6d3010136; Wed, 18 Jan 2006 15:16:06 -0500 (EST) Date: Wed, 18 Jan 2006 15:16:06 -0500 (EST) Message-Id: <200601182016.k0IKG6d3010136@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Charter Update X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Most of the comments so far have dealt with Russ's request for thoughts on the peering relationships authentication/authorization mechanisms. I was also wondering about the following item on the new charter: July 06 Submit initial document discussing security requirements in an OSPFv3 mobile ad hoc environment Is this not also a new item? I'm not opposed, I'm just wondering how it got there. Also, there was discussion in the last rpsec meeting (Aug, Paris) about Manral's rp-existing-crypto draft. I'm sorry that I never spoke up on the list about taking this on - I think we should. Anyone else want to see the issue of existing crypto mechanisms (especially existing use of crypto hash algorithms, especially keyed-MD5) get discussed in the group? Finally, I think Mar 06 as deadlines for the attack tree and the OSPF vulnerabilities draft are a bit soon - there's been very little discussion of these. And a deadline of Mar 06 for the BGP security requriements draft would be ..... difficult? astonishing? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 18 15:47:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKDE-0002aZ-6y; Wed, 18 Jan 2006 15:47:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKDC-0002aK-Bt for rpsec@megatron.ietf.org; Wed, 18 Jan 2006 15:47:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22125 for ; Wed, 18 Jan 2006 15:45:55 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzKLV-0000t8-2d for rpsec@ietf.org; Wed, 18 Jan 2006 15:56:00 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0IKkxIC005830; Wed, 18 Jan 2006 15:47:00 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200601182016.k0IKG6d3010136@tislabs.com> References: <200601182016.k0IKG6d3010136@tislabs.com> Date: Wed, 18 Jan 2006 15:32:27 -0500 To: sandy@tislabs.com From: Stephen Kent Subject: Re: [RPSEC] Charter Update Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org I concur with Sandy's observations about the OSPFv3 for mobile ad hoc nets, and question the appropriateness of this new work item. Security for routing in ad hoc mobile nets is a hot research topic these days. RPSEC is an IETF, not IRTF, group, so it seems a bit ambitious to start work on an IETF standard for this tough problem. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 18 18:41:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzMvG-0007fZ-CC; Wed, 18 Jan 2006 18:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzMvE-0007fU-Ha for rpsec@megatron.ietf.org; Wed, 18 Jan 2006 18:41:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21164 for ; Wed, 18 Jan 2006 18:39:35 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzN3e-0004Fa-0E for rpsec@ietf.org; Wed, 18 Jan 2006 18:49:43 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2006 15:40:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,382,1131350400"; d="scan'208"; a="19993962:sNHT23387408" Received: from RussPC (rtp-vpn4-364.cisco.com [10.82.209.108]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0INej6I024206; Wed, 18 Jan 2006 18:40:48 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Wed, 18 Jan 2006 18:40:44 -0500 X-PGP-Universal: processed; by RussPC on Wed, 18 Jan 2006 18:40:44 -0500 Message-ID: <43CED1F4.60501@cisco.com> Date: Wed, 18 Jan 2006 18:40:36 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] Charter Update References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> First off, could you clarify a bit what you mean by "requirements for >> peering relationship authorization and authentication mechanisms" in >> practice? Which layer(s) are we talking about -- anything from L1 to >> L9, or..? For example, are the administrative processes for >> establishing peering relationship in scope? It'd very useful if you >> could expand on this a bit as I think there hasn't been a personal I-D >> to look at yet. > > These are fair questions to ask, at least up to L7 :-). I would assume > that there is always an administrative process for deciding which ASes > with which one peers, so it does not seem like an appropriate topic for > a technical standards WG like ours. I expect Russ was referring to > technical security controls to enforce policies devised by AS operators. > In that context, we are talking about authentication mechanisms that > allow routers to (securely) identify one another, either as specific > routers or as routers that are authorized representatives of a specified > AS. Then the routers use that ID info as input to to an authorization > (access control) mechanism, i.e., to decide if they want to peer with > one another, based on locally configured access control policy. Yes, correct. The concept is simple: It appears we've come to the "end of our rope" with MD5, in particular. Should we produce a doc that will define a concencus of requirements for what is to replace MD5? I don't know if we really need this work or not, since replacements are already in progress, I believe, but, that's part of the information we need to include to decide if this is worthwhile work or not. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ87R/BEdu7FIVPTkEQL9EwCg4b58zRHzaypHWBPzEdR9Pmn/WmkAoPmP ONlOG3WCboByRRixE4/UlIWY =9hra -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 18 18:46:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzN0G-00006E-Fw; Wed, 18 Jan 2006 18:46:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzN0E-000063-WE for rpsec@megatron.ietf.org; Wed, 18 Jan 2006 18:46:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21507 for ; Wed, 18 Jan 2006 18:44:45 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzN8f-0004Pn-7k for rpsec@ietf.org; Wed, 18 Jan 2006 18:54:53 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2006 15:46:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,382,1131350400"; d="scan'208"; a="19994153:sNHT23509254" Received: from RussPC (rtp-vpn4-364.cisco.com [10.82.209.108]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0INjwJg021443; Wed, 18 Jan 2006 18:45:59 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Wed, 18 Jan 2006 18:45:55 -0500 X-PGP-Universal: processed; by RussPC on Wed, 18 Jan 2006 18:45:55 -0500 Message-ID: <43CED32C.5030804@cisco.com> Date: Wed, 18 Jan 2006 18:45:48 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sandy@tislabs.com Subject: Re: [RPSEC] Charter Update References: <200601182016.k0IKG6d3010136@tislabs.com> In-Reply-To: <200601182016.k0IKG6d3010136@tislabs.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I was also wondering about the following item on the new charter: > > July 06 Submit initial document discussing security requirements in > an OSPFv3 mobile ad hoc environment > > Is this not also a new item? I'm not opposed, I'm just wondering how > it got there. This is new, and it's from various suggestions I've gotten that we work on this area. As Steve says in a later email (trying to combine things here, to make the conversation "flow"): > I concur with Sandy's observations about the OSPFv3 for mobile ad hoc > nets, and question the appropriateness of this new work item. > > Security for routing in ad hoc mobile nets is a hot research topic > these days. RPSEC is an IETF, not IRTF, group, so it seems a bit > ambitious to start work on an IETF standard for this tough problem. Working on security implications of the MANET extensions to OSPF being proposed is a "middle ground." It's not really "researchy," since some of these extension proposals are actually being considered/planned for delpoyment, and the extensions are, for the most part, modest extensions to OSPF, rather than an entirely new protocol, which limits the scope of work. > Also, there was discussion in the last rpsec meeting (Aug, Paris) > about Manral's rp-existing-crypto draft. I'm sorry that I never > spoke up on the list about taking this on - I think we should. Anyone > else want to see the issue of existing crypto mechanisms (especially > existing use of crypto hash algorithms, especially keyed-MD5) get > discussed in the group? Yes, we could include this in the charter, if we have concensus around it. > Finally, I think Mar 06 as deadlines for the attack tree and the OSPF > vulnerabilities draft are a bit soon - there's been very little > discussion of these. And a deadline of Mar 06 for the BGP security > requriements draft would be ..... difficult? astonishing? Well, when I wrote this, March 06 seemed like a long time off. Now, it seems pretty close. :-) Perhaps we should reset these to be: - -- Just before the June IETF for stuff that we just need to "wrap up." - -- Just before the fall IETF for stuff that we feel we need some work on, but it's at least written, and in progress, etc. - -- One year for now for totally new stuff. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ87TMxEdu7FIVPTkEQIicgCeO5d+5gInVQMEwp6/fbgn5QOI40UAnRck 8q9eNSB0a0r8/q477GGIrjTF =51JQ -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 18 18:53:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzN7i-0004Hs-RA; Wed, 18 Jan 2006 18:53:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzN7g-0004Hn-Um for rpsec@megatron.ietf.org; Wed, 18 Jan 2006 18:53:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22031 for ; Wed, 18 Jan 2006 18:52:27 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzNG7-0004gx-Bo for rpsec@ietf.org; Wed, 18 Jan 2006 19:02:35 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2006 15:53:43 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,382,1131350400"; d="scan'208"; a="19994463:sNHT23613196" Received: from RussPC (rtp-vpn4-364.cisco.com [10.82.209.108]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0INrc6I025942; Wed, 18 Jan 2006 18:53:40 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Wed, 18 Jan 2006 18:53:36 -0500 X-PGP-Universal: processed; by RussPC on Wed, 18 Jan 2006 18:53:36 -0500 Message-ID: <43CED4F9.9070409@cisco.com> Date: Wed, 18 Jan 2006 18:53:29 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> I understand your reasoning, but even this seems tricky. What if some >>> routers can support crypto using software because the UPDATE >>> frequency is low enough for where they are used, but other routers >>> cannot? Is the criteria that if any router anywhere in the Internet >>> has to be replaced in order support a proposed security technology >>> then that technology is unsuitable? >> This would need to be left as a judgment call when evaluating the >> tradeoffs a solution makes, I think. > agreed, which is why I think it makes sense to consider these > (necessarily) vague considerations as goals, but not requirements. Hmmm... I would think that if this is something that's required for any system to have a realistic opportunity of actually being deployed, then it's still at least a SHOULD. Perfectly undeployable perfect systems are not really solutions at all. :-) >> UPDATE frequency as such doesn't help much. You need to consider the >> protential update frequency -- e.g., what would happen if the session >> was reset or flapping and basically all the prefixes would need to be >> processed at once one or more times. > When I said UPDATE frequency I was considering this as well. When a > session is reset and one receives a lot of UPDATEs from a peer, it is > not necessary to verify the signatures on all of them, if one uses a > mechanism based on signed UPDATEs. One shoud look at each UPDATE and ask > "if this UPDATE is authentic, does it cause me to change my LocRIB?" If > the answer is no, then there is no need to peform crypto verification on > the UPDATE at that time. If you lose a peer, you have to clear your RIB for all information previously received from that peer, receive all updates, and then reinstall all of them into your RIB. It's not always clear when an update will change you RIB or not--there's no implementation I know of that evaluates whether or not a route would win if installed before processing the route, they all choose their best route, and attempt to install the route, seeing if it actually is installed when the attempt is completed. (I know, just a nit, but the closer we are to reality in our understanding of how implementations actually work, the closer we can mold requirements so they will be do-able in the real world). :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ87VABEdu7FIVPTkEQIEswCg1tIgX2hJK9T9VpeyhMIcNFS4Hx8AniYT eu4umzX4I5Uz9n/4maNyobrb =5QDi -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 03:54:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzVYQ-0006R0-Ey; Thu, 19 Jan 2006 03:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzVYO-0006Qs-2g for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 03:54:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01825 for ; Thu, 19 Jan 2006 03:52:32 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.204] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzVgr-0006Q0-Il for rpsec@ietf.org; Thu, 19 Jan 2006 04:02:46 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1EzVY2-0004Cx-TW; Thu, 19 Jan 2006 09:53:39 +0100 Message-ID: <43CF5394.1010206@schlund.net> Date: Thu, 19 Jan 2006 09:53:40 +0100 From: Stefan Mink User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> In-Reply-To: <43CED4F9.9070409@cisco.com> X-Enigmail-Version: 0.91.0.0 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rpsec@ietf.org, Tony Tauber , 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: , Content-Type: multipart/mixed; boundary="===============1479018015==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1479018015== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigECDDA8F5E4A26B5C3570E06A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigECDDA8F5E4A26B5C3570E06A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Russ, Russ White wrote: > If you lose a peer, you have to clear your RIB for all information > previously received from that peer, receive all updates, and then > reinstall all of them into your RIB. what about graceful restart for BGP? tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigECDDA8F5E4A26B5C3570E06A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDz1OUehvPYvDU0roRAuGLAKCdyynVtmDk8/qSJw7+tpUBY37l3QCgnZLj RJp42hi6KgOWlpDFUhbiT+g= =91jW -----END PGP SIGNATURE----- --------------enigECDDA8F5E4A26B5C3570E06A-- --===============1479018015== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1479018015==-- From rpsec-bounces@ietf.org Thu Jan 19 09:55:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbCK-0000Si-FW; Thu, 19 Jan 2006 09:55:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbCI-0000SY-UC for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 09:55:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28658 for ; Thu, 19 Jan 2006 09:54:08 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzbKq-0001wH-7K for rpsec@ietf.org; Thu, 19 Jan 2006 10:04:25 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JEtEIG009492; Thu, 19 Jan 2006 09:55:17 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43CED4F9.9070409@cisco.com> References: <43CED4F9.9070409@cisco.com> Date: Thu, 19 Jan 2006 09:48:34 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Russ, >... >> agreed, which is why I think it makes sense to consider these >> (necessarily) vague considerations as goals, but not requirements. > >Hmmm... I would think that if this is something that's required for any >system to have a realistic opportunity of actually being deployed, then >it's still at least a SHOULD. Perfectly undeployable perfect systems are >not really solutions at all. :-) yes, but vague comments about performance and manageability are just fodder for debate, not objective metrics that should be described as "requirements." :-) > >>> UPDATE frequency as such doesn't help much. You need to consider the >>> protential update frequency -- e.g., what would happen if the session >>> was reset or flapping and basically all the prefixes would need to be >>> processed at once one or more times. > >> When I said UPDATE frequency I was considering this as well. When a >> session is reset and one receives a lot of UPDATEs from a peer, it is >> not necessary to verify the signatures on all of them, if one uses a >> mechanism based on signed UPDATEs. One shoud look at each UPDATE and ask >> "if this UPDATE is authentic, does it cause me to change my LocRIB?" If >> the answer is no, then there is no need to peform crypto verification on >> the UPDATE at that time. > >If you lose a peer, you have to clear your RIB for all information >previously received from that peer, receive all updates, and then >reinstall all of them into your RIB. It's not always clear when an >update will change you RIB or not--there's no implementation I know of >that evaluates whether or not a route would win if installed before >processing the route, they all choose their best route, and attempt to >install the route, seeing if it actually is installed when the attempt >is completed. (I know, just a nit, but the closer we are to reality in >our understanding of how implementations actually work, the closer we >can mold requirements so they will be do-able in the real world). Which RIB? The AdjRIB for the peer in question can be populated with unverified advertisements safely, so long as no unverified routes are selected for use in the LocRIB. When a route is selected as the "best" for the NLRI in question, then it needs to be verified before it can be used safely. What aspect of this heuristic do you feel is inconsistent with how implementations actually work? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 10:16:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbW6-000853-L1; Thu, 19 Jan 2006 10:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbW4-00083l-MM for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 10:16:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00150 for ; Thu, 19 Jan 2006 10:14:33 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezbec-0002hX-70 for rpsec@ietf.org; Thu, 19 Jan 2006 10:24:51 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2006 07:15:49 -0800 X-IronPort-AV: i="3.99,385,1131350400"; d="scan'208"; a="1768138984:sNHT85632308" Received: from RussPC (rtp-vpn4-342.cisco.com [10.82.209.86]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0JFFkQK006223; Thu, 19 Jan 2006 07:15:48 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 10:15:43 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 10:15:43 -0500 Message-ID: <43CFAD14.1070708@cisco.com> Date: Thu, 19 Jan 2006 10:15:32 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Mink Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> <43CF5394.1010206@schlund.net> In-Reply-To: <43CF5394.1010206@schlund.net> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=UTF-8; format=flowed Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: rpsec@ietf.org, Tony Tauber , Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>If you lose a peer, you have to clear your RIB for all information >>previously received from that peer, receive all updates, and then >>reinstall all of them into your RIB. > > what about graceful restart for BGP? Certainly, but that's not the "normal" mode of BGP operation. Perhaps, in 5 or 6 years, when it's "commonly deployed," we can assume GR is the normal mode of operation. Today, I don't think you can. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8+tHxEdu7FIVPTkEQIQ2gCeLxIQl+HN9BImXz0ylDgaWZvWDyoAoL2c 7lQ4yiEahR54n+XYAbBHVbhT =QDBG -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 10:16:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbX1-0008Vf-7d; Thu, 19 Jan 2006 10:16:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbWz-0008V8-Uf for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 10:16:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00213 for ; Thu, 19 Jan 2006 10:15:30 -0500 (EST) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzbfU-0002im-KJ for rpsec@ietf.org; Thu, 19 Jan 2006 10:25:48 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id BD567194C; Thu, 19 Jan 2006 15:16:30 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 877kasPqC0272Mo1; Thu, 19 Jan 2006 15:16:29 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 872kasPqb0381Mo1; Thu, 19 Jan 2006 15:16:27 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.27I); Thu, 19 Jan 2006 15:16:27 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID491kasPqb2008Xo1 Received: from localhost ([65.247.36.31]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 08:16:26 -0700 Date: Thu, 19 Jan 2006 10:16:26 -0500 From: Jeffrey Haas To: Stefan Mink Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Message-ID: <20060119151626.GV22020@nexthop.com> References: <43CED4F9.9070409@cisco.com> <43CF5394.1010206@schlund.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43CF5394.1010206@schlund.net> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 19 Jan 2006 15:16:26.0969 (UTC) FILETIME=[51225C90:01C61D0B] 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Stefan, On Thu, Jan 19, 2006 at 09:53:40AM +0100, Stefan Mink wrote: > > If you lose a peer, you have to clear your RIB for all information > > previously received from that peer, receive all updates, and then > > reinstall all of them into your RIB. > > what about graceful restart for BGP? In graceful restart, you (often) start with no RIB. You seed the RIB with the FIB and then stale out RIB entries once your protocol has resynchronized. > Stefan -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 10:26:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezbg8-0003Q5-Is; Thu, 19 Jan 2006 10:26:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezbg7-0003PS-4K for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 10:26:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00779 for ; Thu, 19 Jan 2006 10:24:56 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezboe-00030V-Mi for rpsec@ietf.org; Thu, 19 Jan 2006 10:35:14 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Jan 2006 07:26:08 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,385,1131350400"; d="scan'208"; a="20031515:sNHT23044348" Received: from RussPC (rtp-vpn4-342.cisco.com [10.82.209.86]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0JFQ46I028705; Thu, 19 Jan 2006 10:26:05 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 10:26:00 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 10:26:00 -0500 Message-ID: <43CFAF81.90608@cisco.com> Date: Thu, 19 Jan 2006 10:25:53 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> agreed, which is why I think it makes sense to consider these >>> (necessarily) vague considerations as goals, but not requirements. >> Hmmm... I would think that if this is something that's required for any >> system to have a realistic opportunity of actually being deployed, then >> it's still at least a SHOULD. Perfectly undeployable perfect systems are >> not really solutions at all. :-) > yes, but vague comments about performance and manageability are just > fodder for debate, not objective metrics that should be described as > "requirements." :-) Just because something isn't easy to define doesn't mean it's not a requirement, IMHO. :-) >> If you lose a peer, you have to clear your RIB for all information >> previously received from that peer, receive all updates, and then >> reinstall all of them into your RIB. It's not always clear when an >> update will change you RIB or not--there's no implementation I know of >> that evaluates whether or not a route would win if installed before >> processing the route, they all choose their best route, and attempt to >> install the route, seeing if it actually is installed when the attempt >> is completed. (I know, just a nit, but the closer we are to reality in >> our understanding of how implementations actually work, the closer we >> can mold requirements so they will be do-able in the real world). > > Which RIB? The RIB is the table from which forwarding information is drawn whether for forwarding or for building forwarding tables. > The AdjRIB for the peer in question can be populated with unverified > advertisements safely, so long as no unverified routes are selected for > use in the LocRIB. When a route is selected as the "best" for the NLRI > in question, then it needs to be verified before it can be used safely. > > What aspect of this heuristic do you feel is inconsistent with how > implementations actually work? There's no such things as an AdjRIB in any implementation of BGP that I'm aware of--well, you might want to count the soft reset tables in Cisco IOS as an "adjrib," but, in reality, we (Cisco) strongly suggest customers not to use that feature at all, but rely on route refresh, instead. In fact, I'm not aware of a single BGP implementation that strictly follows the model implementation described in the BGP specification(s). Routers don't just run one protocol, as the BGP specifications assume. In fact, a single BGP process may not populate a single RIB. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8+viBEdu7FIVPTkEQLybwCgpSDyUSCFGV9iZbPIN8eBl5maaccAoODN AarcErsivd2+Vy+rDO3lDEP0 =GT0S -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 10:44:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbxP-0002eY-LV; Thu, 19 Jan 2006 10:44:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbxN-0002eT-Ay for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 10:44:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01806 for ; Thu, 19 Jan 2006 10:42:46 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezc5v-0003VB-6E for rpsec@ietf.org; Thu, 19 Jan 2006 10:53:04 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1EzbxK-0001wW-UK; Thu, 19 Jan 2006 16:44:11 +0100 Message-ID: <43CFB3CD.6010704@schlund.net> Date: Thu, 19 Jan 2006 16:44:13 +0100 From: Stefan Mink User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Haas Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> <43CF5394.1010206@schlund.net> <20060119151626.GV22020@nexthop.com> In-Reply-To: <20060119151626.GV22020@nexthop.com> X-Enigmail-Version: 0.91.0.0 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1851639788==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1851639788== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF215915A2C0F1388BBE68EF4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF215915A2C0F1388BBE68EF4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeffrey Haas wrote: > In graceful restart, you (often) start with no RIB. You seed the > RIB with the FIB and then stale out RIB entries once your protocol > has resynchronized. ok, depending on the site you're looking at: the partner staying alive and seeing the neighbors control plane going down and coming up again AFAIK sustains his RIB and in this case would not have to authenticate each route again, if its still in the RIB (and thus was checked in the past), does he? tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigF215915A2C0F1388BBE68EF4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFDz7PNehvPYvDU0roRAn6mAJdpSinhVdCnr/1EOCMjRE5rIjifAJ4xVKYQ Y/oEBOmM3fPTnW7fbgAyRA== =DcXC -----END PGP SIGNATURE----- --------------enigF215915A2C0F1388BBE68EF4-- --===============1851639788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1851639788==-- From rpsec-bounces@ietf.org Thu Jan 19 10:59:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzcBt-0000tR-5w; Thu, 19 Jan 2006 10:59:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzcBr-0000s0-8b for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 10:59:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02909 for ; Thu, 19 Jan 2006 10:57:43 -0500 (EST) Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzcKM-00040R-Vn for rpsec@ietf.org; Thu, 19 Jan 2006 11:08:02 -0500 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id 2902F1F6B; Thu, 19 Jan 2006 15:58:53 +0000 (GMT) Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 442kasP710114Mo1; Thu, 19 Jan 2006 15:58:53 GMT Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 441kasP7Y0039Mo1; Thu, 19 Jan 2006 15:58:51 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.27I); Thu, 19 Jan 2006 15:58:51 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com gw3.EXCHPROD.USA.NET X-USANET-MsgId: XID058kasP7z1785Xo1 Received: from localhost ([65.247.36.31]) by gw3.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 08:58:50 -0700 Date: Thu, 19 Jan 2006 10:58:49 -0500 From: Jeffrey Haas To: Stefan Mink Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Message-ID: <20060119155849.GW22020@nexthop.com> References: <43CED4F9.9070409@cisco.com> <43CF5394.1010206@schlund.net> <20060119151626.GV22020@nexthop.com> <43CFB3CD.6010704@schlund.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43CFB3CD.6010704@schlund.net> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 19 Jan 2006 15:58:50.0473 (UTC) FILETIME=[3D2E4590:01C61D11] X-Spam-Score: 0.0 (/) 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Thu, Jan 19, 2006 at 04:44:13PM +0100, Stefan Mink wrote: > ok, depending on the site you're looking at: the partner staying > alive and seeing the neighbors control plane going down and coming > up again AFAIK sustains his RIB and in this case would not have to > authenticate each route again, if its still in the RIB (and thus > was checked in the past), does he? I'd expect so. If the question you're asking is "Could Graceful Restart be extended to allow a lower impact on a restarting router", I think that the answer is "maybe". Let's agree how to secure things outside of restart context first. > Stefan -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 11:04:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzcHQ-0001mc-V3; Thu, 19 Jan 2006 11:04:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzcHP-0001mH-Hc for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 11:04:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03156 for ; Thu, 19 Jan 2006 11:03:28 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzcPy-00048o-70 for rpsec@ietf.org; Thu, 19 Jan 2006 11:13:46 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1EzcHN-00068v-OO; Thu, 19 Jan 2006 17:04:53 +0100 Message-ID: <43CFB8A8.4090706@schlund.net> Date: Thu, 19 Jan 2006 17:04:56 +0100 From: Stefan Mink User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Haas Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> <43CF5394.1010206@schlund.net> <20060119151626.GV22020@nexthop.com> <43CFB3CD.6010704@schlund.net> <20060119155849.GW22020@nexthop.com> In-Reply-To: <20060119155849.GW22020@nexthop.com> X-Enigmail-Version: 0.91.0.0 X-Virus-Scanned: Symantec AntiVirus Scan Engine 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: , Content-Type: multipart/mixed; boundary="===============0645688786==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0645688786== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigADE8158CC46812CBD1EF94B0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigADE8158CC46812CBD1EF94B0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeffrey Haas wrote: > Let's agree how to secure things outside of restart context first. ACK tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigADE8158CC46812CBD1EF94B0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDz7ioehvPYvDU0roRApaXAJ4/ktimgB9q74MBjwNjLcKIWjVROACgyj0u N6MqlpO8DNSEPVC1fYmM9d8= =L6HS -----END PGP SIGNATURE----- --------------enigADE8158CC46812CBD1EF94B0-- --===============0645688786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0645688786==-- From rpsec-bounces@ietf.org Thu Jan 19 11:13:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzcPY-00062T-1Y; Thu, 19 Jan 2006 11:13:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzcPV-00062O-Ii for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 11:13:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03633 for ; Thu, 19 Jan 2006 11:11:50 -0500 (EST) From: sandy@tislabs.com Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzcY3-0004Mu-Lc for rpsec@ietf.org; Thu, 19 Jan 2006 11:22:08 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0JGCb0a010070 for ; Thu, 19 Jan 2006 11:12:37 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2QayEt; Thu, 19 Jan 06 11:12:16 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0JGEjGf025912; Thu, 19 Jan 2006 11:14:45 -0500 (EST) Date: Thu, 19 Jan 2006 11:14:45 -0500 (EST) Message-Id: <200601191614.k0JGEjGf025912@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 X-Spam-Score: 0.3 (/) 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org I would like to speak against including hardware and software limitations as bgp security requirements. I believe that these are very important issues. I just don't think that they constitute security requirements. They could be called deployment considerations, or solution requirements, or some such. I believe that security requirements should not vary over time, absent such events as the discovery of brand new attacks no one had ever thought of before. But we know that issues of hardware and software performance and cost will necessarily vary in importance over time and over networks. They will vary because: hardware performance, even averaged over the entire router base, will vary over time software performance will vary, both as improved algorithms become available and as hardware changes occur network and protocol design/engineering can ameliorate demands on under powered routers the definition of "heavy" will vary by the network tolerance to risk and to cost vary by network It would be best if the bgp security requirements did not prevent consideration of a solution that would be acceptable to some portions of the Internet or to specific networks, either now or N years from now. So I'd say these issues should be a separate section of the document that talks about considerations of deployment, or barriers to deployment (though that latter might be "unnecessarily pejorative" as someone I know likes to say). Note also: the suggested new text as stated says that heavy processing must not be required of "all routers". But since there is already a requirement addressing tolerance of incremental deployment, there's already a requirement that not all routers participate. So the text as stated is obviated by other text. If you really did mean the "all" part of "must not require that heavy processing is required on all the BGP routers", then we don't need this requirement. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 11:25:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezcb4-0001bM-AQ; Thu, 19 Jan 2006 11:25:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezcb2-0001av-Cv for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 11:25:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAB04406 for ; Thu, 19 Jan 2006 11:23:45 -0500 (EST) From: sandy@tislabs.com Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezcja-0004ji-Fx for rpsec@ietf.org; Thu, 19 Jan 2006 11:34:03 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0JGOgD9012862 for ; Thu, 19 Jan 2006 11:24:42 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_4ayhz; Thu, 19 Jan 06 11:24:39 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0JGR70Q026706; Thu, 19 Jan 2006 11:27:07 -0500 (EST) Date: Thu, 19 Jan 2006 11:27:07 -0500 (EST) Message-Id: <200601191627.k0JGR70Q026706@tislabs.com> To: rpsec@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: sandy@tislabs.com Subject: [RPSEC] incremental deployment X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org The bgp security requirement draft speaks of tolerance of incremental deployment, with the motivation that deployment across the Internet will not be instantaneous. That would be the traditional interpretation of the term "incremental" - there's a suggestion that eventually the entire system will be covered. But as has been mentioned at various times in various discussions and spec, there may never be ubiquitous deployment. There may never be such widespread deployment that we can consider areas of non-use as special cases to be dealt with separately. We should consider "incremental deployment" to mean "non-homogeneous deployment" and treat it as a consistent requirement, not a phase. BGP-4 ubiquitously replaced BGP-3 (I sure hope no one speaks up to shatter that illusion). And that surely required upgrades to software and configurations, maybe even platforms. But the security deployment will vary by factors that probably will not change over time, including network design. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 11:46:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzcvX-0008IU-R4; Thu, 19 Jan 2006 11:46:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzcvW-0008Hy-2p for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 11:46:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06014 for ; Thu, 19 Jan 2006 11:44:54 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezd44-0005PB-4i for rpsec@ietf.org; Thu, 19 Jan 2006 11:55:13 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 678401F60; Thu, 19 Jan 2006 16:45:58 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 663kasqt50410Mo2; Thu, 19 Jan 2006 16:45:57 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 657kasqt30044Mo2; Thu, 19 Jan 2006 16:45:55 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Thu, 19 Jan 2006 16:45:54 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID061kasqt45128Xo2 Received: from localhost ([65.247.36.31]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 Jan 2006 09:45:54 -0700 Date: Thu, 19 Jan 2006 11:45:53 -0500 From: Jeffrey Haas To: sandy@tislabs.com Subject: Re: [RPSEC] incremental deployment Message-ID: <20060119164553.GX22020@nexthop.com> References: <200601191627.k0JGR70Q026706@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601191627.k0JGR70Q026706@tislabs.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 19 Jan 2006 16:45:54.0616 (UTC) FILETIME=[D0804B80:01C61D17] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Sandy, On Thu, Jan 19, 2006 at 11:27:07AM -0500, sandy@tislabs.com wrote: > BGP-4 ubiquitously replaced BGP-3 (I sure hope no one speaks up > to shatter that illusion). And that surely required upgrades to > software and configurations, maybe even platforms. But the security > deployment will vary by factors that probably will not change over > time, including network design. I think a better analogy would be the deployment of multi-protocol BGP with respect to IPv6 or multicast SAFIs. Many people still speak BGP-4 conformantly without supporting these extentions. Many networks support MP-BGP without having deployed multicast or IPv6. Probably the strongest protocol specific analogy would be the AS-4byte support for BGP-4. A transition mechanism is part of the specification. At some point, it is hoped that the transition mechanism just goes away and that the entire Internet is AS-4byte based. > --Sandy -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 11:46:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezcvv-00006l-JM; Thu, 19 Jan 2006 11:46:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezcvu-00006W-7E for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 11:46:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06053 for ; Thu, 19 Jan 2006 11:45:18 -0500 (EST) From: sandy@tislabs.com Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezd4S-0005Qj-Cp for rpsec@ietf.org; Thu, 19 Jan 2006 11:55:37 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0JGkEBY017582 for ; Thu, 19 Jan 2006 11:46:14 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXtaquI; Thu, 19 Jan 06 11:46:11 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0JG7Ota025473; Thu, 19 Jan 2006 11:07:24 -0500 (EST) Date: Thu, 19 Jan 2006 11:07:24 -0500 (EST) Message-Id: <200601191607.k0JG7Ota025473@tislabs.com> To: kent@bbn.com, riw@cisco.com Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 X-Spam-Score: 0.3 (/) 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org >Just because something isn't easy to define doesn't mean it's not a >requirement, IMHO. :-) There are lots of requirements we all vaguely understand ("run a secure operation", "secure the protocols", "be happy", ...) but writing a specification of a requirement should be much more crisply stated. Otherwise, future solution designs compared against the requirements will lead to an endless round of "Yes, it is -- No, it isn't -- Is, too -- No way" with no way to resolve the dispute. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 11:47:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezcwx-0000kt-E8; Thu, 19 Jan 2006 11:47:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezcwv-0000kh-Vb for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 11:47:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06138 for ; Thu, 19 Jan 2006 11:46:22 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezd5S-0005Rz-4V for rpsec@ietf.org; Thu, 19 Jan 2006 11:56:41 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JGlRIE017063; Thu, 19 Jan 2006 11:47:29 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43CFAF81.90608@cisco.com> References: <43CED4F9.9070409@cisco.com> <43CFAF81.90608@cisco.com> Date: Thu, 19 Jan 2006 11:11:36 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 10:25 AM -0500 1/19/06, Russ White wrote: >... >Just because something isn't easy to define doesn't mean it's not a >requirement, IMHO. :-) Requirements need to be objectively testable to be useful. So, "easy to define" is not show stopper, but impossible to define in an objective, testable fashion is. So far the discussion yielded wording for these criteria that are objectively testable, and not simultaneously silly. So, for example, a simple statement like "Any security mechanism MUST/SHOULD NOT degrade router performance" is objectively testable, but its also silly; years of experience indicate that the introduction of any just about security mechanism in any computing or communication environment will add some overhead. > >... > >There's no such things as an AdjRIB in any implementation of BGP that >I'm aware of--well, you might want to count the soft reset tables in >Cisco IOS as an "adjrib," but, in reality, we (Cisco) strongly suggest >customers not to use that feature at all, but rely on route refresh, >instead. In fact, I'm not aware of a single BGP implementation that >strictly follows the model implementation described in the BGP >specification(s). I asked the question because the BGP spec (RFC 4271) specifically distinguishes AdjRIBs from the LocRIB as part of the model for BGP operation. A compliant implementation must behave in a fashion consistent with this abstract model, irrespective of how the functions are implemented. However you implement BGP, there still needs to be a distinction between an advertisement from a peer that is NOT the best route for a given set of NLRI at the time the advertisement is received, but which still needs to be maintained in case the current best route is withdrawn. One also needs to mark each route based on which peer advertised it, to ensure than only the peer that advertised the route can withdraw it. Given these requirements, it is still possible to do what I described, i.e., don't spend time validating a route which does not appear to be the best route for a given set of NLRI. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 11:47:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezcwx-0000lI-TK; Thu, 19 Jan 2006 11:47:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezcwv-0000kg-TV for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 11:47:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06139 for ; Thu, 19 Jan 2006 11:46:22 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezd5S-0005SA-4Z for rpsec@ietf.org; Thu, 19 Jan 2006 11:56:41 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JGlRIK017063; Thu, 19 Jan 2006 11:47:32 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43CED1F4.60501@cisco.com> References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> Date: Thu, 19 Jan 2006 11:47:33 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Charter Update Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 6:40 PM -0500 1/18/06, Russ White wrote: >... >Yes, correct. The concept is simple: It appears we've come to the "end >of our rope" with MD5, in particular. Should we produce a doc that will >define a concencus of requirements for what is to replace MD5? > >I don't know if we really need this work or not, since replacements are >already in progress, I believe, but, that's part of the information we >need to include to decide if this is worthwhile work or not. Two observations: - although collisions in MD5 make it a concern for use a hash function with digital signatures, use of MD5 as a MAC is a slightly different issue. In particular, the goal of an adversary in the BGP context where the MD5-based MAC is used is to modify a TCP segment in a fashion that yields the same MAC value, or to create a new message with the same MAC value. I don't believe the attacks on MD5 (or SHA-1) can do this yet. nonetheless, I agree that the current TCP MD5 checksum option should be replaced. - there are two individual I-Ds that have been published recently, each proposing replacement mechanisms for the TCP MD5 checksum, including improved key management. The community needs one replacement, not two. I have reviewed both I-Ds and each has serious problems that need to be addressed. I'm in favor of RPSEC making the selection of a replacement for the TCP MD5 checksum option a work item, it the routing ADs agree it should be here. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 11:59:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezd80-0006Vw-SX; Thu, 19 Jan 2006 11:59:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezd7x-0006Vn-Va for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 11:59:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06834 for ; Thu, 19 Jan 2006 11:57:46 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzdGW-0005le-3A for rpsec@ietf.org; Thu, 19 Jan 2006 12:08:05 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0JGwoHa021227; Thu, 19 Jan 2006 18:58:50 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0JGwopY021224; Thu, 19 Jan 2006 18:58:50 +0200 Date: Thu, 19 Jan 2006 18:58:50 +0200 (EET) From: Pekka Savola To: sandy@tislabs.com Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 In-Reply-To: <200601191607.k0JG7Ota025473@tislabs.com> Message-ID: References: <200601191607.k0JG7Ota025473@tislabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1245/Wed Jan 18 18:57:44 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL, L_SPAM_COM_URL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: rpsec@ietf.org, kent@bbn.com, riw@cisco.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Thu, 19 Jan 2006, sandy@tislabs.com wrote: > Otherwise, future solution designs compared against the requirements > will lead to an endless round of "Yes, it is -- No, it isn't -- Is, too > -- No way" with no way to resolve the dispute. Frankly, that situation smells a lot like one where the group would not have anywhere near rough consensus on the solution it wants to design. In that case, no matter the wording of requirements, I doubt consensus would emerge before the group would be overtaken by events. -- 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 Thu Jan 19 12:14:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzdMg-0000P8-CT; Thu, 19 Jan 2006 12:14:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzdMe-0000OP-LO for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 12:14:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08090 for ; Thu, 19 Jan 2006 12:12:57 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18rEy+eyiCUmPOvWobVSHUFVjWDqvuLQ7g=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzdVA-0006G8-D7 for rpsec@ietf.org; Thu, 19 Jan 2006 12:23:16 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+mS0hnFWBOd5d2HfM2r8kfqcsMI/fCdXM@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0JHDNL2005171; Thu, 19 Jan 2006 17:13:35 GMT Date: Thu, 19 Jan 2006 17:13:26 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 In-Reply-To: Message-ID: References: <43CED4F9.9070409@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.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.87.1/1245/Wed Jan 18 16:57:44 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Thu, 19 Jan 2006, Stephen Kent wrote: > yes, but vague comments about performance and manageability are just fodder > for debate, not objective metrics that should be described as "requirements." > :-) Indeed, agreed. Pekka's original comment though did point at a better definition though: " In particular, the solution must not require that heavy processing is required on all the BGP routers." I.e. I think the key point here is "on all the BGP routers" - not to define 'heavy processing' (lets ignore degree of 'heavy' as you suggest). Whether "on all" is or is not acceptable is the key. Some people might prefer it not to be acceptable and hence have the requirements allow for a solution in which the crypto-load can be off-loaded and confined to a subset of routers. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: The meek don't want it. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 12:30:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzdcY-0003NT-UD; Thu, 19 Jan 2006 12:30:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzdcX-0003Mb-K1 for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 12:30:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09718 for ; Thu, 19 Jan 2006 12:29:21 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezdl0-0006wK-W9 for rpsec@ietf.org; Thu, 19 Jan 2006 12:39:38 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0JHUFHa021995; Thu, 19 Jan 2006 19:30:15 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0JHUFLN021992; Thu, 19 Jan 2006 19:30:15 +0200 Date: Thu, 19 Jan 2006 19:30:15 +0200 (EET) From: Pekka Savola To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1245/Wed Jan 18 18:57:44 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.5 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Wed, 18 Jan 2006, Stephen Kent wrote: > When I said UPDATE frequency I was considering this as well. When a session > is reset and one receives a lot of UPDATEs from a peer, it is not necessary > to verify the signatures on all of them, if one uses a mechanism based on > signed UPDATEs. One shoud look at each UPDATE and ask "if this UPDATE is > authentic, does it cause me to change my LocRIB?" If the answer is no, then > there is no need to peform crypto verification on the UPDATE at that time. I'd say that in most cases the answer would be "yes". The whole point of peering (unless the link is acting as a cold backup) is to accept prefixes. Operators also tend to set preferences in the incoming advertisements, making them preferable. When such sessions (with 1,000-200,000 "yes, loc-rib update would be needed" prefixes) flap, the resulting computation could be rather intensive. >> Endless debate will ensue in any case if the group(s) cannot get to rough >> consensus. If the group can, this shouldn't be too big a problem. I'm >> more concerned about an endless debate that could ensue from trying to >> fine-tune the metrics :) > > but introducing these metrics is already a source of such debate, and it > creates the need to refine them if we're going to put them into the document, > especially as requirements. I maintain these issues are vital for deployment, but I don't think it's productive to continue this discussion in this thread. >> But assuming you don't have a common trust anchor with your and all your >> peers' certificates, you'll need to keep at least some (local) data on >> which certs you find acceptable. I don't know well enough what's needed, >> whether there would be issues with rollovers, whether you'd need deal with >> CRL-like situations, etc. -- but with N peers (where N is a non-trivial >> number), this seems somewhat comparable administrative complexity to >> managing TCP-MD5 keys if the MD5 keys are never changed. > > If you don't have a PKI to manage certs, then certs are not appropriate for > this sort of context. Note that efforts are now beginning to establish a PKI > for address and AS number allocation, starting at the RIR level. (The > proposed PKI uses RFC 3779 extensions to represent address blocks and AS > numbers.) The AS number part is much easier than the address allocation > part, because there are fewer discrete allocations, and they are effected > only by registries. With certs issued by the registries to AS number holders, > ISPs can issue certs to routers and it is easy to tell if a router is > authorized to represent a specific AS. That PKI, if it is successful, would > address the trust anchor concern you cite above. Such PKIs would certainly simplify a number of things, but it's not clear yet how successful they are going to be. If we are going to depend on them in the design, the requirements could possibly say a few words on whether that kind of dependency is acceptable or not. >> IPsec does not really seem to provide even the same level of verification >> of ICMP error messages as that draft. RFC 4301 mainly focuses on requiring >> that the implementations must have configurable options which type/code etc >> ICMPs to listen to and which to discard. This is my reading of section 6.1 >> of RFC 4301. Section 6.2 (which provides a bit more checking) doesn't seem >> to apply in this situation very well assuming you don't configure an ICMP >> SAs for all the peers and ignore other ICMP errors. > > Yes, these are the relevant sections of 4301, but they have to be read in the > context of the access control mechanisms that IPsec already provides. IPsec > allows you to filter ICMP error messages, to make sure that they come from a > source consistent with the claimed address to which they refer in the > payload. Could you quote the specific text in RFC 4301 Section 6 that specifies this? I can't seem to find it. >> Hence, I don't see how IPsec would give additional protection against ICMP >> errors compared to non-IPsec TCP (w/ draft-gont-tcpm-icmp-attacks-05 >> checks). The protection might very well be even worse by default. > > When IPsec is introduced, it create a barrier that ALL traffic must traverse. > In a router, this barrier could be established around the router's management > host and thus would process any traffic, including ICMP traffic, directed to > that internal host. In the typical, not-multi-hop BGP peering case, you > would accept ICMP error messages relevant to the BGP TCP session to come only > from the peer router, and thus they can be authenticated, and filtered. ICMP error messages must be accepted from anywhere, with any source address. While the only ICMP error messages relevant to such a BGP TCP session would need to come from your peer, you'd need to have verification checks in the ICMP processing code that deals with this case when the ICMP error carries only an IP header and 8 bytes of payload. At the moment, I haven't been able to locate this text in RFC 4301. > I would disagree that it is safe, in general, to ignore attacks against links > between routers. GTSM is clever, but fails in the context of such attacks. > The existing TCP-MD5 checksum is poor cryptographically, but the bigger > problem is the lack of automated key management capability. I think it is > reasonable to start by addressing peering session security, on a > point-to-point basis, the move on to the harder, transitive security issues > associated with advertisements. I'd like to know if folks have actually asked what the BGP operators actually _want_. Unless I see a survey on this, I will continue to believe that less than 5% of operators see an urgent need for new mechanisms in the peering session security problem space. -- 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 Thu Jan 19 13:26:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzeUO-00014O-W2; Thu, 19 Jan 2006 13:26:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzeUN-00013F-IS for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 13:26:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13628 for ; Thu, 19 Jan 2006 13:25:01 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezecu-0000JU-Kb for rpsec@ietf.org; Thu, 19 Jan 2006 13:35:19 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JIQ0IC023312; Thu, 19 Jan 2006 13:26:01 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <43CED4F9.9070409@cisco.com> Date: Thu, 19 Jan 2006 13:26:05 -0500 To: Paul Jakma From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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: , Content-Type: multipart/mixed; boundary="===============1770701186==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org --===============1770701186== Content-Type: multipart/alternative; boundary="============_-1074427324==_ma============" --============_-1074427324==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 5:13 PM +0000 1/19/06, Paul Jakma wrote: >On Thu, 19 Jan 2006, Stephen Kent wrote: > >>yes, but vague comments about performance and manageability are >>just fodder for debate, not objective metrics that should be >>described as "requirements." :-) > >Indeed, agreed. Pekka's original comment though did point at a >better definition though: > >" In particular, the solution must not require that heavy processing > is required on all the BGP routers." > >I.e. I think the key point here is "on all the BGP routers" - not to >define 'heavy processing' (lets ignore degree of 'heavy' as you >suggest). > >Whether "on all" is or is not acceptable is the key. Some people >might prefer it not to be acceptable and hence have the requirements >allow for a solution in which the crypto-load can be off-loaded and >confined to a subset of routers. > >regards, >-- >Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A I'd suggest text more consistent with a goal flavor, e.g., Processing The introduction of mechanisms to improve routing security will generally increase the processing performed by a router. The increased processing typically will result from additional checks performed to determine the validity of UPDATEs, especially if these checks entail cryptographic operations. Since currently deployed routers generally do not have hardware to accelerate cryptographic operations, these operations could impose a significant processing burden under some circumstances. Thus proposed solutions should be evaluated carefully with regard to the processing burden they may impose, since deployment may be impeded if network operators perceive that a specific solution will impose an unacceptable processing burden. This text has the flavor of articulating a goal for solutions, and providing a rationale for that goal, but is not worded as a requirement. Steve --============_-1074427324==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03
At 5:13 PM +0000 1/19/06, Paul Jakma wrote:
On Thu, 19 Jan 2006, Stephen Kent wrote:
yes, but vague comments about performance and manageability are just fodder for debate, not objective metrics that should be described as "requirements." :-)

Indeed, agreed. Pekka's original comment though did point at a better definition though:

" In particular, the solution must not require that heavy processing
  is required on all the BGP routers."

I.e. I think the key point here is "on all the BGP routers" - not to define 'heavy processing' (lets ignore degree of 'heavy' as you suggest).

Whether "on all" is or is not acceptable is the key. Some people might prefer it not to be acceptable and hence have the requirements allow for a solution in which the crypto-load can be off-loaded and confined to a subset of routers.

regards,
--
Paul Jakma      paul@clubi.ie   paul@jakma.org  Key ID: 64A2FF6A

I'd suggest text more consistent with a goal flavor, e.g.,

Processing
The introduction of mechanisms to improve routing security will generally increase the processing performed by a router. The increased processing typically will result from additional checks performed to determine the validity of UPDATEs, especially if these checks entail cryptographic operations. Since currently deployed routers generally do not have hardware to accelerate cryptographic operations, these operations could impose a significant processing burden under some circumstances. Thus proposed solutions should be evaluated carefully with regard to the processing burden they may impose, since deployment may be impeded if network operators perceive that a specific solution will impose an unacceptable processing burden.
This text has the flavor of articulating a goal for solutions, and providing a rationale for that goal, but is not worded as a requirement.

Steve
--============_-1074427324==_ma============-- --===============1770701186== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1770701186==-- From rpsec-bounces@ietf.org Thu Jan 19 13:26:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzeUX-0001Hu-IY; Thu, 19 Jan 2006 13:26:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzeUU-0001HT-OK for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 13:26:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13649 for ; Thu, 19 Jan 2006 13:25:08 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezed4-0000K2-JV for rpsec@ietf.org; Thu, 19 Jan 2006 13:35:27 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JIQ0IE023312; Thu, 19 Jan 2006 13:26:02 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 19 Jan 2006 13:23:01 -0500 To: Pekka Savola From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 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: , Content-Type: multipart/mixed; boundary="===============1050957905==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org --===============1050957905== Content-Type: multipart/alternative; boundary="============_-1074427324==_ma============" --============_-1074427324==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 7:30 PM +0200 1/19/06, Pekka Savola wrote: >On Wed, 18 Jan 2006, Stephen Kent wrote: >>When I said UPDATE frequency I was considering this as well. When a >>session is reset and one receives a lot of UPDATEs from a peer, it >>is not necessary to verify the signatures on all of them, if one >>uses a mechanism based on signed UPDATEs. One shoud look at each >>UPDATE and ask "if this UPDATE is authentic, does it cause me to >>change my LocRIB?" If the answer is no, then there is no need to >>peform crypto verification on the UPDATE at that time. > >I'd say that in most cases the answer would be "yes". The whole >point of peering (unless the link is acting as a cold backup) is to >accept prefixes. Operators also tend to set preferences in the >incoming advertisements, making them preferable. I'm puzzled by this statement. Of course one peers with neighbor ASes to accept advertisements. But, not every advertisement will yield a better route than the current best route. Flapping is precisely a situation where a route oscillates because a sequence of advertisements causes this behavior. But we all want to avoid flapping, and try to achieve this via various means, e.g., through dampening, preference settings, etc. I used to assume that the worst case arose when a BGP router was at an exchange, with a lot of peers, and thus a lot of opportunities for UPDATEs to arrive quickly from each peer. However, I have been told by operators that this is not as bad as I had imagined. The reasoning is that the peers at an exchange are mostly downstream providers from whom the set of acceptable prefixes is fairly small and static and thus filtering (w/o use of crypto checks) would deal with most of these UPDATEs. >When such sessions (with 1,000-200,000 "yes, loc-rib update would be >needed" prefixes) flap, the resulting computation could be rather >intensive. Again, you refer to the number of prefixes involved, but the cost is more properly a function of the number of peers and the length of the paths in the advertisements, not the number of prefixes. >>... > >I maintain these issues are vital for deployment, but I don't think >it's productive to continue this discussion in this thread. Do you think the discussion will become easier or more productive if we put this type of language into the document? :-) > >>... > >Such PKIs would certainly simplify a number of things, but it's not >clear yet how successful they are going to be. If we are going to >depend on them in the design, the requirements could possibly say a >few words on whether that kind of dependency is acceptable or not. that's a reasonable suggestion. >>... >>Yes, these are the relevant sections of 4301, but they have to be >>read in the context of the access control mechanisms that IPsec >>already provides. IPsec allows you to filter ICMP error messages, >>to make sure that they come from a source consistent with the >>claimed address to which they refer in the payload. > >Could you quote the specific text in RFC 4301 Section 6 that >specifies this? I can't seem to find it. see the cites below. >... >ICMP error messages must be accepted from anywhere, with any source address. not in an IPsec protected environment. remember, IPsec is all about access control. we note that ICMP error messages arriving on the unprotected side of the boundary cannot generally be authenticated, and thus implementations MUST allow an admin to configure controls to reject this traffic, and to impose limits on the effects of messages, e.g., not allowing the PMTU to be set too low. > While the only ICMP error messages relevant to such a BGP TCP >session would need to come from your peer, you'd need to have >verification checks in the ICMP processing code that deals with this >case when the ICMP error carries only an IP header and 8 bytes of >payload. At the moment, I haven't been able to locate this text in >RFC 4301. Start of 6.2: When an ICMP error message is transmitted via an SA to a device "behind" an IPsec implementation, both the payload and the header of the ICMP message require checking from an access control perspective. ... Thus, an IPsec implementation MUST be configurable to check that this payload header information is consistent with the SA via which it arrives. (This means that the payload header, with source and destination address and port fields reversed, matches the traffic selectors for the SA.) This says that when an ICMP error message arrives on an SA from a peer, you look at the IP header carried within the message to verify that it refers to traffic that would have been carried on the matching, outbound SA. Thus, for example, a peer can send ICMP error messages that will be accepted ONLY if they refer to traffic that would have been sent to that peer. >>... > >I'd like to know if folks have actually asked what the BGP operators >actually _want_. Unless I see a survey on this, I will continue to >believe that less than 5% of operators see an urgent need for new >mechanisms in the peering session security problem space. At workshops on routing security conducted by DHS, the range of responses was pretty varied. Some operators said that they mandated use of the TCP MD5 facility for all their downstream peers, others said they refused to use it because of DoS concerns. I don't think there is consensus on this topic in the operator community. Steve --============_-1074427324==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03
At 7:30 PM +0200 1/19/06, Pekka Savola wrote:
On Wed, 18 Jan 2006, Stephen Kent wrote:
When I said UPDATE frequency I was considering this as well. When a session is reset and one receives a lot of UPDATEs from a peer, it is not necessary to verify the signatures on all of them, if one uses a mechanism based on signed UPDATEs. One shoud look at each UPDATE and ask "if this UPDATE is authentic, does it cause me to change my LocRIB?" If the answer is no, then there is no need to peform crypto verification on the UPDATE at that time.

I'd say that in most cases the answer would be "yes".  The whole point of peering (unless the link is acting as a cold backup) is to accept prefixes.  Operators also tend to set preferences in the incoming advertisements, making them preferable.

I'm puzzled by this statement. Of course one peers with neighbor ASes to accept advertisements. But, not every advertisement will yield a better route than the current best route. Flapping is precisely a situation where a route oscillates because a sequence of advertisements causes this behavior.  But we all want to avoid flapping, and try to achieve this via various means, e.g., through dampening, preference settings, etc.

I used to assume that the worst case arose when a BGP router was at an exchange, with a lot of peers, and thus a lot of opportunities for UPDATEs to arrive quickly from  each peer. However, I have been told by operators that this is not as bad as I had imagined. The reasoning is that the peers at an exchange are mostly downstream providers from whom the set of acceptable prefixes is fairly small and static and thus filtering (w/o use of crypto checks) would deal with most of these UPDATEs.

When such sessions (with 1,000-200,000 "yes, loc-rib update would be needed" prefixes) flap, the resulting computation could be rather intensive.

Again, you refer to the number of prefixes involved, but the cost is more properly a function of the number of peers and the length of the paths in the advertisements, not the number of prefixes.


...

I maintain these issues are vital for deployment, but I don't think it's productive to continue this discussion in this thread.

Do you think the discussion will become easier or more productive if we put this type of language into the document? :-)


...

Such PKIs would certainly simplify a number of things, but it's not clear yet how successful they are going to be.  If we are going to depend on them in the design, the requirements could possibly say a few words on whether that kind of dependency is acceptable or not.

that's a reasonable suggestion.
...
Yes, these are the relevant sections of 4301, but they have to be read in the context of the access control mechanisms that IPsec already provides. IPsec allows you to filter ICMP error messages, to make sure that they come from a source consistent with the claimed address to which they refer in the payload.

Could you quote the specific text in RFC 4301 Section 6 that specifies this?  I can't seem to find it.

see the cites below.

...
ICMP error messages must be accepted from anywhere, with any source address.

not in an IPsec protected environment. remember, IPsec is all about access control. we note that ICMP error messages arriving on the unprotected side of the boundary cannot generally be authenticated, and thus implementations MUST allow an admin to configure controls to reject this traffic, and to impose limits on the effects of messages, e.g., not allowing the PMTU to be set too low.

 While the only ICMP error messages relevant to such a BGP TCP session would need to come from your peer, you'd need to have verification checks in the ICMP processing code that deals with this case when the ICMP error carries only an IP header and 8 bytes of payload.  At the moment, I haven't been able to locate this text in RFC 4301.

Start of 6.2:

When an ICMP error message is transmitted via an SA to a device "behind" an IPsec implementation, both the payload and the header of
the ICMP message require checking from an access control perspective. ...

Thus, an IPsec implementation MUST be configurable to check that this payload header information is consistent with the SA via which it arrives. (This means that the payload header, with source and destination address and port fields reversed, matches the traffic selectors for the SA.)

This says that when an ICMP error message arrives on an SA from a peer, you look at the IP header carried within the message to verify that it refers to traffic that would have been carried on the matching, outbound SA. Thus, for example, a peer can send ICMP error messages that will be accepted ONLY if they refer to traffic that would have been sent to that peer.


...

I'd like to know if folks have actually asked what the BGP operators actually _want_.  Unless I see a survey on this, I will continue to believe that less than 5% of operators see an urgent need for new mechanisms in the peering session security problem space.

At workshops on routing security conducted by DHS, the range of responses was pretty varied. Some operators said that they mandated use of the TCP MD5 facility for all their downstream peers, others said they refused to use it because of DoS concerns. I don't think there is consensus on this topic in the operator community.

Steve
--============_-1074427324==_ma============-- --===============1050957905== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============1050957905==-- From rpsec-bounces@ietf.org Thu Jan 19 13:31:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzeZc-0002Mj-Vk; Thu, 19 Jan 2006 13:31:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzeZb-0002MY-Nx for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 13:31:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14264 for ; Thu, 19 Jan 2006 13:30:25 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezei7-0000ZL-Qr for rpsec@ietf.org; Thu, 19 Jan 2006 13:40:44 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2006 10:31:38 -0800 X-IronPort-AV: i="3.99,385,1131350400"; d="scan'208"; a="1768221860:sNHT31516664" Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0JIVWc2005758; Thu, 19 Jan 2006 10:31:37 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 13:31:37 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 13:31:37 -0500 Message-ID: <43CFDAFE.8050800@cisco.com> Date: Thu, 19 Jan 2006 13:31:26 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sandy@tislabs.com Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <200601191614.k0JGEjGf025912@tislabs.com> In-Reply-To: <200601191614.k0JGEjGf025912@tislabs.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I would like to speak against including hardware and software limitations > as bgp security requirements. > I believe that these are very important issues. I just don't think that > they constitute security requirements. They could be called > deployment considerations, or solution requirements, or some such. > So I'd say these issues should be a separate section of the document > that talks about considerations of deployment, or barriers to > deployment (though that latter might be "unnecessarily pejorative" as > someone I know likes to say). The main problem here is that you end up considering them "second class citizens." In other words, you end up saying that securing "BGP processing" is somehow more valid than ralizing the impact securing that processing might have. Of course, a lot of this comes down to whether you believe that security is primarily focused on making existing specifications "secure," or about securing systems, with the inherent tradeoffs that entails. You secure networks, not specifications, in the real world, something we should probably keep in mind. :-) Anyway, IMHO, if we move this stuff all to a seperate section, we need to make certain it's clear in the document that this doesn't make them secondary concerns, or secondary issues, that aren't as important as the "primary issue" of "making the BGP specification secure." > It would be best if the bgp security requirements did not prevent > consideration of a solution that would be acceptable to some portions > of the Internet or to specific networks, either now or N years from now. Would you say it shouldn't favor solutions that can be deployed today, however? > Note also: the suggested new text as stated says that heavy processing > must not be required of "all routers". But since there is already a > requirement addressing tolerance of incremental deployment, there's > already a requirement that not all routers participate. So the text > as stated is obviated by other text. If you really did mean the "all" > part of "must not require that heavy processing is required on all the > BGP routers", then we don't need this requirement. These are not orthogonal, they are complimentary. You don't get rid of red because you have blue, you mix the two to make purple. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8/bCREdu7FIVPTkEQKouwCeMm23Nukkhq21ov2zJMsVJgJScdUAoPhz lUK4AxVbcgHdi2sgSWpD8qSD =clqi -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 13:32:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzeaP-0002Z8-MS; Thu, 19 Jan 2006 13:32:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzeaO-0002Yg-43 for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 13:32:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14383 for ; Thu, 19 Jan 2006 13:31:14 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezeix-0000bb-Er for rpsec@ietf.org; Thu, 19 Jan 2006 13:41:32 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2006 10:32:29 -0800 X-IronPort-AV: i="4.01,201,1136188800"; d="scan'208"; a="250108261:sNHT31165400" Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0JIWRc2006276; Thu, 19 Jan 2006 10:32:28 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 13:32:29 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 13:32:29 -0500 Message-ID: <43CFDB36.1060306@cisco.com> Date: Thu, 19 Jan 2006 13:32:22 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sandy@tislabs.com Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <200601191607.k0JG7Ota025473@tislabs.com> In-Reply-To: <200601191607.k0JG7Ota025473@tislabs.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>Just because something isn't easy to define doesn't mean it's not a >>requirement, IMHO. :-) > > There are lots of requirements we all vaguely understand ("run a > secure operation", "secure the protocols", "be happy", ...) > but writing a specification of a requirement should be much more > crisply stated. > > Otherwise, future solution designs compared against the requirements > will lead to an endless round of "Yes, it is -- No, it isn't -- Is, too > -- No way" with no way to resolve the dispute. And, if you don't state what performance impacts are acceptable, then you wind up with a perfect, but perfectly undeployable, solution. Performance impacts, while always difficult to measure and consider, still need to be taken into consideration. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8/bPREdu7FIVPTkEQLu7QCg1gvFCvWHaksLjme67MShGELejwIAn1V9 /9+JkzBK/+1oezAUrFAZq70N =NJEt -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 13:39:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzehT-0006sE-SA; Thu, 19 Jan 2006 13:39:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzehR-0006qk-VV for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 13:39:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15147 for ; Thu, 19 Jan 2006 13:38:31 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezeq2-0000wf-6H for rpsec@ietf.org; Thu, 19 Jan 2006 13:48:50 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2006 10:39:49 -0800 X-IronPort-AV: i="3.99,385,1131350400"; d="scan'208"; a="1768224406:sNHT32129500" Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0JIdlQK005780; Thu, 19 Jan 2006 10:39:48 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 13:39:48 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 13:39:48 -0500 Message-ID: <43CFDCED.70303@cisco.com> Date: Thu, 19 Jan 2006 13:39:41 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> <43CFAF81.90608@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Just because something isn't easy to define doesn't mean it's not a >> requirement, IMHO. :-) > > Requirements need to be objectively testable to be useful. So, "easy to > define" is not show stopper, but impossible to define in an objective, > testable fashion is. > > So far the discussion yielded wording for these criteria that are > objectively testable, and not simultaneously silly. So, for example, a > simple statement like "Any security mechanism MUST/SHOULD NOT degrade > router performance" is objectively testable, but its also silly; years > of experience indicate that the introduction of any just about security > mechanism in any computing or communication environment will add some > overhead. So, then, what you want to be able to say is something more specific. For instance, "a pair of BGP speakers MUST be able to exchange and install routes no slower than twice the rate at which those speakers would exchange and install routes without the security mechanism installed with no additional hardware installed (additional off box hardware is allowed)...." Or some such, insert what amount of slower convergence operators are willing to live with here. You could get to the point of being so specific as to be unproductive with this sort of thing, as well, for two reasons: - -- It's unproductive to standardize a test on which a standard will built; everyone will argue over the test, rather than the actual mechanism being designed (witness the current nonsense in the OSPF MANET work, where the focus is on the results of simulation, rather than actual protocol design). - -- Everyone will build their system "to the test," defeating the purpose of the test in the first place ("Vendor X beats vendor Y in our in house forwarding tests") >> There's no such things as an AdjRIB in any implementation of BGP that >> I'm aware of--well, you might want to count the soft reset tables in >> Cisco IOS as an "adjrib," but, in reality, we (Cisco) strongly suggest >> customers not to use that feature at all, but rely on route refresh, >> instead. In fact, I'm not aware of a single BGP implementation that >> strictly follows the model implementation described in the BGP >> specification(s). > > I asked the question because the BGP spec (RFC 4271) specifically > distinguishes AdjRIBs from the LocRIB as part of the model for BGP > operation. A compliant implementation must behave in a fashion > consistent with this abstract model, irrespective of how the functions > are implemented. > > However you implement BGP, there still needs to be a distinction between > an advertisement from a peer that is NOT the best route for a given set > of NLRI at the time the advertisement is received, but which still needs > to be maintained in case the current best route is withdrawn. One also > needs to mark each route based on which peer advertised it, to ensure > than only the peer that advertised the route can withdraw it. Given > these requirements, it is still possible to do what I described, i.e., > don't spend time validating a route which does not appear to be the best > route for a given set of NLRI. Perhaps, perhaps not, in all conditions. We're digging into the efficiency of a particular proposed solution, however, which really isn't necessarily good territory to get into, here. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8/c9BEdu7FIVPTkEQKbuACfeB1NcXcjUQAfOFWqQCZ55770bFMAn3Ri lxd50nYhzZ7ai+4t2Mqkyqih =JKDH -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 13:54:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzevL-0004wh-Ls; Thu, 19 Jan 2006 13:54:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzevK-0004wZ-9o for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 13:54:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16094 for ; Thu, 19 Jan 2006 13:52:52 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezf3u-0001Nb-OL for rpsec@ietf.org; Thu, 19 Jan 2006 14:03:11 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2006 10:54:09 -0800 X-IronPort-AV: i="4.01,201,1136188800"; d="scan'208"; a="250111761:sNHT32718966" Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0JIs7c2014887; Thu, 19 Jan 2006 10:54:08 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 13:54:09 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 13:54:09 -0500 Message-ID: <43CFE049.1030901@cisco.com> Date: Thu, 19 Jan 2006 13:54:01 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'm puzzled by this statement. Of course one peers with neighbor ASes to > accept advertisements. But, not every advertisement will yield a better > route than the current best route. Flapping is precisely a situation > where a route oscillates because a sequence of advertisements causes > this behavior. But we all want to avoid flapping, and try to achieve > this via various means, e.g., through dampening, preference settings, etc. > > I used to assume that the worst case arose when a BGP router was at an > exchange, with a lot of peers, and thus a lot of opportunities for > UPDATEs to arrive quickly from each peer. However, I have been told by > operators that this is not as bad as I had imagined. The reasoning is > that the peers at an exchange are mostly downstream providers from whom > the set of acceptable prefixes is fairly small and static and thus > filtering (w/o use of crypto checks) would deal with most of these UPDATEs. Again, this is directed at the efficiency of a specific proposed mechanism, which really isn't a good direction to be taking on this list, but I'll try to answer this to some degree or another. This assumes two things about BGP implementations that aren't true, the first of which is good for this specific proposed solution, the second of which is very bad. In a real startup mode, no BGP implementations actually process routes as they are received. They store routes, and wait until all their peers are finished talking, then process routes, and then send what their best paths are. The bad thing is that you aren't likely to receive the route you're going to end up preferring in the first set of routes you receive. Statistically, the route you're going to end up preferring will probably come about half way through the advertisements you're receiving. In the startup case, this probably doesn't matter. In other cases, where you lose a large number of peers, but not all of them, it can matter a great deal. I would point out that we can't assume, from the beginning, that all routing information is going to wind up as "completely trustable" or "completely garbage." I think that's been an assumption throughout, but it's obviously not true, when you consider incremental deployments. For instance, suppose you have two routes, one of which you can "validate," in some way, three of the AS' in the AS Path. In the other route, you can "validate" only two of the AS' in the AS Path. Is it reasonable to expect the provider to be able to choose between these two routes, based on the degree to which the AS Paths can be validated, in some way? Or should the security system require that both routes be treated equally, since some part of the AS Path can be "validated?" If the first is true, then this concept of "I'll find my best path, and then validate it just before I install it," falls apart, in many circumstances. How well a route can be "validated" becomes a part of the decision process itself. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8/gUREdu7FIVPTkEQICNQCgtPTg+cq9tPcZeQgapLiSNWGR3/oAoMK0 Hsm71Ep+C9JEuoOOPw2o6KrA =uzCH -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 14:37:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzfbX-0004y0-EK; Thu, 19 Jan 2006 14:37:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzfbV-0004vz-9z for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 14:37:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20669 for ; Thu, 19 Jan 2006 14:36:26 -0500 (EST) From: sandy@tislabs.com Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezfk5-0002fU-38 for rpsec@ietf.org; Thu, 19 Jan 2006 14:46:46 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0JJbKcV027832 for ; Thu, 19 Jan 2006 14:37:20 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVAayb2; Thu, 19 Jan 06 14:36:47 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0JJc0ls006454; Thu, 19 Jan 2006 14:38:00 -0500 (EST) Date: Thu, 19 Jan 2006 14:38:00 -0500 (EST) Message-Id: <200601191938.k0JJc0ls006454@tislabs.com> To: riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org >> It would be best if the bgp security requirements did not prevent >> consideration of a solution that would be acceptable to some portions >> of the Internet or to specific networks, either now or N years from now. > >Would you say it shouldn't favor solutions that can be deployed today, >however? If we identify a feature as a security requirement and it turns out that the only solution meeting that requirement is not deployable everywhere then we have lots of options: (1) deploy it where it can be deployed with consideration of what that means system wide (2) institute immediate and urgent action on three fronts (a) a research into a solution (b) improvements to existing environment so it is deployable (c) research into new securable routing protocol >you believe that security is primarily focused on making existing >specifications "secure," or about securing systems, You can stipulate requirements for a protocol, then require that any proposed solution must state how requirements that were not met by the solution would be handled by other considerations - like operational practices, for example. I do not favor identifying requirements, looking at the difficulty at meeting them, and throwing out requirements that cannot be *CURRENTLY* met. (A requirement for solving the halting problem would therefore not be considered.) >These are not orthogonal, they are complimentary. You don't get rid of >red because you have blue, you mix the two to make purple. I did not say orthogonal, I said obviated. One part of the doc says "not all routers have to participate" and the other part says "the solution must not require X of all routers". Well, of course the solution won't require X of all routers, because not all routers have to participate. One part of the document makes the other statement unnecessary. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 15:04:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezg0m-0004sV-7c; Thu, 19 Jan 2006 15:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezg0j-0004s6-Uv for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 15:03:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22497 for ; Thu, 19 Jan 2006 15:02:30 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezg9J-0003Tk-Dx for rpsec@ietf.org; Thu, 19 Jan 2006 15:12:50 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JK3dIC029707; Thu, 19 Jan 2006 15:03:40 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43CFDB36.1060306@cisco.com> References: <200601191607.k0JG7Ota025473@tislabs.com> <43CFDB36.1060306@cisco.com> Date: Thu, 19 Jan 2006 14:11:06 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 1:32 PM -0500 1/19/06, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>>Just because something isn't easy to define doesn't mean it's not a >>>requirement, IMHO. :-) >> >> There are lots of requirements we all vaguely understand ("run a >> secure operation", "secure the protocols", "be happy", ...) >> but writing a specification of a requirement should be much more >> crisply stated. >> >> Otherwise, future solution designs compared against the requirements >> will lead to an endless round of "Yes, it is -- No, it isn't -- Is, too >> -- No way" with no way to resolve the dispute. > >And, if you don't state what performance impacts are acceptable, then >you wind up with a perfect, but perfectly undeployable, solution. >Performance impacts, while always difficult to measure and consider, >still need to be taken into consideration. Russ, I think this WG cannot state what performance impacts are acceptable. You attended the same DHS routing security workshops that I did. You saw the tremendous range of views on what constitutes acceptable performance impacts even for an existing security mechanism, i.e., the TCP MD5 option. The best we can do is to note that performance impacts are a concern because they probably will influence deployment decisions, and that SIDR should keep this in mind when evaluating solution options. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 15:04:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezg0m-0004su-NQ; Thu, 19 Jan 2006 15:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezg0j-0004s3-KR for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 15:03:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22496 for ; Thu, 19 Jan 2006 15:02:30 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezg9J-0003To-E1 for rpsec@ietf.org; Thu, 19 Jan 2006 15:12:50 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JK3dIE029707; Thu, 19 Jan 2006 15:03:40 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43CFDCED.70303@cisco.com> References: <43CED4F9.9070409@cisco.com> <43CFAF81.90608@cisco.com> <43CFDCED.70303@cisco.com> Date: Thu, 19 Jan 2006 14:30:09 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Russ, >... > >So, then, what you want to be able to say is something more specific. >For instance, "a pair of BGP speakers MUST be able to exchange and >install routes no slower than twice the rate at which those speakers >would exchange and install routes without the security mechanism >installed with no additional hardware installed (additional off box >hardware is allowed)...." Or some such, insert what amount of slower >convergence operators are willing to live with here. you could do that in an effort to satisfy the objective testability criteria I mentioned, but we probably would not get consensus on the parameters. > >You could get to the point of being so specific as to be unproductive >with this sort of thing, as well, for two reasons: > >- -- It's unproductive to standardize a test on which a standard will >built; everyone will argue over the test, rather than the actual >mechanism being designed (witness the current nonsense in the OSPF MANET >work, where the focus is on the results of simulation, rather than >actual protocol design). we're not talking about a standard test, but rather requirements that are testable. most IETF standards do not address performance explicitly, and I think we are seeing the problems that can arise when we try to make performance metrics requirements. >- -- Everyone will build their system "to the test," defeating the purpose >of the test in the first place ("Vendor X beats vendor Y in our in house >forwarding tests") I think this would be a more serious concern if we were talking about test cases, vs. performance metrics, but I agree that this is a possible trap. >... > > >> However you implement BGP, there still needs to be a distinction between >> an advertisement from a peer that is NOT the best route for a given set >> of NLRI at the time the advertisement is received, but which still needs >> to be maintained in case the current best route is withdrawn. One also >> needs to mark each route based on which peer advertised it, to ensure >> than only the peer that advertised the route can withdraw it. Given >> these requirements, it is still possible to do what I described, i.e., >> don't spend time validating a route which does not appear to be the best >> route for a given set of NLRI. > >Perhaps, perhaps not, in all conditions. We're digging into the >efficiency of a particular proposed solution, however, which really >isn't necessarily good territory to get into, here. I'm happy to avoid detailed discussions of specific proposals, so long as other don't head down that path. But, if we try to make performance criteria into requirements we may be drawn into that arena. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 15:04:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezg11-0004ts-Na; Thu, 19 Jan 2006 15:04:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezg0z-0004tn-MT for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 15:04:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22520 for ; Thu, 19 Jan 2006 15:02:47 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezg9a-0003UY-N0 for rpsec@ietf.org; Thu, 19 Jan 2006 15:13:07 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JK3dII029707; Thu, 19 Jan 2006 15:03:43 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43CFE049.1030901@cisco.com> References: <43CFE049.1030901@cisco.com> Date: Thu, 19 Jan 2006 14:51:05 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Russ, >... >Again, this is directed at the efficiency of a specific proposed >mechanism, which really isn't a good direction to be taking on this >list, but I'll try to answer this to some degree or another. Actually my analysis is applicable to ANY solution that expends resources to validate a received UPDATE. It is more important if the UPDATE validation processing might be resource intensive, but it applicable in any case. >This assumes two things about BGP implementations that aren't true, the >first of which is good for this specific proposed solution, the second >of which is very bad. In a real startup mode, no BGP implementations >actually process routes as they are received. They store routes, and >wait until all their peers are finished talking, then process routes, >and then send what their best paths are. your characterization seems a bit incomplete, in that it does not say how a router tells when a peer has no more UPDATEs to send, e.g., a timer. also, my analysis was not limited to startup mode. >The bad thing is that you aren't likely to receive the route you're >going to end up preferring in the first set of routes you receive. >Statistically, the route you're going to end up preferring will probably >come about half way through the advertisements you're receiving. In the >startup case, this probably doesn't matter. In other cases, where you >lose a large number of peers, but not all of them, it can matter a great >deal. I do not understand the argument above. If, upon startup, a router waits for all (active) peers to "finish talking", as you said, then at the end of that interval there is exactly one route that is the best route for each prefix, right? Only UPDATEs that arrive later, after the end of the "finished talking" interval, could offer routes that are new and potentially better that the current best route. So, where does 50% enter into this calculation? >I would point out that we can't assume, from the beginning, that all >routing information is going to wind up as "completely trustable" or >"completely garbage." I think that's been an assumption throughout, but >it's obviously not true, when you consider incremental deployments. For >instance, suppose you have two routes, one of which you can "validate," >in some way, three of the AS' in the AS Path. In the other route, you >can "validate" only two of the AS' in the AS Path. I've not made the assumption you cited. Your text, however, includes an assumption that a portion of a route may be amenable to validation. Incremental deployment may or may not yield such situations, depending on the mechanism in question. >Is it reasonable to expect the provider to be able to choose between >these two routes, based on the degree to which the AS Paths can be >validated, in some way? Or should the security system require that both >routes be treated equally, since some part of the AS Path can be >"validated?" If the first is true, then this concept of "I'll find my >best path, and then validate it just before I install it," falls apart, >in many circumstances. How well a route can be "validated" becomes a >part of the decision process itself. In general, in configuring security mechanisms, people have found that management complexity can easily overwhelm the intended security benefits of the mechanisms. Thus we have to be careful to not expect operators to accurately configure potentially complex validation parameters in order to take advantage of the info that may be available due to partial deployment of a routing security mechanism, dealing with routes that are not merely valid or unknown. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 15:22:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzgIj-0006IW-Ql; Thu, 19 Jan 2006 15:22:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzgIi-0006IO-95 for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 15:22:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23908 for ; Thu, 19 Jan 2006 15:21:05 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzgRJ-00044b-37 for rpsec@ietf.org; Thu, 19 Jan 2006 15:31:25 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2006 12:22:22 -0800 X-IronPort-AV: i="4.01,201,1136188800"; d="scan'208"; a="250140602:sNHT32619676" Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0JKMKc2027860; Thu, 19 Jan 2006 12:22:21 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 15:22:22 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 15:22:22 -0500 Message-ID: <43CFF4F7.1010800@cisco.com> Date: Thu, 19 Jan 2006 15:22:15 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CFE049.1030901@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> This assumes two things about BGP implementations that aren't true, >> the first of which is good for this specific proposed solution, the >> second of which is very bad. In a real startup mode, no BGP >> implementations actually process routes as they are received. They >> store routes, and wait until all their peers are finished talking, >> then process routes, and then send what their best paths are. > your characterization seems a bit incomplete, in that it does not say > how a router tells when a peer has no more UPDATEs to send, e.g., a > Correct. I wasn't trying for a tutorial on how BGP is implemented, just giving a general overview. :-) > timer. also, my analysis was not limited to startup mode. >> The bad thing is that you aren't likely to receive the route you're >> going to end up preferring in the first set of routes you receive. >> Statistically, the route you're going to end up preferring will >> probably come about half way through the advertisements you're >> receiving. In the startup case, this probably doesn't matter. In >> other cases, where you lose a large number of peers, but not all of >> them, it can matter a great deal. > > I do not understand the argument above. If, upon startup, a router > waits for all (active) peers to "finish talking", as you said, then > at the end of that interval there is exactly one route that is the > best route for each prefix, right? Only UPDATEs that arrive later, > after the end of the "finished talking" interval, could offer routes > that are new and potentially better that the current best route. So, > where does 50% enter into this calculation? To repeat: >> In other cases, where you lose a large number of peers, but not all >> of them, it can matter a great deal. And, as you said: > timer. also, my analysis was not limited to startup mode. >> I would point out that we can't assume, from the beginning, that >> all routing information is going to wind up as "completely >> trustable" or "completely garbage." I think that's been an >> assumption throughout, but it's obviously not true, when you >> consider incremental deployments. For instance, suppose you have >> two routes, one of which you can "validate," in some way, three of >> the AS' in the AS Path. In the other route, you can "validate" only >> two of the AS' in the AS Path. > > I've not made the assumption you cited. Your text, however, includes > an assumption that a portion of a route may be amenable to > validation. Incremental deployment may or may not yield such > situations, depending on the mechanism in question. First, I believe all currently proposed solutions can have this property. Second, I think it would actually be hard to design a system that doesn't have this property, unless the system arbitrarily places this type of partial validation out of bounds for some reason. >> Is it reasonable to expect the provider to be able to choose >> between these two routes, based on the degree to which the AS Paths >> can be validated, in some way? Or should the security system >> require that both routes be treated equally, since some part of the >> AS Path can be "validated?" If the first is true, then this concept >> of "I'll find my best path, and then validate it just before I >> install it," falls apart, in many circumstances. How well a route >> can be "validated" becomes a part of the decision process itself. > > In general, in configuring security mechanisms, people have found > that management complexity can easily overwhelm the intended security > benefits of the mechanisms. Thus we have to be careful to not expect > operators to accurately configure potentially complex validation > parameters in order to take advantage of the info that may be > available due to partial deployment of a routing security mechanism, > dealing with routes that are not merely valid or unknown. Parameters are different from policy. Providers today deal with much more complex policy than this--and I wouldn't preclude the use of possibly policies just because the designer of the system thinks the users of that system will find them "too complicated." :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8/0/hEdu7FIVPTkEQIQiACgs/qKLXpmEo3+xmTIfbxIeryRI4kAoOft Gp+cp1Zx95S3tZyjU96BK0ck =y1LG -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 15:26:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzgMG-0007J6-Rd; Thu, 19 Jan 2006 15:26:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzgMF-0007IL-ER for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 15:26:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24082 for ; Thu, 19 Jan 2006 15:24:44 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzgUp-00049b-K9 for rpsec@ietf.org; Thu, 19 Jan 2006 15:35:05 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2006 12:26:01 -0800 X-IronPort-AV: i="4.01,201,1136188800"; d="scan'208"; a="1768266026:sNHT31447832" Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0JKPwc2029015; Thu, 19 Jan 2006 12:25:59 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 15:26:00 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 15:26:00 -0500 Message-ID: <43CFF5D1.6080509@cisco.com> Date: Thu, 19 Jan 2006 15:25:53 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <200601191607.k0JG7Ota025473@tislabs.com> <43CFDB36.1060306@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I think this WG cannot state what performance impacts are acceptable. > You attended the same DHS routing security workshops that I did. You saw > the tremendous range of views on what constitutes acceptable performance > impacts even for an existing security mechanism, i.e., the TCP MD5 > option. The best we can do is to note that performance impacts are a > concern because they probably will influence deployment decisions, and > that SIDR should keep this in mind when evaluating solution options. Was the performance of encryption not taken into account when designing such solutions as IPsec? Let me put it another way: I don't believe it's the right thing just to rule out discussing performance impacts, which the users of any proposed system are obviously concerned about, just because they cannot be "specified cripsly." If we only specified things we could "specify crisply," then half of what we work on could never be specified. I do believe it's useful to have a discussion about how to contain the performance requirements within some text that implementors and designers will understand. I don't beleive it's useful to simply remove such text because it's "hard to specify." :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8/12BEdu7FIVPTkEQIsYwCg7WM2tzVgaXT2nMzRbfZf3RRF7eMAn1Gw 51jQzu5aEEmcs7MmCOZJOzVL =PYVs -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 15:29:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzgP3-0007j0-2T; Thu, 19 Jan 2006 15:29:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzgP1-0007iv-LE for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 15:29:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAB24250 for ; Thu, 19 Jan 2006 15:27:36 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzgXc-0004Dv-T5 for rpsec@ietf.org; Thu, 19 Jan 2006 15:37:57 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2006 12:28:54 -0800 X-IronPort-AV: i="4.01,201,1136188800"; d="scan'208"; a="250141752:sNHT74778860" Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0JKSqc2000205; Thu, 19 Jan 2006 12:28:53 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 15:28:54 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 15:28:54 -0500 Message-ID: <43CFF67F.3030205@cisco.com> Date: Thu, 19 Jan 2006 15:28:47 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> <43CFAF81.90608@cisco.com> <43CFDCED.70303@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> So, then, what you want to be able to say is something more specific. >> For instance, "a pair of BGP speakers MUST be able to exchange and >> install routes no slower than twice the rate at which those speakers >> would exchange and install routes without the security mechanism >> installed with no additional hardware installed (additional off box >> hardware is allowed)...." Or some such, insert what amount of slower >> convergence operators are willing to live with here. > > you could do that in an effort to satisfy the objective testability > criteria I mentioned, but we probably would not get consensus on the > parameters. I believe you could, actually, reach concensus on a very loosely worded test of this type. You must be careful not to jump too far down into details, but it might be a useful excercise to see if we can build wording that is "crisper" to make those unhappy about the "looseness" of the current wording happy, while at the same time leaving the concept open enough to interpretation to make a range of tests under a range of conditions useful. I would prefer to examine the performance impacts by examining the real world impacts of any given solution on actual implementations, but that's a completely different measure, and is harder to quantify. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ8/2hhEdu7FIVPTkEQLJPgCgmk+rcELqIlIa1Z8ik+BiN1DAfEMAnRPz +3SjvSvv2y1Y14HzFBDcYecH =VipL -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 16:15:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezh7q-0001M4-BV; Thu, 19 Jan 2006 16:15:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezh7o-0001Lt-Vs for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 16:15:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27674 for ; Thu, 19 Jan 2006 16:13:53 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzhGP-0005qO-M7 for rpsec@ietf.org; Thu, 19 Jan 2006 16:24:15 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2006 13:15:10 -0800 X-IronPort-AV: i="4.01,201,1136188800"; d="scan'208"; a="250152267:sNHT32394872" Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0JLF9QK001374; Thu, 19 Jan 2006 13:15:10 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 16:15:10 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 16:15:10 -0500 Message-ID: <43D00158.1040402@cisco.com> Date: Thu, 19 Jan 2006 16:15:04 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sandy@tislabs.com Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <200601191938.k0JJc0ls006454@tislabs.com> In-Reply-To: <200601191938.k0JJc0ls006454@tislabs.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>Would you say it shouldn't favor solutions that can be deployed today, >>however? > > If we identify a feature as a security requirement and it turns out > that the only solution meeting that requirement is not deployable > everywhere then we have lots of options: > (1) deploy it where it can be deployed with consideration of what > that means system wide > (2) institute immediate and urgent action on three fronts > (a) a research into a solution > (b) improvements to existing environment so it is deployable > (c) research into new securable routing protocol So, rather than doing what can be done, you'd rather set the requirements so they are "perfect," without any consideration for deployability, and then deploy nothing for several years, until the entire infrastructure of the Internet and all connected networks can be replaced? I consider this view a bit unrealistic. Further, I consider the deployability part of the set of requirements that would make any such proposal "perfect." What you appear to be arguing for is to place a specific piece of the problem--"security requirements"--above the remainder of the requirements. I would actually boil this down to: "we should place securing BGP processing above actually securing the BGP component (or subsystem) of networks on which BGP runs." I assume, from this line of argument, that IPsec is the most perfect system possible for protecting data transported in IP packets, and it's just a happy coincidence that it's actually deployable.... Somehow, I don't think anyone is going to tell me that IPsec was actually designed without regard to the impacts on the systems deploying it. :-) > One part of the doc says "not all routers have to participate" > and the other part says "the solution must not require X of > all routers". Well, of course the solution won't require X of > all routers, because not all routers have to participate. > One part of the document makes the other statement unnecessary. Then we should modify the part that says: "Don't require X of all routers," to: "don't require X of all routers on which the proposed solution is running." :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9ABXhEdu7FIVPTkEQIIfQCgumfHGobw9LlHx8osd3jVoanJ3pcAoJr7 IqBhXRWq52argf9JuyDNgift =ZKwQ -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 16:18:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzhAZ-0001WH-MJ; Thu, 19 Jan 2006 16:18:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzhAY-0001WC-Ex for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 16:18:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27826 for ; Thu, 19 Jan 2006 16:16:42 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzhJ8-0005uG-K3 for rpsec@ietf.org; Thu, 19 Jan 2006 16:27:03 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2006011921174801100dj08ue>; Thu, 19 Jan 2006 21:17:52 +0000 In-Reply-To: References: <43CED4F9.9070409@cisco.com> <43CFAF81.90608@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <904DFE90-6771-4826-AF0C-7363CC1AAC5C@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Date: Thu, 19 Jan 2006 13:17:33 -0800 To: Stephen Kent X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Steve, > However you implement BGP, there still needs to be a distinction > between an advertisement from a peer that is NOT the best route for > a given set of NLRI at the time the advertisement is received, but > which still needs to be maintained in case the current best route > is withdrawn. One also needs to mark each route based on which peer > advertised it, to ensure than only the peer that advertised the > route can withdraw it. Given these requirements, it is still > possible to do what I described, i.e., don't spend time validating > a route which does not appear to be the best route for a given set > of NLRI. That may be possible, but it is unlikely to be the best implementation approach. Any path that is accepted by the system may, at some point in the future, become the best path. An implementation COULD choose to defer validation until a path is selected, but this would cause computational load to be transferred to a convergence event, thus impacting overall convergence times. Thus, a more sophisticated approach is to attempt to validate all authenticated paths, but to do so with background processing. IMHO, this is an architectural requirement for any tractable and deployable solution: it must be possible to temporally decouple security processing from the remainder of BGP processing so that the security overhead can be shifted out of the convergence window. Regards, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 16:54:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzhjT-0007jM-Qh; Thu, 19 Jan 2006 16:54:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzhjR-0007j9-OQ for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 16:54:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00400 for ; Thu, 19 Jan 2006 16:52:46 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezhrq-000709-HR for rpsec@ietf.org; Thu, 19 Jan 2006 17:02:55 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JLrRIC006301; Thu, 19 Jan 2006 16:53:28 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43CFF4F7.1010800@cisco.com> References: <43CFE049.1030901@cisco.com> <43CFF4F7.1010800@cisco.com> Date: Thu, 19 Jan 2006 15:38:02 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Russ, >... > > >Correct. I wasn't trying for a tutorial on how BGP is implemented, just >giving a general overview. :-) and the answer to my question is ...? >... > > I do not understand the argument above. If, upon startup, a router >> waits for all (active) peers to "finish talking", as you said, then >> at the end of that interval there is exactly one route that is the >> best route for each prefix, right? Only UPDATEs that arrive later, >> after the end of the "finished talking" interval, could offer routes >> that are new and potentially better that the current best route. So, >> where does 50% enter into this calculation? > >To repeat: > >>> In other cases, where you lose a large number of peers, but not all > >> of them, it can matter a great deal. that's not an answer to my question >... > > >> I've not made the assumption you cited. Your text, however, includes >> an assumption that a portion of a route may be amenable to >> validation. Incremental deployment may or may not yield such >> situations, depending on the mechanism in question. > >First, I believe all currently proposed solutions can have this >property. Second, I think it would actually be hard to design a system >that doesn't have this property, unless the system arbitrarily places >this type of partial validation out of bounds for some reason. S-BGP can be incrementally deployed, but we made a decision long ago to NOT try to provide partial path validation, for two good (not arbitrary) reasons: - to take advantage of partial path validation the configuration of routers would be very complex - since a side effect of adding signatures to UPDATEs is consumption of more memory in the RIB(s), it seemed likely that ASes that did not deploy the technology would not have enough memory to hold the signatures for which they had no use > >... > >Parameters are different from policy. Providers today deal with much >more complex policy than this--and I wouldn't preclude the use of >possibly policies just because the designer of the system thinks the >users of that system will find them "too complicated." Policies are human expressions of criteria, that have to be translated into machine-interpretable language for enforcement by machines. Parameters are often the means by which such language is represented, e.g., ACLs, firewall filter rules, etc. The 1998 NRC report "Trust in Cyberspace" notes that many computer and network security problems that we experience are attributable to an inability by administrators (and users) to manage security controls for complex environments. I think what we are discussing here is a perfect example of that. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 17:20:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezi8e-0000Pf-Ai; Thu, 19 Jan 2006 17:20:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezi8b-0000PI-Ga for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 17:20:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02706 for ; Thu, 19 Jan 2006 17:18:44 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EziH8-0007vb-Lt for rpsec@ietf.org; Thu, 19 Jan 2006 17:29:05 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JMJsIG007834; Thu, 19 Jan 2006 17:19:58 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <904DFE90-6771-4826-AF0C-7363CC1AAC5C@tony.li> References: <43CED4F9.9070409@cisco.com> <43CFAF81.90608@cisco.com> <904DFE90-6771-4826-AF0C-7363CC1AAC5C@tony.li> Date: Thu, 19 Jan 2006 17:19:34 -0500 To: Tony Li From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 1:17 PM -0800 1/19/06, Tony Li wrote: >Steve, > >>However you implement BGP, there still needs to be a distinction >>between an advertisement from a peer that is NOT the best route for >>a given set of NLRI at the time the advertisement is received, but >>which still needs to be maintained in case the current best route >>is withdrawn. One also needs to mark each route based on which peer >>advertised it, to ensure than only the peer that advertised the >>route can withdraw it. Given these requirements, it is still >>possible to do what I described, i.e., don't spend time validating >>a route which does not appear to be the best route for a given set >>of NLRI. > > >That may be possible, but it is unlikely to be the best >implementation approach. Any path that is >accepted by the system may, at some point in the future, become the best path. agreed > An >implementation COULD choose to defer validation until a path is >selected, but this would >cause computational load to be transferred to a convergence event, >thus impacting overall >convergence times. maybe, depends on how fast the validation is. it might be the case that trying to validate all advertisements would overwhelm the router during busy times, but that validation of just the viable candidate "best" routes would avoid this problem. I bet one needs a fairly accurate simulation to tell. >Thus, a more sophisticated approach is to attempt to validate all >authenticated paths, but to do so with background processing. background processing might be a good solution in general, but in the situations where the processing load is most likely to be a concern, it may be that there is not enough "background" time available for such processing. > IMHO, this is an >architectural requirement for any tractable and deployable solution: >it must be possible to >temporally decouple security processing from the remainder of BGP >processing so that >the security overhead can be shifted out of the convergence window. This is certainly an implementation issue; it may or may not be an architectural issue. Most descriptions of routing security mechanisms I've seen would accommodate any of the approaches we have discussed, i.e., do it now, do it when you have to, or do it in the background. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 17:20:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezi8e-0000Q4-Qe; Thu, 19 Jan 2006 17:20:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezi8b-0000PH-D6 for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 17:20:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02704 for ; Thu, 19 Jan 2006 17:18:43 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EziH8-0007vZ-BA for rpsec@ietf.org; Thu, 19 Jan 2006 17:29:05 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JMJsIC007834; Thu, 19 Jan 2006 17:19:55 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43CFF5D1.6080509@cisco.com> References: <200601191607.k0JG7Ota025473@tislabs.com> <43CFDB36.1060306@cisco.com> <43CFF5D1.6080509@cisco.com> Date: Thu, 19 Jan 2006 17:10:59 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 3:25 PM -0500 1/19/06, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >> I think this WG cannot state what performance impacts are acceptable. >> You attended the same DHS routing security workshops that I did. You saw >> the tremendous range of views on what constitutes acceptable performance >> impacts even for an existing security mechanism, i.e., the TCP MD5 >> option. The best we can do is to note that performance impacts are a >> concern because they probably will influence deployment decisions, and >> that SIDR should keep this in mind when evaluating solution options. > >Was the performance of encryption not taken into account when designing >such solutions as IPsec? For the most part no, it was not a major issue. IPsec originally required support for DES, but other algorithms, some faster, some nominally stronger, were allowed. We then moved to 3DES, was was stronger by 2X, but was also 3X slower! We added support for combined mode algorithms in 4301, because crypto technology had evolved to a point where we could encrypt a lot faster than we could do integrity checking, and combined mode algorithms allow one to do both operations in a very fast manner. We did pay attention to the order in which integrity and encryption operations were performed, to minimize the impact of DoS attacks that are made possible because of using IPsec. That's a good thing for RPSEC to note as well. If we turned back the clock to the later half of the 90's, one could argue that some applications running on commonly available hardware might not be able to use IPsec because of performance concerns. That did not prevent IPsec form being defined in a fashion that allowed for its use with these apps as performance improved. In fairness, though, IPsec can be used, or not used, on a pairwise basis between consenting end points. BGP security measures need widespread adoption by ISPs to be effective, so the two situations are not quite the same. >Let me put it another way: I don't believe it's the right thing just to >rule out discussing performance impacts, which the users of any proposed >system are obviously concerned about, just because they cannot be >"specified cripsly." If we only specified things we could "specify >crisply," then half of what we work on could never be specified. > >I do believe it's useful to have a discussion about how to contain the >performance requirements within some text that implementors and >designers will understand. I don't beleive it's useful to simply remove >such text because it's "hard to specify." > I don't suggest we remove all references to performance. But I provided an example of the sort of text I would suggest we adopt, at least as a starting point. The suggestion is to acknowledge that performance is a concern that must be considered, while also acknowledging that we cannot create requirements for performance because of the complexity of specifying objective criteria. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 17:20:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezi9K-0000h1-RF; Thu, 19 Jan 2006 17:20:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezi9J-0000gn-3D for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 17:20:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02835 for ; Thu, 19 Jan 2006 17:19:29 -0500 (EST) 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 1EziHu-0007yM-Ce for rpsec@ietf.org; Thu, 19 Jan 2006 17:29:51 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 19 Jan 2006 14:20:46 -0800 Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0JMKiQj005275; Thu, 19 Jan 2006 14:20:45 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 17:20:46 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 17:20:46 -0500 Message-ID: <43D010B6.7030600@cisco.com> Date: Thu, 19 Jan 2006 17:20:38 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CFE049.1030901@cisco.com> <43CFF4F7.1010800@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Correct. I wasn't trying for a tutorial on how BGP is implemented, just >> giving a general overview. :-) > and the answer to my question is ...? Depends on the implementation. :-) Generally timers started at specific places in the peering relationship paired with a set of timers. >> Parameters are different from policy. Providers today deal with much >> more complex policy than this--and I wouldn't preclude the use of >> possibly policies just because the designer of the system thinks the >> users of that system will find them "too complicated." > > Policies are human expressions of criteria, that have to be translated > into machine-interpretable language for enforcement by machines. > Parameters are often the means by which such language is represented, > e.g., ACLs, firewall filter rules, etc. The 1998 NRC report "Trust in > Cyberspace" notes that many computer and network security problems that > we experience are attributable to an inability by administrators (and > users) to manage security controls for complex environments. I think > what we are discussing here is a perfect example of that. Policies are local, and determine preference, while options are global (or at least end-to-end at each peering session), and determine operational sequence and properties, etc. I see these as two completely different fields. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9AQvhEdu7FIVPTkEQI8yACgxbqU1ITipFAtTa8Y5ztg3NkEyzsAn0ck QjKpIj+Ilf3Rj7pFAX60r+cV =yyL2 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 18:36:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzjKI-0003LG-Ic; Thu, 19 Jan 2006 18:36:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzjKG-0003Ks-FC for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 18:36:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07852 for ; Thu, 19 Jan 2006 18:34:52 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzjSs-0001lg-Eg for rpsec@ietf.org; Thu, 19 Jan 2006 18:45:15 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0JNZdIC010792; Thu, 19 Jan 2006 18:35:40 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43D010B6.7030600@cisco.com> References: <43CFE049.1030901@cisco.com> <43CFF4F7.1010800@cisco.com> <43D010B6.7030600@cisco.com> Date: Thu, 19 Jan 2006 18:00:16 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Russ, >... > > >> Policies are human expressions of criteria, that have to be translated >> into machine-interpretable language for enforcement by machines. >> Parameters are often the means by which such language is represented, >> e.g., ACLs, firewall filter rules, etc. The 1998 NRC report "Trust in >> Cyberspace" notes that many computer and network security problems that >> we experience are attributable to an inability by administrators (and >> users) to manage security controls for complex environments. I think >> what we are discussing here is a perfect example of that. > >Policies are local, and determine preference, while options are global >(or at least end-to-end at each peering session), and determine >operational sequence and properties, etc. I see these as two completely >different fields. > >:-) > >Russ "options?" when did options enter the discussion? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 18:50:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzjXk-0002po-Bv; Thu, 19 Jan 2006 18:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzjXh-0002pB-IJ for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 18:50:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09134 for ; Thu, 19 Jan 2006 18:48:45 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18RX7PiM5zZ45dTE0cmuugiZtRX3dXLKy8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzjgI-0002Jt-Ul for rpsec@ietf.org; Thu, 19 Jan 2006 18:59:08 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+t6iNrzK0VbpBpIFRiH+QSvWzGzwOBNTc@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0JNnIGe010984; Thu, 19 Jan 2006 23:49:21 GMT Date: Thu, 19 Jan 2006 23:49:23 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 In-Reply-To: Message-ID: References: <43CED4F9.9070409@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.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.87.1/1245/Wed Jan 18 16:57:44 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Thu, 19 Jan 2006, Stephen Kent wrote: > I'd suggest text more consistent with a goal flavor, e.g., > > Processing > The introduction of mechanisms to improve routing security will > generally increase the processing performed by a router. The > increased processing typically will result from additional checks > performed to determine the validity of UPDATEs, especially if these > checks entail cryptographic operations. Since currently deployed > routers generally do not have hardware to accelerate cryptographic > operations, these operations could impose a significant processing > burden under some circumstances. Thus proposed solutions should be > evaluated carefully with regard to the processing burden they may > impose, since deployment may be impeded if network operators > perceive that a specific solution will impose an unacceptable > processing burden. That works for me. > This text has the flavor of articulating a goal for solutions, and > providing a rationale for that goal, but is not worded as a > requirement. Right, it's more a recommendation. > Steve regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "Plan to throw one away. You will anyway." - Fred Brooks, "The Mythical Man Month" _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 18:56:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezje0-0004I4-F5; Thu, 19 Jan 2006 18:56:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezjdz-0004Hd-AL for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 18:56:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10242 for ; Thu, 19 Jan 2006 18:55:17 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX18zi7B8Rc9hOKYSiALhecDYInvUYGalX3A=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzjmY-0002kN-RV for rpsec@ietf.org; Thu, 19 Jan 2006 19:05:38 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX18baUkoaf3pQkR2RcLMr4lS4e4QvhBXTq0@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0JNtcM8011055; Thu, 19 Jan 2006 23:55:50 GMT Date: Thu, 19 Jan 2006 23:55:42 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Stephen Kent Subject: Re: [RPSEC] Charter Update In-Reply-To: Message-ID: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.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.87.1/1245/Wed Jan 18 16:57:44 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Thu, 19 Jan 2006, Stephen Kent wrote: > - there are two individual I-Ds that have been published > recently, each proposing replacement mechanisms for the TCP MD5 > checksum, including improved key management. The community needs > one replacement, not two. I have reviewed both I-Ds and each has > serious problems that need to be addressed. > > I'm in favor of RPSEC making the selection of a replacement for the TCP MD5 > checksum option a work item, it the routing ADs agree it should be here. I'm curious, why do people want to formulate yet more IP security hacks? We now have a standard IETF IP security and key exchange protocol, deployable today. What exactly is wrong with IPSec that makes it unsuitable that can not be fixed? If it's really not suitable, surely at least parts of IPSec could be re-used? Be it on the key exchange protocol side (IKE) or else on the IP processing side (AH ip opt). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Alimony is the high cost of leaving. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 18:57:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzjfC-0004ll-RC; Thu, 19 Jan 2006 18:57:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzjfB-0004kD-50 for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 18:57:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10607 for ; Thu, 19 Jan 2006 18:56:28 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezjnf-0002pq-5f for rpsec@ietf.org; Thu, 19 Jan 2006 19:06:46 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (rwcrmhc12) with SMTP id <2006011923572101400dl2ike>; Thu, 19 Jan 2006 23:57:24 +0000 In-Reply-To: References: <43CED4F9.9070409@cisco.com> <43CFAF81.90608@cisco.com> <904DFE90-6771-4826-AF0C-7363CC1AAC5C@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81503E27-2588-4F8B-BC8B-571C7DD151B7@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Date: Thu, 19 Jan 2006 15:57:11 -0800 To: Stephen Kent X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Steve, >> An >> implementation COULD choose to defer validation until a path is >> selected, but this would >> cause computational load to be transferred to a convergence event, >> thus impacting overall >> convergence times. > > maybe, depends on how fast the validation is. I think it's reasonably safe to assume that any validation operation will take non-zero time and computational resource. Even if there is a way to offload this to another processor, there is some overhead (e.g., a DMA setup). >> Thus, a more sophisticated approach is to attempt to validate all >> authenticated paths, but to do so with background processing. > > background processing might be a good solution in general, but in > the situations where the processing load is most likely to be a > concern, it may be that there is not enough "background" time > available for such processing. Agreed, in which case it would impact convergence. Again, the sophisticated implementation can prioritize the validation of best prefixes to the foreground, while moving alternate prefixes to the background. An implementation may also choose to simply select and utilize alternate paths BEFORE validation. This is not unreasonable under the assumption that all paths will eventually be validated or they will set of alarms elsewhere in the network and that temporarily broken connectivity while under attack is better that very slow convergence always. >> IMHO, this is an >> architectural requirement for any tractable and deployable >> solution: it must be possible to >> temporally decouple security processing from the remainder of BGP >> processing so that >> the security overhead can be shifted out of the convergence window. > > This is certainly an implementation issue; it may or may not be an > architectural issue. Most descriptions of routing security > mechanisms I've seen would accommodate any of the approaches we > have discussed, i.e., do it now, do it when you have to, or do it > in the background. I think that anyone wishing to have a proposal that passes the laugh test and actually gets implementation resources devoted to it had best keep this in mind. I won't argue with you about whether it's architectural or an implementation issue. It is a pragmatic requirement of any deployable solution and it does not seem to be recognized as such, as far as I can tell. I do believe that it places significant constraints on the solution space and thus does have some significant bearing on the situation. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 20:02:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzkfA-0007hx-KF; Thu, 19 Jan 2006 20:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezkf8-0007hp-Bb for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 20:01:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17113 for ; Thu, 19 Jan 2006 20:00:32 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezknk-0005L2-2Q for rpsec@ietf.org; Thu, 19 Jan 2006 20:10:54 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 19 Jan 2006 17:01:47 -0800 Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0K11ic2026637; Thu, 19 Jan 2006 17:01:46 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 20:01:46 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 20:01:46 -0500 Message-ID: <43D03673.7030508@cisco.com> Date: Thu, 19 Jan 2006 20:01:39 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jakma Subject: Re: [RPSEC] Charter Update References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> - there are two individual I-Ds that have been published recently, >> each proposing replacement mechanisms for the TCP MD5 checksum, >> including improved key management. The community needs one >> replacement, not two. I have reviewed both I-Ds and each has serious >> problems that need to be addressed. >> >> I'm in favor of RPSEC making the selection of a replacement for the >> TCP MD5 checksum option a work item, it the routing ADs agree it >> should be here. > > I'm curious, why do people want to formulate yet more IP security hacks? > We now have a standard IETF IP security and key exchange protocol, > deployable today. > > What exactly is wrong with IPSec that makes it unsuitable that can not > be fixed? If it's really not suitable, surely at least parts of IPSec > could be re-used? Be it on the key exchange protocol side (IKE) or else > on the IP processing side (AH ip opt). A large segment of the routing community believes IPsec is too heavyweight (me among them), and isn't suited for the multicast environment most routing protocols operate in. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9A2ehEdu7FIVPTkEQKy5ACgu4xhSgI1nuDEWjPyqkieol8088QAoIBD /lQNipL7MKblMWPSSYF1m7BZ =+Cxx -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 20:06:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzkjM-00006Y-Nd; Thu, 19 Jan 2006 20:06:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzkjL-00006T-JU for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 20:06:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17326 for ; Thu, 19 Jan 2006 20:04:53 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezkry-0005S0-4F for rpsec@ietf.org; Thu, 19 Jan 2006 20:15:15 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2006 17:06:08 -0800 X-IronPort-AV: i="4.01,202,1136188800"; d="scan'208"; a="250193966:sNHT36491668" Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0K166QK004994; Thu, 19 Jan 2006 17:06:08 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 20:06:08 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 20:06:08 -0500 Message-ID: <43D03779.6030007@cisco.com> Date: Thu, 19 Jan 2006 20:06:01 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jakma Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> The introduction of mechanisms to improve routing security will >> generally increase the processing performed by a router. The increased >> processing typically will result from additional checks performed to >> determine the validity of UPDATEs, especially if these checks entail >> cryptographic operations. Since currently deployed routers generally >> do not have hardware to accelerate cryptographic operations, these >> operations could impose a significant processing burden under some >> circumstances. Thus proposed solutions should be evaluated carefully >> with regard to the processing burden they may impose, since deployment >> may be impeded if network operators perceive that a specific solution >> will impose an unacceptable processing burden. > That works for me. I believe this is too "soft," simply saying you should examine this issue, not what the result should be. Perhaps replace the last sentence with: "Thus proposed solutions should be evaluated with regard to the processing burden they impose. Solutions with lower processing burdens, and solutions capable of allowing processing to take place on devices outside the router, SHOULD be preferred." I think that more of right sense. It doesn't specify how to evaluate these things, it gives hints as to what to look for, and it gives mild direction as to how to handle the results of any given evaluation. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9A3gBEdu7FIVPTkEQJT2wCeIoSSFhvFFIsn/zhf/DV6khMkdUcAoKj8 EdypsgJMimXo7IW78cdh0h+M =MAat -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 20:10:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezkmw-0000cl-0p; Thu, 19 Jan 2006 20:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezkmu-0000cH-Eg for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 20:10:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17615 for ; Thu, 19 Jan 2006 20:08:34 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzkvX-0005Z7-7N for rpsec@ietf.org; Thu, 19 Jan 2006 20:18:56 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2006 17:09:50 -0800 X-IronPort-AV: i="4.01,202,1136188800"; d="scan'208"; a="250195108:sNHT31754896" Received: from RussPC (sjc-vpn6-76.cisco.com [10.21.120.76]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0K19mQK007006; Thu, 19 Jan 2006 17:09:49 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 19 Jan 2006 20:09:49 -0500 X-PGP-Universal: processed; by RussPC on Thu, 19 Jan 2006 20:09:49 -0500 Message-ID: <43D03856.1040702@cisco.com> Date: Thu, 19 Jan 2006 20:09:42 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CFE049.1030901@cisco.com> <43CFF4F7.1010800@cisco.com> <43D010B6.7030600@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> Policies are human expressions of criteria, that have to be translated >>> into machine-interpretable language for enforcement by machines. >>> Parameters are often the means by which such language is represented, >>> e.g., ACLs, firewall filter rules, etc. The 1998 NRC report "Trust in >>> Cyberspace" notes that many computer and network security problems that >>> we experience are attributable to an inability by administrators (and >>> users) to manage security controls for complex environments. I think >>> what we are discussing here is a perfect example of that. >> >> Policies are local, and determine preference, while options are global >> (or at least end-to-end at each peering session), and determine >> operational sequence and properties, etc. I see these as two completely >> different fields. >> >> :-) >> >> Russ > > > "options?" when did options enter the discussion? What would you prefer to call the various capabilities a protocol can use to modify its operation? My point is there's a radical difference between having ten different ways to encapsulate data, five different key options, four different signalling mechanisms, etc, and the ability to locally configure policy to prefer one route over another, based on security, as well as other parameters. I, for one, do not want to see a mechanism standardized that only provides "valid" or "invalid" as its output. This is not a piece of data you're transporting across a network that's either correct or incorrect, like an encrypted email. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9A4XREdu7FIVPTkEQKMkwCfVrL4gjcF0OMI6v1Y+nkLLGfWIGcAoPdc Fx/N5NCSefJEFdpXIsJ21v/F =ZCQ0 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 19 20:47:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlNR-0006CE-NP; Thu, 19 Jan 2006 20:47:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzlNQ-0006C3-Do for rpsec@megatron.ietf.org; Thu, 19 Jan 2006 20:47:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20686 for ; Thu, 19 Jan 2006 20:46:17 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX189h7PPuxNcoh/Rrv77Sf9Vcv9658KuS5I=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzlW2-0006rD-6g for rpsec@ietf.org; Thu, 19 Jan 2006 20:56:40 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19e3DZU9pQarpFDOEe0GgI7lVy/GLvxghk@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0K1l1HR012786; Fri, 20 Jan 2006 01:47:04 GMT Date: Fri, 20 Jan 2006 01:47:06 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Russ White Subject: Re: [RPSEC] Charter Update In-Reply-To: <43D03673.7030508@cisco.com> Message-ID: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.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.87.1/1246/Thu Jan 19 21:44:42 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Thu, 19 Jan 2006, Russ White wrote: > A large segment of the routing community believes IPsec is too > heavyweight (me among them), What specifically? And 'large segment' is a fairly bold claim too. > and isn't suited for the multicast environment most routing > protocols operate in. That's seems a red-herring. The multicast protocols already are using statically keyed HMACs anyway. Which leaves BGP, which uses TCP - not exactly multicast. The IPSec AH side of things /can/ be used in multicast, if I remember correctly. That leaves the key distribution side - a problem being worked on I thought (for IKE). The other alternative is to use an in-protocol key distribution mechanism, but again that shouldn't preclude using AH (which is what is being vaguely considered for OSPF, iirc). What indisputable/immovable reasons are there to go off and reinvent IPSec (with the real risk of doing so poorly)? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: You are going to have a new love affair. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 05:36:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EztdU-00065M-Sl; Fri, 20 Jan 2006 05:36:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EztdS-000658-PE for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 05:36:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29263 for ; Fri, 20 Jan 2006 05:35:22 -0500 (EST) Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eztm9-0006rK-Jp for rpsec@ietf.org; Fri, 20 Jan 2006 05:45:50 -0500 Received: from [192.168.0.3] ([71.39.132.246]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0KAaC1m027812 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 20 Jan 2006 02:36:13 -0800 In-Reply-To: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <621205c5710eb1f9048bc766edec2eff@merike.com> Content-Transfer-Encoding: 7bit From: Merike Kaeo Subject: Re: [RPSEC] Charter Update Date: Fri, 20 Jan 2006 02:37:35 -0800 To: Paul Jakma X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Stephen Kent , Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org OK. Since this is something I've been wondering about I'll chime in....... Most router (and other) IPsec configurations are fairly horrible and from my experience (configuring at least 20 different implementations in last 8 years and doing some testing 3 years back to see how 3 varying large router vendors dealt with IPsec interoperability) one major problem is operational deployment headache which (in my ever optimistic mind) can be fixed by: - same defaults for most IPsec choices [i.e. use esp w/null encryption and SHA-1] - have no more than 4 configuration lines [yes, this can be done] hint: 1. state routing protocol; 2. state using IPsec and with which neighbor; 3. state how you want to authenticate Diffie-Hellman exchange (let's assume pre-shared key); 4. define pre-shared key This gives you similar config as with the MD-5 authentication today but you get added benefit of 'new' keys used for authentication algorithm (let's say SHA-1) which are periodically 'refreshed'. Is the processing overhead really that intensive when using IKE and esp w/null encryption that IPsec is a non-starter? Dave Ward had a draft a few years back on securing BGP using IPsec and I had asked him to resurrect it 2 years ago.......mainly to get an authentication mechanism deployable where keys were not static for years :) There was no interest then in that work which I thought too bad. But maybe I'm not understanding some subtle (or maybe more obvious) issue in terms of actual implementation and performance. And I would really love to hear the technical justifications so that I can put the matter to rest in my mind. There's a draft defining how OSPFv3 should do authentication and it is defining ESP w/ null encryption as a MUST and AH as a SHOULD. Automated key management is not mandated due largely to multicast issues but I also thought some of those issues were being addressed and worked on. - merike On Jan 19, 2006, at 5:47 PM, Paul Jakma wrote: > On Thu, 19 Jan 2006, Russ White wrote: > >> A large segment of the routing community believes IPsec is too >> heavyweight (me among them), > > What specifically? > > And 'large segment' is a fairly bold claim too. > >> and isn't suited for the multicast environment most routing protocols >> operate in. > > That's seems a red-herring. The multicast protocols already are using > statically keyed HMACs anyway. Which leaves BGP, which uses TCP - not > exactly multicast. > > The IPSec AH side of things /can/ be used in multicast, if I remember > correctly. That leaves the key distribution side - a problem being > worked on I thought (for IKE). The other alternative is to use an > in-protocol key distribution mechanism, but again that shouldn't > preclude using AH (which is what is being vaguely considered for OSPF, > iirc). > > What indisputable/immovable reasons are there to go off and reinvent > IPSec (with the real risk of doing so poorly)? > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > You are going to have a new love affair. > > _______________________________________________ > 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 Fri Jan 20 06:48:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezul7-0004Nc-OK; Fri, 20 Jan 2006 06:48:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezul6-0004NL-2N for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 06:48:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04160 for ; Fri, 20 Jan 2006 06:47:19 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezutl-0000ax-Rv for rpsec@ietf.org; Fri, 20 Jan 2006 06:57:49 -0500 Received: from pc6 (1Cust155.tnt16.lnd4.gbr.da.uu.net [62.188.145.155]) by astro.systems.pipex.net (Postfix) with SMTP id DC574E0003B4; Fri, 20 Jan 2006 11:48:23 +0000 (GMT) Message-ID: <021301c61dae$fca318e0$0601a8c0@pc6> From: "Tom Petch" To: "Paul Jakma" , "Stephen Kent" References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> Subject: Re: [RPSEC] Charter Update Date: Fri, 20 Jan 2006 10:22:52 +0100 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: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org ----- Original Message ----- From: "Paul Jakma" To: "Stephen Kent" Cc: ; "Russ White" Sent: Friday, January 20, 2006 12:55 AM Subject: Re: [RPSEC] Charter Update > On Thu, 19 Jan 2006, Stephen Kent wrote: > > > - there are two individual I-Ds that have been published > > recently, each proposing replacement mechanisms for the TCP MD5 > > checksum, including improved key management. The community needs > > one replacement, not two. I have reviewed both I-Ds and each has > > serious problems that need to be addressed. > > > > I'm in favor of RPSEC making the selection of a replacement for the TCP MD5 > > checksum option a work item, it the routing ADs agree it should be here. > > I'm curious, why do people want to formulate yet more IP security > hacks? We now have a standard IETF IP security and key exchange > protocol, deployable today. > > We have several. We are moving away from the 'every application must do it in its own way' exemplified by OSPFv2, BGP4 and SNMPv3 to use a standard approach at a lower layer. Yes, we have a standard at layer 3 but we also have, at layer 4, SSH and TLS competing for market share. SNMP has now chosen the SSH approach for good reason, BGP might do the same I think it important to move away from the former approach simply because security needs to be updated as and when it is breached and that is in general not in synch with the needs to update the application, so security and application need decoupling. And, within any security, as in those I mention above, it is necessary to be able to slot in new algorithms as and when an algorithm becomes too weak for its purpose. So replacing MD5 in BGP with SHA-1 or SHA-256 would, for me, be totally wrong. Tom Petch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 06:48:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezul8-0004O4-67; Fri, 20 Jan 2006 06:48:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezul5-0004NK-VS for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 06:48:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04158 for ; Fri, 20 Jan 2006 06:47:19 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezutl-0000b2-Rz for rpsec@ietf.org; Fri, 20 Jan 2006 06:57:49 -0500 Received: from pc6 (1Cust155.tnt16.lnd4.gbr.da.uu.net [62.188.145.155]) by astro.systems.pipex.net (Postfix) with SMTP id A2287E0004D0; Fri, 20 Jan 2006 11:48:28 +0000 (GMT) Message-ID: <021401c61dae$fd6c8360$0601a8c0@pc6> From: "Tom Petch" To: "Stephen Kent" References: Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Date: Fri, 20 Jan 2006 10:41:50 +0100 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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org ----- Original Message ----- From: "Stephen Kent" To: "Tony Tauber" Cc: Sent: Wednesday, January 11, 2006 4:32 PM Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 > Tony, > the current BGP spec (in the RFC editor's queue) ... Now an RFC, in fact about ten of them, starting at RFC 1771+2500=4271. Tom Petch > does not relax the > loop-free requirement, so I think it still belongs here. > > > _______________________________________________ > 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 Fri Jan 20 07:24:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzvK5-0002sz-BW; Fri, 20 Jan 2006 07:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzvK3-0002sO-0b for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 07:24:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08181 for ; Fri, 20 Jan 2006 07:23:28 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzvSl-0002IH-Sf for rpsec@ietf.org; Fri, 20 Jan 2006 07:33:56 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0KCOKHa019420; Fri, 20 Jan 2006 14:24:20 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0KCOJDH019417; Fri, 20 Jan 2006 14:24:19 +0200 Date: Fri, 20 Jan 2006 14:24:19 +0200 (EET) From: Pekka Savola To: Stephen Kent In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1246/Thu Jan 19 23:44:42 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: rpsec@ietf.org, Tony Tauber Subject: [RPSEC] bgpsecrec-03 (mostly on IPsec and ICMP now) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Thu, 19 Jan 2006, Stephen Kent wrote: > At 7:30 PM +0200 1/19/06, Pekka Savola wrote: ... >> I'd say that in most cases the answer would be "yes". The whole point of >> peering (unless the link is acting as a cold backup) is to accept prefixes. >> Operators also tend to set preferences in the incoming advertisements, >> making them preferable. > > I'm puzzled by this statement. Of course one peers with neighbor ASes to > accept advertisements. But, not every advertisement will yield a better route > than the current best route. Flapping is precisely a situation where a route > oscillates because a sequence of advertisements causes this behavior. But we > all want to avoid flapping, and try to achieve this via various means, e.g., > through dampening, preference settings, etc. In my experience, the current mechanisms are not flexible enough and sufficiently widely used to support this. Let's take an example: an ISP has two upstream providers, and wants to mainly use one of them for whatever reasons. When that session goes down, 200K routes get active on the backup session. When that session comes back up, 200K routes get re-activated on the primary session. The same applies to peering with smaller number of prefixes. > I used to assume that the worst case arose when a BGP router was at an > exchange, with a lot of peers, and thus a lot of opportunities for UPDATEs to > arrive quickly from each peer. However, I have been told by operators that > this is not as bad as I had imagined. The reasoning is that the peers at an > exchange are mostly downstream providers from whom the set of acceptable > prefixes is fairly small and static and thus filtering (w/o use of crypto > checks) would deal with most of these UPDATEs. For those operators, less than 20% of peers contribute over 80% of prefixes (or so I'd estimate). Yet, the large number of prefixes heard from peers (rather than downstreams) is the real problem. >> While the only ICMP error messages relevant to such a BGP TCP session >> would need to come from your peer, you'd need to have verification checks >> in the ICMP processing code that deals with this case when the ICMP error >> carries only an IP header and 8 bytes of payload. At the moment, I haven't >> been able to locate this text in RFC 4301. > > Start of 6.2: > > When an ICMP error message is transmitted via an SA to a device "behind" an > IPsec implementation, both the payload and the header of > the ICMP message require checking from an access control perspective. ... This text deals with ICMPs protected by an SA. Do you assume that ICMP traffic between the neighbors would need to be protected by an SA? > Thus, an IPsec implementation MUST be configurable to check that this payload > header information is consistent with the SA via which it arrives. (This > means that the payload header, with source and destination address and port > fields reversed, matches the traffic selectors for the SA.) > > This says that when an ICMP error message arrives on an SA from a peer, you > look at the IP header carried within the message to verify that it refers to > traffic that would have been carried on the matching, outbound SA. Thus, for > example, a peer can send ICMP error messages that will be accepted ONLY if > they refer to traffic that would have been sent to that peer. AFAICS, this doesn't really help: - source and destination addresses from the IP header can be checked but are not integrity-protected - the payload need not include more than 8 bytes of the payload, so in case of ESP (for example, similar for AH), you could only see the IPsec SPI and Acknowledgement number. Maybe you're assuming that the peer would send back the whole packet in ICMP payload (so that you could pass it to the IPsec layer for cryptographic verification). That's not required by RFC 1812. As the integrity of the payload cannot be verified, I think anyone can send an ICMP message which contains the source and destination address used by the outbound SA. -- 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 Fri Jan 20 08:08:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezw0L-0001aR-F2; Fri, 20 Jan 2006 08:08:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezw0J-0001Zr-R2 for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 08:08:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11250 for ; Fri, 20 Jan 2006 08:07:09 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19f6Q1gj+ZX6kVyf5JIU54m1hLGaC7GKnI=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezw92-0003iM-CQ for rpsec@ietf.org; Fri, 20 Jan 2006 08:17:38 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX18p4faRCUg4oPQHrl+GY6887I8GhyqNhPY@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0KD8BqX021555; Fri, 20 Jan 2006 13:08:13 GMT Date: Fri, 20 Jan 2006 13:08:16 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tom Petch Subject: Re: [RPSEC] Charter Update In-Reply-To: <021301c61dae$fca318e0$0601a8c0@pc6> Message-ID: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <021301c61dae$fca318e0$0601a8c0@pc6> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.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.87.1/1246/Thu Jan 19 21:44:42 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rpsec@ietf.org, Stephen Kent , Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Fri, 20 Jan 2006, Tom Petch wrote: > We have several. We are moving away from the 'every application > must do it in its own way' exemplified by OSPFv2, BGP4 and SNMPv3 > to use a standard approach at a lower layer. Laudable. > Yes, we have a standard at layer 3 but we also have, at layer 4, > SSH and TLS competing for market share. SNMP has now chosen the > SSH approach for good reason, BGP might do the same Neither SSH nor TLS could work for BGP, as neither would protect the TCP session. > I think it important to move away from the former approach simply > because security needs to be updated as and when it is breached and > that is in general not in synch with the needs to update the > application, so security and application need decoupling. Yes, I agree. Hence why I really do not see why we should we invent another IPSec-alike to replace TCP-MD5 for BGP. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: He is truly wise who gains wisdom from another's mishap. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 10:20:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezy3Z-00070g-N1; Fri, 20 Jan 2006 10:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezy3Y-00070I-2R for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 10:20:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20766 for ; Fri, 20 Jan 2006 10:18:36 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyCH-0007gP-Uv for rpsec@ietf.org; Fri, 20 Jan 2006 10:29:07 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Jan 2006 10:19:52 -0500 X-IronPort-AV: i="4.01,206,1136178000"; d="scan'208"; a="80631564:sNHT32203164" Received: from RussPC (rtp-vpn4-469.cisco.com [10.82.209.213]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0KFJl6I004349; Fri, 20 Jan 2006 10:19:49 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Fri, 20 Jan 2006 10:19:49 -0500 X-PGP-Universal: processed; by RussPC on Fri, 20 Jan 2006 10:19:49 -0500 Message-ID: <43D0FF8E.5010503@cisco.com> Date: Fri, 20 Jan 2006 10:19:42 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jakma Subject: Re: [RPSEC] Charter Update References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> A large segment of the routing community believes IPsec is too >> heavyweight (me among them), > What specifically? I think Merike answered that one well, so I'll leave it for the moment. > And 'large segment' is a fairly bold claim too. Well, I talk to a lot of people about these things.... :-) >> and isn't suited for the multicast environment most routing protocols >> operate in. > That's seems a red-herring. The multicast protocols already are using > statically keyed HMACs anyway. Which leaves BGP, which uses TCP - not > exactly multicast. The original proposed charter statement is that we should devise a set of requirements, not necessarily a solution. I actually think we could go to the point of "everything but the transport" in this case, but the original concept was requirements. > The IPSec AH side of things /can/ be used in multicast, if I remember > correctly. That leaves the key distribution side - a problem being > worked on I thought (for IKE). The other alternative is to use an > in-protocol key distribution mechanism, but again that shouldn't > preclude using AH (which is what is being vaguely considered for OSPF, > iirc). Can IPsec be used IS-IS? No.... Can IPsec handle the unicast/multicast nature of OSPF, really? Most people don't realize that OSPF and IS-IS (and every other IGP other than RIP) use a mix of unicast and multicast on a single link, even a single link type, under varying conditions. I don't know that we want to set up a single IPsec session for multicast from every router to every router (multicast) and then a full mesh of IPsec sessions on a single link to handle the unicast routing traffic. IMHO, that's a lot of a overhead (see the "too heavy" comment above). It seems like replacement suggestions are moving forward without anyone actually looking at the requirements--is there a need to look at the requirements in these situations, and make recommendations? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9D/lREdu7FIVPTkEQLtWwCfeR4RNU48xgpIuQB78KgYXZ7ExhAAoKcC aAEEkNU4OfERXked1bx2vXlU =+oks -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 10:37:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyKm-0003s2-Hu; Fri, 20 Jan 2006 10:37:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyKk-0003qG-3d for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 10:37:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22785 for ; Fri, 20 Jan 2006 10:36:22 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyTS-00005Z-46 for rpsec@ietf.org; Fri, 20 Jan 2006 10:46:53 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0KFbVIC008642; Fri, 20 Jan 2006 10:37:31 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <81503E27-2588-4F8B-BC8B-571C7DD151B7@tony.li> References: <43CED4F9.9070409@cisco.com> <43CFAF81.90608@cisco.com> <904DFE90-6771-4826-AF0C-7363CC1AAC5C@tony.li> <81503E27-2588-4F8B-BC8B-571C7DD151B7@tony.li> Date: Fri, 20 Jan 2006 10:13:53 -0500 To: Tony Li From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Tony, Upon reading your responses I think we are generally in agreement. Any route validation process will require some processing, thus will contribute in some way to delays in transmitting a new UPDATE, and thus may impact convergence time. However, without an implementation and realistic testing, or very detailed analysis and simulation, it probably is not possible to determine the extent to which convergence is affected by a given mechanism, at least in many cases. Since there already seems to be considerable variance in convergence times based on other aspects of specific BGP implementation and the parameter setting for an implementation, it would seem premature to declare that every deferred processing approach will be unacceptable, or that background processing will always be preferable. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 10:37:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyKn-0003sU-0o; Fri, 20 Jan 2006 10:37:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyKk-0003qd-EX for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 10:37:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22783 for ; Fri, 20 Jan 2006 10:36:22 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyTS-000061-W6 for rpsec@ietf.org; Fri, 20 Jan 2006 10:46:53 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0KFbVIG008642; Fri, 20 Jan 2006 10:37:33 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43D03779.6030007@cisco.com> References: <43CED4F9.9070409@cisco.com> <43D03779.6030007@cisco.com> Date: Fri, 20 Jan 2006 10:08:18 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Russ, >... > >I believe this is too "soft," simply saying you should examine this >issue, not what the result should be. Perhaps replace the last sentence >with: > >"Thus proposed solutions should be evaluated with regard to the >processing burden they impose. Solutions with lower processing burdens, >and solutions capable of allowing processing to take place on devices >outside the router, SHOULD be preferred." > >I think that more of right sense. It doesn't specify how to evaluate >these things, it gives hints as to what to look for, and it gives mild >direction as to how to handle the results of any given evaluation. The problem with your wording is that a solution with a lower processing burden is automatically preferred. However, the lower burden might be only slightly lower, and thus of little practical import. If a slightly more burdensome solution offered much better security, it would seem inappropriate to automatically prefer the less burdensome solution, with worse security. So, that's why I suggest we describe why performance is a concern and thus why it needs to be considered in evaluating solutions, but why we ought not try to create a requirement based on performance. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 10:37:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyKq-0003tt-M0; Fri, 20 Jan 2006 10:37:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyKo-0003th-R9 for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 10:37:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22805 for ; Fri, 20 Jan 2006 10:36:27 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyTU-00006Q-D3 for rpsec@ietf.org; Fri, 20 Jan 2006 10:46:58 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0KFbVIE008642; Fri, 20 Jan 2006 10:37:32 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43D03673.7030508@cisco.com> References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> Date: Fri, 20 Jan 2006 10:37:39 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Charter Update Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rpsec@ietf.org, Paul Jakma X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 8:01 PM -0500 1/19/06, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>> - there are two individual I-Ds that have been published recently, >>> each proposing replacement mechanisms for the TCP MD5 checksum, >>> including improved key management. The community needs one >>> replacement, not two. I have reviewed both I-Ds and each has serious >>> problems that need to be addressed. >>> >>> I'm in favor of RPSEC making the selection of a replacement for the >>> TCP MD5 checksum option a work item, it the routing ADs agree it >>> should be here. >> >> I'm curious, why do people want to formulate yet more IP security hacks? >> We now have a standard IETF IP security and key exchange protocol, >> deployable today. >> >> What exactly is wrong with IPSec that makes it unsuitable that can not >> be fixed? If it's really not suitable, surely at least parts of IPSec >> could be re-used? Be it on the key exchange protocol side (IKE) or else >> on the IP processing side (AH ip opt). > >A large segment of the routing community believes IPsec is too >heavyweight (me among them), and isn't suited for the multicast >environment most routing protocols operate in. We're talking about BGP peering sessions, which take place over TCP. The proposals I noted are for TCP session authentication, primarily in support of BGP session protection. TCP does not support multicast. Why do you mention multicast above? It seems irrelevant to this discussion. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 10:51:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyXx-0003vH-Dx; Fri, 20 Jan 2006 10:51:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyXv-0003s9-Ng for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 10:51:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24574 for ; Fri, 20 Jan 2006 10:50:00 -0500 (EST) From: sandy@tislabs.com Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezygg-0000oa-7M for rpsec@ietf.org; Fri, 20 Jan 2006 11:00:31 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0KFovZ6007685 for ; Fri, 20 Jan 2006 10:50:57 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAeQaO_o; Fri, 20 Jan 06 10:50:51 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0KFrFxI025134; Fri, 20 Jan 2006 10:53:15 -0500 (EST) Date: Fri, 20 Jan 2006 10:53:15 -0500 (EST) Message-Id: <200601201553.k0KFrFxI025134@tislabs.com> To: riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 X-Spam-Score: 0.3 (/) 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org >So, rather than doing what can be done, you'd rather set the >requirements so they are "perfect," without any consideration for >deployability, and then deploy nothing for several years, until the >entire infrastructure of the Internet and all connected networks can be >replaced? I consider this view a bit unrealistic. I would prefer to analyze the security requirements and then compare proposed solutions against the security requirements and the engineering decisions of performance and scale and deployability. I would prefer not to prohibit certain security solutions from getting any consideration at all because they would present difficulties in the current environment. Environments differ now at different places and at different special purpose networks and will certainly differ in the future. The document already says that any solution must tolerate incremental deployment. So bringing up the "entire infrastructure of the Internet" is only a bugaboo. >Then we should modify the part that says: "Don't require X of all >routers," to: "don't require X of all routers on which the proposed solution is running." Exactly as I said: "If you really mean the "all" part...." --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 10:52:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyYh-0004Fs-Vj; Fri, 20 Jan 2006 10:52:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyYf-0004Fi-Qs for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 10:52:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24629 for ; Fri, 20 Jan 2006 10:50:45 -0500 (EST) Received: from [64.192.171.205] (helo=red2.netartifex.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyhN-0000pC-QP for rpsec@ietf.org; Fri, 20 Jan 2006 11:01:17 -0500 Received: from [10.0.1.2] (c-67-168-5-135.hsd1.or.comcast.net [67.168.5.135]) (authenticated bits=0) by red2.netartifex.com (8.13.4/8.13.4/Debian-3) with ESMTP id k0KFpj2R020376 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2006 10:51:48 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Blaine Christian Subject: Re: [RPSEC] Charter Update Date: Fri, 20 Jan 2006 07:52:13 -0800 To: rpsec@ietf.org X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Jan 20, 2006, at 7:37 AM, Stephen Kent wrote: > At 8:01 PM -0500 1/19/06, Russ White wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >>>> - there are two individual I-Ds that have been published >>>> recently, >>>> each proposing replacement mechanisms for the TCP MD5 checksum, >>>> including improved key management. The community needs one >>>> replacement, not two. I have reviewed both I-Ds and each has >>>> serious >>>> problems that need to be addressed. >>>> >>>> I'm in favor of RPSEC making the selection of a replacement for >>>> the >>>> TCP MD5 checksum option a work item, it the routing ADs agree it >>>> should be here. I believe identifying preferences for key management belongs in this group. It is called out in the BGP rpsec draft as an issue to be addressed. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 10:54:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezyb2-0004gQ-CY; Fri, 20 Jan 2006 10:54:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezyb1-0004gG-1v for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 10:54:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24730 for ; Fri, 20 Jan 2006 10:53:11 -0500 (EST) From: sandy@tislabs.com Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezyjl-0000tJ-D4 for rpsec@ietf.org; Fri, 20 Jan 2006 11:03:42 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id k0KFs8Lo008449 for ; Fri, 20 Jan 2006 10:54:08 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA60aGEq; Fri, 20 Jan 06 10:54:05 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id k0KFuMPG025269; Fri, 20 Jan 2006 10:56:22 -0500 (EST) Date: Fri, 20 Jan 2006 10:56:22 -0500 (EST) Message-Id: <200601201556.k0KFuMPG025269@tislabs.com> To: paul@clubi.ie, riw@cisco.com Subject: Re: [RPSEC] Charter Update X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org >A large segment of the routing community believes IPsec is too >heavyweight (me among them), and isn't suited for the multicast >environment most routing protocols operate in. The difficulty I've heard is management, due to implementation inadequacies. Can you explain "most"? (And there is work in the IETF in IPsec for multicast.) _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 10:56:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzycL-0004wE-HK; Fri, 20 Jan 2006 10:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzycJ-0004w6-K5 for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 10:55:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24840 for ; Fri, 20 Jan 2006 10:54:31 -0500 (EST) Received: from [64.192.171.205] (helo=red2.netartifex.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezyl1-0000vz-OT for rpsec@ietf.org; Fri, 20 Jan 2006 11:05:03 -0500 Received: from [10.0.1.2] (c-67-168-5-135.hsd1.or.comcast.net [67.168.5.135]) (authenticated bits=0) by red2.netartifex.com (8.13.4/8.13.4/Debian-3) with ESMTP id k0KFtSBs020418 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 20 Jan 2006 10:55:30 -0500 In-Reply-To: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Blaine Christian Subject: Re: [RPSEC] Charter Update Date: Fri, 20 Jan 2006 07:55:53 -0800 To: Stephen Kent X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Paul Jakma , Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org >>> My .02 >>> What exactly is wrong with IPSec that makes it unsuitable that >>> can not >>> be fixed? If it's really not suitable, surely at least parts of >>> IPSec >>> could be re-used? Be it on the key exchange protocol side (IKE) >>> or else >>> on the IP processing side (AH ip opt). >> >> A large segment of the routing community believes IPsec is too >> heavyweight (me among them), and isn't suited for the multicast >> environment most routing protocols operate in. > IPSec is a pain in the rear to configure and manage. MD5 is very easy but the key management methods currently available stink. > We're talking about BGP peering sessions, which take place over > TCP. The proposals I noted are for TCP session authentication, > primarily in support of BGP session protection. TCP does not > support multicast. Why do you mention multicast above? It seems > irrelevant to this discussion. Have to agree here... Not sure what is meant by the multicast comment. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 10:59:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezyfj-000631-BC; Fri, 20 Jan 2006 10:59:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezyfh-000620-Pu for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 10:59:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25102 for ; Fri, 20 Jan 2006 10:58:02 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzyoS-00013O-9m for rpsec@ietf.org; Fri, 20 Jan 2006 11:08:33 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0KFx9IC009837; Fri, 20 Jan 2006 10:59:09 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43D03856.1040702@cisco.com> References: <43CFE049.1030901@cisco.com> <43CFF4F7.1010800@cisco.com> <43D010B6.7030600@cisco.com> <43D03856.1040702@cisco.com> Date: Fri, 20 Jan 2006 10:43:38 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Russ, >... > >What would you prefer to call the various capabilities a protocol can >use to modify its operation? My point is there's a radical difference >between having ten different ways to encapsulate data, five different >key options, four different signalling mechanisms, etc, and the ability >to locally configure policy to prefer one route over another, based on >security, as well as other parameters. I no longer have any idea what you're talking about relative to our original discussion, so I'll just stop pursuing attempts to clarify these comments. >I, for one, do not want to see a mechanism standardized that only >provides "valid" or "invalid" as its output. This is not a piece of data >you're transporting across a network that's either correct or incorrect, >like an encrypted email. At lower levels, security mechanisms do output precisely valid/invalid indications. This is true for integrity checks, authentication checks, and authorization checks, and has been for decades. One can choose to takes these outputs from security mechanisms and allow a person to make a value judgement that determines how the output affects behavior. One can try to translate the human decision criteria into a machine-enforceable policy. However, we often see people unable to interpret the binary outputs of the low level mechanisms. We almost always see people surprised by the results of trying to translate their decisions processes into machine-enforceable policies. Using the e-mail example above, S/MIME will tell a user if a message is signed or not, if the signature can be validated using available trust anchors and cert status data, and whether the result of the validation procedure was successful. All of these are binary outputs but users have trouble dealing wit them, in practice. For example, S/MIME software generally will not pop up a window to display the cert that was validated, for a signed message. Thus a user will tend to think that the name in the From field has been verified as the sender of the message, but that is not what was checked! Also, even in an environment where signed e-mail is common (or nominally required) a user will not automatically reject all unsigned messages. My concern is that if we give network operators a complex set of controls for dealing with security characteristics for advertisements, the result will be way too hard for many (most?) operators to use safely. A simple output of verified or not verified is probably OK, but any sort of partial verification (3 out of 5 ASes in the path?) is likely to cause more confusion that its worth. I don't say this because I know how operators work; I say it because I have a lot of experience with security management technologies. My view on this topic is shared by others in the security arena, as noted in the NRC report I cited in a previous message. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 11:08:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyoA-0002ig-PZ; Fri, 20 Jan 2006 11:08:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezyo9-0002gU-7w for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 11:08:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25887 for ; Fri, 20 Jan 2006 11:06:45 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezywt-0001MK-Ts for rpsec@ietf.org; Fri, 20 Jan 2006 11:17:17 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Jan 2006 08:08:04 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,206,1136188800"; d="scan'208"; a="20117350:sNHT22904892" Received: from RussPC (rtp-vpn4-469.cisco.com [10.82.209.213]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0KG7x6I013190; Fri, 20 Jan 2006 11:08:00 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Fri, 20 Jan 2006 11:08:01 -0500 X-PGP-Universal: processed; by RussPC on Fri, 20 Jan 2006 11:08:01 -0500 Message-ID: <43D10AD9.1000209@cisco.com> Date: Fri, 20 Jan 2006 11:07:53 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> <43D03779.6030007@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The problem with your wording is that a solution with a lower > processing burden is automatically preferred. However, the lower > burden might be only slightly lower, and thus of little practical > import. If a slightly more burdensome solution offered much better > security, it would seem inappropriate to automatically prefer the > less burdensome solution, with worse security. So, that's why I > suggest we describe why performance is a concern and thus why it > needs to be considered in evaluating solutions, but why we ought not > try to create a requirement based on performance. That's why it's a SHOULD rather than MUST--these are things that need to be traded off against other requirements in the draft. Saying: "You must consider the processing burdens" gives no guidance whatsoever. The simple answer is: "I've considered it, and I believe it doesn't matter." That's a valid answer, based on the text you've suggested--but it's not a valid answer given the intent of the text. Another possibility is: Thus proposed solutions should be evaluated with regard to the processing burden they impose. Gains in security MUST be weighted against increases in processing burden, including the ability to shift processing requirements onto devices external to an implementing router. Solutions imposing smaller processing burdens with small perceived operational security losses SHOULD be preferred. BTW, weren't you just arguing for more precise language, rather than less precise language? :-) :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9EK4REdu7FIVPTkEQIVkgCguA0BKAxqJrmaKVMhTymk2M5KsHoAoMk7 9jWFZCb5L7PXJbIatNJjA5uB =T4lX -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 11:18:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezyy7-0004T3-By; Fri, 20 Jan 2006 11:18:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezyy2-0004Rk-N6 for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 11:18:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26513 for ; Fri, 20 Jan 2006 11:16:58 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezz6n-0001cv-F2 for rpsec@ietf.org; Fri, 20 Jan 2006 11:27:30 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Jan 2006 11:18:17 -0500 X-IronPort-AV: i="4.01,206,1136178000"; d="scan'208"; a="80636320:sNHT31225440" Received: from RussPC (rtp-vpn4-469.cisco.com [10.82.209.213]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0KGIA6I015152; Fri, 20 Jan 2006 11:18:14 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Fri, 20 Jan 2006 11:18:14 -0500 X-PGP-Universal: processed; by RussPC on Fri, 20 Jan 2006 11:18:14 -0500 Message-ID: <43D10D3D.9030907@cisco.com> Date: Fri, 20 Jan 2006 11:18:05 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Blaine Christian Subject: Re: [RPSEC] Charter Update References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: rpsec@ietf.org, Paul Jakma , Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> We're talking about BGP peering sessions, which take place over TCP. >> The proposals I noted are for TCP session authentication, primarily >> in support of BGP session protection. TCP does not support multicast. >> Why do you mention multicast above? It seems irrelevant to this >> discussion. > Have to agree here... Not sure what is meant by the multicast comment. Is RPsec limited to BGP? I didn't realize it.... :-) Is OSPF multicast, and used a lot? I thought so.... Is IS-IS multicast, and used a lot? I thought so... Maybe I'm just living in an alternate universe, and in the real world, BGP is the only routing protocol actually used by anyone (?).... :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9ENRhEdu7FIVPTkEQKUtwCeLp2hLHmZlkorqFSFasB5OZFg+h8AoPMG m6bS+mz3PTq/184PBeshziy3 =hBt4 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 11:20:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezz0F-0005Dg-VI; Fri, 20 Jan 2006 11:20:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezz0E-0005DZ-NC for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 11:20:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26709 for ; Fri, 20 Jan 2006 11:19:14 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezz8z-0001hP-JD for rpsec@ietf.org; Fri, 20 Jan 2006 11:29:46 -0500 Received: by postman.ripe.net (Postfix, from userid 4008) id 3D45C24117; Fri, 20 Jan 2006 17:20:21 +0100 (CET) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 6F41E24108; Fri, 20 Jan 2006 17:20:20 +0100 (CET) Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by herring.ripe.net (Postfix) with ESMTP id 62E6D2F59C; Fri, 20 Jan 2006 17:20:20 +0100 (CET) Received: from localhost (pierre@localhost) by cow.ripe.net (8.12.10/8.12.6) with ESMTP id k0KGKKig009082; Fri, 20 Jan 2006 17:20:20 +0100 X-Authentication-Warning: cow.ripe.net: pierre owned process doing -bs Date: Fri, 20 Jan 2006 17:20:20 +0100 (CET) From: Pierre Baume To: Tony Li Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 In-Reply-To: <81503E27-2588-4F8B-BC8B-571C7DD151B7@tony.li> Message-ID: References: <43CED4F9.9070409@cisco.com> <43CFAF81.90608@cisco.com> <904DFE90-6771-4826-AF0C-7363CC1AAC5C@tony.li> <81503E27-2588-4F8B-BC8B-571C7DD151B7@tony.li> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000494 / -5.9 X-RIPE-Signature: bd7723c0cb6ad7dc145a0c863512dd32 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Tony, On Thu, 19 Jan 2006, Tony Li wrote: [...] > Again, the sophisticated implementation can prioritize the validation of > best prefixes to the foreground, while moving alternate prefixes to the > background. > > An implementation may also choose to simply select and utilize alternate > paths BEFORE validation. This is not unreasonable under the assumption > that all paths will eventually be validated or they will set of alarms > elsewhere in the network and that temporarily broken connectivity while > under attack is better that very slow convergence always. [...] > Tony The text above might have been for the sake of the argument, but I'd expect that validated (though possibly stale) prefixes should always be preferred to unvalidated ones. In the first scenario above, the injection of many illegitimate, seemingly good prefixes, would delay, possibly forever, depending on the prioritisation, the validation of legitimate, less good prefixes. In the second one, it's worse, these illegitimate, seemingly good prefixes would be used, instead of the previously known good prefix (which might still be the best). I'd argue for first come, first validated and not validated, not used. Pierre. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 11:25:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezz4T-0007SM-Nt; Fri, 20 Jan 2006 11:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezz4R-0007N9-Dv for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 11:25:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27105 for ; Fri, 20 Jan 2006 11:23:35 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzzDC-0001sl-2p for rpsec@ietf.org; Fri, 20 Jan 2006 11:34:07 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Jan 2006 11:24:54 -0500 X-IronPort-AV: i="4.01,206,1136178000"; d="scan'208"; a="80636877:sNHT32143772" Received: from RussPC (rtp-vpn4-469.cisco.com [10.82.209.213]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0KGOn6I016378; Fri, 20 Jan 2006 11:24:50 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Fri, 20 Jan 2006 11:24:51 -0500 X-PGP-Universal: processed; by RussPC on Fri, 20 Jan 2006 11:24:51 -0500 Message-ID: <43D10ECB.2090206@cisco.com> Date: Fri, 20 Jan 2006 11:24:43 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CFE049.1030901@cisco.com> <43CFF4F7.1010800@cisco.com> <43D010B6.7030600@cisco.com> <43D03856.1040702@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I, for one, do not want to see a mechanism standardized that only >> provides "valid" or "invalid" as its output. This is not a piece of data >> you're transporting across a network that's either correct or incorrect, >> like an encrypted email. > > At lower levels, security mechanisms do output precisely valid/invalid > indications. This is true for integrity checks, authentication checks, > and authorization checks, and has been for decades. One can choose to > takes these outputs from security mechanisms and allow a person to make > a value judgement that determines how the output affects behavior. One > can try to translate the human decision criteria into a > machine-enforceable policy. However, we often see people unable to > interpret the binary outputs of the low level mechanisms. We almost > always see people surprised by the results of trying to translate their > decisions processes into machine-enforceable policies. > > Using the e-mail example above, S/MIME will tell a user if a message is > signed or not, if the signature can be validated using available trust > anchors and cert status data, and whether the result of the validation > procedure was successful. All of these are binary outputs but users > have trouble dealing wit them, in practice. For example, S/MIME software > generally will not pop up a window to display the cert that was > validated, for a signed message. Thus a user will tend to think that the > name in the From field has been verified as the sender of the message, > but that is not what was checked! Also, even in an environment where > signed e-mail is common (or nominally required) a user will not > automatically reject all unsigned messages. The problem is that an email is all "one thing." Let's extend the example a little, and it might make more sense. Suppose you receive 10 emails, all with signatures, and all with slightly different attachments. Now, all of them pass through your signature test, but you can actually only read one of them. Which one will you pick? Now, suppose you could set up a local policy about which one to pick--would you simply say: "Well, they all pass the signature test, so they're all equal there?" Or, would you be inclined to say: "Well, these four also have their attachments signed, and these six don't, so let's toss out the six that don't, since I know I can trust those attachments?" I believe you would choose the latter. The problem is, you're injecting a false sense of the "oneness" of a BGP "route" into the system that doesn't exist in real BGP, or real BGP implementations. As for the assertion that providers aren't going to "be able to handle the policy, it's too complex," I would say that you shouldn't be so sure of that. If I were a provider, I would say: "The more policy control you can give me, the better, no matter if you think I can handle it or not." :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9EO0xEdu7FIVPTkEQLhJQCfbxqa5VpGtJQY5lrlR1rjdZLsmrgAoLC6 DpC/Reo3D4nDtrbqc/Bn80Lx =g8Ue -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 11:29:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezz91-0001wH-5v; Fri, 20 Jan 2006 11:29:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezz8z-0001w2-LE for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 11:29:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27353 for ; Fri, 20 Jan 2006 11:28:17 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1+MJY6lwysTLkut7IPvDvqhkuizmMcC+nQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzzHk-00020Z-3W for rpsec@ietf.org; Fri, 20 Jan 2006 11:38:49 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19gdQiVXcoTCYah/W32c4RgO6EItsivCa4@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0KGTPOJ024123; Fri, 20 Jan 2006 16:29:28 GMT Date: Fri, 20 Jan 2006 16:29:31 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Russ White Subject: Re: [RPSEC] Charter Update In-Reply-To: <43D0FF8E.5010503@cisco.com> Message-ID: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> <43D0FF8E.5010503@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.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.87.1/1246/Thu Jan 19 21:44:42 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Fri, 20 Jan 2006, Russ White wrote: > I think Merike answered that one well, so I'll leave it for the moment. I read his reply as being mostly in support of using IPSec. >> And 'large segment' is a fairly bold claim too. > > Well, I talk to a lot of people about these things.... :-) Undoubtedly. ;) How many of the concerns people in the community whom you talk you are related to the actual protocol though, rather than implementation? > Can IPsec be used IS-IS? No.... Well, why not? > Can IPsec handle the unicast/multicast nature of OSPF, really? Yes, why couldn't it? There's even a draft to replace the in-protocol HMAC with IPSec for v3. > link, even a single link type, under varying conditions. I don't > know that we want to set up a single IPsec session for multicast > from every router to every router (multicast) and then a full mesh > of IPsec sessions on a single link to handle the unicast routing > traffic. IMHO, that's a lot of a overhead (see the "too heavy" > comment above). Urg, I'd agree if were like that. It isn't AIUI. > It seems like replacement suggestions are moving forward without > anyone actually looking at the requirements--is there a need to > look at the requirements in these situations, and make > recommendations? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: It's stuck in the Web. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 11:57:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzZS-0004iD-Fc; Fri, 20 Jan 2006 11:57:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzZQ-0004hw-Kp for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 11:57:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00011 for ; Fri, 20 Jan 2006 11:55:36 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzziB-00034U-Lq for rpsec@ietf.org; Fri, 20 Jan 2006 12:06:08 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0KGukIC013479; Fri, 20 Jan 2006 11:56:47 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43D10AD9.1000209@cisco.com> References: <43CED4F9.9070409@cisco.com> <43D03779.6030007@cisco.com> <43D10AD9.1000209@cisco.com> Date: Fri, 20 Jan 2006 11:28:34 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Russ, >... > >That's why it's a SHOULD rather than MUST--these are things that need to >be traded off against other requirements in the draft. Saying SHOULD vs. MUST does not adequately convey the tradeoff notion that you suggest. It establishes performance as a more important criteria than security, but that's all it says. >Saying: "You must consider the processing burdens" gives no guidance >whatsoever. The simple answer is: "I've considered it, and I believe it >doesn't matter." That's a valid answer, based on the text you've >suggested--but it's not a valid answer given the intent of the text. But it IS a valid answer if the example I gave were being considered, e.g., the performance different is so small between the two candidates that the difference doesn't matter, or it's small and the security benefits of one outweigh the performance benefits of the other. >Another possibility is: > >Thus proposed solutions should be evaluated with regard to the >processing burden they impose. Gains in security MUST be weighted >against increases in processing burden, including the ability to shift >processing requirements onto devices external to an implementing router. >Solutions imposing smaller processing burdens with small perceived >operational security losses SHOULD be preferred. > >BTW, weren't you just arguing for more precise language, rather than >less precise language? :-) I argued that IF you insist on making the text a requirement, then it needs to be more precise. If it is a goal statement, as I suggest, then precision is not needed. I belive this is still the case, which is why I am not enthusiastic about the revised wording. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 11:58:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzbA-0004wx-CD; Fri, 20 Jan 2006 11:58:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezzb9-0004wo-FV for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 11:58:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00200 for ; Fri, 20 Jan 2006 11:57:23 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezzju-00038C-JQ for rpsec@ietf.org; Fri, 20 Jan 2006 12:07:55 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2006 08:58:40 -0800 X-IronPort-AV: i="4.01,206,1136188800"; d="scan'208"; a="1768551260:sNHT30015420" Received: from RussPC (rtp-vpn4-469.cisco.com [10.82.209.213]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0KGwdc2029645; Fri, 20 Jan 2006 08:58:40 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Fri, 20 Jan 2006 11:58:40 -0500 X-PGP-Universal: processed; by RussPC on Fri, 20 Jan 2006 11:58:40 -0500 Message-ID: <43D116B8.6080900@cisco.com> Date: Fri, 20 Jan 2006 11:58:32 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jakma Subject: Re: [RPSEC] Charter Update References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> <43D0FF8E.5010503@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > How many of the concerns people in the community whom you talk you are > related to the actual protocol though, rather than implementation? Both. >> Can IPsec be used IS-IS? No.... > > Well, why not? Hmmm... Because IS-IS doesn't run on top of IP?? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9EWwBEdu7FIVPTkEQLyVQCeJxKzWUw4/6nyFRajioNgvy3VDXgAn0Hl w+95R2JWWxhqcLEa8LGlTm2f =hMZI -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 12:02:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezzf5-0005hY-1g; Fri, 20 Jan 2006 12:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezzf2-0005gK-9f for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 12:02:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00480 for ; Fri, 20 Jan 2006 12:01:24 -0500 (EST) 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 1Ezznn-0003Fd-94 for rpsec@ietf.org; Fri, 20 Jan 2006 12:11:56 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 20 Jan 2006 09:02:42 -0800 Received: from RussPC (rtp-vpn4-469.cisco.com [10.82.209.213]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0KH2eWG027761; Fri, 20 Jan 2006 09:02:41 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Fri, 20 Jan 2006 12:02:41 -0500 X-PGP-Universal: processed; by RussPC on Fri, 20 Jan 2006 12:02:41 -0500 Message-ID: <43D117AA.5090007@cisco.com> Date: Fri, 20 Jan 2006 12:02:34 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> <43D03779.6030007@cisco.com> <43D10AD9.1000209@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> That's why it's a SHOULD rather than MUST--these are things that need to >> be traded off against other requirements in the draft. > > Saying SHOULD vs. MUST does not adequately convey the tradeoff notion > that you suggest. It establishes performance as a more important > criteria than security, but that's all it says. Actually, I disagree with this. There are specific things, in security terms, any proposed ssytem MUST do to be considered, and there are some things that any proposed system SHOULD do to be considered. The SHOULD language in my proposed text simply allows the designers to trade off between the various SHOULDs contained in the document. The way you would word it processing burdens would not be considered at all. > But it IS a valid answer if the example I gave were being considered, > e.g., the performance different is so small between the two candidates > that the difference doesn't matter, or it's small and the security > benefits of one outweigh the performance benefits of the other. Now you're making all sorts of value judgements without precise language stating what you should do with those value judgements, and no way of measuring those value judgements. In effect, taking the SHOULD out strips this text of actually saying anything useful. Again, I have no problem with: >> Thus proposed solutions should be evaluated with regard to the >> processing burden they impose. Gains in security MUST be weighted >> against increases in processing burden, including the ability to shift >> processing requirements onto devices external to an implementing router. >> Solutions imposing smaller processing burdens with small perceived >> operational security losses SHOULD be preferred. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9EXsREdu7FIVPTkEQIQJACgicndFD4OZ1BlXwUUz/IksX65ycQAoIfY 4jps2gm0yxrp93AMyM6Dc1ws =H4qn -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 12:07:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezzjx-0006Nt-U0; Fri, 20 Jan 2006 12:07:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezzjw-0006Nc-FM for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 12:07:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00805 for ; Fri, 20 Jan 2006 12:06:28 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezzsh-0003PC-Kk for rpsec@ietf.org; Fri, 20 Jan 2006 12:17:00 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 20 Jan 2006 09:07:46 -0800 X-IronPort-AV: i="4.01,206,1136188800"; d="scan'208"; a="250333816:sNHT31639476" Received: from RussPC (rtp-vpn4-469.cisco.com [10.82.209.213]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0KH7hQK021052; Fri, 20 Jan 2006 09:07:45 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Fri, 20 Jan 2006 12:07:45 -0500 X-PGP-Universal: processed; by RussPC on Fri, 20 Jan 2006 12:07:45 -0500 Message-ID: <43D118DA.2090904@cisco.com> Date: Fri, 20 Jan 2006 12:07:38 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pierre Baume Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> <43CFAF81.90608@cisco.com> <904DFE90-6771-4826-AF0C-7363CC1AAC5C@tony.li> <81503E27-2588-4F8B-BC8B-571C7DD151B7@tony.li> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The text above might have been for the sake of the argument, but I'd > expect that validated (though possibly stale) prefixes should always be > preferred to unvalidated ones. > > In the first scenario above, the injection of many illegitimate, > seemingly good prefixes, would delay, possibly forever, depending on the > prioritisation, the validation of legitimate, less good prefixes. Aren't "more good" and "less good" policy concerns best left to the provider? In other words, BGP traditionally gives users a set of tools, and leaves it up to them as to how to use those tools, beyond simply taking out routes that are provably loops. This is part of the difference between the routing world and the security world; things in the security world are very black and white. Either it's valid, or it's invalid. You don't adjust preferences, you either trust something, or throw it away. BGP has a few "black and white" decisions, and a lot of "preference" decisions. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9EY4REdu7FIVPTkEQL+twCgl+ygPFE2yzSZWUrtFaLcgf2i4akAoN6I lgL32hPR3gd8bZsCBKaIML7F =48eW -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 12:09:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezzle-0006mX-DK; Fri, 20 Jan 2006 12:09:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezzld-0006mI-2w for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 12:09:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00997 for ; Fri, 20 Jan 2006 12:08:12 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX184FWrSxuV3iSYQbI3L07qRltZVT/CVMkE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzzuN-0003Uo-NJ for rpsec@ietf.org; Fri, 20 Jan 2006 12:18:45 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+vv4Y1aOaS7wtnusVoOifg95AvCY909dA@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0KH9NNl025032; Fri, 20 Jan 2006 17:09:26 GMT Date: Fri, 20 Jan 2006 17:09:29 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Russ White Subject: Re: [RPSEC] Charter Update In-Reply-To: <43D116B8.6080900@cisco.com> Message-ID: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> <43D0FF8E.5010503@cisco.com> <43D116B8.6080900@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.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.87.1/1246/Thu Jan 19 21:44:42 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Fri, 20 Jan 2006, Russ White wrote: > Hmmm... Because IS-IS doesn't run on top of IP?? Ah, sorry, I don't follow IS-IS. I thought there was an effort underway to encapsulate IS-IS in IP and that you were referring to that. ISO IS-IS obviously isn't going to benefit from anything done in the IP space. So again that seems a red-herring, if that's what you refer to. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: All generalizations are false, including this one. -- Mark Twain _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 12:13:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzpI-0007nX-O4; Fri, 20 Jan 2006 12:13:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzzpF-0007mV-NV for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 12:13:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01401 for ; Fri, 20 Jan 2006 12:11:57 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezzy0-0003f2-WB for rpsec@ietf.org; Fri, 20 Jan 2006 12:22:30 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Jan 2006 12:13:16 -0500 X-IronPort-AV: i="4.01,206,1136178000"; d="scan'208"; a="80640508:sNHT31510032" Received: from RussPC (rtp-vpn4-469.cisco.com [10.82.209.213]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0KHDB6I024437; Fri, 20 Jan 2006 12:13:13 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Fri, 20 Jan 2006 12:13:13 -0500 X-PGP-Universal: processed; by RussPC on Fri, 20 Jan 2006 12:13:13 -0500 Message-ID: <43D11A22.6080003@cisco.com> Date: Fri, 20 Jan 2006 12:13:06 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jakma Subject: Re: [RPSEC] Charter Update References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> <43D0FF8E.5010503@cisco.com> <43D116B8.6080900@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Hmmm... Because IS-IS doesn't run on top of IP?? > > Ah, sorry, I don't follow IS-IS. I thought there was an effort underway > to encapsulate IS-IS in IP and that you were referring to that. > > ISO IS-IS obviously isn't going to benefit from anything done in the IP > space. So again that seems a red-herring, if that's what you refer to. So, you consider it "not worth worrying about?" Or??? Why shouldn't we investigate the requirements for solutions that would fit both in the IS-IS and OSPF spaces? Or, are you saying that IPsec works for OSPF (which I'm not positive I agree with yet, nor that even if it works, most network operators would agree it's the ideal or best solution), there's no reason to look at requirements, because the only protocol left is IS-IS? Or... (?) :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9EaKREdu7FIVPTkEQKvSQCgke1UoSO1n8I3E9J0j4VrvhymrncAoJDM 2jXr9JZ/RAZiYTZ5NAti6d1q =kvP3 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 12:33:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0094-00052e-LW; Fri, 20 Jan 2006 12:33:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0093-00051M-34 for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 12:33:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03589 for ; Fri, 20 Jan 2006 12:32:24 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19hmFPyxAESgrONf6X6aTTHALudESzFlj8=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00Ho-0004Xi-5X for rpsec@ietf.org; Fri, 20 Jan 2006 12:42:57 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX180X5nZB7OwToav+c9m1fSPQRktqn/4MDA@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0KHXDcg025429; Fri, 20 Jan 2006 17:33:29 GMT Date: Fri, 20 Jan 2006 17:33:20 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Russ White Subject: Re: [RPSEC] Charter Update In-Reply-To: <43D11A22.6080003@cisco.com> Message-ID: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> <43D0FF8E.5010503@cisco.com> <43D116B8.6080900@cisco.com> <43D11A22.6080003@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.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.87.1/1246/Thu Jan 19 21:44:42 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Fri, 20 Jan 2006, Russ White wrote: > So, you consider it "not worth worrying about?" Or??? I didn't say that. > Why shouldn't we investigate the requirements for solutions that > would fit both in the IS-IS and OSPF spaces? Is it possible to specify an L3 transport authentication mechanism that could be common to both? If you think it is, fair enough, fire away. I would have thought it might be difficult. If you mean more general key certificate infrastructure, x.509, whatever - sure. > Or, are you saying that IPsec works for OSPF (which I'm not > positive I agree with yet, nor that even if it works, most network > operators would agree it's the ideal or best solution), there's no > reason to look at requirements, because the only protocol left is > IS-IS? Or... (?) Let me restate the question, I didn't realise ISO L2 was going to be dragged into it: What good reason is there to not use IPSec to protect IP transported routing protocols? Even more specifically, what good reason is there to replace TCP-MD5 with anything other than IPSec? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: excessive collisions & not enough packet ambulances _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 12:43:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00Ib-0000jW-Qe; Fri, 20 Jan 2006 12:43:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F00Ia-0000jM-HJ for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 12:43:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04368 for ; Fri, 20 Jan 2006 12:42:16 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/Uv1X94okcWQVzmEgEsDyJhN+K+h8JLe4=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F00RM-0004sQ-Dr for rpsec@ietf.org; Fri, 20 Jan 2006 12:52:49 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+1ZZQhabJ7aY64/RFt2mtXtjBwlmBeHks@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0KHhUcU025525; Fri, 20 Jan 2006 17:43:32 GMT Date: Fri, 20 Jan 2006 17:43:36 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 In-Reply-To: Message-ID: References: <43CED4F9.9070409@cisco.com> <43D03779.6030007@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.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.87.1/1246/Thu Jan 19 21:44:42 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Fri, 20 Jan 2006, Stephen Kent wrote: > less burdensome solution, with worse security. So, that's why I > suggest we describe why performance is a concern and thus why it > needs to be considered in evaluating solutions, but why we ought > not try to create a requirement based on performance. Ack, balance between the two is what is desired. A no-brainer obviously. The problem, again obviously, is where that balance should lie. If it's not within the remit of this group to decide on that issue, then Stephen's text is perfect imho. > Steve regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: You know you've landed gear-up when it takes full power to taxi. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 13:44:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01F9-0008VQ-0d; Fri, 20 Jan 2006 13:44:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01F7-0008Ub-Fb for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 13:44:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09378 for ; Fri, 20 Jan 2006 13:42:46 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F01Nr-00070Y-Fm for rpsec@ietf.org; Fri, 20 Jan 2006 13:53:18 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 Jan 2006 10:44:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,206,1136188800"; d="scan'208"; a="20127778:sNHT23163756" Received: from RussPC (rtp-vpn4-469.cisco.com [10.82.209.213]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0KIhvJg007737; Fri, 20 Jan 2006 13:43:59 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Fri, 20 Jan 2006 13:43:59 -0500 X-PGP-Universal: processed; by RussPC on Fri, 20 Jan 2006 13:43:59 -0500 Message-ID: <43D12F67.2080704@cisco.com> Date: Fri, 20 Jan 2006 13:43:51 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jakma Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CED4F9.9070409@cisco.com> <43D03779.6030007@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> less burdensome solution, with worse security. So, that's why I >> suggest we describe why performance is a concern and thus why it needs >> to be considered in evaluating solutions, but why we ought not try to >> create a requirement based on performance. > > Ack, balance between the two is what is desired. A no-brainer obviously. > > The problem, again obviously, is where that balance should lie. If it's > not within the remit of this group to decide on that issue, then > Stephen's text is perfect imho. I believe it is "within the remit of this group" to provide guidance on where that balance should lie. Choosing "security required, deployability optional" isn't a balance. Again, if there's no guidance to be given, then we are ignoring the operator's input (which has been the direction this process has been pushed anyway, looking at the history of it), and I disagree with that completely. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9EvbxEdu7FIVPTkEQKnGgCghad5/Ntkyus9nI26rPYEyug++RcAn3TI VMt4n/GMEHVOVF9Au0Lgj+4P =X7Sg -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 15:10:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02aP-0005Dz-To; Fri, 20 Jan 2006 15:10:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02aO-0005Cb-Bz for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 15:10:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15598 for ; Fri, 20 Jan 2006 15:08:49 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02jB-0001Fu-28 for rpsec@ietf.org; Fri, 20 Jan 2006 15:19:22 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0KK9wIC025407; Fri, 20 Jan 2006 15:09:58 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43D10ECB.2090206@cisco.com> References: <43CFE049.1030901@cisco.com> <43CFF4F7.1010800@cisco.com> <43D010B6.7030600@cisco.com> <43D03856.1040702@cisco.com> <43D10ECB.2090206@cisco.com> Date: Fri, 20 Jan 2006 15:05:47 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 11:24 AM -0500 1/20/06, Russ White wrote: >... >The problem is that an email is all "one thing." Let's extend the >example a little, and it might make more sense. > >Suppose you receive 10 emails, all with signatures, and all with >slightly different attachments. Now, all of them pass through your >signature test, but you can actually only read one of them. Which one >will you pick? Now, suppose you could set up a local policy about which >one to pick--would you simply say: "Well, they all pass the signature >test, so they're all equal there?" > >Or, would you be inclined to say: "Well, these four also have their >attachments signed, and these six don't, so let's toss out the six that >don't, since I know I can trust those attachments?" bad analogy, in more than one way. An ability to sign the message body also confers an ability to sign attachments. So, did you mean that some messages have no attachments and thus no signed attachments, or that some have attachments that are not signed even though the message is signed? See how even a little complexity, coupled with imprecise attempts to express a policy leads to confusion? >I believe you would choose the latter. The problem is, you're injecting >a false sense of the "oneness" of a BGP "route" into the system that >doesn't exist in real BGP, or real BGP implementations. huh? >As for the assertion that providers aren't going to "be able to handle >the policy, it's too complex," I would say that you shouldn't be so sure >of that. If I were a provider, I would say: "The more policy control you >can give me, the better, no matter if you think I can handle it or not." A very manly statement, but experience suggests that more knobs leads not to greater security through more fine-grained control, but to more config errors :-). Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 15:10:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02aQ-0005EY-Gw; Fri, 20 Jan 2006 15:10:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F02aP-0005DA-5Q for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 15:10:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15603 for ; Fri, 20 Jan 2006 15:08:50 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F02jC-0001G5-TR for rpsec@ietf.org; Fri, 20 Jan 2006 15:19:23 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0KK9wIE025407; Fri, 20 Jan 2006 15:09:59 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43D10D3D.9030907@cisco.com> References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> <43D10D3D.9030907@cisco.com> Date: Fri, 20 Jan 2006 15:09:38 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Charter Update Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rpsec@ietf.org, Paul Jakma X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 11:18 AM -0500 1/20/06, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>> We're talking about BGP peering sessions, which take place over TCP. >>> The proposals I noted are for TCP session authentication, primarily >>> in support of BGP session protection. TCP does not support multicast. >>> Why do you mention multicast above? It seems irrelevant to this >>> discussion. > >> Have to agree here... Not sure what is meant by the multicast comment. > >Is RPsec limited to BGP? I didn't realize it.... :-) As you may have noted from other comments on your message, the thread was dealing explicitly with the candidate replacements for the TCP MD5 option, not network or transport layer security for all routing protocols. I feel pretty confident about that since it was my message to which you responded. >Is OSPF multicast, and used a lot? I thought so.... Is IS-IS multicast, >and used a lot? I thought so... Maybe I'm just living in an alternate >universe, and in the real world, BGP is the only routing protocol >actually used by anyone (?).... You appear to be living in a universe where the topic of a thread is easily lost. Maybe you need duck tape in your universe. :-) Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 15:43:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F036k-0000qQ-EF; Fri, 20 Jan 2006 15:43:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F036j-0000pV-6M for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 15:43:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17726 for ; Fri, 20 Jan 2006 15:42:13 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F03FV-0002CO-TB for rpsec@ietf.org; Fri, 20 Jan 2006 15:52:47 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0KKhQIG027248; Fri, 20 Jan 2006 15:43:29 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43D117AA.5090007@cisco.com> References: <43CED4F9.9070409@cisco.com> <43D03779.6030007@cisco.com> <43D10AD9.1000209@cisco.com> <43D117AA.5090007@cisco.com> Date: Fri, 20 Jan 2006 15:41:07 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 12:02 PM -0500 1/20/06, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>> That's why it's a SHOULD rather than MUST--these are things that need to >>> be traded off against other requirements in the draft. >> >> Saying SHOULD vs. MUST does not adequately convey the tradeoff notion >> that you suggest. It establishes performance as a more important >> criteria than security, but that's all it says. > >Actually, I disagree with this. There are specific things, in security >terms, any proposed ssytem MUST do to be considered, and there are some >things that any proposed system SHOULD do to be considered. The SHOULD >language in my proposed text simply allows the designers to trade off >between the various SHOULDs contained in the document. MUST and SHOULD are reserved words in the context of Internet standards track documents. Using them to express preferences in tradeoffs is not within the scope of their definition as per RFC 2119. >The way you would word it processing burdens would not be considered at all. I don't think most individuals who are proficient in English would agree with that characterization. > >> But it IS a valid answer if the example I gave were being considered, >> e.g., the performance different is so small between the two candidates >> that the difference doesn't matter, or it's small and the security >> benefits of one outweigh the performance benefits of the other. > >Now you're making all sorts of value judgements without precise language >stating what you should do with those value judgements, and no way of >measuring those value judgements. In effect, taking the SHOULD out >strips this text of actually saying anything useful. I'm giving an example that demonstrates why your proposed wording is biased. > >Again, I have no problem with: > >>> Thus proposed solutions should be evaluated with regard to the >>> processing burden they impose. Gains in security MUST be weighted >>> against increases in processing burden, including the ability to shift >>> processing requirements onto devices external to an implementing router. >>> Solutions imposing smaller processing burdens with small perceived > >> operational security losses SHOULD be preferred. I do have a problem with it. Russ, irrespective of your technical capabilities in the routing area, our extended debates on this list often have shown that you often have trouble generating language that is clearly understood by all WG members. Perhaps we need to have someone else work on suitable language here. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 19:54:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F071H-0003Nv-NV; Fri, 20 Jan 2006 19:54:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F071G-0003LJ-F1 for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 19:54:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17216 for ; Fri, 20 Jan 2006 19:52:51 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F07A3-0005pM-3M for rpsec@ietf.org; Fri, 20 Jan 2006 20:03:27 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2006 13:48:02 -0800 X-IronPort-AV: i="unknown"; a="1768690671:sNHT0" Received: from RussPC (rtp-vpn4-469.cisco.com [10.82.209.213]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0KLlqc2027525; Fri, 20 Jan 2006 13:47:58 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Fri, 20 Jan 2006 16:47:58 -0500 X-PGP-Universal: processed; by RussPC on Fri, 20 Jan 2006 16:47:58 -0500 Message-ID: <43D15A81.7050000@cisco.com> Date: Fri, 20 Jan 2006 16:47:45 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] Charter Update References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> <43D10D3D.9030907@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rpsec@ietf.org, Paul Jakma X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Is OSPF multicast, and used a lot? I thought so.... Is IS-IS multicast, >> and used a lot? I thought so... Maybe I'm just living in an alternate >> universe, and in the real world, BGP is the only routing protocol >> actually used by anyone (?).... > You appear to be living in a universe where the topic of a thread is > easily lost. Maybe you need duck tape in your universe. :-) Or, perhaps, I'm not the one who lost the topic of the thread. The original charter item under discussion was: Mar 06 Submit initial document discussing requirements for peering relationship authorization and authentication mechanisms. I don't see BGP in there. The original intent was to produce a requirements document for peering authorization/authentication requirements for all protocols, since the requirements should be fairly common among them. But, the scope, number of docs, whether this was useful work, etc, was where the original discussion started. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9FajhEdu7FIVPTkEQLMJgCePcT0WwC5yspqmIGePmIXReY7lcgAn14O 6Lxg6EL7YUZal688JNVWRP4X =vEoo -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 20 19:54:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F071v-0003zn-An; Fri, 20 Jan 2006 19:54:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F071t-0003zi-DU for rpsec@megatron.ietf.org; Fri, 20 Jan 2006 19:54:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17238 for ; Fri, 20 Jan 2006 19:53:30 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F07Ai-0005q2-1t for rpsec@ietf.org; Fri, 20 Jan 2006 20:04:05 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2006 13:50:42 -0800 X-IronPort-AV: i="unknown"; a="1768691807:sNHT0" Received: from RussPC (rtp-vpn4-469.cisco.com [10.82.209.213]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0KLocc2028949; Fri, 20 Jan 2006 13:50:39 -0800 (PST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Fri, 20 Jan 2006 16:50:38 -0500 X-PGP-Universal: processed; by RussPC on Fri, 20 Jan 2006 16:50:38 -0500 Message-ID: <43D15B28.2090708@cisco.com> Date: Fri, 20 Jan 2006 16:50:32 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 References: <43CFE049.1030901@cisco.com> <43CFF4F7.1010800@cisco.com> <43D010B6.7030600@cisco.com> <43D03856.1040702@cisco.com> <43D10ECB.2090206@cisco.com> In-Reply-To: X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Suppose you receive 10 emails, all with signatures, and all with >> slightly different attachments. Now, all of them pass through your >> signature test, but you can actually only read one of them. Which one >> will you pick? Now, suppose you could set up a local policy about which >> one to pick--would you simply say: "Well, they all pass the signature >> test, so they're all equal there?" >> >> Or, would you be inclined to say: "Well, these four also have their >> attachments signed, and these six don't, so let's toss out the six that >> don't, since I know I can trust those attachments?" > > bad analogy, in more than one way. An ability to sign the message body > also confers an ability to sign attachments. So, did you mean that some Bad assumption.... :-) > messages have no attachments and thus no signed attachments, or that > some have attachments that are not signed even though the message is > signed? See how even a little complexity, coupled with imprecise > attempts to express a policy leads to confusion? Certainly, but as a receiver, I should be able to handle problems like this, rather than simply saying: "I declare all received messages invalid that aren't completely signed." In fact, this sort of decleration makes partial deployments of a routing security system impossible, since it's impossible to believe that the entire AS Path is going to be validatable (??) on day one, or even at _any_ point in the future realm of possibility. >> As for the assertion that providers aren't going to "be able to handle >> the policy, it's too complex," I would say that you shouldn't be so sure >> of that. If I were a provider, I would say: "The more policy control you >> can give me, the better, no matter if you think I can handle it or not." > > A very manly statement, but experience suggests that more knobs leads > not to greater security through more fine-grained control, but to more > config errors :-). Perhaps, perhaps not. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ9FbLhEdu7FIVPTkEQI6YwCg7YYNHjFxVYJNAfw3sZjPpXHqmRIAn0df FT1St9XHwIYr3HjNmQQl9ko4 =p87F -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Jan 21 07:49:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0IBM-00071B-4s; Sat, 21 Jan 2006 07:49:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0IBK-0006z4-95 for rpsec@megatron.ietf.org; Sat, 21 Jan 2006 07:49:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27788 for ; Sat, 21 Jan 2006 07:47:57 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0IKF-0007dh-JX for rpsec@ietf.org; Sat, 21 Jan 2006 07:58:41 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0LCmpHa021682; Sat, 21 Jan 2006 14:48:51 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0LCmkRu021676; Sat, 21 Jan 2006 14:48:46 +0200 Date: Sat, 21 Jan 2006 14:48:46 +0200 (EET) From: Pekka Savola To: Paul Jakma In-Reply-To: Message-ID: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <021301c61dae$fca318e0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1246/Thu Jan 19 23:44:42 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: rpsec@ietf.org, Tom Petch , Stephen Kent , Russ White Subject: [RPSEC] no TCP-MD5 replacement please X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Fri, 20 Jan 2006, Paul Jakma wrote: ... > Yes, I agree. Hence why I really do not see why we should we invent another > IPSec-alike to replace TCP-MD5 for BGP. FWIW, I agree with this. TCP-MD5, especially in years to come, is not a perfect solution for BGP. It probably isn't even a "good" solution. But is it a sufficient solution, given other mechanisms (e.g., GTSM) that exist? In my opinion, yes. If you're worried about attacks on the link [1], you'll want to use something strong, and I'd recommend considering IPsec, not reinventing it. If you're worried about attacks from outside the link, you can use stuff like ingress filtering, proper ICMP error verification and/or GTSM to complement TCP-MD5. Heck, you may not even need to use TCP-MD5 at all. The original goal of TCP-MD5 was to create a simple solution. Reinventing IPsec to replace it might or might not end up being "simple (enough)" but nonetheless I'm puzzled why doing so would make sense. [1] TCP-MD5 (or something like that) is really only needed when you have multiple sessions over an internet exchange, and you want to protect the session from deliberate attacks from the other exchange members' peering routers. In the exchanges we participate at, we don't see this as a significant threat. Other mechanisms (ingress filtering, GTSM) can deal with all the other major usage scenarios. -- 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 Sat Jan 21 19:51:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0TRl-0001iz-4E; Sat, 21 Jan 2006 19:51:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0TRk-0001el-0G for rpsec@megatron.ietf.org; Sat, 21 Jan 2006 19:51:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06296 for ; Sat, 21 Jan 2006 19:49:30 -0500 (EST) Received: from bathurst.ozonline.com.au ([203.23.159.222] helo=ozonline.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0Tad-00010L-2n for rpsec@ietf.org; Sat, 21 Jan 2006 20:00:20 -0500 Received: from IBM3600A6A6AC6 (adsl-syd-2-168.ozonline.com.au [202.173.193.168]) by ozonline.com.au (8.13.4/8.12.11) with SMTP id k0M0nweB013259; Sun, 22 Jan 2006 11:50:09 +1100 Message-ID: <006401c61eed$c8ac5f20$6401a8c0@IBM3600A6A6AC6> From: "Dan B" To: "Pekka Savola" , "Paul Jakma" References: <438F3F9F.30907@cisco.com><43C6581B.9000000@cisco.com><43CED1F4.60501@cisco.com><021301c61dae$fca318e0$0601a8c0@pc6> Subject: Re: [RPSEC] no TCP-MD5 replacement please Date: Sun, 22 Jan 2006 11:49:58 +1100 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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Tom Petch , Stephen Kent , Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org I agree,,,,, dan bernardo information security officer dept of commerce, nsw, australia ----- Original Message ----- From: "Pekka Savola" To: "Paul Jakma" Cc: ; "Tom Petch" ; "Stephen Kent" ; "Russ White" Sent: Saturday, January 21, 2006 11:48 PM Subject: [RPSEC] no TCP-MD5 replacement please > On Fri, 20 Jan 2006, Paul Jakma wrote: > ... > > Yes, I agree. Hence why I really do not see why we should we invent another > > IPSec-alike to replace TCP-MD5 for BGP. > > FWIW, I agree with this. TCP-MD5, especially in years to come, is not > a perfect solution for BGP. It probably isn't even a "good" solution. > But is it a sufficient solution, given other mechanisms (e.g., GTSM) > that exist? > > In my opinion, yes. If you're worried about attacks on the link [1], > you'll want to use something strong, and I'd recommend considering > IPsec, not reinventing it. If you're worried about attacks from > outside the link, you can use stuff like ingress filtering, proper > ICMP error verification and/or GTSM to complement TCP-MD5. Heck, you > may not even need to use TCP-MD5 at all. > > The original goal of TCP-MD5 was to create a simple solution. > Reinventing IPsec to replace it might or might not end up being > "simple (enough)" but nonetheless I'm puzzled why doing so would make > sense. > > [1] TCP-MD5 (or something like that) is really only needed when you > have multiple sessions over an internet exchange, and you want to > protect the session from deliberate attacks from the other exchange > members' peering routers. In the exchanges we participate at, we don't > see this as a significant threat. Other mechanisms (ingress > filtering, GTSM) can deal with all the other major usage scenarios. > > -- > 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 > > _____________________________________________________ > This mail has been virus scanned by Australia On Line > see http://www.australiaonline.net.au/mailscanning > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 23 12:29:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F15Vu-0001pG-SV; Mon, 23 Jan 2006 12:29:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F15Vs-0001oX-Oc for rpsec@megatron.ietf.org; Mon, 23 Jan 2006 12:29:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04506 for ; Mon, 23 Jan 2006 12:28:27 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F15fD-0005nP-T5 for rpsec@ietf.org; Mon, 23 Jan 2006 12:39:39 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0NHTYIC001144; Mon, 23 Jan 2006 12:29:34 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43D15A81.7050000@cisco.com> References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <43D03673.7030508@cisco.com> <43D10D3D.9030907@cisco.com> <43D15A81.7050000@cisco.com> Date: Mon, 23 Jan 2006 12:26:35 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Charter Update Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Russ, >-... >Or, perhaps, I'm not the one who lost the topic of the thread. The >original charter item under discussion was: > >Mar 06 Submit initial document discussing requirements for peering >relationship authorization and authentication mechanisms. > >I don't see BGP in there. The original intent was to produce a >requirements document for peering authorization/authentication >requirements for all protocols, since the requirements should be fairly >common among them. > >But, the scope, number of docs, whether this was useful work, etc, was >where the original discussion started. Sorry, Russ, I was viewing the thread as being rooted at the messages last Wednesday, where I responded to Pekka, and you concurred, saying "Yes, correct. The concept is simple: It appears we've come to the "end of our rope" with MD5, in particular. Should we produce a doc that will define a concencus [sic] of requirements for what is to replace MD5?" However, the thread with the original Subject of "Charter Update" dates back to 12/1/05, when you suggested broadening the charter via the bullet you cited above. That bullet was not specific to BGP, but since that message was 6 weeks prior to the current discussion, and given your more recent comment about what we were discussing (as quoted above), I think most of us assumed that the more recent, BGP-focused comment you made was what we were discussing now. Hence the multi-cast vs. unicast confusion. Going forward I think the original bullet is too broad and should be replace by protocol-specific bullets. It seems rather ambitious to call for even an initial document addressing authorization and authentication for all IETF routing protocols in two months. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 23 13:48:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F16jh-00076y-MK; Mon, 23 Jan 2006 13:48:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F16jf-00076t-AT for rpsec@megatron.ietf.org; Mon, 23 Jan 2006 13:48:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09138 for ; Mon, 23 Jan 2006 13:46:45 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F16t2-0008JI-1z for rpsec@ietf.org; Mon, 23 Jan 2006 13:57:58 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0NIlhIC005588; Mon, 23 Jan 2006 13:47:43 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 23 Jan 2006 13:47:46 -0500 To: Pekka Savola From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: rpsec@ietf.org, Tony Tauber Subject: [RPSEC] Re: bgpsecrec-03 (mostly on IPsec and ICMP now) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Pekka, >>... > >In my experience, the current mechanisms are not flexible enough and >sufficiently widely used to support this. Are you saying that you don't feel that current mechanisms deal well with suppression of route flaps? if so I agree that there is a lot of room for improvement, which is important irrespective of whether we deploy routing security mechanisms. >Let's take an example: an ISP has two upstream providers, and wants >to mainly use one of them for whatever reasons. When that session >goes down, 200K routes get active on the backup session. When that >session comes back up, 200K routes get re-activated on the primary >session. The same applies to peering with smaller number of prefixes. OK, fair example, except that I thought the route total these days was about 180K, but, hey, what's 20K routes among friends :-)? > >>... > >For those operators, less than 20% of peers contribute over 80% of >prefixes (or so I'd estimate). Yet, the large number of prefixes >heard from peers (rather than downstreams) is the real problem. OK. But, as I noted earlier, the number of prefixes is not so much an issue as the number of UPDATE messages that carry them, and the number of hops for each route. >>... > >This text deals with ICMPs protected by an SA. Do you assume that >ICMP traffic between the neighbors would need to be protected by an >SA? yes, but that can be one SA that carries both ICMP traffic plus BGP traffic. >>... > >AFAICS, this doesn't really help: > - source and destination addresses from the IP header can be >checked but are not integrity-protected If there is one SA between two peers, and that SA carries the ICMP error messages, then the S/D address check is implicit. This is because the key used for that SA is unique to the peers and the S/D values are checked as part of the access control processing applied to all incoming (IPsec-protected) packets via the SAD entry. > - the payload need not include more than 8 bytes of the payload, so >in case of ESP (for example, similar for AH), you could only see the >IPsec SPI and Acknowledgement number. If the ICMP error message is generated using the IPsec-protected, received message then yes, the returned content is limited. But, I think it is sufficient anyway. >Maybe you're assuming that the peer would send back the whole packet >in ICMP payload (so that you could pass it to the IPsec layer for >cryptographic verification). That's not required by RFC 1812. I don't assume more than the usual ICMP error message requirements. But I do assume that the ICMP message is IPsec-protected. >As the integrity of the payload cannot be verified, I think anyone >can send an ICMP message which contains the source and destination >address used by the outbound SA. Not quite. If the ICMP message is received via then same SA that carries BGP traffic (which is what I have assumed), then the receiver knows the source and the IPsec processing for ICMP error messages will reject an error message IF the error message purports to refer to traffic that would not have been carried on the SA via which it was received. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 23 15:16:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1877-0002gP-PE; Mon, 23 Jan 2006 15:16:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1874-0002g3-SF for rpsec@megatron.ietf.org; Mon, 23 Jan 2006 15:16:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14745 for ; Mon, 23 Jan 2006 15:15:00 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F18GT-0002oC-BO for rpsec@ietf.org; Mon, 23 Jan 2006 15:26:14 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k0NKGBIE010886; Mon, 23 Jan 2006 15:16:12 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <438F3F9F.30907@cisco.com> <43C6581B.9000000@cisco.com> <43CED1F4.60501@cisco.com> <021301c61dae$fca318e0$0601a8c0@pc6> Date: Mon, 23 Jan 2006 14:21:42 -0500 To: Pekka Savola From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: rpsec@ietf.org Subject: [RPSEC] Re: no TCP-MD5 replacement please X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Pekka, I think your message states the important criteria, i.e., if an ISP is not concerned about on-link attacks, then GTSM, ingress filtering, and ICMP security measures are probably sufficient. However, when on-link attacks are a concern, we need a suitable replacement for the TCP-MD5 option. (I would not include the qualification "... deliberate attacks from the other exchange members' peering routers." The attacks could be launched by any device with access to the links via which the peering takes place.) From a standards perspective, our goal should be to develop standards that give the operators the necessary standards from which to choose, based on their perception of the threat. I take Paul's messages to be in that spirit when he suggests we consider IPsec as an alternative to replacing the TCP-MD5 option with a similar option that updates the algorithms and improves key management. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 23 16:29:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F19FI-0008IN-8C; Mon, 23 Jan 2006 16:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F19FG-0008GZ-5v for rpsec@megatron.ietf.org; Mon, 23 Jan 2006 16:29:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22573 for ; Mon, 23 Jan 2006 16:27:33 -0500 (EST) 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 1F19Oe-0006PK-8Y for rpsec@ietf.org; Mon, 23 Jan 2006 16:38:46 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 23 Jan 2006 13:28:50 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0NLSnKT024314; Mon, 23 Jan 2006 13:28:50 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 13:28:49 -0800 Received: from [128.107.22.160] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 Jan 2006 13:28:49 -0800 User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Mon, 23 Jan 2006 15:28:51 -0600 Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please From: David Ward To: Stephen Kent , Pekka Savola , David Ward Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Jan 2006 21:28:49.0292 (UTC) FILETIME=[FFD94CC0:01C62063] X-Spam-Score: 1.1 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org All - In the past I wrote a draft on how to run BGP w/ IPsec. There are effectively no protocol changes required. If we want it dusted off and republished, I can revisit it. Note that there is no magical golden ring that one obtains by running BGP over IPsec but, it can easily be done and written as a BCP, informational ... -DWard On 1/23/06 1:21 PM, "Stephen Kent" wrote: > Pekka, > > I think your message states the important criteria, i.e., if an ISP > is not concerned about on-link attacks, then GTSM, ingress filtering, > and ICMP security measures are probably sufficient. However, when > on-link attacks are a concern, we need a suitable replacement for the > TCP-MD5 option. (I would not include the qualification "... > deliberate attacks from the other exchange members' peering routers." > The attacks could be launched by any device with access to the links > via which the peering takes place.) > > From a standards perspective, our goal should be to develop standards > that give the operators the necessary standards from which to choose, > based on their perception of the threat. I take Paul's messages to be > in that spirit when he suggests we consider IPsec as an alternative > to replacing the TCP-MD5 option with a similar option that updates > the algorithms and improves key management. > > Steve > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 23 17:35:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1AHR-0002gi-Gn; Mon, 23 Jan 2006 17:35:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1AHP-0002gT-4h for rpsec@megatron.ietf.org; Mon, 23 Jan 2006 17:35:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00052 for ; Mon, 23 Jan 2006 17:33:49 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19lR38P/ZFP06jesZ7I/YxQTBKDeXEJRAQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1AQo-00011e-0N for rpsec@ietf.org; Mon, 23 Jan 2006 17:45:04 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19SdVaTkZ1kHzEuZ4vfdMxbxu5+hsfS40A@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k0NMYabu018609; Mon, 23 Jan 2006 22:34:41 GMT Date: Mon, 23 Jan 2006 22:34:50 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Russ White Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 In-Reply-To: <43D12F67.2080704@cisco.com> Message-ID: References: <43CED4F9.9070409@cisco.com> <43D03779.6030007@cisco.com> <43D12F67.2080704@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.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.87.1/1247/Sat Jan 21 10:24:51 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Fri, 20 Jan 2006, Russ White wrote: > I believe it is "within the remit of this group" to provide > guidance on where that balance should lie. Choosing "security > required, deployability optional" isn't a balance. Agreed. > Again, if there's no guidance to be given, then we are ignoring the > operator's input (which has been the direction this process has > been pushed anyway, looking at the history of it), and I disagree > with that completely. Well Stephen's proposed text does refer to the deployability balance: "Thus proposed solutions should be evaluated carefully with regard to the processing burden they may impose, since deployment may be impeded if network operators perceive that a specific solution will impose an unacceptable processing burden." That seems quite reasonable, balanced and neutral. More to the point, how long can we go on to argue 'by proxy' via the requirements text? Either let's discuss and decide on the points festering behind the scenes here directly, or if it's not in scope to do so, let's adopt something reasonable that remains neutral and hence has some chance of consensus so the next group which /will/ be allowed to argue the meat of the matter and make the decision(s) can then go and do so. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Remember: use logout to logout. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 27 15:08:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Zta-0004b9-22; Fri, 27 Jan 2006 15:08:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2ZtX-0004ag-IF for rpsec@megatron.ietf.org; Fri, 27 Jan 2006 15:08:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10389 for ; Fri, 27 Jan 2006 15:06:59 -0500 (EST) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2a3k-0003qV-Au for rpsec@ietf.org; Fri, 27 Jan 2006 15:19:05 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 27 Jan 2006 12:08:01 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id D012D67423; Fri, 27 Jan 2006 12:08:00 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 2A20667420; Fri, 27 Jan 2006 12:08:00 -0800 (PST) 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.3a-GA) with ESMTP id CUK72661; Fri, 27 Jan 2006 12:07:59 -0800 (PST) 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 B892720501; Fri, 27 Jan 2006 12:07:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] Re: no TCP-MD5 replacement please Date: Fri, 27 Jan 2006 12:07:59 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36357E32@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [RPSEC] Re: no TCP-MD5 replacement please Thread-Index: AcYgZBTOFxRHirH/RkCNysL7IjWjDADGRWcw From: "Bora Akyol" To: "David Ward" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006012708; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230342E34334441374332412E303032312D412D; ENG=IBF; TS=20060127200803; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006012708_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FC4A22B41W4938817-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Can you please qualify "easily"? Just like the TCP-MD5, the distribution of keys, management, synchronized rollover etc, become similar issues with IPSEC, no? Regards, Bora > -----Original Message----- > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org]=20 > On Behalf Of David Ward > Sent: Monday, January 23, 2006 1:29 PM > To: Stephen Kent; Pekka Savola; David Ward > Cc: rpsec@ietf.org > Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please >=20 > All - >=20 > In the past I wrote a draft on how to run BGP w/ IPsec. There=20 > are effectively no protocol changes required. If we want it=20 > dusted off and republished, I can revisit it. Note that there=20 > is no magical golden ring that one obtains by running BGP=20 > over IPsec but, it can easily be done and written as a BCP,=20 > informational ... >=20 > -DWard _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 27 15:31:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2aG8-0005BH-Iu; Fri, 27 Jan 2006 15:31:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2aG5-0005A2-PB for rpsec@megatron.ietf.org; Fri, 27 Jan 2006 15:31:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11879 for ; Fri, 27 Jan 2006 15:30:17 -0500 (EST) 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 1F2aQI-0004X5-ND for rpsec@ietf.org; Fri, 27 Jan 2006 15:42:24 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 27 Jan 2006 12:31:39 -0800 X-IronPort-AV: i="4.01,227,1136188800"; d="scan'208"; a="397402055:sNHT31373994" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0RKVdKT001946; Fri, 27 Jan 2006 12:31:39 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Jan 2006 12:31:39 -0800 Received: from [171.71.141.111] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 Jan 2006 12:31:38 -0800 User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Fri, 27 Jan 2006 14:31:44 -0600 Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please From: David Ward To: Bora Akyol , David Ward Message-ID: In-Reply-To: <03235919BBDE634289BB6A0758A20B36357E32@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Jan 2006 20:31:38.0864 (UTC) FILETIME=[ACCE8700:01C62380] X-Spam-Score: 1.1 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org "Easily" means that there are no BGP or IPsec changes necessary. As we know, IPsec is designed to allow apps to be able to run w/o change over a tunnel or in transport mode. In this regard, BGP is just another application. Wrt the operational needs of IPsec and key mgmt ... it already is specified and there is wide implementation of sync rollover, management, distribution, etc. 0.02$ -DWard On 1/27/06 2:07 PM, "Bora Akyol" wrote: > Can you please qualify "easily"? > > Just like the TCP-MD5, the distribution of keys, management, > synchronized rollover etc, become similar issues with IPSEC, no? > > Regards, > > Bora > > >> -----Original Message----- >> From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] >> On Behalf Of David Ward >> Sent: Monday, January 23, 2006 1:29 PM >> To: Stephen Kent; Pekka Savola; David Ward >> Cc: rpsec@ietf.org >> Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please >> >> All - >> >> In the past I wrote a draft on how to run BGP w/ IPsec. There >> are effectively no protocol changes required. If we want it >> dusted off and republished, I can revisit it. Note that there >> is no magical golden ring that one obtains by running BGP >> over IPsec but, it can easily be done and written as a BCP, >> informational ... >> >> -DWard > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 27 15:32:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2aGf-0005UE-FT; Fri, 27 Jan 2006 15:32:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2aGd-0005Sh-Gt for rpsec@megatron.ietf.org; Fri, 27 Jan 2006 15:32:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11906 for ; Fri, 27 Jan 2006 15:30:50 -0500 (EST) Received: from purgatory.unfix.org ([213.136.24.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2aQq-0004Xm-JI for rpsec@ietf.org; Fri, 27 Jan 2006 15:42:57 -0500 Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 50AD47FC8; Fri, 27 Jan 2006 21:31:47 +0100 (CET) Message-ID: <43DA8301.10804@unfix.org> Date: Fri, 27 Jan 2006 21:30:57 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Bora Akyol Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please References: <03235919BBDE634289BB6A0758A20B36357E32@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <03235919BBDE634289BB6A0758A20B36357E32@NT-SJCA-0751.brcm.ad.broadcom.com> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=333E7C23; url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: rpsec@ietf.org, David Ward 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: , Content-Type: multipart/mixed; boundary="===============0021335895==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0021335895== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig651059D1DF039DEF083F0894" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig651059D1DF039DEF083F0894 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bora Akyol wrote: > Can you please qualify "easily"? >=20 > Just like the TCP-MD5, the distribution of keys, management, > synchronized rollover etc, become similar issues with IPSEC, no? You mean to say that you still type every line of the configuration file in your router!? :) Indeed it gives some pains but a management utility for your router will take most of those away. Having an extra line for the configuration statements that IPSEC brings is not much different from having the management utility generate that line you needed to generate for the TCP-MD5 option... Next to the IPSEC option, (maybe I missed out on this one) is the option for checking the TTL, thus that it is still 255 already done? That would also already save quite some trouble, at least it limits hijacking/rst's etc, if they are possible, to the same subnet when spoofed packets could be directed to the RE. Greets, Jeroen --------------enig651059D1DF039DEF083F0894 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFD2oMBKaooUjM+fCMRAoLsAKCLmvLrWMIu0ojCY3EU+nG5YRG45ACgor18 oTEgVEDfpgt4VEk5XmOmKFg= =szUX -----END PGP SIGNATURE----- --------------enig651059D1DF039DEF083F0894-- --===============0021335895== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0021335895==-- From rpsec-bounces@ietf.org Fri Jan 27 15:35:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2aJJ-0006gm-CX; Fri, 27 Jan 2006 15:35:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2aJG-0006d2-TW for rpsec@megatron.ietf.org; Fri, 27 Jan 2006 15:35:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12085 for ; Fri, 27 Jan 2006 15:33:34 -0500 (EST) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2aTU-0004ei-QY for rpsec@ietf.org; Fri, 27 Jan 2006 15:45:41 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 27 Jan 2006 12:34:44 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 7F11167420; Fri, 27 Jan 2006 12:34:44 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 1EA8A67420; Fri, 27 Jan 2006 12:34:44 -0800 (PST) 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.3a-GA) with ESMTP id CUK80530; Fri, 27 Jan 2006 12:34:43 -0800 (PST) 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 C49D620501; Fri, 27 Jan 2006 12:34:43 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] Re: no TCP-MD5 replacement please Date: Fri, 27 Jan 2006 12:34:42 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36357E34@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [RPSEC] Re: no TCP-MD5 replacement please Thread-Index: AcYjgLyprhLq92vhTRefDOuGXaq7+QAABddQ From: "Bora Akyol" To: "Jeroen Massar" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006012708; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230332E34334441383236462E303030312D412D; ENG=IBF; TS=20060127203448; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006012708_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FC45C6E41W4942958-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org The problem is that the other end of the connection is not necessarily **my router**. You have to synchronize your keys etc with a partner outside the organization. Clearly, this is easier than the general IPSEC key distribution problem, but still not easy when done in large scale. Out of curiousity, how often do you change the TCP-MD5 keys in your routers? Do you use the same key for all BGP peers to the same peering AS? Thanks =20 > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@unfix.org]=20 > Sent: Friday, January 27, 2006 12:31 PM > To: Bora Akyol > Cc: David Ward; rpsec@ietf.org > Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please >=20 > Bora Akyol wrote: > > Can you please qualify "easily"? > >=20 > > Just like the TCP-MD5, the distribution of keys, management,=20 > > synchronized rollover etc, become similar issues with IPSEC, no? >=20 > You mean to say that you still type every line of the=20 > configuration file in your router!? :) Indeed it gives some=20 > pains but a management utility for your router will take most=20 > of those away. >=20 > Having an extra line for the configuration statements that=20 > IPSEC brings is not much different from having the management=20 > utility generate that line you needed to generate for the=20 > TCP-MD5 option... >=20 >=20 > Next to the IPSEC option, (maybe I missed out on this one) is=20 > the option for checking the TTL, thus that it is still 255=20 > already done? That would also already save quite some=20 > trouble, at least it limits hijacking/rst's etc, if they are=20 > possible, to the same subnet when spoofed packets could be=20 > directed to the RE. >=20 > Greets, > Jeroen >=20 >=20 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 27 15:39:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2aNb-0007kt-5q; Fri, 27 Jan 2006 15:39:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2aNY-0007jM-NS for rpsec@megatron.ietf.org; Fri, 27 Jan 2006 15:39:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12334 for ; Fri, 27 Jan 2006 15:37:59 -0500 (EST) Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2aXk-0004lm-Hq for rpsec@ietf.org; Fri, 27 Jan 2006 15:50:06 -0500 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 27 Jan 2006 12:39:10 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id C2F9467420; Fri, 27 Jan 2006 12:39:10 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 1899067423; Fri, 27 Jan 2006 12:39:09 -0800 (PST) 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.3a-GA) with ESMTP id CUK81772; Fri, 27 Jan 2006 12:39:09 -0800 (PST) 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 8800020502; Fri, 27 Jan 2006 12:39:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] Re: no TCP-MD5 replacement please Date: Fri, 27 Jan 2006 12:39:08 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36357E37@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [RPSEC] Re: no TCP-MD5 replacement please Thread-Index: AcYjgLQolF6g3KgzQACYkFnWbu5ucAAAG1aQ From: "Bora Akyol" To: "David Ward" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006012708; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230342E34334441383337372E303032322D412D; ENG=IBF; TS=20060127203912; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006012708_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FC45B6410G5039258-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org > Wrt the operational needs of IPsec and key mgmt ... it=20 > already is specified and there is wide implementation of sync=20 > rollover, management, distribution, etc.=20 >=20 > 0.02$ >=20 > -DWard >=20 Thank you, I am more familiar with the IPSEC case then the TCP-MD5 case, can you please define "wide"? For VPN access using one time passwords or certs, yes, there are many tools. However, for connectivity between two hosts that are not under the same administrative domain, other than using certificates issued by a mutually trusted root, what other mechanisms do we have to synhcronize rollover of pre-shared keys and manage this on=20 a lot of routers? If you have any pointers to published work, I would appreciate it. I am hoping that such work exists after the blind TCP reset issue that appeared a couple years ago. Thanks Bora _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 27 16:47:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2bRG-00013A-SW; Fri, 27 Jan 2006 16:47:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2bRF-000132-OL for rpsec@megatron.ietf.org; Fri, 27 Jan 2006 16:47:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19480 for ; Fri, 27 Jan 2006 16:45:52 -0500 (EST) Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2bbU-0000Qn-Ad for rpsec@ietf.org; Fri, 27 Jan 2006 16:58:00 -0500 Received: from [82.138.212.228] (host3.host-82-138-212-224.telecomplete.net [82.138.212.228]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id k0RLl3kb015707 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 27 Jan 2006 13:47:05 -0800 In-Reply-To: <03235919BBDE634289BB6A0758A20B36357E37@NT-SJCA-0751.brcm.ad.broadcom.com> References: <03235919BBDE634289BB6A0758A20B36357E37@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Merike Kaeo Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please Date: Fri, 27 Jan 2006 13:48:25 -0800 To: "Bora Akyol" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, David Ward X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org While it is true that pre-shared key roll-over is the same problem as changing the MD-5 keys used in today's non-IPsec authentication implementations, IPsec works a bit differently. The pre-shared key is used to originally authenticate the communicating peers (i.e. the Diffie-Hellman exchange) which then results in a shared secret. This shared secret is then used to derive the actual key used for the MD-5 or SHA-1 authentication used in IPsec. These authentication keys are refreshed based on a defined lifetime, which is the so-called 'automated' key rollover. So, at least you change the keys used to perform the actual authentication........and you also keep your options open for a PKI infrastructure solution which provides 'better' dynamic authentication for the communicating peers (which I still have an optimistic view of happening in my lifetime) - merike On Jan 27, 2006, at 12:39 PM, Bora Akyol wrote: > >> Wrt the operational needs of IPsec and key mgmt ... it >> already is specified and there is wide implementation of sync >> rollover, management, distribution, etc. >> >> 0.02$ >> >> -DWard >> > > Thank you, > > I am more familiar with the IPSEC case then the TCP-MD5 case, > can you please define "wide"? > > For VPN access using one time passwords or certs, yes, there are > many tools. However, for connectivity between two hosts that > are not under the same administrative domain, other than using > certificates issued by a mutually trusted root, what other mechanisms > do > we > have to synhcronize rollover of pre-shared keys and manage this on > a lot of routers? > > If you have any pointers to published work, I would appreciate it. > I am hoping that such work exists after the blind TCP reset issue that > appeared a couple years ago. > > Thanks > > Bora > > > > _______________________________________________ > 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 Fri Jan 27 17:25:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2c2X-0007le-GL; Fri, 27 Jan 2006 17:25:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2c2V-0007lZ-CX for rpsec@megatron.ietf.org; Fri, 27 Jan 2006 17:25:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21809 for ; Fri, 27 Jan 2006 17:24:22 -0500 (EST) Received: from purgatory.unfix.org ([213.136.24.43] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2cCj-0001XP-4A for rpsec@ietf.org; Fri, 27 Jan 2006 17:36:30 -0500 Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 5FF747FC8; Fri, 27 Jan 2006 23:25:31 +0100 (CET) Message-ID: <43DA9DAB.3070001@unfix.org> Date: Fri, 27 Jan 2006 23:24:43 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Bora Akyol Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please References: <03235919BBDE634289BB6A0758A20B36357E34@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <03235919BBDE634289BB6A0758A20B36357E34@NT-SJCA-0751.brcm.ad.broadcom.com> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=333E7C23; url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey 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: , Content-Type: multipart/mixed; boundary="===============0780290887==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0780290887== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6BC100B1C2D2CD87C8694B87" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6BC100B1C2D2CD87C8694B87 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bora Akyol wrote: > The problem is that the other end of the connection is not necessarily > **my router**. > > You have to synchronize your keys etc with a partner outside the > organization. Isn't that like in every situation? When it is your own network it is indeed all in your own hands, but then you also have way more control of the infrastructure itself. > Clearly, this is easier than the general IPSEC key distribution problem= , > but still not easy when done in large scale. Currently, with or with MD5 you will have a few fields (ip address, asn etc) in an email, just add a couple of fields specifying those values. It ain't that tough. > Out of curiousity, how often do you change the TCP-MD5 keys in your > routers? TCP-MD5 has more flaws than uses in our situation. (If one is able to spoof packets on the subnet they can easily send false TCP-MD5 packets and up goes the load on the RE) In our case we give remote peers access to a website (ssl'd ;) where they can login to and change their details without telling us. Thus add/remove peers, change IP's etc. Of course this means that we do have change management and before the change gets committed an engineer will approve the change but it makes a number of things much easier. Indeed we make it the other parties problem to set it up. In case where somebody has a similar system one could take turns to do it. In case you are wondering, yes that management system supports configuring IPSEC, but not all platforms correctly support it unfortunately, next to the overhead being quite great in some situations and quite unnecessary in most others. You could also work with emails or other forms for this of course, making it automated simply makes your life easier and isn't that what we are doing all this work for? :) As an example, public system, for AS8298 (GRH) we have a fully automated system which doesn't even ask engineers to commit, it does it directly; the interface gives a user the right to make/remove/change peers for the ASN and prefixes (based on IRR data) he is trusted for. Thus they stick a new route6 in the RIPE IRR, tries to add peer, management tool checks route6 object if it belongs to one of his authorized ASN's and allows it. Presto, no work for us except for the initial approval ;) PS: Maybe netconf could come into play here to standardize some way of exchanging these informations? > Do you use the same key for all BGP peers to the same peering AS? No, per-peer a different key, otherwise it would be very silly. The management interface enforces this policy. Greets, Jeroen --------------enig6BC100B1C2D2CD87C8694B87 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFD2p2rKaooUjM+fCMRApOVAJwLl9tbhoHph8sG+De6oKYHis+OswCcDXU8 u4hYv6vWOPVb94TYIFEj51E= =raGy -----END PGP SIGNATURE----- --------------enig6BC100B1C2D2CD87C8694B87-- --===============0780290887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0780290887==-- From rpsec-bounces@ietf.org Mon Jan 30 13:38:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3dv7-0001Di-4w; Mon, 30 Jan 2006 13:38:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3dv4-0001DC-58 for rpsec@megatron.ietf.org; Mon, 30 Jan 2006 13:38:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15639 for ; Mon, 30 Jan 2006 13:36:54 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3e5t-0005MS-07 for rpsec@ietf.org; Mon, 30 Jan 2006 13:49:41 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2006 10:38:17 -0800 X-IronPort-AV: i="4.01,235,1136188800"; d="scan'208"; a="252331700:sNHT30909688" Received: from [128.107.163.246] (dhcp-128-107-163-246.cisco.com [128.107.163.246]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0UIcGQJ014971; Mon, 30 Jan 2006 10:38:16 -0800 (PST) Message-ID: <43DE5D48.6010902@cisco.com> Date: Mon, 30 Jan 2006 10:39:04 -0800 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Merike Kaeo Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please References: <03235919BBDE634289BB6A0758A20B36357E37@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Merike Kaeo wrote: > While it is true that pre-shared key roll-over is the same problem as > changing the MD-5 keys used in today's non-IPsec authentication > implementations, IPsec works a bit differently. The pre-shared key is > used to originally authenticate the communicating peers (i.e. the > Diffie-Hellman exchange) which then results in a shared secret. This > shared secret is then used to derive the actual key used for the MD-5 or > SHA-1 authentication used in IPsec. These authentication keys are > refreshed based on a defined lifetime, which is the so-called > 'automated' key rollover. The real roll-over problem is that an IPsec system can have only one valid IPsec pre-shared key for each peer, and if the two peers disagree on the value of the current key at any point in time the connection will fail. What Merike describes above shows that that once authentication completes, there is usually a few hours before it gets used again. Under ordinary circumstances, this gives the operations staffs of the two peers a period of a few hours to synchronize changing the key. But if one peer unexpectedly has a need to re-authenticate when only one side has installed the new key, they won't be able to bring up the BGP session just as in the case when keyed-MD5 authentication keys are different. Whether or not this level of risk is acceptable to operators is unknown to me, but in any case it has to be considered. Brian > So, at least you change the keys used to perform the actual > authentication........and you also keep your options open for a PKI > infrastructure solution which provides 'better' dynamic authentication > for the communicating peers (which I still have an optimistic view of > happening in my lifetime) > > - merike > > > On Jan 27, 2006, at 12:39 PM, Bora Akyol wrote: > >> >>> Wrt the operational needs of IPsec and key mgmt ... it >>> already is specified and there is wide implementation of sync >>> rollover, management, distribution, etc. >>> >>> 0.02$ >>> >>> -DWard >>> >> >> Thank you, >> >> I am more familiar with the IPSEC case then the TCP-MD5 case, >> can you please define "wide"? >> >> For VPN access using one time passwords or certs, yes, there are >> many tools. However, for connectivity between two hosts that >> are not under the same administrative domain, other than using >> certificates issued by a mutually trusted root, what other mechanisms do >> we >> have to synhcronize rollover of pre-shared keys and manage this on >> a lot of routers? >> >> If you have any pointers to published work, I would appreciate it. >> I am hoping that such work exists after the blind TCP reset issue that >> appeared a couple years ago. >> >> Thanks >> >> Bora >> >> >> >> _______________________________________________ >> 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 > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 30 23:37:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3nGW-0001xb-F9; Mon, 30 Jan 2006 23:37:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3nGV-0001wD-M5 for rpsec@megatron.ietf.org; Mon, 30 Jan 2006 23:37:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12097 for ; Mon, 30 Jan 2006 23:35:32 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3nRE-00047M-By for rpsec@ietf.org; Mon, 30 Jan 2006 23:48:23 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id A268764443; Mon, 30 Jan 2006 21:36:36 -0700 (MST) In-Reply-To: <43DE5D48.6010902@cisco.com> References: <03235919BBDE634289BB6A0758A20B36357E37@NT-SJCA-0751.brcm.ad.broadcom.com> <43DE5D48.6010902@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1BC3791E-90B3-49B9-9CD7-4E1108E09F74@castlepoint.net> Content-Transfer-Encoding: 7bit From: Shane Amante Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please Date: Mon, 30 Jan 2006 21:36:41 -0700 To: Brian Weis X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 2.2 (++) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Brian, On Jan 30, 2006, at 11:39 AM, Brian Weis wrote: > Merike Kaeo wrote: >> While it is true that pre-shared key roll-over is the same problem >> as changing the MD-5 keys used in today's non-IPsec authentication >> implementations, IPsec works a bit differently. The pre-shared >> key is used to originally authenticate the communicating peers >> (i.e. the Diffie-Hellman exchange) which then results in a shared >> secret. This shared secret is then used to derive the actual key >> used for the MD-5 or SHA-1 authentication used in IPsec. These >> authentication keys are refreshed based on a defined lifetime, >> which is the so-called 'automated' key rollover. > > The real roll-over problem is that an IPsec system can have only > one valid IPsec pre-shared key for each peer, and if the two peers > disagree on the value of the current key at any point in time the > connection will fail. > > What Merike describes above shows that that once authentication > completes, there is usually a few hours before it gets used again. > Under ordinary circumstances, this gives the operations staffs of > the two peers a period of a few hours to synchronize changing the > key. But if one peer unexpectedly has a need to re-authenticate > when only one side has installed the new key, they won't be able to > bring up the BGP session just as in the case when keyed-MD5 > authentication keys are different. > > Whether or not this level of risk is acceptable to operators is > unknown to me, but in any case it has to be considered. Speaking as an operator, this is an acceptable risk, which (as you already said) I have to deal with anyway today for keyed MD5. Here's some additional points, (probably re-stating some of what's already been said): 1) Re-using a _standard_ authentication protocol, such as IKE+IPsec, is advantageous in that crypto/security experts, plus developers!, have worked on the protocol for quite a while and understand its inherent strengths and weaknesses. Furthermore, IKE+IPsec attracts (and, presumably, will continue to attract) a good deal of peer review in the crypto/security community, which gives me a good deal of confidence that if weaknesses are exposed in IKE+IPsec, it's bound to be noticed and fixed in relatively short order. 2) That said, we need to ensure the proper balance between throwing too much functionality (a.k.a.: knobs) into IKE+IPsec making it difficult, bordering on impossible, to deploy. I'd advocate choosing a very, very small set of pre-defined 'crypto suites' analogous to what the IPsec WG almost adopted during the re-spin of IKEv1 into IKEv2. This ensures you don't have two operators (in two different organizations) arguing whether or not they want 3DES, SHA-1 or AES for IKE Phase 1, PFS on/off, Phase 1 & Phase 2 key lifetimes, etc., etc., etc. Just define 3 crypto-suites (High, Medium, Low?), bake 'em in and then Ops can tell each other: "Just use Crypto Suite 1", throw in a pre-shared (secret) key and they're off. I'm sure there will be much gnashing of teeth on the appropriate list over exactly what options get defined in those suites, but that's a good thing: 1) That means a lot of people have looked at it and came to rough consensus on the "best" (or "least evil", depending on your viewpoint) set of choices for a pre-defined suite; 2) vendors only need to code & test against a narrow set of standard options; 3) it will save Ops tons of time and hair-pulling down the road; and, 4) it will ensure more widespread deployment because "it's super-easy to enable". 3) It's not clear to me why we'd want to include IS-IS as "in scope" for this effort, since: a) it's an IGP; and, b) because it's an IGP, it should only be run across "trusted" links, anyway, otherwise caveat emptor. If people really want to secure it with IPsec, let them go to IS-IS WG, first, and try to rescuitate the IS-IS/IPv4 work ... good luck with that, BTW ;-). (Alternatively, convert your IGP to OSPF, which could use IPsec, or use one of the proprietary, but interoperable, mechanisms already supported by numerous vendors for securing IS-IS domains :-). > Brian > >> So, at least you change the keys used to perform the actual >> authentication........and you also keep your options open for a >> PKI infrastructure solution which provides 'better' dynamic >> authentication for the communicating peers (which I still have an >> optimistic view of happening in my lifetime) Although somewhat contradictory to what I said in #2, but along the lines of what Merike just said, I would favor an approach where we first defined IKE+IPsec using pre-shared (secret) keys and then look at enabling a more dynamic mechanism to exchange keying material along the lines of what is (or could be) done in "Opportunistic Encryption": http://www.ietf.org/rfc/rfc4322.txt ... but modified to be for authentication, not [just] encryption, if I understand it correctly. In this case, DNS+DNSSEC is used to publish, fetch + authenticate public keys to bootstrap IKE endpoints. In this way, Ops can publish DNS RR's for their public keys, which allows an iBGP mesh to change over relatively easily or, alternatively, an external peer (or, perhaps, set of peers) to change over easily w/out coordination as in the case of pre-shared keys. One huge obstacle of this approach would be deployment of DNSSEC (if you wanted to do it right), which may or may not happen within our lifetime, but who said this would be easy? ;-) -shane > > >> - merike >> On Jan 27, 2006, at 12:39 PM, Bora Akyol wrote: >>> >>>> Wrt the operational needs of IPsec and key mgmt ... it >>>> already is specified and there is wide implementation of sync >>>> rollover, management, distribution, etc. >>>> >>>> 0.02$ >>>> >>>> -DWard >>>> >>> >>> Thank you, >>> >>> I am more familiar with the IPSEC case then the TCP-MD5 case, >>> can you please define "wide"? >>> >>> For VPN access using one time passwords or certs, yes, there are >>> many tools. However, for connectivity between two hosts that >>> are not under the same administrative domain, other than using >>> certificates issued by a mutually trusted root, what other >>> mechanisms do >>> we >>> have to synhcronize rollover of pre-shared keys and manage this on >>> a lot of routers? >>> >>> If you have any pointers to published work, I would appreciate it. >>> I am hoping that such work exists after the blind TCP reset issue >>> that >>> appeared a couple years ago. >>> >>> Thanks >>> >>> Bora >>> >>> >>> >>> _______________________________________________ >>> 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 > > > -- > Brian Weis > Advanced Security Development, Security Technology Group, Cisco > Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > _______________________________________________ > 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