From mailman-bounces@ietf.org Mon Nov 1 07:46:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26844 for ; Mon, 1 Nov 2004 07:46:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COboq-0006OR-VA for rpsec-web-archive@ietf.org; Mon, 01 Nov 2004 08:01:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZZQ-0008AE-I3 for rpsec-web-archive@ietf.org; Mon, 01 Nov 2004 05:37:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rpsec-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:15:34 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rpsec-web-archive@ietf.org: List Password // URL ---- -------- rpsec@ietf.org lLFY https://www1.ietf.org/mailman/options/rpsec/rpsec-web-archive%40ietf.org From rpsec-bounces@ietf.org Mon Nov 1 15:42:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28690 for ; Mon, 1 Nov 2004 15:42:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COjFr-0002MK-NO for rpsec-web-archive@ietf.org; Mon, 01 Nov 2004 15:58:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COieo-00033q-FY; Mon, 01 Nov 2004 15:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COiaf-0006e3-0i for rpsec@megatron.ietf.org; Mon, 01 Nov 2004 15:15:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25671 for ; Mon, 1 Nov 2004 15:15:42 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COipc-0001iI-2w for rpsec@ietf.org; Mon, 01 Nov 2004 15:31:13 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id iA1KFCAQ032655 for ; Mon, 1 Nov 2004 12:15:12 -0800 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.12.11/8.12.11/Submit) with ESMTP id iA1KFCCW032652 for ; Mon, 1 Nov 2004 12:15:12 -0800 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Mon, 1 Nov 2004 12:15:12 -0800 (PST) From: Tony Tauber To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [RPSEC] BGP Security Requirements Document 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 If you'll recall, some months ago a Design Team was kicked-off to tackle the problem of documenting BGP security requirements: http://www1.ietf.org/mail-archive/web/rpsec/current/msg00808.html That group has produced a document: http://www1.ietf.org/internet-drafts/draft-christian-bgpsecrec-01.txt which needs to be read and reviewed by the meeting next week (IETF61). Remember, this document is only the output of the Design Team and doesn't represent the last word on this topic nor does it automatically become a Working Group document. Please read and comment to the RPSEC list. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Nov 3 16:12:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19856 for ; Wed, 3 Nov 2004 16:12:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPSft-0007fj-TG for rpsec-web-archive@ietf.org; Wed, 03 Nov 2004 16:28:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPSML-0001s5-BD; Wed, 03 Nov 2004 16:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPSLF-0001DS-SH for rpsec@megatron.ietf.org; Wed, 03 Nov 2004 16:06:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19634 for ; Wed, 3 Nov 2004 16:06:52 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPSab-0007ZT-4G for rpsec@ietf.org; Wed, 03 Nov 2004 16:22:45 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iA3L5xjf015582; Wed, 3 Nov 2004 16:06:00 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 3 Nov 2004 16:05:06 -0500 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements Document Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c375f2012a4f820b0c0fd6fb14a28357 Here are my comments on the document. I stripped out the title, pagination blank lines, headers, footers, and boilerplate to make it easier to read with embedded comments. Steve ------- Abstract The security of BGP is critical to the continued health and well being of internetworking. While securing a link between two BGP peers is a relatively easy technical matter, the manner in which to do so is not standard. Additionally, a secure link does not provide security or authentication of the routes updates themselves. The phrase "security or authentication" makes "security" sound like a service parallel to authentication, e.g., like confidentiality, integrity, etc. Not sure exactly what you meant to convey via this choice of words. In this document, we describe a set of requirements for securing BGP is described, both in the areas of peering relationships and prefix authentication. As above, the wording here is ambiguous, or it suggests a less than comprehensive view of what security for BGP means. 1. Introduction Securing peering relationships and the generation/reception of prefixes is important to ensuring the validity of route updates. Be more precise about what you mean by "securing peering relationships." For example, do you mean that each peer verifies the identity of the other, or the authorization of the peer to represent a specified AS, or both? Call out requirements for packet-level security services too, e.g., connection-oriented integrity. The guarantee of packet delivery is not part of the BGP protocol security model. Just because a packet is addressed to a specific peer does not mean it will be received, even with a "secure" route. These two sentences are very confusing, with the reference to "guarantee of packet delivery" coming out of nowhere. Are you talking about forwarding of subscriber traffic, or BGP traffic? For example: an attacker could have compromised an intermediate router and installed a static route for target address A.B.C.D pointing to an inappropriate direction or an attacker might splice into a circuit between two secure routers and install a device that diverts A.B.C.D traffic without requiring the compromise of control plane devices. This example suggests that the previous mention of a guarantee was a reference to forwarding. So, I suggest you just make a clear statement about the differences between routing and forwarding here, to clarify the scope of this requirement document, rather than relying on an example to convey this notion. 2. Definition of Verifiable For the purposes of this document the word verifiable indicates the ability to determine through algorithmic means whether a unit of information is correct. "A unit of information?" seems rather abstract at this point on the document, and there is no reference to what inputs the algorithm might use to verify correctness, so this is not a great definition. How about addressing what correctness means for BGP as a starting point? That might be a suitable starting point for a document of this sort, if one also decides that correctness and security for BGP are closely related. 3. Incremental Deployments Requirements The following attributes of BGP SHOULD be preserved with a security mechanism in place: o Convergence Speed: BGP's convergence speed, with a security system in operation, SHOULD be equivalent to or faster than BGP running without the security system in operation. This includes the preservation of optimizations currently used to produce acceptable convergence speeds on current hardware, including update packing, peer groups, and others. This is a rather dubious requirement, since we rarely, if ever, add security to ANY base system and make the system FASTER than it was previously! o Current timers, including hold timers, keepalive timers, and the peering process, SHOULD NOT be impacted by the security system. Why is this a requirement? Are these timers variables that cannot be changed. Or do we fear that if they are changed then BGP will blow up? It's not enough to state requirements in a document like this; one needs to motivate them. o BGP SHOULD support both secured and unsecured routes with the security system in place. You have not defined what a secure route is, so this is a hard sentence to interpret. o The security system MUST support a range of possible outputs for local determination of the trust level for a specific route. Any given route should be trustable to a locally configured degree, based on the completeness of security information for the update and other factors. Experience in the security area shows that people are very, very bad at managing notions of trust. In the PKI arena, for example, anything other than very simple models of "trust" are subject to frequent mismanagement, and resulting vulnerabilities. So, why do you feel this is an essential feature for BGP security? Don't we have lots of experience that suggests that the current operational model which exhibits just this sort of property, creates significant vulnerabilities? o The security system SHOULD allow the operator to determine whether the speed of convergence is more important than security operations, or security operations are more important than the speed of convergence. This facilitates the incremental deployment of security on systems not designed to support increased processing requirements imposed by the security system. Is speed of convergence a purely local matter? If not, then making this a local parameter seems a bit odd, as described here. Network recovery times for secured routing as well as unsecured routing SHOULD work with similar speed and SHOULD perform with equivalent, or greater, rapidity than legacy routing methods. Unsecured routing of secured prefixes MUST be supported so that a mix of secured and unsecured routing paths will provide security for the prefixes that have security features applied, but will not penalize or preempt "normal" prefixes. As above, the leck of definition of secured vs. unsecured routes makes this hard to interpret. Also, the suggestion that use of security will SPEED UP the basic routing function is almost absurd. 4. Trust Models this section is off to a bad start, since it does not describe the relevance of trust models to the problem, instead it dives into examples. Also, at this stage we have NO definition of what security is for BGP, yet we seem to be starting to discuss properties of solutions. 4.1 Trust Model Examples One example of a trust model is a distributed trust system. Inter-domain routing as implemented today is based on the concept of distributed trust. There is no central authority; each AS is free to choose whom to trust and whom to avoid placing trust in. This model is expressed through the filtering of routing information received from BGP peers. Financial contracts and business arrangements play a large role in how an AS chooses to filter their peers. BGP embodies a distributed decision making model for routing, but that is NOT a distributed trust model. The filtering described here represents a locally managed mechanism for enforcing business arrangements. But what really happens in the system today, from a trust management perspective, is transitive trust. The transitivity arise because updates nominally represent data that has been passed from one AS to another (modulo aggregation). So, it is not clear that BGP is appropriately described as being based on a distributed trust model, it least not from the BGP RFC. This discussion seems to confuse enforcement mechanisms and trust models. A second trust model is a hierarchical system much like how root certificates for SSL/TLS are distributed today. In this model, a central authority controls all information. For example, all address allocations are authenticated and signed by ICANN, then by a regional registry, then a large ISP, a small ISP, etc. ICANN serves as the root of the address allocation system. This type of trust is usually referred to as a strict hierarchical trust model or a chain of trust. The discussion here is inaccurate in several respects. The SSL/TLS has no intrinsic trust model. Browsers making use of these protocols embody a model of the sort described immediately above, but this sort of model is not defined anywhere in SSL/TLS. Also, this text here suggests that there are only two types of trust models, but from a PKI perspective, this is not true. Finally, it is important to distinguish between a PKI used to convey authentication data, vs. one used to convey authorization data. The browser PKI model addresses the former (and not very well, in many respects), not the latter. The later seems more relevant for BGP. 4.2 Trust Model Recommendation While there are a number of trust models available, a distributed trust mechanism lends itself well to the current model used throughout the various networks and internetworks making up the public Internet and other large scale internetworks. Since the definition of distributed trust above is not quite accurate, I question this assertion. Nonetheless, this paragraph seems to say that since the current, insecure system is based on transitive trust and distributed enforcement, that one should adopt that model as the basis for what we hope will be a more secure system. Certainly this is not a good argument to make. In the public Internet today, larger service providers trust each other to appropriately deploy edge based filtering mechanisms to protect the Internet as a whole and to protect sensitive inter- provider peering sessions. These peering relationships, with their interprovider legal contracts and partnerships, are comparable to the relationships established within the PGP web of trust. This paragraph seems to assert that the current system works well re transitive trust, but this is simply not true, i.e., the transitive trust aspect of the current model is what allows errors by one ISP, or a successful attack against one ISP, to adversely affect others ISPs that "trusted" it. Also, the allusion to contracts seems out of place in a technical requirements document. It's a bit like saying that we have laws that criminalize bank robbery, so we don't need good vaults. The analogy here to PGP is an obvious one, but not necessarily a good one. PGP was developed to authenticate e-mail senders and recipients. In that context there was an assumption of human value judgment in evaluation of certificate paths. Also, there was no suitable, authoritative basis for identifying e-mail users. In the BGP context, the relevant information is not who is whom, but rather whether a router is authorized to represent and AS, whether an AS is authorized to advertise a prefix, etc. Authorization is NOT the same as authentication and so the PKI analogy to PGP is generally inappropriate. The establishment of a distributed trust mechanism allows operators to make their own decisions about the level with which they trust their peers and their customers. Operators may choose to honor, or create, a strict hierarchy of trust up to the level of numbering authority within the distributed model if so desired. I'm not sure what this last sentence means. I'm guessing it's an attempt to express the notion that ISPs should be able to select trust anchors at various points in a PKI, which might be a hierarchic PKI. If so, then this needs a lot of work to express that notion clearly. A distributed trust model that allows for varying levels of trust based on operator input and a trust hierarchy MUST be supported. The distributed trust model SHOULD allow for a strict hierarchy to root authorities if desired. The discussion above does NOT substantiate this conclusion. 5. Path Attributes and NLRI Authentication BGP distributes routing information across the Internet (between BGP speakers) using the BGP UPDATE messages. The UPDATE message contains withdrawn routes, path attributes and one or more NLRIs. For the remainder of this section, we will focus on Path Attributes and the NLRI. The AS_PATH for specific prefixes must be protected in any proposed security system in three ways: o Authorization of Originating AS: For all prefixes announced in BGP, the originating AS MUST be verifiable through the trust model as the authorized announcer of the prefix. The verification mechanism must account for existing BGP mechanisms such as summarization. What I think you want to say here is that it must be possible to verify that the originating AS is authorized to advertise the prefix, either because the prefix was allocated to that AS or because the "owner" of the prefix authorized the AS to originate the prefix. The definition of "verifiable" presented in section 2 does not align well with its use here, i.e., try substituting the definition for the word "verifiable" and see what happens. o The AS_PATH list MUST correspond to a verifiable list of autonomous systems based on the peering topology of the network. This is a subset of what the semantics of BGP imply. To make this a requirement, instead of the more stringent requirement that each AS along the path advertised a prefix to the next hop, is to abandon a security capability rather early in the process! This looks like blatant gerrymandering of a requirements document to accommodate a solution, i.e., soBGP. o Announcing AS Check: For all BGP peers, a BGP Implementation MUST ensure that the first element of the AS_PATH list corresponds to the locally configured AS of that peer. This seems to suggest that it is enough to verify that the UPDATE arrived via an interface consistent with the asserted AS number of the last hop. That sort of check does not ensure that the UPDATE was directed to the recipient, i.e., it admits mis-delivery of UPDATEs. Since BGP is a stateful routing protocol, the timeliness and freshness of reachability updates are critical for consistent routing state within the BGP routing system. To this end, there MUST be a mechanism to ensure that changes to reachability that result in an explicit or implicit withdrawal of reachability (RFC1771) are propagated within the secured BGP routing system in a timely manner. Two types of verification MAY be offered for the NLRI and the AS_PATH: o Contents of the UPDATE message SHOULD be authenticated in real-time as the UPDATE message is processed. What does authentication mean here? Is that the message arrived from a specific router that is configured as a peer, and has not been tampered with, or is there more that is required? o The route information base MAY be authenticated periodically or in an event driven manner by scanning the data and verifying the originating AS and the verifiability of the AS-PATH list. This remedial approach may be OK, but there is no rationale provided to justify it. For example, how much damage can result from "periodic" scanning as opposed to realtime scanning? 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. Again, no analysis is presented to justify why the periodic or event driven approach is "good enough." The originating AS of a prefix may occasionally need to be changed either due to a re-assignment or a network transition. Any BGP security mechanism MUST support the change of an originating AS for a prefix within normal convergence times of the internetwork. What is a "network transition?" Also, the document needs to justify the time interval mandated for responding to the change of AS advertising a prefix. Such changes are not instantaneous, in that they require the sort of contractual arrangements the document discussed earlier, or allocation of new prefixes via an RIR or through an ISP, processes that require manual intervention that is certainly longer than convergence time. 5.1 Address Allocation As part of the regular operation of the Internet, addresses that are allocated to an organization may be advertised by a different organization. Common reasons for this practice include multi-homing and route reduction for the purposes of resource conservation. There are two modes of delegation: o Mode 1 Delegation: In this mode, a BGP speaker and listener have chosen to restrict the amount of received prefixes for the listener. The listener has chosen to honor route announcements sent in a summary fashion by the speaker. The Mode 1 text above does not discuss how the addresses were ALLOCATED, but rather describes a mechanism that an ISP may use to help protect itself against bad advertisements. o Mode 2 Delegation: In this mode, the address space that is being delegated is part of a larger allocation that is owned by an autonomous system. The owner then delegates the smaller block to another AS for purposes of advertisement. This mode is commonly observed in multi-homing. These two modes lead to a single common requirement: Any BGP Security solution MUST support delegation of an address block of any size regardless of its relationship to other address blocks to another entity via verifiable means. This is a very odd, piecemeal characterization of a requirement re support for address allocation. It needs to be better expressed. 6. NLRI and Path Attribute Tracking Non-repudiation of a routing update, the ability for a receiver to know exactly who originated and forwarded a routing update, is a desirable trait. This document doesn't make any claims about the technical ability to actually deploy non-reputable security in various networks, including the public Internet, but we do believe non-repudiation to be an important goal. The term non-repudiation is mis-used above. What I think you are trying to say is that it would be desirable for an AS to be able to verify that a received UPDATE accurately represents the propagation of advertisements for the NLRI in question, along the path asserted by the UPDATE (modulo aggregation). I would argue that this is exactly what BGP assumes when its operates on an UPDATE, and so would argue that this represents a basic security requirement, one that can be traced to the underlying protocol. Instead, the text here denigrates it, suggesting that is would be nice but that it does not seem feasible to deploy. This is a value judgment with no substantiation. Any security system SHOULD provide some method to allow the receiver of an UPDATE to verify that the originator actually originated the UPDATE, and the AS's listed in the AS_PATH actually forwarded it. This seems to be a more precise statement of what the previous paragraph described, so it seems to be in conflict with that paragraph, since here this is a SHOULD, and above it's characterized as a "goal." The data generated by logging may be very large depending on the number of peers, the number of prefixes received, the authentication model used and routing policies. Logging what? There has been no mention of logging anything, so this statement has no context! Path and NLRI attributes MUST be logged using a standard format. The format must be scalable with the amount of data logged and the frequency of log generation. The frequency of log generation should be controllable by the operator. The logging mechanisms for the tracked information MUST be standardized across all platforms. Logging ability both on and off line is considered highly desirable. It looks like some chunk of text is missing, as there was no mention of logging previously, no indication of where any action would be logged, and no discussion of what logging would accomplish re security. Again, no rationale is provided for this. 7. Transport Protection Transport protection is an aspect of BGP routing protocol security and provides the potential for a linked transport/prefix authentication mechanism. This section discusses transport security requirements for BGP and covers peering and authentication of peering. Need to explain what "linked transport/prefix authentication mechanism is. Any proposed security mechanism MUST include provisions for authenticating both iBGP and eBGP peering sessions. Examples of session security mechanisms include TCP-MD5 and IPSec, though possible security alternatives are not limited to those two. IPsec is misspelled above. No justification for why iBGP requires this security feature, especially since the rest of this text never even mentions iBGP vs. eBGP. Again, missing rationale for this requirement. Transport protection systems SHOULD function as a component of the BGP routing protocol security mechanism. This includes the use of the same key generation/management systems as the rest of the security system. Since there has been little of no discussion of any key generation/management above, this seems out of place. Also, it seems likely to conflict with the mention of use of the TCP/MD-5 mechanism, since that facility, as currently implemented, makes use of manual key management. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Nov 5 04:37:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20444 for ; Fri, 5 Nov 2004 04:37:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0mc-000616-Gv for rpsec-web-archive@ietf.org; Fri, 05 Nov 2004 04:53:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0Rz-0005qE-Gu; Fri, 05 Nov 2004 04:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0M2-0004oI-Ul for rpsec@megatron.ietf.org; Fri, 05 Nov 2004 04:25:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19576 for ; Fri, 5 Nov 2004 04:25:56 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0bk-0005nY-Ki for rpsec@ietf.org; Fri, 05 Nov 2004 04:42:13 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp8.clb.oleane.net with ESMTP id iA59PQBY006931 for ; Fri, 5 Nov 2004 10:25:26 +0100 Message-Id: <200411050925.iA59PQBY006931@smtp8.clb.oleane.net> From: "Gunther Palmer" To: Date: Fri, 5 Nov 2004 10:25:22 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTDGV/jyNDuIxx9Tuac/IrRFqOURA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Subject: [RPSEC] SSL VPN Conference: Call for proposals 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="===============0919987998==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb This is a multi-part message in MIME format. --===============0919987998== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AA_01C4C321.C2CFEC80" This is a multi-part message in MIME format. ------=_NextPart_000_00AA_01C4C321.C2CFEC80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . How to provide SSL-based remote access to a broad range of Web and legacy applications? . What about application performance and requirements? . Are encrypted application tunnelling issues solved? . What differences with IPsec VPNs? These questions, among others, will be tackled by the most recognised experts in this field during the SSL VPN Conference to be held in Paris from April 5 to 8, 2005 The call for proposal dead line has been extended to November 30. Details at: http://www.upperside.fr/sslvpn05/sslvpn05intro.htm ------=_NextPart_000_00AA_01C4C321.C2CFEC80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

• = How to provide SSL-based remote access to a broad range of Web and legacy applications?
• = What about application performance and requirements?
• = Are encrypted application tunnelling issues solved?
• = What differences with IPsec VPNs?

These questions, among others, will be tackled by the most recognised = experts in this field during the SSL VPN = Conference to be held in Paris from April 5 to 8, 2005

 

The call for proposal dead line has been = extended to November 30.

 

Details = at:

 

http://www.upperside.fr/sslvpn05/sslvpn05intro.htm

 

------=_NextPart_000_00AA_01C4C321.C2CFEC80-- --===============0919987998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0919987998==-- From rpsec-bounces@ietf.org Mon Nov 8 20:06:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26379 for ; Mon, 8 Nov 2004 20:06:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRKT8-0003mi-7s for rpsec-web-archive@ietf.org; Mon, 08 Nov 2004 20:06:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRKL6-00037k-1H; Mon, 08 Nov 2004 19:58:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRK8v-0000Cd-Ar for rpsec@megatron.ietf.org; Mon, 08 Nov 2004 19:45:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24629 for ; Mon, 8 Nov 2004 19:45:50 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRK9Z-0003BQ-Gu for rpsec@ietf.org; Mon, 08 Nov 2004 19:46:33 -0500 Received: from [208.231.75.212] ([208.231.75.212]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id iA90jHLY019034 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 8 Nov 2004 19:45:21 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 08 Nov 2004 19:45:11 -0500 From: Blaine Christian To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [RPSEC] BGP security requirements draft 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Folks, Please make sure to read Steve's comments to the thread! I am trying to put summaries of his comments into the presentation but you would be aided by reading the full text of his commentary. Also, please make sure you read the 01 version of the draft. It is different in a few spots. Regards, Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Nov 8 20:31:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28539 for ; Mon, 8 Nov 2004 20:31:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRKrH-0004Ko-A0 for rpsec-web-archive@ietf.org; Mon, 08 Nov 2004 20:31:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRKoc-0004R4-QP; Mon, 08 Nov 2004 20:28:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRKiW-0003Hm-0O for rpsec@megatron.ietf.org; Mon, 08 Nov 2004 20:22:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27751 for ; Mon, 8 Nov 2004 20:22:38 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRKj9-0004AO-Vb for rpsec@ietf.org; Mon, 08 Nov 2004 20:23:20 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id iA91M7gd011851 for ; Mon, 8 Nov 2004 17:22:07 -0800 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.12.11/8.12.11/Submit) with ESMTP id iA91M7TO011848 for ; Mon, 8 Nov 2004 17:22:07 -0800 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Mon, 8 Nov 2004 17:22:07 -0800 (PST) From: Tony Tauber To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [RPSEC] Agenda for IETF61 (WashDC) 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi folks, Sorry for being so remiss in sending this out. Thanks, Tony and Russ ---- Routing Protocol Security Requirements WG (rpsec) Tuesday, November 9 at 1300-1400 =================================== CHAIRS: Russ White Tony Tauber AGENDA: Agenda Bashing Threats document status Sandy Murphy draft-ietf-rpsec-routing-threats-07.txt Requirements document status draft-ietf-rpsec-generic-requirements-00.txt OSPF Vulnerability Analysis status draft-ietf-rpsec-OSPF-vuln-00.txt BGP Attack Tree status draft-convery-bgpattack-02.txt BGP Security Requirements Blaine Christian draft-christian-bgpsecreq-01.txt _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Nov 10 16:34:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07145 for ; Wed, 10 Nov 2004 16:34:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS07P-00086X-C2 for rpsec-web-archive@ietf.org; Wed, 10 Nov 2004 16:35:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzvH-0005xT-Bo; Wed, 10 Nov 2004 16:22:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRzn6-0001iC-GW for rpsec@megatron.ietf.org; Wed, 10 Nov 2004 16:14:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04003 for ; Wed, 10 Nov 2004 16:14:06 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRzo7-0007Sd-Dc for rpsec@ietf.org; Wed, 10 Nov 2004 16:15:12 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.11/8.12.11) with ESMTP id iAALDaHF007766 for ; Wed, 10 Nov 2004 13:13:36 -0800 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.12.11/8.12.11/Submit) with ESMTP id iAALDa6q007763 for ; Wed, 10 Nov 2004 13:13:36 -0800 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Wed, 10 Nov 2004 13:13:36 -0800 (PST) From: Tony Tauber To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [RPSEC] Input for meeting minutes 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Please send any notes you have to me for inclusion in the meeting minutes I'm working on. Even if they're rough, partial, and/or paraphrased, they can help. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Nov 12 10:15:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11117 for ; Fri, 12 Nov 2004 10:15:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSdAk-0002N5-8y for rpsec-web-archive@ietf.org; Fri, 12 Nov 2004 10:17:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSd4j-0003gl-04; Fri, 12 Nov 2004 10:10:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSczg-0001Gb-Gb for rpsec@megatron.ietf.org; Fri, 12 Nov 2004 10:05:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09411 for ; Fri, 12 Nov 2004 10:05:42 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSd12-00025V-B2 for rpsec@ietf.org; Fri, 12 Nov 2004 10:07:11 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 12 Nov 2004 07:05:33 -0800 X-BrightmailFiltered: true Received: from russpc.Whitehouse.intra (rtp-vpn1-404.cisco.com [10.82.225.148]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iACF4x9B020570; Fri, 12 Nov 2004 07:05:01 -0800 (PST) Date: Fri, 12 Nov 2004 10:04:23 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements Document In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee > The guarantee of packet delivery is not part of the BGP protocol > security model. Just because a packet is addressed to a specific > peer does not mean it will be received, even with a "secure" route. > These two sentences are very confusing, with the reference to "guarantee > of packet delivery" coming out of nowhere. Are you talking about > forwarding of subscriber traffic, or BGP traffic? I think I would reword this to: The ability to gaurantee data (rather than control) traffic is passed through a specific path is not is outside the scope of this document. > How about addressing what correctness means for BGP as a starting point? > That might be a suitable starting point for a document of this sort, if > one also decides that correctness and security for BGP are closely > related. The problem is larger than what is a "correct unit of data" within the BGP protocol. The BGP protocol acts as part of a larger routing system, and our focus should really be on securing routing as a system, rather than on securing some set of specific "semantics of BGP," which will vary depending on what your view of BGP is, and how you see the routing system as a whole. > This is a rather dubious requirement, since we rarely, if ever, add > security to ANY base system and make the system FASTER than it was > previously! If you think of security as primarily cryptography, this is true. However, there are other elements of a security system which might, actually, speed up the operation of a system, overall. The goal being expressed here is that designers of any such security system should focus on the overall speed of the system, and work towards solutions that, at least, don't impair the operation of the system as a whole, rather than simply assuming we can slow the system down as much as we like, so long as we "secure" it, by tacking cryptographic processes and signatures into the "right places." > o The security system MUST support a range of possible outputs for > local determination of the trust level for a specific route. Any > given route should be trustable to a locally configured degree, > based on the completeness of security information for the update > and other factors. > Experience in the security area shows that people are very, very bad at > managing notions of trust. In the PKI arena, for example, anything other > than very simple models of "trust" are subject to frequent mismanagement, > and resulting vulnerabilities. So, why do you feel this is an essential > feature for BGP security? Don't we have lots of experience that suggests > that the current operational model which exhibits just this sort of > property, creates significant vulnerabilities? In other words, because the system is insecure today, based on the individual choices of operators, we really need something that overrides the individual choices of operators, to enforce security whether or not they like it. I don't tend to agree with this assessment. The origin of this requirement comes from the unwillingness of the community, at large, to have a security system forced on them that disallows their individual policy choices, and leaves them no room for operational or business differentiation. > o The security system SHOULD allow the operator to determine whether > the speed of convergence is more important than security > operations, or security operations are more important than the > speed of convergence. This facilitates the incremental deployment > of security on systems not designed to support increased > processing requirements imposed by the security system. > Is speed of convergence a purely local matter? If not, then making this a > local parameter seems a bit odd, as described here. You've fallen into the convergence trap! =:-O The problem with the word "convergence" is it can mean many things to many people.... It can mean when a single process on a single device learns all the information it needs to build the tables required for forwarding information to directly connected peers. It might mean the time at which a single device has actually built all the tables required for forwarding traffic to directly connected peers. It might mean the time at a specific set of devices have all the information needed to build the tables to forward packets, or perhaps when all those same devices have actually built their forwarding tables. And on it goes.... :-) In the previous instances of "convergence," I think Blaine is trying to get at the time required for the internetwork, as a whole, to converge. Here, he has shifted gears, and is discussing the time it takes for a specific device, locally, to build the tables required to forward traffic. There should be something noting this shift, I think, in the doc. > 4. Trust Models > this section is off to a bad start, since it does not describe the > relevance of trust models to the problem, instead it dives into examples. > Also, at this stage we have NO definition of what security is for BGP, > yet we seem to be starting to discuss properties of solutions. I agree there should be some justification for adding trust models into the document, and how they relate to the problem. I also agree that the requirements in this area need some support. I also agree with the trust model discussion being a part of the document. > BGP embodies a distributed decision making model for routing, but that is > NOT a distributed trust model. The filtering described here represents a > locally managed mechanism for enforcing business arrangements. But what > really happens in the system today, from a trust management perspective, > is transitive trust. The transitivity arise because updates nominally > represent data that has been passed from one AS to another (modulo > aggregation). So, it is not clear that BGP is appropriately described as > being based on a distributed trust model, it least not from the BGP RFC. > This discussion seems to confuse enforcement mechanisms and trust models. I actually disagree with the characterization that transient trust characterizes the interdomain routing system today. You could claim that simply because an update passes from one AS to another, the "trust" also passes from one AS to another. In reality, there is a component of assuming what your peer sends you is valid (what you would term transitive trust), but there are also components of distributed trust in play, as well. They are part of the routing system, however, and not necessarily specifically outlined in the routing protocol specification--which is why it's so important not to try to secure BGP as a bag of bits, but rather to try and secure the system as a whole. It's like trying to secure the door perfectly, while ignoring those old rusty locks on the windows, or the huge gaping whole in the wall just next to the door. > The latter seems more relevant for BGP. I assume you mean here that a strict heirarchical trust model seems more relevant for BGP. I would agree only if you consider BGP a bag of bits to be secured, and don't worry about the system at large, how the systems using BGP actually operate today, and what acceptable modes of operation are for those systems. > 4.2 Trust Model Recommendation > Since the definition of distributed trust above is not quite accurate, I > question this assertion. Nonetheless, this paragraph seems to say that > since the current, insecure system is based on transitive trust and > distributed enforcement, that one should adopt that model as the basis > for what we hope will be a more secure system. Certainly this is not a > good argument to make. You've answered the question without stating what the question is. Is the question how to force current providers to secure interdomain routing, or is the question how do we provide tools for the current providers to secure interdomain routing? Your assumption is that the current system of trust doesn't work because the actors in the system can't be trusted (as you've outlined in this response, and several other times). My assumption is there is no point in trying to force the community to accept something they aren't going to accept anyway. It's better to give the community tools that can be incrementally deployed, and won't damage their current business models, and then attempt to motivate them to use those tools (not that they aren't motivated already, actually, based on my discussions with various providers). Since this is a requirements document, it seems to me to be a legitimate place to address specifically this question. The sense of the design team has been, thus far, that we should require a set of usable tools, rather than defining what "perfect security" would look like, based on a specific view of the way the world really should work. > o The AS_PATH list MUST correspond to a verifiable list of > autonomous systems based on the peering topology of the network. > This is a subset of what the semantics of BGP imply. To make this a > requirement, instead of the more stringent requirement that each AS along > the path advertised a prefix to the next hop, is to abandon a security > capability rather early in the process! This looks like blatant > gerrymandering of a requirements document to accommodate a solution, > i.e., soBGP. Steve, you are off in rant land here, and you know it. You are trying to overload the AS Path in BGP, pushing in information that simply wasn't ever designed to be there, and isn't there today, in any known operational BGP system. As for shaping the requirements to favor an existing solution, you're flat wrong. The requirements doc currently states the maximum you can actually prove, definitively, within a routing system. Since you can't prove "transitive authorization" within a routing system, the requirements document doesn't ask any given security system to prove it. It's unprovable, and unprovable things can't be requirements. > o Announcing AS Check: For all BGP peers, a BGP Implementation MUST > ensure that the first element of the AS_PATH list corresponds to > the locally configured AS of that peer. > This seems to suggest that it is enough to verify that the UPDATE arrived > via an interface consistent with the asserted AS number of the last hop. > That sort of check does not ensure that the UPDATE was directed to the > recipient, i.e., it admits mis-delivery of UPDATEs. This is what we, in Cisco land, call "enforce first as." I always fall back to this terminology, because I don't know of any accepted "three word term" that's currently used to describe what this paragraph is stating. Without this check, no amount of signatures, graphs, encryption, or anything else will secure BGP in any meaningful way. As for accepting mis-delivery of updates, well, this addresses one part of the problem. As for the second part of your statement: Would you say it's more important to secure the information in the routing database, or more important to secure how it got there? Can you secure how something gets into a database, and still wind up with invalid data? The update process is how information gets into the database. While you focus on the process whereby information makes it into the database, I think the design team has, rightly, focused on the actual validation of information in the database. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Nov 15 19:00:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28051 for ; Mon, 15 Nov 2004 19:00:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTqnn-0006AG-4M for rpsec-web-archive@ietf.org; Mon, 15 Nov 2004 19:02:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTqjz-0005BJ-PI; Mon, 15 Nov 2004 18:58:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTqho-0004lr-BM for rpsec@megatron.ietf.org; Mon, 15 Nov 2004 18:56:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27720 for ; Mon, 15 Nov 2004 18:56:17 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTqjq-00063G-Tb for rpsec@ietf.org; Mon, 15 Nov 2004 18:58:30 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAFNtRjf021192; Mon, 15 Nov 2004 18:55:28 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 15 Nov 2004 18:54:32 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements Document X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.1 (/) X-Scan-Signature: 3adba28c47054ea827843deea22a7215 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="===============0318427851==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: dce614827510b4050294eeec86a3642d --===============0318427851== Content-Type: multipart/alternative; boundary="============_-1111559621==_ma============" --============_-1111559621==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Russ, >>How about addressing what correctness means for BGP as a starting >>point? That might be a suitable starting point for a document of >>this sort, if one also decides that correctness and security for >>BGP are closely related. > >The problem is larger than what is a "correct unit of data" within >the BGP protocol. The BGP protocol acts as part of a larger routing >system, and our focus should really be on securing routing as a >system, rather than on securing some set of specific "semantics of >BGP," which will vary depending on what your view of BGP is, and how >you see the routing system as a whole. I agree that one needs to keep in mind the system context in which a protocol operates in order to develop appropriate security requirement and mechanisms. But, as a rule, the IETF develops standards for protocols, not for systems, although there are exceptions to this general rule. The charter for RPSEC discusses both routing systems and routing protocols, but in terms of this document, the relevant charter item seems to be: - Document security analysis and requirements for specific routing protocols (e.g., OSPF, BGP) I believe the stated goal for this document is developing security requirements for BGP, the protocol, not for inter-domain routing as a system. One could discuss implementation vulnerability issues in BGP, best practices for ISP management of routers, etc. in a system context. But that does not appear to be within the scope for this document. >>This is a rather dubious requirement, since we rarely, if ever, add >>security to ANY base system and make the system FASTER than it was >>previously! > >If you think of security as primarily cryptography, this is true. >However, there are other elements of a security system which might, >actually, speed up the operation of a system, overall. The goal >being expressed here is that designers of any such security system >should focus on the overall speed of the system, and work towards >solutions that, at least, don't impair the operation of the system >as a whole, rather than simply assuming we can slow the system down >as much as we like, so long as we "secure" it, by tacking >cryptographic processes and signatures into the "right places." While cryptography is a good example of a security technology that tends to make a system slower, rather than faster, it is not the only example. In general improving the security of a protocol (or an application, ...) involves performing additional checks on inputs and on the results of processing. Such checks take more time, and thus do not make the protocol faster. One might argue that, in the case of attack, suitable security measures may help avoid computations that are easily detected as bogus, and thus the time spent on the security checks will be less than the time spent acting on bogus inputs. But, the text talked in more general terms, and in the more general context it is unlikely that added security measures will reduce or maintain the performance of the protocol, all else being equal. >> o The security system MUST support a range of possible outputs for >> local determination of the trust level for a specific route. Any >> given route should be trustable to a locally configured degree, >> based on the completeness of security information for the update >> and other factors. > >>Experience in the security area shows that people are very, very >>bad at managing notions of trust. In the PKI arena, for example, >>anything other than very simple models of "trust" are subject to >>frequent mismanagement, and resulting vulnerabilities. So, why do >>you feel this is an essential feature for BGP security? Don't we >>have lots of experience that suggests that the current operational >>model which exhibits just this sort of property, creates >>significant vulnerabilities? > >In other words, because the system is insecure today, based on the >individual choices of operators, we really need something that >overrides the individual choices of operators, to enforce security >whether or not they like it. I don't tend to agree with this >assessment. The origin of this requirement comes from the >unwillingness of the community, at large, to have a security system >forced on them that disallows their individual policy choices, and >leaves them no room for operational or business differentiation. You have grossly mischaracterized my comments above, and then used that to justify your conclusion. I made two observations: - First, non-trivial, "trust based" PKIs have generally proven to be too hard for people to manage, especially as the size of the grows. This is an objectively true statement, based on a fair amount of experience with PKIs. - Second, a number of errors appear in routes advertised by ISPs and these errors are propagated. It is very hard for operators to get everything "right" and keep it right on a continuing basis. Transitive trust models allow for propagation of errors, and thus are intrinsically vulnerable. We both agree that individual operators should be free to operate autonomously; after all, we call these ASes for a reason. I have never suggested that local policies are anything other than locally managed. But, that does not mean that we ought not make available data from authoritative sources, e.g., for address and AS number assignment, to enable operators (who choose to make use of such data) to avoid being victimized by the error of other operators, as happens today. Availability of such data in no way impinges on the ability of an operator to control the local routing policies that he manages today. It merely enables an operator to determine whether other operators are representing path attributes in a fashion that is independently verifiable. A serious vulnerability of today's system is the lack of securely available, authoritative data that operators can use to evaluate UPDATEs. Does your last comment suggest that emitting bogus routes is a good means of business differentiation for an ISP :-) >> o The security system SHOULD allow the operator to determine whether >> the speed of convergence is more important than security >> operations, or security operations are more important than the >> speed of convergence. This facilitates the incremental deployment >> of security on systems not designed to support increased >> processing requirements imposed by the security system. > >>Is speed of convergence a purely local matter? If not, then making >>this a local parameter seems a bit odd, as described here. > >You've fallen into the convergence trap! =:-O > >The problem with the word "convergence" is it can mean many things >to many people.... It can mean when a single process on a single >device learns all the information it needs to build the tables >required for forwarding information to directly connected peers. It >might mean the time at which a single device has actually built all >the tables required for forwarding traffic to directly connected >peers. It might mean the time at a specific set of devices have all >the information needed to build the tables to forward packets, or >perhaps when all those same devices have actually built their >forwarding tables. And on it goes.... :-) > >In the previous instances of "convergence," I think Blaine is trying >to get at the time required for the internetwork, as a whole, to >converge. Here, he has shifted gears, and is discussing the time it >takes for a specific device, locally, to build the tables required >to forward traffic. There should be something noting this shift, I >think, in the doc. yes, one can look at convergence times in local or global contexts, and the text here is either ambiguous or inconsistent with the previous uses of the term in the document. so, the document needs to be fixed to avoid this apparent contradiction. >>BGP embodies a distributed decision making model for routing, but >>that is NOT a distributed trust model. The filtering described here >>represents a locally managed mechanism for enforcing business >>arrangements. But what really happens in the system today, from a >>trust management perspective, is transitive trust. The transitivity >>arise because updates nominally represent data that has been passed >>from one AS to another (modulo aggregation). So, it is not clear >>that BGP is appropriately described as being based on a distributed >>trust model, it least not from the BGP RFC. This discussion seems >>to confuse enforcement mechanisms and trust models. > >I actually disagree with the characterization that transient trust >characterizes the interdomain routing system today. You could claim >that simply because an update passes from one AS to another, the >"trust" also passes from one AS to another. In reality, there is a >component of assuming what your peer sends you is valid (what you >would term transitive trust), but there are also components of >distributed trust in play, as well. They are part of the routing >system, however, and not necessarily specifically outlined in the >routing protocol specification--which is why it's so important not >to try to secure BGP as a bag of bits, but rather to try and secure >the system as a whole. We seem to agree that when on AS accepts an UPDATE from another AS and assumes that the route represented in the UPDATE is valid, that constitutes an example of transitive trust. Yes, it is possible for external, extra-protocol measures to be used to help reject bogus routes. But, if these system (vs. protocol) measures are based on what you call distributed trust, and if that distributed trust is vulnerable to the sorts of operator errors we see today, then the resulting system is intrinsically vulnerable, which is what we have today. Presumably, we are working on requirements that will improve BGP security, from both a protocol and system perspective. >It's like trying to secure the door perfectly, while ignoring those >old rusty locks on the windows, or the huge gaping whole in the wall >just next to the door. I think we agree that one needs to adopt a balanced approach to security, an approach that takes into account the implications of a "weakest link." But, we also have to be careful to not propose solutions that are intrinsically limited in the security they can achieve based on their reliance on any given facet of the solution. Foe example, we understand that if one insists on using passwords for user authentication the result will be a system with limited security, no matter how well we manage the passwords. If, on the other hand, we adopt a crypto-based approach to user authentication, we can improve the elements of the system to be more secure, even as the threat changes. Use of crypto does not ensure that user authentication will be more secure, but it allows that to be true. >>The latter seems more relevant for BGP. > >I assume you mean here that a strict heirarchical trust model seems >more relevant for BGP. I would agree only if you consider BGP a bag >of bits to be secured, and don't worry about the system at large, >how the systems using BGP actually operate today, and what >acceptable modes of operation are for those systems. BGP is a protocol. As such it embodies syntax (your allusion to a "bag of bits") and a state machine. The semantics of BGP arise form analysis of the state machine, in the system context of inter-domain routing. I get the feeling that when you allude to "system" you mean a much broader set of things, some of which may be more like the procedures that one might document in a BCP, but not a standards track RFC for a protocol. I think the charter of this task for this WG, and the focus of this document is the former, not the latter. > >>4.2 Trust Model Recommendation > >>Since the definition of distributed trust above is not quite >>accurate, I question this assertion. Nonetheless, this paragraph >>seems to say that since the current, insecure system is based on >>transitive trust and distributed enforcement, that one should adopt >>that model as the basis for what we hope will be a more secure >>system. Certainly this is not a good argument to make. > >You've answered the question without stating what the question is. >Is the question how to force current providers to secure interdomain >routing, or is the question how do we provide tools for the current >providers to secure interdomain routing? Your assumption is that the >current system of trust doesn't work because the actors in the >system can't be trusted (as you've outlined in this response, and >several other times). I didn't answer a question above; I said that there are flaws in the definitions and in the reasoning in the text, and these flaws undermine the asserted conclusion. You are the one stating a question above, a question that may be appropriate somewhere, but not at this point in the document. Again you have grossly msicharacterized what I said. I noted that transitive trust models are inherently vulnerable and the way BGP operates reflects a transitive trust model, in most respects. I didn't say that the ISPs "can't be trusted." However, any system which relies on transitive trust makes the parties vulnerable to errors made by "trusted" parties and to successful attacks against those parties. >My assumption is there is no point in trying to force the community >to accept something they aren't going to accept anyway. It's better >to give the community tools that can be incrementally deployed, and >won't damage their current business models, and then attempt to >motivate them to use those tools (not that they aren't motivated >already, actually, based on my discussions with various providers). Your paragraph starts with a tautology, which limits its utility in this discussion. Not only have you decided what is and is not acceptable to the community, but you have also decided what potential solutions fall into which categories. That suggests that you really want this requirements document to reinforce your pre-existing notions of what constitutes an acceptable solution, rather than it acting as a legitimate analysis of security requirements for BGP. >Since this is a requirements document, it seems to me to be a >legitimate place to address specifically this question. The sense of >the design team has been, thus far, that we should require a set of >usable tools, rather than defining what "perfect security" would >look like, based on a specific view of the way the world really >should work. This text is begging the question, and thus is not a useful contribution to this discussion. >> o The AS_PATH list MUST correspond to a verifiable list of >> autonomous systems based on the peering topology of the network. > >>This is a subset of what the semantics of BGP imply. To make this a >>requirement, instead of the more stringent requirement that each AS >>along the path advertised a prefix to the next hop, is to abandon a >>security capability rather early in the process! This looks like >>blatant gerrymandering of a requirements document to accommodate a >>solution, i.e., soBGP. > >Steve, you are off in rant land here, and you know it. You are >trying to overload the AS Path in BGP, pushing in information that >simply wasn't ever designed to be there, and isn't there today, in >any known operational BGP system. If you want to criticize my comment, the professional way is to explain how the protocol spec differs from what I asserted, rather to rail at me and offer no supporting evidence. >As for shaping the requirements to favor an existing solution, >you're flat wrong. The requirements doc currently states the maximum >you can actually prove, definitively, within a routing system. Since >you can't prove "transitive authorization" within a routing system, >the requirements document doesn't ask any given security system to >prove it. It's unprovable, and unprovable things can't be >requirements. You've gone off the deep end here, Russ. I don't recall any references to what one can "prove" in the document, or any mention by me above of "transitive authorization." I think you should restrict your comments to the text in the draft, and my comments on the draft. >> o Announcing AS Check: For all BGP peers, a BGP Implementation MUST >> ensure that the first element of the AS_PATH list corresponds to >> the locally configured AS of that peer. > >>This seems to suggest that it is enough to verify that the UPDATE >>arrived via an interface consistent with the asserted AS number of >>the last hop. That sort of check does not ensure that the UPDATE >>was directed to the recipient, i.e., it admits mis-delivery of >>UPDATEs. > >This is what we, in Cisco land, call "enforce first as." I always >fall back to this terminology, because I don't know of any accepted >"three word term" that's currently used to describe what this >paragraph is stating. Without this check, no amount of signatures, >graphs, encryption, or anything else will secure BGP in any >meaningful way. As for accepting mis-delivery of updates, well, this >addresses one part of the problem. Russ, try to pay attention to what I say, not what you think I might mean. What I pointed out is that the check described above is not sufficient, as worded. In a requirements document one should be articulating the essence of what needs to be verified, and explaining why. This bullet fails to do so. My comment did not say what checks need to be done, but I did provide suggested text in a private message to John Scudder, in response to a query from him: - very that the Update is received via an authenticated and integrity-secure channel associated with a configured peer - verify that the first AS number appearing in the Update is that of the peer associated with the secure channel The wording of the bullet is imprecise, and the phrase "enforce first as" is equally poor, as it fails to articulate the need to establish the authenticity of the source and the integrity of the communication path. >As for the second part of your statement: Would you say it's more >important to secure the information in the routing database, or more >important to secure how it got there? Can you secure how something >gets into a database, and still wind up with invalid data? The >update process is how information gets into the database. While you >focus on the process whereby information makes it into the database, >I think the design team has, rightly, focused on the actual >validation of information in the database. Russ, have you stopped beating your wife? That question is about as well formed as the one you pose above. First, it is not clear what it would mean to "secure the information in the routing database." I assume what you really mean is to ensure that the data in the routing database is accurate, since accurate data is what one wants in order for BGP to work properly. Also, you say that the "update process is how information gets into the database" but this ignores static route entries, and the influence of local policies on what inputs are accepted from which peers. Anyway, I think we agree that the goal is to try to work toward ensuring the accuracy of the routes that are accepted into the routing database. I do tend to focus on ways to allow an AS to verify that data received via UPDATEs is accurate, and thus to avoid being mislead in case an AS has made an error or has been attacked and is emitting "bogus" UPDATEs. You suggest that it is sufficient to verify that the database is accurate, irrespective of how the data in it has arrived. That is a legitimate strategy, but you emphasize "actual validation of the information in the database." This suggests use of some sort of oracle, that can tell an AS whether the data in its database is accurate. Oracles are popular notions in academic analyses of protocols, but in the real world we have few oracles. In the BGP context, we have no oracles that provide up to date info about the accuracy of routes. To do so would require omniscience. Only if one relaxes the definition of what constitutes accurate (valid) routes, might one be able to provide the sort of oracle you allude to indirectly. Specifically, one must be willing to ask "could the ASes along this path have announced this route based on published policy info," as opposed to "have the ASes along this path announced this route. " BGP operates based on the latter assumption, and has no concept of the former in its standard definition. Steve --============_-1111559621==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] BGP Security Requirements Document
Russ,

<SNIP>

How about addressing what correctness means for BGP as a starting point? That might be a suitable starting point for a document of this sort, if one also decides that correctness and security for BGP are closely related.

The problem is larger than what is a "correct unit of data" within the BGP protocol. The BGP protocol acts as part of a larger routing system, and our focus should really be on securing routing as a system, rather than on securing some set of specific "semantics of BGP," which will vary depending on what your view of BGP is, and how you see the routing system as a whole.

I agree that one needs to keep in mind the system context in which a protocol operates in order to develop appropriate security requirement and mechanisms. But, as a rule, the IETF develops standards for protocols, not for systems, although there are exceptions to this general rule. The charter for RPSEC discusses both routing systems and routing protocols, but in terms of this document, the relevant charter item seems to be:

   - Document security analysis and requirements for specific routing protocols (e.g., OSPF, BGP)
I believe the stated goal for this document is developing security requirements for BGP, the protocol, not for inter-domain routing as a system. One could discuss implementation vulnerability issues in BGP, best practices for ISP management of routers, etc. in a system context. But that does not appear to be within the scope for this document.

This is a rather dubious requirement, since we rarely, if ever, add security to ANY base system and make the system FASTER than it was previously!

If you think of security as primarily cryptography, this is true. However, there are other elements of a security system which might, actually, speed up the operation of a system, overall. The goal being expressed here is that designers of any such security system should focus on the overall speed of the system, and work towards solutions that, at least, don't impair the operation of the system as a whole, rather than simply assuming we can slow the system down as much as we like, so long as we "secure" it, by tacking cryptographic processes and signatures into the "right places."

While cryptography is a good example of a security technology that tends to make a system slower, rather than faster, it is not the only example. In general improving the security of a protocol (or an application, ...) involves performing additional checks on inputs and on the results of processing. Such checks take more time, and thus do not make the protocol faster. One might argue that, in the case of attack, suitable security measures may help avoid computations that are easily detected as bogus, and thus the time spent on the security checks will be less than the time spent acting on bogus inputs. But, the text talked in more general terms, and in the more general context it is unlikely that added security measures will reduce or maintain the performance of the protocol, all else being equal.


   o The security system MUST support a range of possible outputs for
      local determination of the trust level for a specific route.  Any
      given route should be trustable to a locally configured degree,
      based on the completeness of security information for the update
      and other factors.

Experience in the security area shows that people are very, very bad at managing notions of trust. In the PKI arena, for example, anything other than very simple models of "trust" are subject to frequent mismanagement, and resulting vulnerabilities. So, why do you feel this is an essential feature for BGP security? Don't we have lots of experience that suggests that the current operational model which exhibits just this sort of property, creates significant vulnerabilities?

In other words, because the system is insecure today, based on the individual choices of operators, we really need something that overrides the individual choices of operators, to enforce security whether or not they like it. I don't tend to agree with this assessment. The origin of this requirement comes from the unwillingness of the community, at large, to have a security system forced on them that disallows their individual policy choices, and leaves them no room for operational or business differentiation.

You have grossly mischaracterized my comments above, and then used that to justify your conclusion. I made two observations:
 
        - First, non-trivial, "trust based" PKIs have generally proven to be too hard for people to manage, especially as the size of the grows. This is an objectively true statement, based on a fair amount of experience with PKIs.
        - Second, a number of errors appear in routes advertised by ISPs and these errors are propagated. It is very hard for operators to get everything "right" and keep it right on a continuing basis. Transitive trust models allow for propagation of errors, and thus are intrinsically vulnerable.

We both agree that individual operators should be free to operate autonomously; after all, we call these ASes for a reason. I have never suggested that local policies are anything other than locally managed. But, that does not mean that we ought not make available data from authoritative sources, e.g., for address and AS number assignment, to enable operators (who choose to make use of such data) to avoid being victimized by the error of other operators, as happens today. Availability of such data in no way impinges on the ability of an operator to control the local routing policies that he manages today. It merely enables an operator to determine whether other operators are representing path attributes in a fashion that is independently verifiable. A serious vulnerability of today's system is the lack of securely available, authoritative data that operators can use to evaluate UPDATEs.

Does your last comment suggest that emitting bogus routes is a good means of business differentiation for an ISP :-)


   o The security system SHOULD allow the operator to determine whether
      the speed of convergence is more important than security
      operations, or security operations are more important than the
      speed of convergence.  This facilitates the incremental deployment
      of security on systems not designed to support increased
      processing requirements imposed by the security system.

Is speed of convergence a purely local matter? If not, then making this a local parameter seems a bit odd, as described here.

You've fallen into the convergence trap! =:-O

The problem with the word "convergence" is it can mean many things to many people.... It can mean when a single process on a single device learns all the information it needs to build the tables required for forwarding information to directly connected peers. It might mean the time at which a single device has actually built all the tables required for forwarding traffic to directly connected peers. It might mean the time at a specific set of devices have all the information needed to build the tables to forward packets, or perhaps when all those same devices have actually built their forwarding tables. And on it goes.... :-)
In the previous instances of "convergence," I think Blaine is trying to get at the time required for the internetwork, as a whole, to converge. Here, he has shifted gears, and is discussing the time it takes for a specific device, locally, to build the tables required to forward traffic. There should be something noting this shift, I think, in the doc.

yes, one can look at convergence times in local or global contexts, and the text here is either ambiguous or inconsistent with the previous uses of the term in the document. so, the document needs to be fixed to avoid this apparent contradiction.
 
<SNIP>

BGP embodies a distributed decision making model for routing, but that is NOT a distributed trust model. The filtering described here represents a locally managed mechanism for enforcing business arrangements. But what really happens in the system today, from a trust management perspective, is transitive trust. The transitivity arise because updates nominally represent data that has been passed from one AS to another (modulo aggregation). So, it is not clear that BGP is appropriately described as being based on a distributed trust model, it least not from the BGP RFC. This discussion seems to confuse enforcement mechanisms and trust models.

I actually disagree with the characterization that transient trust characterizes the interdomain routing system today. You could claim that simply because an update passes from one AS to another, the "trust" also passes from one AS to another. In reality, there is a component of assuming what your peer sends you is valid (what you would term transitive trust), but there are also components of distributed trust in play, as well. They are part of the routing system, however, and not necessarily specifically outlined in the routing protocol specification--which is why it's so important not to try to secure BGP as a bag of bits, but rather to try and secure the system as a whole.

We seem to agree that when on AS accepts an UPDATE from another AS and assumes that the route represented in the UPDATE is valid, that constitutes an example of transitive trust. Yes, it is possible for external, extra-protocol measures to be used to help reject bogus routes. But, if these system (vs. protocol) measures are based on what you call distributed trust, and if that distributed trust is vulnerable to the sorts of operator errors we see today, then the resulting system is intrinsically vulnerable, which is what we have today. Presumably, we are working on requirements that will improve BGP security, from both a protocol and system perspective.

It's like trying to secure the door perfectly, while ignoring those old rusty locks on the windows, or the huge gaping whole in the wall just next to the door.

I think we agree that one needs to adopt a balanced approach to security, an approach that takes into account the implications of a "weakest link." But, we also have to be careful to not propose solutions that are intrinsically limited in the security they can achieve based on their reliance on any given facet of the solution. Foe example, we understand that if one insists on using passwords for user authentication the result will be a system with limited security, no matter how well we manage the passwords. If, on the other hand, we adopt a crypto-based approach to user authentication, we can improve the elements of the system to be more secure, even as the threat changes. Use of crypto does not ensure that user authentication will be more secure, but it allows that to be true.

The latter seems more relevant for BGP.

I assume you mean here that a strict heirarchical trust model seems more relevant for BGP. I would agree only if you consider BGP a bag of bits to be secured, and don't worry about the system at large, how the systems using BGP actually operate today, and what acceptable modes of operation are for those systems.

BGP is a protocol. As such it embodies syntax (your allusion to a "bag of bits") and a state machine. The semantics of BGP arise form analysis of the state machine, in the system context of inter-domain routing. I get the feeling that when you allude to "system" you mean a much broader set of things, some of which may be more like the procedures that one might document in a BCP, but not a standards track RFC for a protocol. I think the charter of this task for this WG, and the focus of this document is the former, not the latter.


4.2 Trust Model Recommendation

Since the definition of distributed trust above is not quite accurate, I question this assertion. Nonetheless, this paragraph seems to say that since the current, insecure system is based on transitive trust and distributed enforcement, that one should adopt that model as the basis for what we hope will be a more secure system. Certainly this is not a good argument to make.

You've answered the question without stating what the question is. Is the question how to force current providers to secure interdomain routing, or is the question how do we provide tools for the current providers to secure interdomain routing? Your assumption is that the current system of trust doesn't work because the actors in the system can't be trusted (as you've outlined in this response, and several other times).

I didn't answer a question above; I said that there are flaws in the definitions and in the reasoning in the text, and these flaws undermine the asserted conclusion. You are the one stating a question above, a question that may be appropriate somewhere, but not at this point in the document.

Again you have grossly msicharacterized what I said. I noted that transitive trust models are inherently vulnerable and the way BGP operates reflects a transitive trust model, in most respects. I didn't say that the ISPs "can't be trusted."  However, any system which relies on transitive trust makes the parties vulnerable to errors made by "trusted" parties and to successful attacks against those parties.

My assumption is there is no point in trying to force the community to accept something they aren't going to accept anyway. It's better to give the community tools that can be incrementally deployed, and won't damage their current business models, and then attempt to motivate them to use those tools (not that they aren't motivated already, actually, based on my discussions with various providers).

Your paragraph starts with a tautology, which limits its utility in this discussion. Not only have you decided what is and is not acceptable to the community, but you have also decided what potential solutions fall into which categories. That suggests that you really want this requirements document to reinforce your pre-existing notions of what constitutes an acceptable solution, rather than it acting as a legitimate analysis of security requirements for BGP.


Since this is a requirements document, it seems to me to be a legitimate place to address specifically this question. The sense of the design team has been, thus far, that we should require a set of usable tools, rather than defining what "perfect security" would look like, based on a specific view of the way the world really should work.

This text is begging the question, and thus is not a useful contribution to this discussion.


   o The AS_PATH list MUST correspond to a verifiable list of
      autonomous systems based on the peering topology of the network.

This is a subset of what the semantics of BGP imply. To make this a requirement, instead of the more stringent requirement that each AS along the path advertised a prefix to the next hop, is to abandon a security capability rather early in the process! This looks like blatant gerrymandering of a requirements document to accommodate a solution, i.e., soBGP.

Steve, you are off in rant land here, and you know it. You are trying to overload the AS Path in BGP, pushing in information that simply wasn't ever designed to be there, and isn't there today, in any known operational BGP system.

If you want to criticize my comment, the professional way is to explain how the protocol spec differs from what I asserted, rather to rail at me and offer no supporting evidence.

As for shaping the requirements to favor an existing solution, you're flat wrong. The requirements doc currently states the maximum you can actually prove, definitively, within a routing system. Since you can't prove "transitive authorization" within a routing system, the requirements document doesn't ask any given security system to prove it. It's unprovable, and unprovable things can't be requirements.

You've gone off the deep end here, Russ. I don't recall any references to what one can "prove" in the document, or any mention by me above of "transitive authorization." I think you should restrict your comments to the text in the draft, and my comments on the draft.

   o Announcing AS Check: For all BGP peers, a BGP Implementation MUST
      ensure that the first element of the AS_PATH list corresponds to
      the locally configured AS of that peer.

This seems to suggest that it is enough to verify that the UPDATE arrived via an interface consistent with the asserted AS number of the last hop. That sort of check does not ensure that the UPDATE was directed to the recipient, i.e., it admits mis-delivery of UPDATEs.

This is what we, in Cisco land, call "enforce first as." I always fall back to this terminology, because I don't know of any accepted "three word term" that's currently used to describe what this paragraph is stating. Without this check, no amount of signatures, graphs, encryption, or anything else will secure BGP in any meaningful way. As for accepting mis-delivery of updates, well, this addresses one part of the problem.

Russ, try to pay attention to what I say, not what you think I might mean.  What I pointed out is that the check described above is not sufficient, as worded. In a requirements document one should be articulating the essence of what needs to be verified, and explaining why. This bullet fails to do so. My comment did not say what checks need to be done, but I did provide suggested text in a private message to John Scudder, in response to a query from him:

        - very that the Update is received via an authenticated and integrity-secure channel associated with a configured peer

        - verify that the first AS number appearing in the Update is that of the peer associated with the secure channel

The wording of the bullet is imprecise, and the phrase "enforce first as" is equally poor, as it fails to articulate the need to establish the authenticity of the source and the integrity of the communication path.

As for the second part of your statement: Would you say it's more important to secure the information in the routing database, or more important to secure how it got there? Can you secure how something gets into a database, and still wind up with invalid data? The update process is how information gets into the database. While you focus on the process whereby information makes it into the database, I think the design team has, rightly, focused on the actual validation of information in the database.

Russ, have you stopped beating your wife? That question is about as well formed as the one you pose above.

First, it is not clear what it would mean to "secure the information in the routing database." I assume what you really mean is to ensure that the data in the routing database is accurate, since accurate data is what one wants in order for BGP to work properly. Also, you say that the "update process is how information gets into the database" but this ignores static route entries, and the influence of local policies on what inputs are accepted from which peers.
Anyway, I think we agree that the goal is to try to work toward ensuring the accuracy of the routes that are accepted into the routing database. I do tend to focus on ways to allow an AS to verify that data received via UPDATEs is accurate, and thus to avoid being mislead in case an AS has made an error or has been attacked and is emitting "bogus" UPDATEs. You suggest that it is sufficient to verify that the database is accurate, irrespective of how the data in it has arrived. That is a legitimate strategy, but you emphasize "actual validation of the information in the database." This suggests use of some sort of oracle, that can tell an AS whether the data in its database is accurate. Oracles are popular notions in academic analyses of protocols, but in the real world we have few oracles. In the BGP context, we have no oracles that provide up to date info about the accuracy of routes. To do so would require omniscience. Only if one relaxes the definition of what constitutes accurate (valid) routes, might one be able to provide the sort of oracle you allude to indirectly. Specifically, one must be willing to ask "could the ASes along this path have announced this route based on published policy info," as opposed to  "have the ASes along this path announced this route. "  BGP operates based on the latter assumption, and has no concept of the former in its standard definition.

Steve
--============_-1111559621==_ma============-- --===============0318427851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0318427851==-- From rpsec-bounces@ietf.org Mon Nov 15 20:06:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03367 for ; Mon, 15 Nov 2004 20:06:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTrps-0007Yi-P4 for rpsec-web-archive@ietf.org; Mon, 15 Nov 2004 20:08:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTrlF-00059q-6X; Mon, 15 Nov 2004 20:03:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTri8-0004pS-7t for rpsec@megatron.ietf.org; Mon, 15 Nov 2004 20:00:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02995 for ; Mon, 15 Nov 2004 20:00:42 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTrkE-0007Rs-Ge for rpsec@ietf.org; Mon, 15 Nov 2004 20:02:55 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 15 Nov 2004 20:26:05 -0500 X-BrightmailFiltered: true Received: from russpc.Whitehouse.intra (rtp-vpn3-317.cisco.com [10.82.217.63]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAG106E5006327; Mon, 15 Nov 2004 20:00:07 -0500 (EST) Date: Mon, 15 Nov 2004 19:59:34 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements Document In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c >> The problem is larger than what is a "correct unit of data" within the >> BGP protocol. The BGP protocol acts as part of a larger routing system, >> and our focus should really be on securing routing as a system, rather >> than on securing some set of specific "semantics of BGP," which will >> vary depending on what your view of BGP is, and how you see the routing >> system as a whole. > > I agree that one needs to keep in mind the system context in which a > protocol operates in order to develop appropriate security requirement > and mechanisms. But, as a rule, the IETF develops standards for > protocols, not for systems, although there are exceptions to this general > rule. The charter for RPSEC discusses both routing systems and routing > protocols, but in terms of this document, the relevant charter item seems > to be: > > - Document security analysis and requirements for specific routing > protocols (e.g., OSPF, BGP) > > I believe the stated goal for this document is developing security > requirements for BGP, the protocol, not for inter-domain routing as a > system. One could discuss implementation vulnerability issues in BGP, > best practices for ISP management of routers, etc. in a system context. > But that does not appear to be within the scope for this document. In other words, you're unwilling to consider anything outside what you define to be "the semantics of BGP," as you've defined them, to be a valid discussion point. You've framed the argument around your definition, BGP as a bag of bits, and with the semantics you believe to be in the protocol spec (ignoring other's interpretations of that same specification), and you refuse to contemplate that there may be other, differing views, on what needs to be secured, what true requirements are, etc. Within that definition, you have the perfect answer, and no-one else can argue with you. I'm sorry if I find your stance unhelpful. >> If you think of security as primarily cryptography, this is true. >> However, there are other elements of a security system which might, >> actually, speed up the operation of a system, overall. The goal being >> expressed here is that designers of any such security system should >> focus on the overall speed of the system, and work towards solutions >> that, at least, don't impair the operation of the system as a whole, >> rather than simply assuming we can slow the system down as much as we >> like, so long as we "secure" it, by tacking cryptographic processes and >> signatures into the "right places." > > While cryptography is a good example of a security technology that tends > to make a system slower, rather than faster, it is not the only example. > In general improving the security of a protocol (or an application, ...) > involves performing additional checks on inputs and on the results of > processing. Such checks take more time, and thus do not make the protocol > faster. One might argue that, in the case of attack, suitable security > measures may help avoid computations that are easily detected as bogus, > and thus the time spent on the security checks will be less than the time > spent acting on bogus inputs. But, the text talked in more general terms, > and in the more general context it is unlikely that added security > measures will reduce or maintain the performance of the protocol, all > else being equal. And, I don't agree. There are elements here that could easily help BGP's convergence speed, since the points at which BGP's convergence speed and BGP's security are weak probably overlap in many places. Rather than exploring those opportunities, you would like to force any possible system design into your box, and your definitions. >>> Experience in the security area shows that people are very, very bad at >>> managing notions of trust. In the PKI arena, for example, anything other >>> than very simple models of "trust" are subject to frequent mismanagement, >>> and resulting vulnerabilities. So, why do you feel this is an essential >>> feature for BGP security? Don't we have lots of experience that suggests >>> that the current operational model which exhibits just this sort of >>> property, creates significant vulnerabilities? >> >> In other words, because the system is insecure today, based on the >> individual choices of operators, we really need something that overrides >> the individual choices of operators, to enforce security whether or not >> they like it. I don't tend to agree with this assessment. The origin of >> this requirement comes from the unwillingness of the community, at large, >> to have a security system forced on them that disallows their individual >> policy choices, and leaves them no room for operational or business >> differentiation. > > You have grossly mischaracterized my comments above, and then used that to > justify your conclusion. I made two observations: > > - First, non-trivial, "trust based" PKIs have generally proven to > be too hard for people to manage, especially as the size of the grows. > This is an objectively true statement, based on a fair amount of > experience with PKIs. > - Second, a number of errors appear in routes advertised by ISPs > and these errors are propagated. It is very hard for operators to get > everything "right" and keep it right on a continuing basis. Transitive > trust models allow for propagation of errors, and thus are intrinsically > vulnerable. > > We both agree that individual operators should be free to operate > autonomously; after all, we call these ASes for a reason. I have never > suggested that local policies are anything other than locally managed. > But, that does not mean that we ought not make available data from > authoritative sources, e.g., for address and AS number assignment, to > enable operators (who choose to make use of such data) to avoid being > victimized by the error of other operators, as happens today. > Availability of such data in no way impinges on the ability of an > operator to control the local routing policies that he manages today. It > merely enables an operator to determine whether other operators are > representing path attributes in a fashion that is independently > verifiable. A serious vulnerability of today's system is the lack of > securely available, authoritative data that operators can use to evaluate > UPDATEs. First, you're again assuming that the attributes within an update are what's important to secure. The important thing to secure is what's in the database, not what's in the update. Again, you're assuming you have the only version of the right question, and assuming, therefore, that your answer is the only possible right answer. > Does your last comment suggest that emitting bogus routes is a good means > of business differentiation for an ISP :-) *sigh* The problem is basically definitions. Unless we can agree on what, exactly, needs to be secured here (the bag of bits in a BGP update, or the information in the routing database), we aren't ever going to agree on what's a requirement, or what's an acceptable set of options. > I think we agree that one needs to adopt a balanced approach to security, > an approach that takes into account the implications of a "weakest link." > But, we also have to be careful to not propose solutions that are > intrinsically limited in the security they can achieve based on their > reliance on any given facet of the solution. Yes, exactly. You cannot prove transitive authorization to advertise something without outright banning aggregation and filtering in a routing system. You can secure anything in the way of updates all you want, but you aren't going to get around that. So, let's focus on what actually _can_ be secured in routing, BGP specifically. Since you can't prove transitive authorization to advertise, then you can't require it in a requirements document. >>> This is a subset of what the semantics of BGP imply. To make this a >>> requirement, instead of the more stringent requirement that each AS >>> along the path advertised a prefix to the next hop, is to abandon a >>> security capability rather early in the process! This looks like >>> blatant gerrymandering of a requirements document to accommodate a >>> solution, i.e., soBGP. >> >> Steve, you are off in rant land here, and you know it. You are trying to >> overload the AS Path in BGP, pushing in information that simply wasn't ever >> designed to be there, and isn't there today, in any known operational BGP >> system. > > If you want to criticize my comment, the professional way is to explain > how the protocol spec differs from what I asserted, rather to rail at me > and offer no supporting evidence. First, your comment is unprofessional because you are accusing the technical design team of doing something it has _explicitely_ not done--design the requirements to fit one specific solution currently available. Second, your comment states that the requirements document should not give up "possibly stronger security" based on a specific belief in the way BGP works, based on your definition of the solution space. In other words, you state that BGP updates imply transitive authorization to readvertise. I countered this with the comment that the type of security you state the requirements document is "giving up" doesn't exist--it's not provable. I've countered this in multiple forums, multiple times. I don't really want to rehash the whole thing here, but I've never seen anyone prove that transitive authority to advertise a specific address space, in a deployment where filtering and aggregation are allowed, exists. In other words, just because my peer advertises 10.1.0.0/16 to me, doesn't imply that I'm authorized to advertise every possible address within the /16 block to my peers as reachable through me. And that is precisely what you are trying to overload onto the BGP update process--that if I receive an update for 10.1.0.0/16, I'm authorized to advertise every possible address within the block. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Nov 15 22:24:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23106 for ; Mon, 15 Nov 2004 22:24:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTtzp-0001Td-Pg for rpsec-web-archive@ietf.org; Mon, 15 Nov 2004 22:27:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTtvr-0005Vk-TP; Mon, 15 Nov 2004 22:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTtum-0005If-4u for rpsec@megatron.ietf.org; Mon, 15 Nov 2004 22:21:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21308 for ; Mon, 15 Nov 2004 22:21:54 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTtws-0001Oq-Uu for rpsec@ietf.org; Mon, 15 Nov 2004 22:24:08 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 15 Nov 2004 22:47:14 -0500 X-BrightmailFiltered: true Received: from russpc.Whitehouse.intra (rtp-vpn3-88.cisco.com [10.82.216.88]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAG3LFE5024976; Mon, 15 Nov 2004 22:21:19 -0500 (EST) Date: Mon, 15 Nov 2004 22:20:41 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] BGP Security Requirements Document In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 > This is a subset of what the semantics of BGP imply. To make this a > requirement, instead of the more stringent requirement that each AS along > the path advertised a prefix to the next hop, is to abandon a security > capability rather early in the process! This looks like blatant > gerrymandering of a requirements document to accommodate a solution, > i.e., soBGP. I was thinking about this entire argument some more, and decided to make one point: The design team, in a set of long an protected discussions, came to the rough concensus, I believe, that while you can ask to verify a path within BGP exists, you cannot ask to prove authorization to readvertise a specific prefix. I could be wrong on this point, but I believe that is what's in the document because such a rough consensus existed within the design team at the time of the document writing. You claim that you _can_ prove transitive authorization to advertise something, and I believe I can provide an example where this simply isn't true. To wit: +----B---+ | | | A | C | | | +----D---+ -- D owns 10.1.0.0/16. -- D suballocates 10.1.1.0/24 to A. D can provide a certificate proving this suballocation to any and all interested parties in the network--this, we can all agree on. -- A determines it would like to advertise 10.1.1.0/24 to D and B, but would not like B to readvertise 10.1.1.0/24 to C. A therefore marks, in some way, it's route to B so B cannot readvertise 10.1.1.0/24. We don't care how this marking works, just so long as we assume such a marking exists, and B will always honor this marking. -- D continues to advertise 10.1.0.0/16 to B. -- B continues to adveritse 10.1.0.0/16 to C Now, a series of questions: -- Does 10.1.0.0/16 contain 10.1.1.0/24? I assume the answer is yes. -- Does B, in fact, "gain authorization" to advertise 10.1.1.0/24 as a part of "gaining authorization" to advertise 10.1.0.0/16? Yes. -- Can A, then, prevent B from advertising 10.1.1.0/24? No, as long as we agree that 10.1.1.0/24 is a part of 10.1.0.0/16. In what sense, then, is A "given" the address space 10.1.1.0/24? D is still advertising it, without A's consent, correct? Either we must specify that D can no longer advertise address space it has suballocated (in other words, there can be no overlapping advertisements in the protocol), or the concept of "ownership" in this case is looser than we are expecting. In fact, the concept of "ownership" of address space, in this context, prevents A from ever controlling where address space it "owns" is avertised. A cannot prevent its address space from being advertised to anyone on the internetwork, thus A cannot, in any meaningful sense, be said to "authorize the readvertisement" of its address space. If I can't prevent something from happening, then it's hard to say how I can authorize it, IMHO. Either I can control it, or I can't. Either I can withold the car keys and prevent my kids from driving the car, or I can't. If the kids have their own copies of the keys to my wife's car, and permanent permission to drive it anyplace they like anytime they like, then I don't have any meaningful control over the situation, most likely. If you can find some hole in the logic, other than asserting that A shouldn't have such a policy, or that it all works without aggregation, and we can't expect the aggregation case to work anyway, then I would like to hear it. I don't know of any holes in this example, and it's a small, uncomplicated example. The problem isn't just in BGP, it's in the concept of address ownership--which, while not outlined specifically in the BGP specification, the idea of overlapping addresses with suballocation without "complete ownership transfer" is embedded in the document as an environmental assumption. The protocol is built, to some degree, around this assumption, and is designed to accomidate it through aggregation. Thus, if you try to secure BGP by focussing on BGP updates, you can miss the forest for the trees. I think the design team did a good job of focusing on the forest. I do believe the document needs more justification, and background, but I also believe the final requirements listed are realistic, in most places, and possible within the technical realm. There are some tongue in cheek things in there, but I don't believe those are out of place, in general, to get the point across that the team was trying to make. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Nov 29 20:52:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08056 for ; Mon, 29 Nov 2004 20:52:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYxGb-0005ht-93 for rpsec-web-archive@ietf.org; Mon, 29 Nov 2004 20:57:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxA1-0004Cx-B7; Mon, 29 Nov 2004 20:50:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYx8K-0003v6-R1 for rpsec@megatron.ietf.org; Mon, 29 Nov 2004 20:48:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07901 for ; Mon, 29 Nov 2004 20:48:47 -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.33) id 1CYxDL-0005dn-Nf for rpsec@ietf.org; Mon, 29 Nov 2004 20:54:00 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2004 18:55:16 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (sjc-vpn4-854.cisco.com [10.21.83.85]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAU1mEf4017453 for ; Mon, 29 Nov 2004 17:48:15 -0800 (PST) Date: Mon, 29 Nov 2004 20:47:38 -0500 (Eastern Standard Time) From: Russ White To: rpsec@ietf.org Message-ID: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part one) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 I've been through the entire draft again, and have some various comments, below the sig line. I've split these up into different pieces for ease of discussion. I'm hoping some of the security folks on list will jump in and help with some of the questions I have, on how to word things and such. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone -- Abstract The security of BGP is critical to the continued health and well being of internetworking. While securing a link between two BGP peers is a relatively easy technical matter, the manner in which to do so is not standard. Additionally, a secure link does not provide security or authentication of the routes updates themselves. In this document, we describe a set of requirements for securing BGP, both in the areas of peering relationships and prefix authentication. I think this might actually be a bit vague (?)..... Possibly something like: The security of BGP is critical to the continued health and well being of large scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routed system, is somewhat more complex. This document describes a set of requirements for securing BGP, including securing peering relationships between BGP speakers, and authenticating routing information carried within BGP. ?? -- 1. Introduction Threats to networking protocols generally fall under one of the three categories as defined in RFC 2196: o Unauthorized access to resources and/or information o Unintended and/or unauthorized disclosure of information o Denial of service I think I would set off "as defined in RFC 2196," into a phrase or something (?). Shouldn't it also be a reference, like this: [RFC2196]," with 2916 listed at the end of the doc as a normative reference? A number of attacks can be realized which, if exploited, can lead to one of the above mentioned threats. These are typically classified as passive attacks and active attacks. Passive attacks are ones where an attacker simply reads information off the network and obtains confidential and/or private information. Active attacks are ones where the attacker writes data to the network and can include replay attacks, message insertion, message deletion, message modification and man-in-the-middle attacks. Often, these attacks are combined as in the instance where a forged BGP packet is injected ^ I think you need a comma here (?). into a BGP routing infrastructure to force a particular data path for traffic that can then be sniffed and used for further destructive behavior. This sentence is, overall, a bit long and unwieldy. Maybe adding a couple of commas would make it better, but it might need to be split into two sentences. Some of the attacks against normal BGP protocol behavior can be difficult to recognize or prevent and these fall outside of the scope of this document. "Undetectable or difficult to recognize attacks against the BGP protocol itself, attacks falling within the normal operating parameters of the BGP protocol, are outside the scope of this document." I'm not certain this revised sentence even says what the group is trying to say (?). Protecting against an attack where an end-system has been compromised is also extremely difficult although wherever ^ comma? possible the requirements will attempt to minimize the extent of the ^ comma? damage under these circumstances. The intent of this requirements document is to prevent attacks that originate false data or create invalid routing paths and therefore addresses issues relating to data integrity and peer entity authentication. "This document is a framework of requirements for building a system to prevent attacks involving falsely originating routing information, or creating invalid routing paths through an internetwork." As described in RFC 3552, data integrity protection ^^^^^^^^ I think this needs to be a reference again, [RFC3552]. ensures that data is not modified in transit and peer entity authentication ensures that there is a reasonable guarantee that the sender and recipient of the data are the intended parties. I'm not certain how this paragraph fits here specifically (?). Maybe we should seperate out the parts about authenticating information transmitted between a single pair of BGP speakers into one section, or one place, consolidating it somewhat? The guarantee of packet delivery is not part of the BGP protocol "Guaranteed packet delivery...." security model. Just because a packet is addressed to a specific peer does not mean it will be received, even with a "secure" route. ^^^^ Do you mean peer here, or destination, in general? Could this include a host destintation as well as a BGP speaker? For example: an attacker could have compromised an intermediate router and installed a static route for target address A.B.C.D pointing to an inappropriate direction or an attacker might splice into a circuit between two secure routers and install a device that diverts A.B.C.D traffic without requiring the compromise of control plane devices. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Nov 29 20:59:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08752 for ; Mon, 29 Nov 2004 20:59:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYxNq-0005vK-7H for rpsec-web-archive@ietf.org; Mon, 29 Nov 2004 21:04:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxAB-0004EL-H1; Mon, 29 Nov 2004 20:50:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYx9C-0003yV-KI for rpsec@megatron.ietf.org; Mon, 29 Nov 2004 20:49:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07922 for ; Mon, 29 Nov 2004 20:49:41 -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.33) id 1CYxED-0005es-GW for rpsec@ietf.org; Mon, 29 Nov 2004 20:54:54 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 29 Nov 2004 17:55:14 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (sjc-vpn4-854.cisco.com [10.21.83.85]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAU1n0AD009819 for ; Mon, 29 Nov 2004 17:49:01 -0800 (PST) Date: Mon, 29 Nov 2004 20:48:31 -0500 (Eastern Standard Time) From: Russ White To: rpsec@ietf.org Message-ID: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Subject: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part 2) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Below sig.... :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone -- 2. Definition of Verifiable For the purposes of this document the word verifiable indicates the ability to determine through algorithmic means whether a unit of information is correct. I do think we need something better here. Perhaps: "Verifiable, within the context of a routing system, and as it's used in this document, means the ability to validate the authorization of a specific autonomous system to advertise a given prefix (or block of IP addresses), and the ability to verify the immediate peer transmitting the update has a route to the destination indicated in the update." Or something like that (?). 3. Incremental Deployments Requirements Here is where we start getting into trouble. :-) We need to be able to back up each of these requirements with some reasoning, or take them out, I think. It might be better to spplit this out into two lists, a list of things that operators would find unacceptable, and then a list of things about BGP that shouldn't be changed, based on the first list. Then you could refer back to the first list in the second list, like this.... "By discussing BGP security proposals and solutions with various users of the BGP protocol involved in large internetworks, including the public Internet, equipment vendors, and others, we have determined the following are important attributes of an interdomain routing system to consider when designing a security system: o Convergence Speed Convergence speed is a major concern to many operators of large scale internetworking systems. Networks, and internetworks, are carrying ever increasing amounts of information that is time and delay sensative; increasing convergence times can adversely impact the usability of the network, and the ability of an internetwork to grow into new functions in the future. o Incremental Deployment We cannot count on any given security system for interdomain routing being deployed through a flag day, and we cannot expect operators to split a large internetwork into multiple pieces while a security system is being deployed. o Trust Level Variability Each secured environment might have different levels of requirements in terms of what is acceptable or unacceptable. For instance, in a military environment, it might not be acceptable to route to a destination until a full check of all information contained in an update is performed, while in many commercial environments, routing information might be checked periodically. Trust levels in different environments can also vary widely, and even between entities within the same environment. These general requirements lead to the following specific requirements for security systems designed for interdomain routing: o BGP's convergence speed SHOULD be equivalent with or without any security system implemented and deployed. Optimizations used to make BGP converge in acceptable times on existing hardware, such as update packing and peer groups, SHOULD NOT be impacted by any proposed security system. This supports the Convergence Speed requirement above. o Any developed and deployed security system MUST NOT disallow the forming of peering relationships between secure and nonsevure BGP speakers, and MUST be backward compatible in the formatting, transmission, and processing of routing information transmitted through a BGP peering session. The BGP peering FSM SHOULD be preserved. This supports the Incremental Deployment requirement above. o Any proposed security system SHOULD support the intermixing of secured and unsecured routes in a single BGP session between a single pair of BGP speakers. BGP implementations SHOULD be able to distinguish secured and unsecured routes without reference to items that can be stripped from a propagated routing update. This supports the Incremental Deployment requirement above. o The security system MUST support a range of possible outputs for local determination of the trust level for a specific route. Any given route should be trustable to a locally configured degree, based on the completeness of security information for the update and other factors. This supports the Trust Level Variability requirement above. o The security system SHOULD allow the operator to determine whether the speed of convergence is more important than security operations, or security operations are more important than the speed of convergence. This facilitates the incremental deployment of security on systems not designed to support increased processing requirements imposed by the security system. -- Network recovery times for secured routing as well as unsecured routing SHOULD work with similar speed and SHOULD perform with equivalent, or greater, rapidity than legacy routing methods. Unsecured routing of secured prefixes MUST be supported so that a mix of secured and unsecured routing paths will provide security for the prefixes that have security features applied, but will not penalize or preempt "normal" prefixes. I think I would take this section out, since it's pretty much covered above, in the section on range of possible inputs requirement. -- 4. Trust Models 4.1 Trust Model Examples One example of a trust model is a distributed trust system. Inter-domain routing as implemented today is based on the concept of distributed trust. There is no central authority; each AS is free to choose whom to trust and whom to avoid placing trust in. This model is expressed through the filtering of routing information received from BGP peers. Financial contracts and business arrangements play a large role in how an AS chooses to filter their peers. I think Steve is correct in stating the current Internet isn't really a distributed trust model, per se. Internet routing is a distributed trust model, perhaps, in the sense that you trust your neighbor to do the right thing, who then trust their neighbor to do the right thing--in effect, you're basing your trust for your neighbor on their actions as well as on their their ability to monitor their trust relationship with their neighbors. A second trust model is a hierarchical system much like how root certificates for SSL/TLS are distributed today. In this model, a central authority controls all information. For example, all address allocations are authenticated and signed by ICANN, then by a regional registry, then a large ISP, a small ISP, etc. ICANN serves as the root of the address allocation system. This type of trust is usually referred to as a strict hierarchical trust model or a chain of trust. And here, I think we are trying to explain heirarchical trust model in too few words, actually. I was poking around for some document we could reference that actually defined the two trust models for us, and found a few interesting leads, but nothing definitive. I think the best thing to do here would be to reference a really good explaination of the two models, something authorative, and then provide a short example of each one in the same internetwork, to help the reader understand the application to this problem, perhaps. I'm hoping one of the security geeks in the WG can help us with a good reference. 4.2 Trust Model Recommendation While there are a number of trust models available, a distributed .... I think the thrust of this section is good, but there's not really a lot of justification behind the requirements laid out. Perhaps something like: "In examining the various environments in which BGP is deployed, and through discussions with various operators working within the context of the public Internet, and other internetworks, it is apparent that various types of trust models would fit specific environments better than others. For instance, in the public Internet, a roughly distributed trust model, following the current pattern of contractural peering arrangements, would fit the business models of the participants well. In other environments, however, where a single entity can be said to control the entire name space within the internetwork, a heirarchical trust model would work better. Thus, any trust system specified in a security mechanism designed for BGP must be flexible, and support both a true distributed trust model among the participants in the internetwork, and a fully heirarchical trust model among the participants in the internetwork. As heirarchical trust models are a subset (or a special case of) a distributed trust model, any security system designed for BGP MUST support a distributed trust model, and also MUST be able to support a heirarchical trust model, if desired. If two internetworks using different trust models are interconnected, they MUST be able to interoprate, using locally determined levels of trust to compensate for differences in their trust models where necessary." I don't know if this flows right, or has all the right words, but it might be a step towards providing stronger justifications for the requirement as presented. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Nov 29 21:01:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08856 for ; Mon, 29 Nov 2004 21:01:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYxPu-0005y9-00 for rpsec-web-archive@ietf.org; Mon, 29 Nov 2004 21:06:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxF2-0005ao-UL; Mon, 29 Nov 2004 20:55:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxA8-0004Dz-Jd for rpsec@megatron.ietf.org; Mon, 29 Nov 2004 20:50:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07957 for ; Mon, 29 Nov 2004 20:50:39 -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.33) id 1CYxF7-0005fd-Je for rpsec@ietf.org; Mon, 29 Nov 2004 20:55:52 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2004 18:57:05 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (sjc-vpn4-854.cisco.com [10.21.83.85]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAU1np9O001053 for ; Mon, 29 Nov 2004 17:49:52 -0800 (PST) Date: Mon, 29 Nov 2004 20:49:26 -0500 (Eastern Standard Time) From: Russ White To: rpsec@ietf.org Message-ID: X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Subject: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part 3) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Below sig, again. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone -- 5. Path Attributes and NLRI Authentication BGP distributes routing information across the Internet (between BGP speakers) using the BGP UPDATE messages. The UPDATE message contains ^^^ Take this "the" out. :-) withdrawn routes, path attributes and one or more NLRIs. For the remainder of this section, we will focus on Path Attributes and the NLRI. I think you mean "AS_PATH" attribute here? Aren't there other attributes called "path attributes?" -- Since BGP is a stateful routing protocol, the timeliness and freshness of reachability updates are critical for consistent routing state within the BGP routing system. To this end, there MUST be a mechanism to ensure that changes to reachability that result in an explicit or implicit withdrawal of reachability (RFC1771) are propagated within the secured BGP routing system in a timely manner. I think this is a good statement, but you've not explained why this is so important. Of course, it's important from the perspective of system convergence, but there's another reason, as well. Perhaps something like: "BGP is a stateful protocol; information received (and validated using any given security mechanism) is assumed good until it is either replaced with new information, or withdrawn from the routing system. Assume some new event occurs which causes the routing information propogated by a specific autonomous system within the internetwork to change. If the routing information and the information used to validate that routing information travel through the internetwork at different rates, there are a number of places where the security of the routing system may be compromised. For example: o If information is withdrawn, the route may be inappropriately used between the time the withdraw is received and the information validating the withdraw is received. o If the originating AS is changed, false routing information may be injected between the time the new route is injected and the information validating the new routing information is received. There are many other ways in which a differential between the speed of disseminating the information validating routing information and the routing information itself can be exploited to attack the routing system on a temporary basis. Because of the possible attacks that might be possible during differentials of routing and security information, any security system designed to secure BGP MUST provide for the distribution of security information at the same speed as the distribution of changes in routing information. This would include: o The distribution of information about the keys used by individual actors within the system, including the keys used by individual autonomous systems to sign certificates and other objects. o The distribution of information about the autonomous system authorized to advertise a given block of IP addresses (or an address space). o The distribution of information about connectivity between autonomous systems and autonomous system policies, if such information is distributed within the security system. Thoughts on this wording? -- Two types of verification MAY be offered for the NLRI and the AS_PATH: o Contents of the UPDATE message SHOULD be authenticated in real-time as the UPDATE message is processed. o The route information base MAY be authenticated periodically or in an event driven manner by scanning the data and verifying the originating AS and the verifiability of the AS-PATH list. 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. I'm not certain we need this section? It seems like this would be covered, if anyplace, under the flexibility section before in the document, where we discuss the ability to support local trust levels. It seems, to me, that the decision to validate routing information before or after installation actually bears on your local decisions about trust for peers, etc. The originating AS of a prefix may occasionally need to be changed either due to a re-assignment or a network transition. Any BGP security mechanism MUST support the change of an originating AS for a prefix within normal convergence times of the internetwork. I think we can drop this, if we reword the other section above on the timeleness of security information within the system. -- 5.1 Address Allocation These two modes lead to a single common requirement: Any BGP Security solution MUST support delegation of an address block of any size regardless of its relationship to other address blocks to another entity via verifiable means. I think, rather than explaining the modes of delegation, I'd just say it's common use within the public Internet, and other large scale internetworks, for these types of suballocation to occur, and provide examples for each (?). An associated delegation criteria is the requirement to allow for non-BGP IP end user implementations. As a result, all secured BGP implementations MUST allow for the propagation of a prefix by more than one originator AS. I think this requirement probably needs to be highlighted a bit more, maybe, and probably give an example of why, or provide the number of routes from a current view of the public Internet routing table with this property. -- 6. NLRI and Path Attribute Tracking .... The data generated by logging may be very large depending on the number of peers, the number of prefixes received, the authentication model used and routing policies. Path and NLRI attributes MUST be logged using a standard format. The format must be scalable with the amount of data logged and the frequency of log generation. The frequency of log generation should be controllable by the operator. The logging mechanisms for the tracked information MUST be standardized across all platforms. Logging ability both on and off line is considered highly desirable. This text comes out of the blue, really. Is there actually a requirement for logging? How does it relate to the path attribute tracking considered in this section? It should probably be made into a seperate section, really. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Nov 30 17:46:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25317 for ; Tue, 30 Nov 2004 17:46:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGr7-0005pd-Nv for rpsec-web-archive@ietf.org; Tue, 30 Nov 2004 17:52:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGNj-0005hl-6Q; Tue, 30 Nov 2004 17:21:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFxF-00084O-3b for rpsec@megatron.ietf.org; Tue, 30 Nov 2004 16:54:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17744 for ; Tue, 30 Nov 2004 16:54:34 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZG2P-0003Oh-Tt for rpsec@ietf.org; Tue, 30 Nov 2004 16:59:58 -0500 Received: from [208.231.75.212] ([208.231.75.212]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id iAULptan016055 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 30 Nov 2004 16:51:59 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 30 Nov 2004 16:51:49 -0500 Subject: Re: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part one) From: Blaine Christian To: Russ White , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit On 11/29/04 8:47 PM, "Russ White" wrote: > > I've been through the entire draft again, and have some various comments, > below the sig line. I've split these up into different pieces for ease of > discussion. I'm hoping some of the security folks on list will jump in and > help with some of the questions I have, on how to word things and such. Oh Joy... You just love to give me pain don't you. > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > -- > > Abstract > > The security of BGP is critical to the continued health and well > being of internetworking. While securing a link between two BGP > peers is a relatively easy technical matter, the manner in which to > do so is not standard. Additionally, a secure link does not provide > security or authentication of the routes updates themselves. In this > document, we describe a set of requirements for securing BGP, both in > the areas of peering relationships and prefix authentication. > > I think this might actually be a bit vague (?)..... Possibly something > like: > > The security of BGP is critical to the continued health and well being > of large scale internetworks, both public and private. While securing > the information transmitted between two BGP speakers is a relatively > easy technical matter, securing BGP, as a routed system, is somewhat > more complex. This document describes a set of requirements for > securing BGP, including securing peering relationships between BGP > speakers, and authenticating routing information carried within BGP. I like everything except when you say "somewhat". I will pull that out and keep the rest... Okay? > > ?? > > -- > > 1. Introduction > > Threats to networking protocols generally fall under one of the three > categories as defined in RFC 2196: > o Unauthorized access to resources and/or information > o Unintended and/or unauthorized disclosure of information > o Denial of service > > I think I would set off "as defined in RFC 2196," into a phrase or > something (?). Shouldn't it also be a reference, like this: > [RFC2196]," with 2916 listed at the end of the doc as a normative > reference? I will add it... > > A number of attacks can be realized which, if exploited, can lead to > one of the above mentioned threats. These are typically classified > as passive attacks and active attacks. Passive attacks are ones > where an attacker simply reads information off the network and > obtains confidential and/or private information. Active attacks are > ones where the attacker writes data to the network and can include > replay attacks, message insertion, message deletion, message > modification and man-in-the-middle attacks. Often, these attacks are > combined as in the instance where a forged BGP packet is injected > ^ > > I think you need a comma here (?). Sure, adding it... Or... Not... See below. > > into a BGP routing infrastructure to force a particular data path for > traffic that can then be sniffed and used for further destructive > behavior. > > This sentence is, overall, a bit long and unwieldy. Maybe adding a > couple of commas would make it better, but it might need to be split > into two sentences. Rephrased sentence: These attacks are often combined. ?? > > Some of the attacks against normal BGP protocol behavior can be > difficult to recognize or prevent and these fall outside of the scope > of this document. > > "Undetectable or difficult to recognize attacks against the BGP > protocol itself, attacks falling within the normal operating > parameters of the BGP protocol, are outside the scope of this > document." > > I'm not certain this revised sentence even says what the group is > trying to say (?). I am not sure I like that sentence very much period. I don't think we should say that something is difficult so we won't do it. I would rather say it as follows. Does this sound better? Rephrased: Attacks that do not involve direct manipulation of BGP, and the information contained within it, are outside the scope of this document. > > Protecting against an attack where an end-system > has been compromised is also extremely difficult although wherever > ^ > comma? > > possible the requirements will attempt to minimize the extent of the > ^ > comma? I hate commas ... But sure... > > damage under these circumstances. > > The intent of this requirements document is to prevent attacks that > originate false data or create invalid routing paths and therefore > addresses issues relating to data integrity and peer entity > authentication. > > "This document is a framework of requirements for building a system to > prevent attacks involving falsely originating routing information, or > creating invalid routing paths through an internetwork." > > As described in RFC 3552, data integrity protection > ^^^^^^^^ > > I think this needs to be a reference again, [RFC3552]. Yep... > > ensures that data is not modified in transit and peer entity > authentication ensures that there is a reasonable guarantee that the > sender and recipient of the data are the intended parties. > > I'm not certain how this paragraph fits here specifically (?). Maybe > we should seperate out the parts about authenticating information > transmitted between a single pair of BGP speakers into one section, or > one place, consolidating it somewhat? Hmm, for me it sort of links into the introduction as a further description of exactly what type of protection we are considering. Let's keep it unless we have other dissenters? > > The guarantee of packet delivery is not part of the BGP protocol > > "Guaranteed packet delivery...." Sounds better... > > security model. Just because a packet is addressed to a specific > peer does not mean it will be received, even with a "secure" route. > ^^^^ > > Do you mean peer here, or destination, in general? Could this include > a host destintation as well as a BGP speaker? Destination is better... Let's be less distinct than host or peer. Replying to your other emails next... _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Nov 30 17:47:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25371 for ; Tue, 30 Nov 2004 17:47:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGrN-0005qD-6B for rpsec-web-archive@ietf.org; Tue, 30 Nov 2004 17:52:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGO3-0005x0-SB; Tue, 30 Nov 2004 17:22:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFz5-0000tH-SU for rpsec@megatron.ietf.org; Tue, 30 Nov 2004 16:56:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18233 for ; Tue, 30 Nov 2004 16:56:29 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZG4H-0003bD-QO for rpsec@ietf.org; Tue, 30 Nov 2004 17:01:54 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id iAULsqjf002487; Tue, 30 Nov 2004 16:54:52 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 30 Nov 2004 16:50:58 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part one) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Russ, I'm glad to see that you are reviewing the text and making suggestions, as did I. I think this is a more productive way for the WG to get to the next version of the document, and to create a better document. I'll save my next round of comments until I see the next version of the document produced by the design team. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Nov 30 17:51:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25997 for ; Tue, 30 Nov 2004 17:51:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGvJ-00063A-H3 for rpsec-web-archive@ietf.org; Tue, 30 Nov 2004 17:56:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGjL-0002Q7-TW; Tue, 30 Nov 2004 17:44:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGLp-0004A8-6N for rpsec@megatron.ietf.org; Tue, 30 Nov 2004 17:20:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21954 for ; Tue, 30 Nov 2004 17:19:58 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGR0-0004mD-RK for rpsec@ietf.org; Tue, 30 Nov 2004 17:25:23 -0500 Received: from [208.231.75.212] ([208.231.75.212]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id iAUMJJan016305 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 30 Nov 2004 17:19:20 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 30 Nov 2004 17:19:13 -0500 Subject: Re: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part 2) From: Blaine Christian To: Russ White , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Content-Transfer-Encoding: 7bit On 11/29/04 8:48 PM, "Russ White" wrote: > > Below sig.... > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > -- > > 2. Definition of Verifiable > > For the purposes of this document the word verifiable indicates the > ability to determine through algorithmic means whether a unit of > information is correct. > > I do think we need something better here. Perhaps: > > "Verifiable, within the context of a routing system, and as it's used > in this document, means the ability to validate the authorization of a > specific autonomous system to advertise a given prefix (or block of IP > addresses), and the ability to verify the immediate peer transmitting > the update has a route to the destination indicated in the update." > > Or something like that (?). You are going to make us define authorization then... Hmmm... I stayed away from authorization because of the slippery slope principle. Authorize works to a certain level but, in the end, it needs to be a network stability choice. Where does authorization end? I think we do not want to see a central "everybody goes here to make their network work" type model. So, we will need to define authorization at a "network" level vs. authorization at an administrative level. Can authorization mean something like 3 out of 4 top tier ISPs agree that a certain ISP is authorized to propagate? How about this for a rephrase: Verifiable, within the context of a routing system, as detailed in this document, means the ability to validate the originator of a specific prefix (or block of IP addresses) and the ability to validate the session through which the prefix was received. > > 3. Incremental Deployments Requirements > > Here is where we start getting into trouble. :-) We need to be able to > back up each of these requirements with some reasoning, or take them > out, I think. It might be better to spplit this out into two lists, a > list of things that operators would find unacceptable, and then a list > of things about BGP that shouldn't be changed, based on the first > list. Then you could refer back to the first list in the second list, > like this.... > > "By discussing BGP security proposals and solutions with various users > of the BGP protocol involved in large internetworks, including the > public Internet, equipment vendors, and others, we have determined the > following are important attributes of an interdomain routing system to > consider when designing a security system: I might reword a bit but your message is good... > > o Convergence Speed > > Convergence speed is a major concern to many operators of large > scale internetworking systems. Networks, and internetworks, are > carrying ever increasing amounts of information that is time and > delay sensative; increasing convergence times can adversely > impact the usability of the network, and the ability of an > internetwork to grow into new functions in the future. > > o Incremental Deployment > > We cannot count on any given security system for interdomain > routing being deployed through a flag day, and we cannot expect > operators to split a large internetwork into multiple pieces > while a security system is being deployed. > > o Trust Level Variability > > Each secured environment might have different levels of > requirements in terms of what is acceptable or unacceptable. For > instance, in a military environment, it might not be acceptable > to route to a destination until a full check of all information > contained in an update is performed, while in many commercial > environments, routing information might be checked > periodically. Trust levels in different environments can also > vary widely, and even between entities within the same > environment. > > These general requirements lead to the following specific requirements > for security systems designed for interdomain routing: > > o BGP's convergence speed SHOULD be equivalent with or without any > security system implemented and deployed. Optimizations used to > make BGP converge in acceptable times on existing hardware, such > as update packing and peer groups, SHOULD NOT be impacted by any > proposed security system. > > This supports the Convergence Speed requirement above. > > o Any developed and deployed security system MUST NOT disallow the > forming of peering relationships between secure and nonsevure BGP > speakers, and MUST be backward compatible in the formatting, > transmission, and processing of routing information transmitted > through a BGP peering session. The BGP peering FSM SHOULD be > preserved. It probably works better if we just say "MUST allow" (I hate double negatives). I think the legacy peering FSM bits MUST be preferred. Otherwise badness eh? The case where it does not have to be preserved would be a brand new "secured" connection. > > This supports the Incremental Deployment requirement above. > > o Any proposed security system SHOULD support the intermixing of > secured and unsecured routes in a single BGP session between a > single pair of BGP speakers. BGP implementations SHOULD be able > to distinguish secured and unsecured routes without reference to > items that can be stripped from a propagated routing update. This was a bit painful to parse. The way I read it though it sounds like we are getting painted into a corner. Does this mean a whole new "secured" prefix propagation system is necessary? > > This supports the Incremental Deployment requirement above. > > o The security system MUST support a range of possible outputs for > local determination of the trust level for a specific route. Any > given route should be trustable to a locally configured degree, > based on the completeness of security information for the update > and other factors. > > This supports the Trust Level Variability requirement above. > > o The security system SHOULD allow the operator to determine > whether the speed of convergence is more important than security > operations, or security operations are more important than the > speed of convergence. > > This facilitates the incremental deployment of security on > systems not designed to support increased processing requirements > imposed by the security system. > > -- > > Network recovery times for secured routing as well as unsecured > routing SHOULD work with similar speed and SHOULD perform with > equivalent, or greater, rapidity than legacy routing methods. > Unsecured routing of secured prefixes MUST be supported so that a mix > of secured and unsecured routing paths will provide security for the > prefixes that have security features applied, but will not penalize > or preempt "normal" prefixes. > > I think I would take this section out, since it's pretty much covered > above, in the section on range of possible inputs requirement. Since the paragraph will be rephrased in the bullets I agree. However, I think we need to come to terms with the secured propagation thing. We put the mix of secured/unsecured routing bit of that paragraph in there to cover flag days etc... > > -- > > 4. Trust Models > > 4.1 Trust Model Examples > > One example of a trust model is a distributed trust system. > Inter-domain routing as implemented today is based on the concept of > distributed trust. There is no central authority; each AS is free to > choose whom to trust and whom to avoid placing trust in. This model > is expressed through the filtering of routing information received > from BGP peers. Financial contracts and business arrangements play a > large role in how an AS chooses to filter their peers. > > I think Steve is correct in stating the current Internet isn't really > a distributed trust model, per se. Internet routing is a distributed > trust model, perhaps, in the sense that you trust your neighbor to do > the right thing, who then trust their neighbor to do the right > thing--in effect, you're basing your trust for your neighbor on their > actions as well as on their their ability to monitor their trust > relationship with their neighbors. Agreed and will change in the document. > > A second trust model is a hierarchical system much like how root > certificates for SSL/TLS are distributed today. In this model, a > central authority controls all information. For example, all address > allocations are authenticated and signed by ICANN, then by a regional > registry, then a large ISP, a small ISP, etc. ICANN serves as the > root of the address allocation system. This type of trust is usually > referred to as a strict hierarchical trust model or a chain of trust. > > And here, I think we are trying to explain heirarchical trust model in > too few words, actually. I was poking around for some document we > could reference that actually defined the two trust models for us, and > found a few interesting leads, but nothing definitive. > > I think the best thing to do here would be to reference a really good > explaination of the two models, something authorative, and then > provide a short example of each one in the same internetwork, to help > the reader understand the application to this problem, perhaps. I'm > hoping one of the security geeks in the WG can help us with a good > reference. I got two very nice emails on this from Radia and Tao (on the other thread). I will forward to the group. > > 4.2 Trust Model Recommendation > > While there are a number of trust models available, a distributed > .... > > I think the thrust of this section is good, but there's not really a > lot of justification behind the requirements laid out. Perhaps > something like: > > "In examining the various environments in which BGP is deployed, and > through discussions with various operators working within the context > of the public Internet, and other internetworks, it is apparent that > various types of trust models would fit specific environments better > than others. For instance, in the public Internet, a roughly > distributed trust model, following the current pattern of contractural > peering arrangements, would fit the business models of the > participants well. > > In other environments, however, where a single entity can be said to > control the entire name space within the internetwork, a heirarchical > trust model would work better. Thus, any trust system specified in a > security mechanism designed for BGP must be flexible, and support both > a true distributed trust model among the participants in the > internetwork, and a fully heirarchical trust model among the > participants in the internetwork. > > As heirarchical trust models are a subset (or a special case of) a > distributed trust model, any security system designed for BGP MUST > support a distributed trust model, and also MUST be able to support a > heirarchical trust model, if desired. > > If two internetworks using different trust models are interconnected, > they MUST be able to interoprate, using locally determined levels of > trust to compensate for differences in their trust models where > necessary." > > I don't know if this flows right, or has all the right words, but it > might be a step towards providing stronger justifications for the > requirement as presented. I think it sounds great... Much more detail... > > _______________________________________________ > 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 Tue Nov 30 17:53:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26212 for ; Tue, 30 Nov 2004 17:53:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGxH-000679-Fa for rpsec-web-archive@ietf.org; Tue, 30 Nov 2004 17:58:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGna-0005KH-Kd; Tue, 30 Nov 2004 17:48:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGZI-0002gt-EI for rpsec@megatron.ietf.org; Tue, 30 Nov 2004 17:33:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23769 for ; Tue, 30 Nov 2004 17:33:53 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGeU-0005Lf-91 for rpsec@ietf.org; Tue, 30 Nov 2004 17:39:18 -0500 Received: from [208.231.75.212] ([208.231.75.212]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id iAUMXMan016468 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 30 Nov 2004 17:33:23 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 30 Nov 2004 17:33:14 -0500 Subject: Re: [RPSEC] Comments on draft-christian-bgpsecrec-01.txt (part 3) From: Blaine Christian To: Russ White , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: 7bit On 11/29/04 8:49 PM, "Russ White" wrote: > > Below sig, again. > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > -- > > 5. Path Attributes and NLRI Authentication > > BGP distributes routing information across the Internet (between BGP > speakers) using the BGP UPDATE messages. The UPDATE message contains > ^^^ > Take this "the" out. :-) No the... > > withdrawn routes, path attributes and one or more NLRIs. For the > remainder of this section, we will focus on Path Attributes and the > NLRI. > > I think you mean "AS_PATH" attribute here? Aren't there other > attributes called "path attributes?" Yes... You are correct... I thought I fixed all that... If you recall the discussion began with the other attributes mentioned but then we threw them out. > > -- > > Since BGP is a stateful routing protocol, the timeliness and > freshness of reachability updates are critical for consistent routing > state within the BGP routing system. To this end, there MUST be a > mechanism to ensure that changes to reachability that result in an > explicit or implicit withdrawal of reachability (RFC1771) are > propagated within the secured BGP routing system in a timely manner. > > I think this is a good statement, but you've not explained why this is > so important. Of course, it's important from the perspective of system > convergence, but there's another reason, as well. Perhaps something > like: > > "BGP is a stateful protocol; information received (and validated using > any given security mechanism) is assumed good until it is either > replaced with new information, or withdrawn from the routing > system. Assume some new event occurs which causes the routing > information propogated by a specific autonomous system within the > internetwork to change. If the routing information and the information > used to validate that routing information travel through the > internetwork at different rates, there are a number of places where > the security of the routing system may be compromised. For example: > > o If information is withdrawn, the route may be inappropriately used > between the time the withdraw is received and the information > validating the withdraw is received. > > o If the originating AS is changed, false routing information may be > injected between the time the new route is injected and the > information validating the new routing information is received. > > There are many other ways in which a differential between the speed of > disseminating the information validating routing information and the > routing information itself can be exploited to attack the routing > system on a temporary basis. Because of the possible attacks that > might be possible during differentials of routing and security > information, any security system designed to secure BGP MUST provide > for the distribution of security information at the same speed as the > distribution of changes in routing information. This would include: > > o The distribution of information about the keys used by individual > actors within the system, including the keys used by individual > autonomous systems to sign certificates and other objects. > > o The distribution of information about the autonomous system > authorized to advertise a given block of IP addresses (or an > address space). > > o The distribution of information about connectivity between > autonomous systems and autonomous system policies, if such > information is distributed within the security system. > > Thoughts on this wording? Again, very nice... Just one thought though. In a secured BGP system, if I "own" a prefix and I withdraw it from the routing table no one else should be able to readvertise it. So perhaps the false routing information rationale does not hang together very well? > > -- > > Two types of verification MAY be offered for the NLRI and the > AS_PATH: > > o Contents of the UPDATE message SHOULD be authenticated in > real-time as the UPDATE message is processed. > o The route information base MAY be authenticated periodically or in > an event driven manner by scanning the data and verifying the > originating AS and the verifiability of the AS-PATH list. > > 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. > > I'm not certain we need this section? It seems like this would be > covered, if anyplace, under the flexibility section before in the > document, where we discuss the ability to support local trust > levels. It seems, to me, that the decision to validate routing > information before or after installation actually bears on your local > decisions about trust for peers, etc. We may want to move the section but it seems that the point is pretty important. We need to clearly state the two alternatives and attempt to detail a preference. Anyone else have a thought on that? > > The originating AS of a prefix may occasionally need to be changed > either due to a re-assignment or a network transition. Any BGP > security mechanism MUST support the change of an originating AS for a > prefix within normal convergence times of the internetwork. > > I think we can drop this, if we reword the other section above on the > timeleness of security information within the system. Okay... But we need to clearly state it. Those darn vendors will take a mile if you give them an inch. This is important for operators. We already have enough barriers to doing business. > > -- > > 5.1 Address Allocation > > These two modes lead to a single common requirement: Any BGP Security > solution MUST support delegation of an address block of any size > regardless of its relationship to other address blocks to another > entity via verifiable means. > > I think, rather than explaining the modes of delegation, I'd just say > it's common use within the public Internet, and other large scale > internetworks, for these types of suballocation to occur, and provide > examples for each (?). > > An associated delegation criteria is the requirement to allow for > non-BGP IP end user implementations. As a result, all secured BGP > implementations MUST allow for the propagation of a prefix by more > than one originator AS. > > I think this requirement probably needs to be highlighted a bit more, > maybe, and probably give an example of why, or provide the number of > routes from a current view of the public Internet routing table with > this property. I am too saturated to put together a view of these. It should be possible with a Perl script to put one together though. I would be curious to see who is doing it. It has been a long time since I was on the customer end of things. > > -- > > 6. NLRI and Path Attribute Tracking > > .... > > The data generated by logging may be very large depending on the > number of peers, the number of prefixes received, the authentication > model used and routing policies. > > Path and NLRI attributes MUST be logged using a standard format. The > format must be scalable with the amount of data logged and the > frequency of log generation. The frequency of log generation should > be controllable by the operator. The logging mechanisms for the > tracked information MUST be standardized across all platforms. > Logging ability both on and off line is considered highly desirable. > > This text comes out of the blue, really. Is there actually a > requirement for logging? How does it relate to the path attribute > tracking considered in this section? It should probably be made into a > seperate section, really. There really is a need for tracking/logging in a commonly formatted, viewable, fashion. This is an important aspect of proper security. When the RFC for the mechanism itself comes out we will probably be better able to detail exactly what should be logged. At a minimum we need to log the prefix, the originator, whether they were secured etc... The fact that operators have to build this stuff from scratch to get the same results is a good indicator. The logging mechanisms may have some bearing on building a rudimentary sort of IDS into the secured protocol as well... Do you agree? _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Nov 30 17:55:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26452 for ; Tue, 30 Nov 2004 17:55:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGzd-0006C7-G6 for rpsec-web-archive@ietf.org; Tue, 30 Nov 2004 18:01:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGnd-0005N2-Qg; Tue, 30 Nov 2004 17:48:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGZt-0003Dp-IS for rpsec@megatron.ietf.org; Tue, 30 Nov 2004 17:34:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23795 for ; Tue, 30 Nov 2004 17:34:30 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGf5-0005Mf-I9 for rpsec@ietf.org; Tue, 30 Nov 2004 17:39:55 -0500 Received: from [208.231.75.212] ([208.231.75.212]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id iAUMXpan016472 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 30 Nov 2004 17:33:55 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 30 Nov 2004 17:33:43 -0500 From: Blaine Christian To: Radia Perlman , Tao Wan Message-ID: In-Reply-To: <41ACE3CB.9070007@sun.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org Subject: [RPSEC] FW: References on Trust Models 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Let's all switch over to rpsec@ietf.org... I have a very detailed set of email from both Steve and Russ (and will appl= y changes to the document as a result). With any luck I will be able to get = a revision of this document out this weekend. If you have something that mus= t change let me know! If you have comments or concerns about I also have a copy of a document titled SPV: Secure Path Vector Routing for Securing BGP if you are interested you should google it. ------ Forwarded Message From: Radia Perlman Date: Tue, 30 Nov 2004 13:19:07 -0800 To: Tao Wan Cc: Subject: Re: References on Trust Models I've also published on this. Here's a couple of references: Perlman, R. =B3An Overview of PKI Trust Models=B2, IEEE Network Magazine, November/December 1999. And also, Kaufman, C., Perlman, R., and Speciner, M., "Network Security: Private Communication in a Public World", (section 15.3 "PKI Trust Models") Tao Wan wrote: >As per Russ's request in his comments on the BGP security requirement doc, >here are some references on trust models in PKIs, which may be useful. > >1. C. Adams and S. Lloyd. "Understanding PKI: Concepts, Standards, and >Deployment Considerations, 2nd Edition". (Chapter 9: Trust Models) > >2. A. Menezes, P.C. van Oorschot, and S. Vanstone. "Handbook of Applied >Cryptography". (Chapter 13.6.2: Trust Models Involving Multiple >Certification Authorities) > >3. W.E. Burr. "PKI Architectures and Interoperability, A preliminary draft >discussion paper for the Federal PKI TWG". >http://csrc.nist.gov/pki/twg/Archive/y1998/papers/twg-98-8.pdf > >Thanks! > >Tao Wan >http://www.scs.carleton.ca/~twan > > > > =20 > ------ End of Forwarded Message _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec