From rpsec-bounces@ietf.org Tue Feb 1 13:33:04 2005 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 NAA04014 for ; Tue, 1 Feb 2005 13:33:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw37w-0001Nw-Up for rpsec-web-archive@ietf.org; Tue, 01 Feb 2005 13:51:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw2gQ-0006QQ-L0; Tue, 01 Feb 2005 13:23:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw2dG-0005cJ-66 for rpsec@megatron.ietf.org; Tue, 01 Feb 2005 13:20:10 -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 NAA02727 for ; Tue, 1 Feb 2005 13:20:07 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw2vS-00012R-Jg for rpsec@ietf.org; Tue, 01 Feb 2005 13:38:59 -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 j11IJXjf007767 for ; Tue, 1 Feb 2005 13:19:34 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Tue, 1 Feb 2005 13:19:27 -0500 To: rpsec@ietf.org From: Stephen Kent 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: 4b66a1e94d7d92973ece9e5da449ff80 Subject: [RPSEC] some thoughts on requirements 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: 36fb765c89ed47dab364ab702a78e8fd Folks, The discussion on BGP security requirements is again taking off without a detailed background and rationale discussion. The result is a set of proposed requirements that may not be comprehensive and which may be hard to motivate/justify. In the security community, we prefer to start by articulating security relevant assumptions a protocol or system seems to embody in its operation in a benign environment. This provides rationale for security requirements that one then ascribes to the protocol/system. Here are some thoughts on the sort of background and rationale I would propose for our security requirements document. Steve ------- Peer Communication 0. BGP traffic travels over TCP between peers, so BGP speakers assume the TCP data delivery guarantees that accrue in a benign environment. This includes ordered, error-free delivery of application traffic from a peer identified by an IP address, plus integrity of the control aspects of TCP. From a security perspective, these guarantees need to be enforced in the context of possible active wiretapping. Basic Application Concepts 1. BGP is a protocol used to convey routing (reachability) information among autonomous systems. [this suggests a focus on e-BGP vs. i-BGP. I think this is appropriate because it appears that the most severe routing security failure modes arise when ASes receive and process bogus UPDATE info across AS boundaries. Routing security problems within an AS are the problem of that AS and its subscribers, and these may arise due to intra-AS routing problems independent of i-BGP use.] 2. Inter-AS forwarding may not always be congruent with inter-AS routing, but the purpose of conveying BGP routing information from one AS to another is to influence inter-AS forwarding. [it's good to agree on intent in deciding what is and is not security relevant. The BGP spec says that a route advertised by a speaker is "used" by the speaker to forward the traffic specified by the advertisement. A corollary of this precept is that inserting a set of AS numbers in a route to cause the ASes in the set to ignore the route ought not be permitted. Also, because path length is a commonly used criteria in selecting from among routes for the same NLRI, we don't want a speaker to advertise a route that omits ASes, to make the route appear to be more preferable.] Semantics of UPDATE Messages 3. When AS A conveys a route to AS B via an UPDATE, AS A is soliciting traffic from AS B, consistent with the NLRI contained in the UPDATE. [if you do not want the traffic, why send the UPDATE to your peer?] 4. When AS A conveys a route to AS B via an UPDATE, AS A is implicitly authorizing AS B to forward the route to other ASes, unless AS A has included the NO_EXPORT community as part of the UPDATE. [NO-EXPORT is a well-known community with a well-defined semantics. If AS A does not want AS B to forward the route, then AS A should include the NO-EXPORT community attribute.] 5. An UPDATE message is not literally forwarded from one AS to another. However "transitive" path attributes in an UPDATE message are intended to be forwarded to subsequent ASes (modulo the restriction noted in #4 above), IF the receiving AS elects to forward the route contained in the UPDATE. [parts of an UPDATE, e.g., withdrawn routes, are local, but other parts are intended to be forwarded to other ASes. The spec appears to be sloppy in its use of terminology, saying that the UPDATE message itself has traversed the path; a reasonable interpretation of the text focuses on the transitive path attributes.] 6. The path contained in an UPDATE message represents the sequence of ASes that UPDATE messages associated with the NLRI traversed. [the BGP specs says this, but it is not clear how to interpret this in the case of AS sets resulting from path aggregation.] a. The first AS in the sequence should be the AS of the peer with which the BGP connection has been established. [the BGP spec describes UPDATE generation and calls for a speaker to prepend it's AS to the AS path when it generates an UPDATE.] b. An AS number may be appear multiple times in succession in an AS path. [the spec says this explicitly] c. An AS number must not appear more that once in an AS PATH, except as noted above. [this is stated I the spec as part of the route loop prevention strategy.] 7. The first AS in the AS path attribute of an UPDATE message represents the origin AS. The origin AS is the holder of the prefix(es) advertised in the NLRI in the UPDATE, or has been authorized by the prefix holders to originate the route in the UPDATE message. [BGP does not specify precise conditions under which routes may be originated, nor does it address the infrastructure associated with prefix allocation. However, it seems reasonable to assert that the origin AS is authorized to advertise the prefixes, else we are condoning bogus advertisements of origin ASes, and black-holing.] 8. UPDATE messages, and the transitive attributes contained therein, carry no timestamps or sequencing numbers. Moreover, there is no notion of an advertisement "timing out." [this is derived from the BGP spec.] Thus, there is no way for an AS receiving an UPDATE to determine if the path attributes used to create the UPDATE are "fresh." This implies that an AS can retain attributes from an "old" UPDATE and use it an advertisement at any later point in time. Combined with the limitations on withdrawal processing noted below, this suggests that an AS can re-advertise a withdrawn route that was previously, legitimately advertised by the AS. Route Withdrawal & BGP Limitations 9. A route can be withdrawn only the by the peer who advertised it. [this is implied by the Adj-RIB-In part of the processing model.] 10. An AS may withdraw a route because it learns a "better" route from a peer, or because a link to a peer fails, or because of a change to local policy. [this is specified in part by the spec.] Thus an AS receiving a route withdrawal in an UPDATE must accept it at face value, i.e., there is no way for a receiver to verify the criteria used by the sender in deciding to withdraw a route. [an AS can decide to withdraw a route for reasons for which there will be no externally visible evidence, because of the role played by the PIB in selection of a best route. Since an AS may advertise different routes to different peers, even external examination of advertisements for consistency does not represent a way to determine whether a withdrawal was "intentional" or the result of an attack or an error internal to an AS.] 11. Because route withdrawal is a local aspect of an UPDATE, and because of the role of the PIB in determining best routes, there is no way to ensure that withdrawal of a route by an AS propagates through a peer to other ASes. To detect an erroneous failure of an AS to propagate route withdrawal would require an oracle capability by other ASes. (For example, these ASes would have to know when an AS more than one hop away withdrew a route, would have to know the topology of the Internet, and would have to know the PIB contents for intervening ASes in order to determine that a route withdrawal failed to propagate properly.) [the oracle capability does not seem to be one we should assume, for practical reasons. If we assume it, then it would solve many if not all of the security concerns that arise, and we should focus only creating that capability. Otherwise, we have to give up on being able to rely on propagation of withdrawals.] Aggregation 12. If a BGP speaker advertises a route based UPDATE messages (with the same next hop) containing more and less specific prefixes, then it may choose to advertise an aggregated route containing only the less specific prefix. If this aggregated route does not contain all of the ASes from the constituent routes, the ATOMIC_AGGREGATE SHOULD be set. This represents an explicitly allowed deviation from the usual concept of forwarded traffic traversing only the ASes enumerated in the path. [this process is described in the BGP spec, but since the spec says that inclusion of ATOMIC is now informational, it seems to weaken the principle of forwarding being congruent to the advertised path in general (since we can't even know if a route was purportedly the result of aggregation. This probably warrants changes to the BGP text by IDR, to make the standard more internally consistent. From a security perspective this says that we cannot mandate simple matching of a path in an UPDATE to any graph if aggregation has been performed. Moreover, because of the loophole created by the fact that a speaker need not even declare that it has performed aggregation, this makes it hard to know when deviation from a graph is potentially valid. One can imagine ways to avoid these problems, e.g., by having speakers NOT delete ASes when performing aggregation in this fashion, but the current BGP text is awfully "flexible" here :.] 13. If a BGP speaker sends an UPDATE message with a route that is the result of aggregating routes received from peers via UPDATE messages, the resulting route must preserve the AS SEQUENCE and SET ordering of the constituent routes. The aggregated route also must not omit any of the ASes or AS SETs from the routes used to construct it, and must not duplicate these route elements. (there are lots of other prohibitions on aggregation here, e.g., not aggregating routes with different MEDs. A more through discussion of aggregation is needed to cover this topic comprehensively and more clearly.) [the BGP spec provides rules for how to construct such aggregated routes, separate from the discussion of route aggregation in the context of overlapping routes. This part of the spec provides another justification for emitting an UPDATE message that contains path attributes that are not just the result of prepending one's own AS number to a route received via an UPDATE.] Route Origination 14. Originating a route for a prefix for which the speaker has no ability to forward traffic would conflict with the basic BGP principle noted earlier, i.e., routes represent how a speaker forwards traffic. So it is important to provide means to detect and reject routes that fail in this regard. 15. A BGP speaker may originate a route based on other sources of data, specifically routes received via IGP and via local configuration. [the BGP spec calls out the first example, but the second example seems obvious. However, the spec says nothing about criteria to be applied when originating a route from local configuration data.] 16. A BGP should originate routes for a prefix only if the prefix has been allocated to its AS, or that its AS has been authorized to advertise the prefix by the prefix holder. [obviously if an AS has bee allocated a prefix, it is authorized to originate it. If the prefix holder becomes a subscriber of the AS, then the AS is authorized to advertise that prefix as well. None of this is explicitly stated in the BGP spec, but it seems derivable from the explicitly stated concept that routes represent how an AS forwards traffic. An aspect of this proposed requirement that is debatable is whether an AS should be allowed to originate a route that represents an implicit form of aggregation, e.g., the prefixes are NOT held by the AS or by subscribers, but rather represent the AS's view of the topology behind it Communities 17. ??? 18. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 1 15:45:06 2005 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 PAA17554 for ; Tue, 1 Feb 2005 15:45:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw5Bm-0004lM-Hx for rpsec-web-archive@ietf.org; Tue, 01 Feb 2005 16:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw4qr-0000g6-Ai; Tue, 01 Feb 2005 15:42:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw4k3-0005KZ-2U for rpsec@megatron.ietf.org; Tue, 01 Feb 2005 15:35:19 -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 PAA16576 for ; Tue, 1 Feb 2005 15:35:16 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw52G-0004Nk-49 for rpsec@ietf.org; Tue, 01 Feb 2005 15:54:09 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j11KZF84007030 for ; Tue, 1 Feb 2005 15:35:15 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAAGHaynn; Tue Feb 1 15:35:05 2005 Date: Tue, 1 Feb 2005 15:35:05 -0500 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [RPSEC] Use and semantics of AS_PATH, etc 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: 9ed51c9d1356100bce94f1ae4ec616a9 Taking off from some discussion on and off the list, I'd like to hear, hopefully from the operational community directly, how various components w/in BGP are used. For instance, Alex Zinin suggested to me some questions and elaboration for which I think "AS_PATH" could be replaced also by "Communities", for instance: ++> 1. Exactly why people want secure AS_PATH ++> 2. How AS_PATH can be secured ++> 3. What exactly secured AS_PATH gives us ++> ++> Point 1 should go beyond "this is how BGP works", since BGP ++> mechanisms (like putting local ASn in the AS_PATH) are the means ++> of achieving certain protocol behavior (e.g. loop-freeness) and ++> information collection (e.g. for debugging flapping routes), ++> rather then self-contained objectives. In other words, BGP is not ++> a route propagation tracking tool. ++> ++> Point 2 should give us the answer on what type of security ++> mechanisms are applicable to the AS_PATH given how BGP speakers ++> manipulate this attribute. E.g., signing at each BGP peer, or ++> whether we can secure ASn deletion, etc. ++> ++> Point 3 should answer the question "ok, the AS_PATH I received ++> passed the security check, what can I tell based on this now?". ++> Part of it will be analyzing how AS_PATH security plays together ++> with the basic BGP behavior. Finally, we should be able to go ++> back to question 1 and say if we can satisfy those requirements. My hope (and Alex's, I think) is to stimulate thought and discussion about: - How these things are used - How they could be abused - The costs of mitigating those risks Discuss. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 03:48:50 2005 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 DAA17138 for ; Wed, 2 Feb 2005 03:48:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwGUH-00007J-01 for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 04:07:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwG9b-0005LG-Fg; Wed, 02 Feb 2005 03:46:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwG4W-0003z2-BB for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 03:41:12 -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 DAA16351 for ; Wed, 2 Feb 2005 03:41:10 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.204] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwGMp-0008DG-Is for rpsec@ietf.org; Wed, 02 Feb 2005 04:00:08 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CwG4N-0000G1-4s; Wed, 02 Feb 2005 09:41:03 +0100 Message-ID: <42009220.6080602@schlund.net> Date: Wed, 02 Feb 2005 09:41:04 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0355818969==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0355818969== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig20CCFD98243149EA39FB7E29" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig20CCFD98243149EA39FB7E29 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Stephen, for me this looks like a good start... Stephen Kent wrote: > 4. When AS A conveys a route to AS B via an UPDATE, AS A is > implicitly authorizing AS B to forward the route to other ASes, unless > AS A has included the NO_EXPORT community as part of the UPDATE. > [NO-EXPORT is a well-known community with a well-defined semantics. If > AS A does not want AS B to forward the route, then AS A should include > the NO-EXPORT community attribute.] for me this is too broad: when I announce a route to a customer, I do not give the authorization to forward it to any other ASes, but only to customer ASes. > 16. A BGP should originate routes for a prefix only if the prefix has > been allocated to its AS, or that its AS has been authorized to is a prefix ever allocated to an AS? AFAIK it's allocated to a LIR which may be operating an AS or not. tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig20CCFD98243149EA39FB7E29 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAJIgehvPYvDU0roRAsBZAJ0WoqmIvK+BHOwg84pCaTd9Cky4owCfZQyZ Qeubl5veGGaoTazDX8wAFbQ= =9yRi -----END PGP SIGNATURE----- --------------enig20CCFD98243149EA39FB7E29-- --===============0355818969== 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 --===============0355818969==-- From rpsec-bounces@ietf.org Wed Feb 2 09:54:43 2005 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 JAA11143 for ; Wed, 2 Feb 2005 09:54:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMCR-0001GN-F9 for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 10:13:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLiQ-00007i-Jy; Wed, 02 Feb 2005 09:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLeL-0006ks-3g for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 09:38: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 JAA09259 for ; Wed, 2 Feb 2005 09:38:28 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLwh-0000gw-2J for rpsec@ietf.org; Wed, 02 Feb 2005 09:57:32 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j12EcMfA002913; Wed, 2 Feb 2005 09:38:22 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAA5.a46e; Wed Feb 2 09:38:10 2005 Date: Wed, 2 Feb 2005 09:38:10 -0500 From: Tony Tauber To: Stefan Mink Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: <42009220.6080602@schlund.net> Message-ID: References: <42009220.6080602@schlund.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da [ Writing not as WG co-chair, but as a longtime carrier BGP operator, now edge BGP operator ] > Hi Stephen, > > for me this looks like a good start... > > Stephen Kent wrote: > > 4. When AS A conveys a route to AS B via an UPDATE, AS A is > > implicitly authorizing AS B to forward the route to other ASes, > > unless AS A has included the NO_EXPORT community as part of the > > UPDATE. [NO-EXPORT is a well-known community with a well-defined > > semantics. If AS A does not want AS B to forward the route, then > > AS A should include the NO-EXPORT community attribute.] > > for me this is too broad: when I announce a route to a customer, I > do not give the authorization to forward it to any other ASes, but > only to customer ASes. Good clarification which points to something not within the base BGP spec but well cemented w/in operational practice. Most ISPs have defined community values for use by customers which can produce this kind of effect. This feature is part of the fairly rich policy language of BGP that is so treasured by its users. I've known of significant use also of tagging routes inbound from another AS in some way to influence behavior. If this approach is used with prior consent, it changes the implicit expectations. That is the receiving AS may be applying a policy on the sender's behalf with the sender having the expectation that that policy will be in force. How about this alternate text: ++ > 4. When AS A conveys a route to AS B via an UPDATE, AS A is ++ > implicitly authorizing AS B to forward the route to other ASes. ++ > Exceptions to this convention may be derived by tagging the ++ > UPDATE with either a well-known community value such as NO_EXPORT ++ > or another value which may have been locally agreed upon to ++ > limit or affect re-announcement in some way. Alternately, this ++ > policy can be effected by the receiving AS either unilaterally or ++ > by prior agreement with AS A. > > 16. A BGP should originate routes for a prefix only if the > > prefix has been allocated to its AS, or that its AS has been > > authorized to > > is a prefix ever allocated to an AS? AFAIK it's allocated to a LIR > which may be operating an AS or not. Another good point, as is becoming clear, there is inconsistent congruence between the delegation structure and the BGP structure. How this fact interacts with the problem at hand is a matter for our attention and comment at the very least. Tony > > tschuess > Stefan _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 10:55:08 2005 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 KAA20250 for ; Wed, 2 Feb 2005 10:55:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwN8v-0003LI-6V for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 11:14:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMig-0008Qe-C8; Wed, 02 Feb 2005 10:47:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMej-00077O-CX for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 10:43: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 KAA18648 for ; Wed, 2 Feb 2005 10:42:57 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.204] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwMx6-0002uD-Fa for rpsec@ietf.org; Wed, 02 Feb 2005 11:02:01 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CwMed-0006MA-VC; Wed, 02 Feb 2005 16:42:56 +0100 Message-ID: <4200F501.7060100@schlund.net> Date: Wed, 02 Feb 2005 16:42:57 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Tauber Subject: Re: [RPSEC] some thoughts on requirements References: <42009220.6080602@schlund.net> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0542072572==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0542072572== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBFB36BD0790E008D9972A259" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBFB36BD0790E008D9972A259 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tony, Tony Tauber wrote: > How about this alternate text: > > ++ > 4. When AS A conveys a route to AS B via an UPDATE, AS A is > ++ > implicitly authorizing AS B to forward the route to other ASes. > ++ > Exceptions to this convention may be derived by tagging the > ++ > UPDATE with either a well-known community value such as NO_EXPORT > ++ > or another value which may have been locally agreed upon to > ++ > limit or affect re-announcement in some way. Alternately, this > ++ > policy can be effected by the receiving AS either unilaterally or > ++ > by prior agreement with AS A. perfect! tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigBFB36BD0790E008D9972A259 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAPUBehvPYvDU0roRAhQBAJ4rfz+k943z+7dVKVv02s9LIHqwpwCg1Uwb dhSh9CDCOkfLyqDnro24Wrk= =Hcdw -----END PGP SIGNATURE----- --------------enigBFB36BD0790E008D9972A259-- --===============0542072572== 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 --===============0542072572==-- From rpsec-bounces@ietf.org Wed Feb 2 11:05:55 2005 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 LAA21260 for ; Wed, 2 Feb 2005 11:05:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNJL-0003gv-8V for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 11:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMrs-0003J2-3i; Wed, 02 Feb 2005 10:56:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwMjl-0000FG-Ox for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 10:48:14 -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 KAA19268 for ; Wed, 2 Feb 2005 10:48:09 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwN29-00034v-40 for rpsec@ietf.org; Wed, 02 Feb 2005 11:07:14 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2005 10:57:43 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-356.cisco.com [10.82.225.100]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j12FlcQM004924; Wed, 2 Feb 2005 10:47:38 -0500 (EST) Date: Wed, 2 Feb 2005 10:47:02 -0500 (Eastern Standard Time) From: Russ White To: Tony Tauber Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: <42009220.6080602@schlund.net> 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: 8abaac9e10c826e8252866cbe6766464 Cc: Stefan Mink , Stephen Kent , rpsec@ietf.org 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f > ++ > 4. When AS A conveys a route to AS B via an UPDATE, AS A is > ++ > implicitly authorizing AS B to forward the route to other ASes. > ++ > Exceptions to this convention may be derived by tagging the > ++ > UPDATE with either a well-known community value such as NO_EXPORT > ++ > or another value which may have been locally agreed upon to > ++ > limit or affect re-announcement in some way. Alternately, this > ++ > policy can be effected by the receiving AS either unilaterally or > ++ > by prior agreement with AS A. I don't quite understand: When you say an AS "implicitely authorizes the advertisement of the routing information," could you explain what you mean? Authorization carries with it the concept of being authorized to do something. What is it you're authorizing? What you're discussing here is policy--it is either the advertiser's policy to allow transit through them, or to them through the peer they've advertised the route to, or it's not their policy. There's no concept of "authorization" here, and we should do our best to leave the concept of "authorization" out of this. You can verify or validate an AS has authorization to originate a specific route, but BGP has no concept of "authorization to readvertise something I've received." The entire concept is in terms of policy, so let's stick to policy, which is the correct term. :-) 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 Wed Feb 2 11:44:43 2005 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 LAA26521 for ; Wed, 2 Feb 2005 11:44:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNuv-000540-7L for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 12:03:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNQd-000641-KK; Wed, 02 Feb 2005 11:32:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNOG-0004y1-GR for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 11:30:04 -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 LAA24480 for ; Wed, 2 Feb 2005 11:29:59 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNge-0004Wk-0S for rpsec@ietf.org; Wed, 02 Feb 2005 11:49:05 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j12GSlmh004592; Wed, 2 Feb 2005 11:28:47 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAAC.aOGi; Wed Feb 2 11:28:34 2005 Date: Wed, 2 Feb 2005 11:28:34 -0500 From: Tony Tauber To: Russ White Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: <42009220.6080602@schlund.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Stefan Mink , Stephen Kent , 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: 8b431ad66d60be2d47c7bfeb879db82c On Wed, 2 Feb 2005, Russ White wrote: > > ++ > 4. When AS A conveys a route to AS B via an UPDATE, AS A is > > ++ > implicitly authorizing AS B to forward the route to other > > ++ > ASes. Exceptions to this convention may be derived by > > ++ > tagging the UPDATE with either a well-known community value > > ++ > such as NO_EXPORT or another value which may have been > > ++ > locally agreed upon to limit or affect re-announcement in > > ++ > some way. Alternately, this policy can be effected by the > > ++ > receiving AS either unilaterally or by prior agreement with > > ++ > AS A. > > I don't quite understand: When you say an AS "implicitely authorizes > the advertisement of the routing information," could you explain > what you mean? Authorization carries with it the concept of being > authorized to do something. What is it you're authorizing? Well, what it says is "authoriz[ing] AS B to forward the route to other ASes." That is, authorizing AS B to propagate the routing information further. I'm not married to the idea if it's not right, but I thought I'd pose some wording. > What you're discussing here is policy--it is either the advertiser's > policy to allow transit through them, or to them through the peer > they've advertised the route to, or it's not their policy. OK, but the default policy (ie. the implicit policy) is to allow the AS you send the route to to propagate it further, thereby drawing traffic through them from beyond (transiting AS B). Absent other configuration, I believe that's how it works. > There's no concept of "authorization" here, and we should do our > best to leave the concept of "authorization" out of this. I don't know what extra flavor it gives, but OK. > You can verify or validate an AS has authorization to originate a > specific route, but BGP has no concept of "authorization to > readvertise something I've received." The entire concept is in terms > of policy, so let's stick to policy, which is the correct term. So, absent some other expression of policy, the default behavior and the methods of expressing the policy are currently as described? What text would be better? Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 12:29:59 2005 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 MAA02504 for ; Wed, 2 Feb 2005 12:29:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwOci-0006eD-HV for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 12:49:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwOFM-0000P9-CP; Wed, 02 Feb 2005 12:24:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwOAK-0006LD-Tw for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 12:19: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 MAA01159 for ; Wed, 2 Feb 2005 12:19:39 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwOSg-0006C7-CU for rpsec@ietf.org; Wed, 02 Feb 2005 12:38:46 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2005 12:19:08 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-356.cisco.com [10.82.225.100]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j12HJ5QM003035; Wed, 2 Feb 2005 12:19:06 -0500 (EST) Date: Wed, 2 Feb 2005 12:18:30 -0500 (Eastern Standard Time) From: Russ White To: Tony Tauber Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: <42009220.6080602@schlund.net> 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: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Stefan Mink , Stephen Kent , rpsec@ietf.org 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: 287c806b254c6353fcb09ee0e53bbc5e >>> ++ > 4. When AS A conveys a route to AS B via an UPDATE, AS A is >>> ++ > implicitly authorizing AS B to forward the route to other >>> ++ > ASes. Exceptions to this convention may be derived by >>> ++ > tagging the UPDATE with either a well-known community value >>> ++ > such as NO_EXPORT or another value which may have been >>> ++ > locally agreed upon to limit or affect re-announcement in >>> ++ > some way. Alternately, this policy can be effected by the >>> ++ > receiving AS either unilaterally or by prior agreement with >>> ++ > AS A. >> >> I don't quite understand: When you say an AS "implicitely authorizes >> the advertisement of the routing information," could you explain >> what you mean? Authorization carries with it the concept of being >> authorized to do something. What is it you're authorizing? > > Well, what it says is "authoriz[ing] AS B to forward the route to other > ASes." That is, authorizing AS B to propagate the routing information > further. I'm not married to the idea if it's not right, but I thought > I'd pose some wording. Do you mean authorizing the advertisement of reachability information to a peer's peers? >> What you're discussing here is policy--it is either the advertiser's >> policy to allow transit through them, or to them through the peer >> they've advertised the route to, or it's not their policy. > > OK, but the default policy (ie. the implicit policy) is to allow the AS > you send the route to to propagate it further, thereby drawing traffic > through them from beyond (transiting AS B). Absent other configuration, I > believe that's how it works. But now you're trying the advertising of routing information (reachability) to forwarding, which brings us back to the forwarding conundrum. If I can't prevent someone from forwarding traffic to me along a certain path, implying I can't "!authorize" them to forward traffic along that path, then what does the concept of "authorization" mean. This is specifically why we shouldn't use the term "authorization" in this context. It opens too many ratholes and problems we just don't want to get in to (unless we want to go into requiring routers to modify their current routing/forwarding behaviour, which would be a larger issue than what I think we're scoped to handle here). >> There's no concept of "authorization" here, and we should do our >> best to leave the concept of "authorization" out of this. > > I don't know what extra flavor it gives, but OK. That you can prevent it from happening if you don't "authorize" it. >> You can verify or validate an AS has authorization to originate a >> specific route, but BGP has no concept of "authorization to >> readvertise something I've received." The entire concept is in terms >> of policy, so let's stick to policy, which is the correct term. > > So, absent some other expression of policy, the default behavior and the > methods of expressing the policy are currently as described? What text > would be better? I'm sticking with the wording I posted to the list several days ago... -- o Routing information carried through BGP SHOULD include information which can be used to verify readvertisement or modification by each autonomous system through which the route has passed. o A BGP speaker MUST, on receiving a route from a peer, be able to verify the AS Path, beginning with the first AS listed in the AS Path, progressing through each AS listed in the AS Path, and ending in the autonomous system advertising the route to the receiving speaker, is a valid route within the internetwork. (Where valid means the AS Path matches a set of pairwise peering relationships that can be shown to exist in the internetwork, and the policy of each AS listed in the path permits the transiting of traffic through the AS). o A BGP speaker MUST, on receiving a route from a peer, be able to verify the originating AS has authorization to advertise the prefix contained in the route. -- Note that none of this is in terms of traffic, or forwarding, or "authorization," at all. I originally implied the policy in the second one above, but you could call out policy separately, if you wanted to. We can discuss the "MUST" or "SHOULD" state of each one: o A BGP speaker [SHOULD/MUST], on receiving a route from a peer, be able to verify the originating AS' policy in regards to transiting traffic through the advertising speaker's AS or the local AS. o A BGP speaker [SHOULD/MUST], on receiving a route from a peer, be able to verify the advertising AS' policy in regards to transiting traffic through the local AS. :-) 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 Wed Feb 2 13:41:51 2005 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 NAA12227 for ; Wed, 2 Feb 2005 13:41:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwPkG-0000zf-AF for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 14:00:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwPLv-00050e-6a; Wed, 02 Feb 2005 13:35:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwPEL-0002ap-TY for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 13:27:58 -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 NAA10179 for ; Wed, 2 Feb 2005 13:27:52 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwPWl-0000OP-Bv for rpsec@ietf.org; Wed, 02 Feb 2005 13:46:59 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j12IRgKP027535; Wed, 2 Feb 2005 13:27:42 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAAnKaan1; Wed Feb 2 13:27:35 2005 Date: Wed, 2 Feb 2005 13:27:35 -0500 From: Tony Tauber To: Russ White Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: <42009220.6080602@schlund.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Stefan Mink , Stephen Kent , 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: 944ecb6e61f753561f559a497458fb4f On Wed, 2 Feb 2005, Russ White wrote: > > > Well, what it says is "authoriz[ing] AS B to forward the route to > > other ASes." That is, authorizing AS B to propagate the routing > > information further. I'm not married to the idea if it's not > > right, but I thought I'd pose some wording. > > Do you mean authorizing the advertisement of reachability > information to a peer's peers? Yes. > > OK, but the default policy (ie. the implicit policy) is to allow > > the AS you send the route to to propagate it further, thereby > > drawing traffic through them from beyond (transiting AS B). Absent > > other configuration, I believe that's how it works. > > But now you're trying the advertising of routing information > (reachability) to forwarding, which brings us back to the forwarding > conundrum. If I can't prevent someone from forwarding traffic to me > along a certain path, implying I can't "!authorize" them to forward > traffic along that path, then what does the concept of > "authorization" mean. > > This is specifically why we shouldn't use the term "authorization" > in this context. It opens too many ratholes and problems we just > don't want to get in to (unless we want to go into requiring routers > to modify their current routing/forwarding behaviour, which would be > a larger issue than what I think we're scoped to handle here). OK, with forwarding/routing, but regarding the propagation of the reachability info, the default behavior is that it can go further than the neighbor AS, ie. it's implicit. > >> There's no concept of "authorization" here, and we should do our > >> best to leave the concept of "authorization" out of this. > > > > I don't know what extra flavor it gives, but OK. > > That you can prevent it from happening if you don't "authorize" it. Well, I believe (and others should chime in right here), that strengthening the policy enforcement might be a goal of securing BGP (or not, but others should make some indication.) > > So, absent some other expression of policy, the default behavior > > and the methods of expressing the policy are currently as > > described? What text would be better? > > I'm sticking with the wording I posted to the list several days ago... > > -- > > o Routing information carried through BGP SHOULD include information > which can be used to verify readvertisement or modification by each > autonomous system through which the route has passed. > > o A BGP speaker MUST, on receiving a route from a peer, be able to > verify the AS Path, beginning with the first AS listed in the AS > Path, progressing through each AS listed in the AS Path, and ending > in the autonomous system advertising the route to the receiving > speaker, is a valid route within the internetwork. > > (Where valid means the AS Path matches a set of pairwise peering > relationships that can be shown to exist in the internetwork, and the > policy of each AS listed in the path permits the transiting of traffic > through the AS). > > o A BGP speaker MUST, on receiving a route from a peer, be able to > verify the originating AS has authorization to advertise the prefix > contained in the route. > > -- Well, what I was commenting on was what Steve sent (and Stephan commented upon) which was an attempt to expose the "motives" behind the requirements. (Would these motives be included in the requirements doc as a precursor to the requirements section?) I think trying to derive these has merit. I recollect Steve commenting at the last RPSEC meeting that the document didn't provide enough in the way of "motivation" for the requirements and expect his strawman text was an effort to get things rolling. All that seems like an especially good place to get Operator input. Tony > Note that none of this is in terms of traffic, or forwarding, or > "authorization," at all. I originally implied the policy in the > second one above, but you could call out policy separately, if you > wanted to. We can discuss the "MUST" or "SHOULD" state of each one: > > o A BGP speaker [SHOULD/MUST], on receiving a route from a peer, > be able to verify the originating AS' policy in regards to > transiting traffic through the advertising speaker's AS or the > local AS. > > o A BGP speaker [SHOULD/MUST], on receiving a route from a peer, > be able to verify the advertising AS' policy in regards to > transiting traffic through the local AS. > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 14:13:52 2005 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 OAA15745 for ; Wed, 2 Feb 2005 14:13:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQFF-00020d-4O for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 14:32:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwPsU-0008Dv-K2; Wed, 02 Feb 2005 14:09:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwPp9-0006or-0f for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 14:05: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 OAA14828 for ; Wed, 2 Feb 2005 14:05:55 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQ7X-0001k1-1H for rpsec@ietf.org; Wed, 02 Feb 2005 14:25:01 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2005 14:05:26 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-356.cisco.com [10.82.225.100]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j12J5Mja017667; Wed, 2 Feb 2005 14:05:23 -0500 (EST) Date: Wed, 2 Feb 2005 14:04:43 -0500 (Eastern Standard Time) From: Russ White To: Tony Tauber Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: <42009220.6080602@schlund.net> 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: 4d87d2aa806f79fed918a62e834505ca Cc: Stefan Mink , Stephen Kent , rpsec@ietf.org 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 >>> Well, what it says is "authoriz[ing] AS B to forward the route to >>> other ASes." That is, authorizing AS B to propagate the routing >>> information further. I'm not married to the idea if it's not >>> right, but I thought I'd pose some wording. >> >> Do you mean authorizing the advertisement of reachability >> information to a peer's peers? > > Yes. To what end? Authorizing the advertisement of routing information to your peer's peers isn't a requirement. When you explain _why_ you want this, you've hit the requirement. On the other side, stating that this is somehow "implicit" in BGP is simply untrue. > OK, with forwarding/routing, but regarding the propagation of the > reachability info, the default behavior is that it can go further than > the neighbor AS, ie. it's implicit. That's the default policy, but it's not "authorization." >> That you can prevent it from happening if you don't "authorize" it. > > Well, I believe (and others should chime in right here), that > strengthening the policy enforcement might be a goal of securing BGP (or > not, but others should make some indication.) To change this, you're going to need to change more than BGP. You're going to have to change the basic requirements for routers, and I believe that when you get into that discussion, what you're going to find is that everyone wants you to change these requirements for everyone else, but not for them. I also happen to think that discussion would be outside the scope of the RPsec working group, since it impact a lot of other areas than even routing protocols. > Well, what I was commenting on was what Steve sent (and Stephan commented > upon) which was an attempt to expose the "motives" behind the > requirements. (Would these motives be included in the requirements doc > as a precursor to the requirements section?) I don't agree with stating there's an "implicit authorization" anyplace in BGP. I've worked on BGP for years, and never heard of such an "implicit authorization," nor has anyone I know ever treated it that way. It is often described in terms of policy, but never authorization. :-) 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 Wed Feb 2 14:51:52 2005 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 OAA20290 for ; Wed, 2 Feb 2005 14:51:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQq1-0003N0-HP for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 15:10:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQOf-0000Bi-VA; Wed, 02 Feb 2005 14:42:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQMO-0007RA-VV for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 14:40:23 -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 OAA18790 for ; Wed, 2 Feb 2005 14:40:17 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQeo-0002tl-8M for rpsec@ietf.org; Wed, 02 Feb 2005 14:59:23 -0500 Received: from [198.202.64.63] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j12Jdcjl006835; Wed, 2 Feb 2005 14:39:45 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <42009220.6080602@schlund.net> References: <42009220.6080602@schlund.net> Date: Wed, 2 Feb 2005 14:06:45 -0500 To: Stefan Mink From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 At 9:41 AM +0100 2/2/05, Stefan Mink wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="------------enig20CCFD98243149EA39FB7E29" > > >Hi Stephen, > >for me this looks like a good start... > >Stephen Kent wrote: >>4. When AS A conveys a route to AS B via an UPDATE, AS A is >>implicitly authorizing AS B to forward the route to other ASes, >>unless AS A has included the NO_EXPORT community as part of the >>UPDATE. [NO-EXPORT is a well-known community with a well-defined >>semantics. If AS A does not want AS B to forward the route, then AS >>A should include the NO-EXPORT community attribute.] > >for me this is too broad: when I announce a route to a customer, >I do not give the authorization to forward it to any other >ASes, but only to customer ASes. I see that Tony made the same observation, but an examination of the BGP specs does not give any indication of this constraint as part of the protocol. how does one define "customer ASes" in an objective fashion? > >>16. A BGP should originate routes for a prefix only if the >>prefix has been allocated to its AS, or that its AS has been >>authorized to > >is a prefix ever allocated to an AS? AFAIK it's allocated to a LIR >which may be operating an AS or not. Good point. prefixes are allocated to organizations, and organizations may operate ASes, or may be subscribers. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 14:52:31 2005 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 OAA20386 for ; Wed, 2 Feb 2005 14:52:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQqf-0003OV-CN for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 15:11:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQOg-0000C5-Cn; Wed, 02 Feb 2005 14:42:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQMQ-0007RC-Gc for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 14:40:23 -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 OAA18796 for ; Wed, 2 Feb 2005 14:40:18 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQeq-0002tn-RU for rpsec@ietf.org; Wed, 02 Feb 2005 14:59:25 -0500 Received: from [198.202.64.63] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j12Jdcjp006835; Wed, 2 Feb 2005 14:39:50 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <42009220.6080602@schlund.net> Date: Wed, 2 Feb 2005 14:28:50 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 97adf591118a232206bdb5a27b217034 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d At 10:47 AM -0500 2/2/05, Russ White wrote: >>++ > 4. When AS A conveys a route to AS B via an UPDATE, AS A is >>++ > implicitly authorizing AS B to forward the route to other ASes. >>++ > Exceptions to this convention may be derived by tagging the >>++ > UPDATE with either a well-known community value such as NO_EXPORT >>++ > or another value which may have been locally agreed upon to >>++ > limit or affect re-announcement in some way. Alternately, this >>++ > policy can be effected by the receiving AS either unilaterally or >>++ > by prior agreement with AS A. > >I don't quite understand: When you say an AS "implicitely authorizes >the advertisement of the routing information," could you explain >what you mean? Authorization carries with it the concept of being >authorized to do something. What is it you're authorizing? The text says that the authorization in question is permission to forward the route to other ASes. >What you're discussing here is policy--it is either the advertiser's >policy to allow transit through them, or to them through the peer >they've advertised the route to, or it's not their policy. There's >no concept of "authorization" here, and we should do our best to >leave the concept of "authorization" out of this. > >You can verify or validate an AS has authorization to originate a >specific route, but BGP has no concept of "authorization to >readvertise something I've received." The entire concept is in terms >of policy, so let's stick to policy, which is the correct term. We'vge disagreed about this before and no amount of discussion between us seems likely to change that. I'll rely on the rest of the WG to decide whether the terminology is appropriate or not. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 14:53:13 2005 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 OAA20471 for ; Wed, 2 Feb 2005 14:53:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQrM-0003Pr-2x for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 15:12:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQOg-0000CI-PW; Wed, 02 Feb 2005 14:42:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQMb-0007Yf-Rs for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 14:40:34 -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 OAA18804 for ; Wed, 2 Feb 2005 14:40:30 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQf2-0002tw-2q for rpsec@ietf.org; Wed, 02 Feb 2005 14:59:36 -0500 Received: from [198.202.64.63] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j12Jdcjn006835; Wed, 2 Feb 2005 14:39:48 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <42009220.6080602@schlund.net> Date: Wed, 2 Feb 2005 14:28:58 -0500 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Tony, > > >How about this alternate text: > >++ > 4. When AS A conveys a route to AS B via an UPDATE, AS A is >++ > implicitly authorizing AS B to forward the route to other ASes. >++ > Exceptions to this convention may be derived by tagging the >++ > UPDATE with either a well-known community value such as NO_EXPORT >++ > or another value which may have been locally agreed upon to >++ > limit or affect re-announcement in some way. Alternately, this >++ > policy can be effected by the receiving AS either unilaterally or >++ > by prior agreement with AS A. The last part sentence is a bit confusing to me, since the focus of the original #4 was to describe the intent of an advertisement from A to B. Unilateral actions by B re interpreting an advertisement don't help much from a security perspective. Can you elaborate? > >> > 16. A BGP should originate routes for a prefix only if the >> > prefix has been allocated to its AS, or that its AS has been >> > authorized to >> >> is a prefix ever allocated to an AS? AFAIK it's allocated to a LIR >> which may be operating an AS or not. > >Another good point, as is becoming clear, there is inconsistent >congruence between the delegation structure and the BGP structure. >How this fact interacts with the problem at hand is a matter for our >attention and comment at the very least. I though this was a simple terminology fix. Is the text in my response not sufficient? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 14:54:19 2005 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 OAA20624 for ; Wed, 2 Feb 2005 14:54:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQsN-0003TS-8j for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 15:13:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQOr-0000GH-BO; Wed, 02 Feb 2005 14:42:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQNQ-00083I-DH for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 14:41:24 -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 OAA18966 for ; Wed, 2 Feb 2005 14:41:20 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQfq-0002uv-N5 for rpsec@ietf.org; Wed, 02 Feb 2005 15:00:27 -0500 Received: from [198.202.64.63] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j12Jdcjr006835; Wed, 2 Feb 2005 14:39:52 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <42009220.6080602@schlund.net> Date: Wed, 2 Feb 2005 14:28:41 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Russ, >But now you're trying the advertising of routing information >(reachability) to forwarding, which brings us back to the forwarding >conundrum. If I can't prevent someone from forwarding traffic to me >along a certain path, implying I can't "!authorize" them to forward >traffic along that path, then what does the concept of >"authorization" mean. If nobody believed that routes and forwarding were generally congruent, we would not bother advertising routes. Each AS exercises autonomy in managing its forwarding table, just as it does its Loc-RIB. But, it is advantageous to advertise routes to neighbors, and beyond, to influence the traffic that is forwarded to an AS, if only to avoid having to receive traffic and throw it away. Moreover, the discussion on this list re use of bogus AS sets by ISPs to cause more distant ASes to reject advertised routes is a clear attempt to influence forwarding. You can't have it both ways, i.e., if you insist that some forms of BGP behavior not condoned by the specs are mandated by operational necessities, then the motivations behind the behavior should be examined to develop security requirements. >But now you're trying the advertising of routing information >(reachability) to forwarding, which brings us back to the forwarding >conundrum. If I can't prevent someone from forwarding traffic to me >along a certain path, implying I can't "!authorize" them to forward >traffic along that path, then what does the concept of >"authorization" mean. I hate to have to say this, but the above statement is a non-sequitur. Maybe you can reword it to yield the result you want and conform to prepositional logic, but as it stands, ... Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 15:25:33 2005 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 PAA24885 for ; Wed, 2 Feb 2005 15:25:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRMd-0004Sl-Nz for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 15:44:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQwc-000167-Mu; Wed, 02 Feb 2005 15:17:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQrW-0005Af-LE for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 15:12:30 -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 PAA23102 for ; Wed, 2 Feb 2005 15:12:26 -0500 (EST) Received: from vacation.karoshi.com ([198.32.6.68] helo=karoshi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwR9x-00044G-2q for rpsec@ietf.org; Wed, 02 Feb 2005 15:31:33 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j12KCAKN011409; Wed, 2 Feb 2005 20:12:10 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j12KCAvA011406; Wed, 2 Feb 2005 20:12:10 GMT Date: Wed, 2 Feb 2005 20:12:10 +0000 From: bmanning@vacation.karoshi.com To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements Message-ID: <20050202201210.GB11151@vacation.karoshi.com.> References: <42009220.6080602@schlund.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Wed, Feb 02, 2005 at 02:28:41PM -0500, Stephen Kent wrote: > Russ, > > >But now you're trying the advertising of routing information > >(reachability) to forwarding, which brings us back to the forwarding > >conundrum. If I can't prevent someone from forwarding traffic to me > >along a certain path, implying I can't "!authorize" them to forward > >traffic along that path, then what does the concept of > >"authorization" mean. > > If nobody believed that routes and forwarding were generally > congruent, we would not bother advertising routes. Each AS exercises > autonomy in managing its forwarding table, just as it does its > Loc-RIB. But, it is advantageous to advertise routes to neighbors, > and beyond, to influence the traffic that is forwarded to an AS, if ^--- try and (or might be better stated, suggest to a peer how 'they' (the immediate AS) want their peers to treat the prefix. It is not clear to me that there is -any- way using the BGP protocol to allow the originating AS to enforce any expected behaviour by an MIM-AS. so how is a receiving AS able to distinguish between the originating AS policy/desire and some MIM-AS who wants to inflict its own policies on the prefix. -- bill _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 15:32:01 2005 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 PAA25604 for ; Wed, 2 Feb 2005 15:32:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRSu-0004gg-CW for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 15:51:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwR94-00026A-6M; Wed, 02 Feb 2005 15:30:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQxY-00021v-JO for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 15:18: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 PAA23844 for ; Wed, 2 Feb 2005 15:18:40 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRFz-0004EU-66 for rpsec@ietf.org; Wed, 02 Feb 2005 15:37:47 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j12KIajT024342; Wed, 2 Feb 2005 15:18:36 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAAqHaWcV; Wed Feb 2 15:18:23 2005 Date: Wed, 2 Feb 2005 15:18:23 -0500 From: Tony Tauber To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: <42009220.6080602@schlund.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 On Wed, 2 Feb 2005, Stephen Kent wrote: > Tony, > > >How about this alternate text: > > > >++ > 4. When AS A conveys a route to AS B via an UPDATE, AS A is > >++ > implicitly authorizing AS B to forward the route to other > >++ > ASes. Exceptions to this convention may be derived by tagging > >++ > the UPDATE with either a well-known community value such as > >++ > NO_EXPORT or another value which may have been locally agreed > >++ > upon to limit or affect re-announcement in some way. > >++ > Alternately, this policy can be effected by the receiving AS > >++ > either unilaterally or by prior agreement with AS A. > > The last part sentence is a bit confusing to me, since the focus of > the original #4 was to describe the intent of an advertisement from > A to B. Unilateral actions by B re interpreting an advertisement > don't help much from a security perspective. Can you elaborate? The situation I had in mind (common in my experience) was for a service provider to agree with a customer to (or other provider) to apply some policy inbound which would affect the re-advertisement (allowing or disallowing to some extent). Alternately, AS B might decide not to announce another ISP's routes to some subset (or all) of its customers. I guess you're saying what AS B decided to do on it's own doesn't change what AS A might have wanted. > >> > 16. A BGP should originate routes for a prefix only if the > >> > prefix has been allocated to its AS, or that its AS has been > >> > authorized to > >> > >> is a prefix ever allocated to an AS? AFAIK it's allocated to a > >> LIR which may be operating an AS or not. > > > >Another good point, as is becoming clear, there is inconsistent > >congruence between the delegation structure and the BGP structure. > >How this fact interacts with the problem at hand is a matter for our > >attention and comment at the very least. > > I though this was a simple terminology fix. Is the text in my > response not sufficient? > > Steve Well, there has to be a provision for an entity w/o an AS to authorize, if that's what's desired. Also, as Stephan pointed out, currently, no mapping between address allocation and AS, even though they are done by the same numbering authorities. For instance, a previous employer had many ASNs and much address space but there was no mapping of which went where, and, as they came from acquisitions, there was no strong correlation, either. The numbering authorities mostly seem to prevent collisions and it could be argued that BGP only requires that no collisions occur w/o inherent attention to who is authorized as long as the traffic can be delivered to the right place. Since traffic delivery can occur outside the scope of BGP, it seems to make sense to try and connect the AS to the prefix more solidly than is done today. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 15:41:24 2005 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 PAA26731 for ; Wed, 2 Feb 2005 15:41:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRby-0004yY-Kp for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 16:00:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwRA0-0002oM-V4; Wed, 02 Feb 2005 15:31:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwR8k-0001mG-HW for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 15:30:18 -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 PAA25483 for ; Wed, 2 Feb 2005 15:30:14 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRRB-0004dr-8c for rpsec@ietf.org; Wed, 02 Feb 2005 15:49:21 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j12KUABV013251; Wed, 2 Feb 2005 15:30:10 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAA3da4Lz; Wed Feb 2 15:30:06 2005 Date: Wed, 2 Feb 2005 15:30:06 -0500 From: Tony Tauber To: Russ White Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: <42009220.6080602@schlund.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Stefan Mink , Stephen Kent , 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: f60d0f7806b0c40781eee6b9cd0b2135 On Wed, 2 Feb 2005, Russ White wrote: > >> Do you mean authorizing the advertisement of reachability > >> information to a peer's peers? > > > > Yes. > > To what end? Authorizing the advertisement of routing information to > your peer's peers isn't a requirement. When you explain _why_ you > want this, you've hit the requirement. On the other side, stating > that this is somehow "implicit" in BGP is simply untrue. I want it so that traffic from beyond them might reach me. In trying to figure whether it's implicit or not, I find myself thinking that there's no way to make it _explicit_. Thus I reason after the fact that it must be implicit. Generally, don't routing protocols seek to propagate information as far as possible short of causing loops and so forth? > > OK, with forwarding/routing, but regarding the propagation of the > > reachability info, the default behavior is that it can go further > > than the neighbor AS, ie. it's implicit. > > That's the default policy, but it's not "authorization." As above, I don't know what the difference is in this case, though perhaps you could explain it. > >> That you can prevent it from happening if you don't "authorize" it. > > > > Well, I believe (and others should chime in right here), that > > strengthening the policy enforcement might be a goal of securing > > BGP (or not, but others should make some indication.) > > To change this, you're going to need to change more than BGP. You're > going to have to change the basic requirements for routers, and I > believe that when you get into that discussion, what you're going to > find is that everyone wants you to change these requirements for > everyone else, but not for them. I also happen to think that > discussion would be outside the scope of the RPsec working group, > since it impact a lot of other areas than even routing protocols. A big assertion (you're going to need to change more than BGP) that I'm not sure I buy. I'd like to hear more discussion. > > Well, what I was commenting on was what Steve sent (and Stephan > > commented upon) which was an attempt to expose the "motives" > > behind the requirements. (Would these motives be included in the > > requirements doc as a precursor to the requirements section?) > > I don't agree with stating there's an "implicit authorization" > anyplace in BGP. I've worked on BGP for years, and never heard of > such an "implicit authorization," nor has anyone I know ever treated > it that way. It is often described in terms of policy, but never > authorization. I don't know what the difference is. How about "permission"? Is the concern that it sounds too contractual? If you allow it, explicitly, does that not mean that you've authorized it? ie. said "That's OK for you to do." Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 17:01:34 2005 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 RAA13166 for ; Wed, 2 Feb 2005 17:01:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSra-0002TV-P5 for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 17:20:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSAq-0000IP-M2; Wed, 02 Feb 2005 16:36:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwRZI-0000hc-T6 for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 15:57: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 PAA28428 for ; Wed, 2 Feb 2005 15:57:40 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRri-0005ff-KQ for rpsec@ietf.org; Wed, 02 Feb 2005 16:16:48 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2005 15:57:13 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-335.cisco.com [10.82.225.79]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j12Kv9QM006334; Wed, 2 Feb 2005 15:57:10 -0500 (EST) Date: Wed, 2 Feb 2005 15:56:29 -0500 (Eastern Standard Time) From: Russ White To: Tony Tauber Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: <42009220.6080602@schlund.net> 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Stefan Mink , Stephen Kent , rpsec@ietf.org 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: a8a20a483a84f747e56475e290ee868e >>>> Do you mean authorizing the advertisement of reachability >>>> information to a peer's peers? >>> >>> Yes. >> >> To what end? Authorizing the advertisement of routing information to >> your peer's peers isn't a requirement. When you explain _why_ you >> want this, you've hit the requirement. On the other side, stating >> that this is somehow "implicit" in BGP is simply untrue. > > I want it so that traffic from beyond them might reach me. In trying to > figure whether it's implicit or not, I find myself thinking that there's > no way to make it _explicit_. Thus I reason after the fact that it must > be implicit. Generally, don't routing protocols seek to propagate > information as far as possible short of causing loops and so forth? > >>> OK, with forwarding/routing, but regarding the propagation of the >>> reachability info, the default behavior is that it can go further >>> than the neighbor AS, ie. it's implicit. >> >> That's the default policy, but it's not "authorization." > > As above, I don't know what the difference is in this case, though > perhaps you could explain it. The biggest difference between policy and authorization is that authorization implies I can "not authorize" something, which means I can prevent it from happening. Policy means I would like for this to happen, within with reality of my peer's policies. Policies interact with each other, authorization implies I have sole control over a specific action others can or will take. >>>> That you can prevent it from happening if you don't "authorize" it. >>> >>> Well, I believe (and others should chime in right here), that >>> strengthening the policy enforcement might be a goal of securing >>> BGP (or not, but others should make some indication.) >> >> To change this, you're going to need to change more than BGP. You're >> going to have to change the basic requirements for routers, and I >> believe that when you get into that discussion, what you're going to >> find is that everyone wants you to change these requirements for >> everyone else, but not for them. I also happen to think that >> discussion would be outside the scope of the RPsec working group, >> since it impact a lot of other areas than even routing protocols. > > A big assertion (you're going to need to change more than BGP) that I'm > not sure I buy. I'd like to hear more discussion. If you want to be able to _force_ someone else to take specific forwarding actions based on the information provided through a routing protocol, you're reaching much farther than the routing protocol itself, and into very broad, hard to define, and hard to get agreement on areas. >> I don't agree with stating there's an "implicit authorization" >> anyplace in BGP. I've worked on BGP for years, and never heard of >> such an "implicit authorization," nor has anyone I know ever treated >> it that way. It is often described in terms of policy, but never >> authorization. > > I don't know what the difference is. How about "permission"? Is the > concern that it sounds too contractual? If you allow it, explicitly, does > that not mean that you've authorized it? ie. said "That's OK for you to > do." The problem is, if I say: "You are authorized to do this," it implies I can also say: "You aren't authorized to do this," that I can somehow prevent you from doing this. In reality, you can't prevent someone from forwarding traffic to you along a path through routing. You can do it with packet filters, but not, strictly, in routing. If you wanted to say you should be able to prevent someone from forwarding traffic along a path through routing alone, then you end up controlling the data plane, the interaction between the data and control planes, as well as a host of other things. We just don't want to go there, IMHO. You can try to word it as: "The receipt of routing information implies permission to route traffic towards the advertising peer, but lack of received (specific?) routing information doesn't imply lack of authorization," then you might get at the gist of the problem. IMHO, the concept of "authorization," in this environment, just doesn't make any sense. For instance, a community is a "group of routes to which a common policy applies," rather than a: "group of routes to which a common authorization applies." The entire BGP language, peering structure, and additions to BGP are built on policy, not authorization, at the peering point. The concept of authorization already exists at the origination point. Extending authorization to the peering point, injecting "authorization" at the peering point is a much bigger mess than we want to get in to. :-) 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 Wed Feb 2 17:16:45 2005 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 RAA16556 for ; Wed, 2 Feb 2005 17:16:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwT6H-0003Yj-Il for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 17:35:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSZy-0003Pz-8G; Wed, 02 Feb 2005 17:02:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSBH-0000wW-HM for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 16:36: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 QAA09754 for ; Wed, 2 Feb 2005 16:36:55 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSTh-0001Ek-Qr for rpsec@ietf.org; Wed, 02 Feb 2005 16:56:03 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j12LZkPJ018865; Wed, 2 Feb 2005 16:35:46 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAAcZaijK; Wed Feb 2 16:35:33 2005 Date: Wed, 2 Feb 2005 16:35:32 -0500 From: Tony Tauber To: Russ White Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: <42009220.6080602@schlund.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Stefan Mink , Stephen Kent , 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: 8b30eb7682a596edff707698f4a80f7d On Wed, 2 Feb 2005, Russ White wrote: > > >> That's the default policy, but it's not "authorization." > > > > As above, I don't know what the difference is in this case, though > > perhaps you could explain it. > > The biggest difference between policy and authorization is that > authorization implies I can "not authorize" something, which means I > can prevent it from happening. Policy means I would like for this to > happen, within with reality of my peer's policies. Policies interact > with each other, authorization implies I have sole control over a > specific action others can or will take. OK, I see what you mean. Taking off also from what Bill posted, I'd state that in my experience, the absolute self-determination of an AS is one of the guiding principles of BGP. I don't know if it's explicitly stated anywhere, but that's been my observation. Anyone else care to give their two cents? [Your other points seem to be re-statements of this bit above.] > The concept of authorization already exists at the origination point. It does? I'm not sure I get that in light of the other things you said. Tony > Extending authorization to the peering point, injecting > "authorization" at the peering point is a much bigger mess than we > want to get in to. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 17:20:54 2005 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 RAA17405 for ; Wed, 2 Feb 2005 17:20:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTAJ-0003ts-D1 for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 17:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSiK-0001ki-Dc; Wed, 02 Feb 2005 17:11:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSJI-0000Zu-LM for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 16:45:19 -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 QAA11253 for ; Wed, 2 Feb 2005 16:45:12 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSbj-0001lG-4G for rpsec@ietf.org; Wed, 02 Feb 2005 17:04:20 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2005 16:54:49 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-335.cisco.com [10.82.225.79]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j12LifQM021495; Wed, 2 Feb 2005 16:44:42 -0500 (EST) Date: Wed, 2 Feb 2005 16:44:06 -0500 (Eastern Standard Time) From: Russ White To: Tony Tauber Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: <42009220.6080602@schlund.net> 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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Stefan Mink , Stephen Kent , rpsec@ietf.org 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: c1c65599517f9ac32519d043c37c5336 >>>> That's the default policy, but it's not "authorization." >>> >>> As above, I don't know what the difference is in this case, though >>> perhaps you could explain it. >> >> The biggest difference between policy and authorization is that >> authorization implies I can "not authorize" something, which means I >> can prevent it from happening. Policy means I would like for this to >> happen, within with reality of my peer's policies. Policies interact >> with each other, authorization implies I have sole control over a >> specific action others can or will take. > > OK, I see what you mean. Taking off also from what Bill posted, I'd > state that in my experience, the absolute self-determination of an AS is > one of the guiding principles of BGP. I don't know if it's explicitly > stated anywhere, but that's been my observation. Anyone else care to > give their two cents? I should actually say that policies interact with each other and with contracts. :-) This "absolute determination of an AS" is one of the problems we're going to face throughout.... Which is why I say a lot of people would like to force everyone else to do "x," but they wouldn't want someone else to force them to do "x." Kind-of like governmental organizations.... >> The concept of authorization already exists at the origination point. > > It does? I'm not sure I get that in light of the other things you said. Well, not in BGP. It does exists within the address allocation structure, BGP really doesn't have too much to say about this piece, but I don't think we can, or want to, ditch the concept of authorization at the origination point. :-) 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 Wed Feb 2 17:32:46 2005 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 RAA19645 for ; Wed, 2 Feb 2005 17:32:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTLm-0004io-9w for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 17:51:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSrd-00017T-6f; Wed, 02 Feb 2005 17:20:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSgu-0000LS-MI for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 17:09: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 RAA15153 for ; Wed, 2 Feb 2005 17:09:36 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSzI-00034s-Lx for rpsec@ietf.org; Wed, 02 Feb 2005 17:28:44 -0500 Received: from [198.202.64.63] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j12M8pjh015657; Wed, 2 Feb 2005 17:08:54 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050202201210.GB11151@vacation.karoshi.com.> References: <42009220.6080602@schlund.net> <20050202201210.GB11151@vacation.karoshi.com.> Date: Wed, 2 Feb 2005 17:07:39 -0500 To: bmanning@vacation.karoshi.com From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 21c69d3cfc2dd19218717dbe1d974352 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 At 8:12 PM +0000 2/2/05, bmanning@vacation.karoshi.com wrote: >On Wed, Feb 02, 2005 at 02:28:41PM -0500, Stephen Kent wrote: >> Russ, >> >> >But now you're trying the advertising of routing information >> >(reachability) to forwarding, which brings us back to the forwarding >> >conundrum. If I can't prevent someone from forwarding traffic to me >> >along a certain path, implying I can't "!authorize" them to forward >> >traffic along that path, then what does the concept of >> >"authorization" mean. >> >> If nobody believed that routes and forwarding were generally >> congruent, we would not bother advertising routes. Each AS exercises >> autonomy in managing its forwarding table, just as it does its >> Loc-RIB. But, it is advantageous to advertise routes to neighbors, >> and beyond, to influence the traffic that is forwarded to an AS, if > ^--- try and (or might be better stated, suggest to > a peer how 'they' (the immediate AS) want their peers to treat > the prefix. It is not clear to me that there is -any- way using > the BGP protocol to allow the originating AS to enforce any > expected behaviour by an MIM-AS. so how is a receiving AS > able to distinguish between the originating AS policy/desire > and some MIM-AS who wants to inflict its own policies on the prefix. > >-- bill Bill, As we are developing a requirements document at this stage, it seems appropriate to explore what is the intent of an AS in propagating an advertisement, without yet asking how one can enforce that intent. Because ASes are "autonomous" it's fair to say that AS A can't rely on other ASes to propagate any advertisement A sends, since A does not in general know the local policies of these other ASes, who may choose to not propagate an advertisement, even if we assume that the other ASes are operating "correctly." But, I hope we can discover a shared perception of what constitutes correct behavior in terms of route origination and propagation. If there is no shared perception, that would suggest that ASes advertise routes with no notion of the effect of the advertisements, which seems hard to believe. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 17:33:22 2005 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 RAA19768 for ; Wed, 2 Feb 2005 17:33:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTMM-0004ki-Rl for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 17:52:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSrd-00017o-SI; Wed, 02 Feb 2005 17:20:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwSgz-0000NE-Rh for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 17:09: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 RAA15167 for ; Wed, 2 Feb 2005 17:09:41 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwSzP-000365-GR for rpsec@ietf.org; Wed, 02 Feb 2005 17:28:49 -0500 Received: from [198.202.64.63] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j12M8pjj015657; Wed, 2 Feb 2005 17:09:05 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <42009220.6080602@schlund.net> Date: Wed, 2 Feb 2005 17:00:54 -0500 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: d185fa790257f526fedfd5d01ed9c976 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: c3a18ef96977fc9bcc21a621cbf1174b At 3:18 PM -0500 2/2/05, Tony Tauber wrote: >On Wed, 2 Feb 2005, Stephen Kent wrote: > >> Tony, >> >> >How about this alternate text: >> > >> >++ > 4. When AS A conveys a route to AS B via an UPDATE, AS A is >> >++ > implicitly authorizing AS B to forward the route to other >> >++ > ASes. Exceptions to this convention may be derived by tagging >> >++ > the UPDATE with either a well-known community value such as >> >++ > NO_EXPORT or another value which may have been locally agreed >> >++ > upon to limit or affect re-announcement in some way. >> >++ > Alternately, this policy can be effected by the receiving AS >> >++ > either unilaterally or by prior agreement with AS A. >> >> The last part sentence is a bit confusing to me, since the focus of >> the original #4 was to describe the intent of an advertisement from >> A to B. Unilateral actions by B re interpreting an advertisement >> don't help much from a security perspective. Can you elaborate? > >The situation I had in mind (common in my experience) was for a >service provider to agree with a customer to (or other provider) to >apply some policy inbound which would affect the re-advertisement >(allowing or disallowing to some extent). >Alternately, AS B might decide not to announce another ISP's routes to >some subset (or all) of its customers. > >I guess you're saying what AS B decided to do on it's own doesn't >change what AS A might have wanted. yes, that is what I am saying. > >> >> > 16. A BGP should originate routes for a prefix only if the >> >> > prefix has been allocated to its AS, or that its AS has been >> >> > authorized to >> >> >> >> is a prefix ever allocated to an AS? AFAIK it's allocated to a >> >> LIR which may be operating an AS or not. >> > >> >Another good point, as is becoming clear, there is inconsistent >> >congruence between the delegation structure and the BGP structure. >> >How this fact interacts with the problem at hand is a matter for our >> >attention and comment at the very least. >> >> I though this was a simple terminology fix. Is the text in my >> response not sufficient? >> >> Steve > >Well, there has to be a provision for an entity w/o an AS to >authorize, if that's what's desired. Also, as Stephan pointed out, >currently, no mapping between address allocation and AS, even though >they are done by the same numbering authorities. For instance, a >previous employer had many ASNs and much address space but there was >no mapping of which went where, and, as they came from acquisitions, >there was no strong correlation, either. yes, there has to be a provision for tracking the delegation of prefixes, and we need a scheme that parallels what folks do when they delegate, acquire prefixes via mergers or bankruptcy, etc. there should be no need for the RIRs to be involved in delegation that takes place after they have done initial assignments, except when a prefix is returned to them for reallocation. >The numbering authorities mostly seem to prevent collisions and it >could be argued that BGP only requires that no collisions occur w/o >inherent attention to who is authorized as long as the traffic can >be delivered to the right place. >Since traffic delivery can occur outside the scope of BGP, it seems to >make sense to try and connect the AS to the prefix more solidly than >is done today. traffic delivery does occur independent of BGP, it it's intra-AS or a result of static route configuration. But, the big security problems for BGP do not seem to be the ones that arise in these contexts. rather, it is inter-AS routing as a result of advertisement propagation where the big security issues arise. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 17:40:25 2005 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 RAA20499 for ; Wed, 2 Feb 2005 17:40:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTTB-00050c-Bf for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 17:59:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwT5h-0001d3-PD; Wed, 02 Feb 2005 17:35:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwStD-0002Vd-Uq for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 17:22:23 -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 RAA17602 for ; Wed, 2 Feb 2005 17:22:19 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTBe-0003we-QF for rpsec@ietf.org; Wed, 02 Feb 2005 17:41:28 -0500 Received: from [198.202.64.63] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j12MLEjl016285; Wed, 2 Feb 2005 17:21:43 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <42009220.6080602@schlund.net> Date: Wed, 2 Feb 2005 17:20:56 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Russ, > >The biggest difference between policy and authorization is that >authorization implies I can "not authorize" something, which means I >can prevent it from happening. Policy means I would like for this to >happen, within with reality of my peer's policies. Policies interact >with each other, authorization implies I have sole control over a >specific action others can or will take. "Authorization" is commonly viewed as a synonym for permission, as any thesaurus will confirm. Generally folks understand that withholding permission does not equate to enforcing a prohibition of an action granted by a complimentary permission. Any parent will attest to the truth of this interpretation :-) , as will many police officers, etc. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 18:13:11 2005 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 SAA24520 for ; Wed, 2 Feb 2005 18:13:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwTyt-000653-JD for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 18:32:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwTYs-00051x-Av; Wed, 02 Feb 2005 18:05:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwTTM-0000Rx-5o for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 17:59: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 RAA22482 for ; Wed, 2 Feb 2005 17:59:39 -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 1CwTlk-0005c2-QE for rpsec@ietf.org; Wed, 02 Feb 2005 18:18:48 -0500 Received: from [208.231.75.210] ([208.231.75.210]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j12Mwlsh015457 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 2 Feb 2005 17:58:51 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 02 Feb 2005 17:58:41 -0500 Subject: Re: [RPSEC] some thoughts on requirements From: Blaine Christian To: Stephen Kent , Tony Tauber 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: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit > yes, there has to be a provision for tracking the delegation of > prefixes, and we need a scheme that parallels what folks do when they > delegate, acquire prefixes via mergers or bankruptcy, etc. there > should be no need for the RIRs to be involved in delegation that > takes place after they have done initial assignments, except when a > prefix is returned to them for reallocation. Just breezing through the thread and found this one... You are absolutely correct. After initial delegation the prefix usage is the responsibility of the operator who purchased the space. An additional point would be that the registries, also, enforce adequate usage of the space before allocating more to prevent gorging by operators. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 18:33:54 2005 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 SAA26748 for ; Wed, 2 Feb 2005 18:33:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwUIx-0006hy-Rj for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 18:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwTw5-0001OE-1f; Wed, 02 Feb 2005 18:29:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwTkm-0004O7-Hn for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 18:17: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 SAA25175 for ; Wed, 2 Feb 2005 18:17:39 -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 1CwU3D-0006Ec-AS for rpsec@ietf.org; Wed, 02 Feb 2005 18:36:48 -0500 Received: from [208.231.75.210] ([208.231.75.210]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j12NGgsh015671 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 2 Feb 2005 18:16:42 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 02 Feb 2005 18:16:35 -0500 Subject: Re: [RPSEC] some thoughts on requirements From: Blaine Christian To: Stephen Kent , 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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit > As we are developing a requirements document at this stage, it seems > appropriate to explore what is the intent of an AS in propagating an > advertisement, without yet asking how one can enforce that intent. Well said... > > Because ASes are "autonomous" it's fair to say that AS A can't rely > on other ASes to propagate any advertisement A sends, since A does > not in general know the local policies of these other ASes, who may > choose to not propagate an advertisement, even if we assume that the > other ASes are operating "correctly." > But, I hope we can discover a shared perception of what constitutes > correct behavior in terms of route origination and propagation. If > there is no shared perception, that would suggest that ASes advertise > routes with no notion of the effect of the advertisements, which > seems hard to believe. > Let me try phrasing it this way... There is a consensual view of reality on the Internet WRT BGP. That view is that a certain netblock is reachable as advertised by a EBGP neighbor AS. The only thing, currently, we can be absolutely sure of is that our neighbor advertised a prefix and that it "looks" like it traversed a set of AS's. It is common perception that your prefix traversed that set of AS's and that, if you were to have a view of the route table in each AS, you would see that prefix. In most cases that view would be correct. However, the AS numbers and prefixes are bound together loosely. Perhaps, if we could take the term AS out of the realm of BGP then it might apply quite neatly to our situation. It is clear that a set of networks under common administration could be considered an autonomous system without necessarily having a single AS. A common example might be my old network which used many AS numbers and distributed prefixes between them. I could say that the network itself (including all AS's) was an autonomous system. Should we try to decrease our focus on AS path in general and talk about an autonomous system as a network (or collection of networks) under common administration? I suspect everyone can agree on the establishment of a "path" from origination point to the local device as a valid component of a secured prefix exchange infrastructure (or can we?). After all, in any system, if we don't know how the prefix came to us how can we be comfortable with it? _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 18:37:33 2005 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 SAA26958 for ; Wed, 2 Feb 2005 18:37:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwUMU-0006nj-Df for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 18:56:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwTw7-0001Pg-DB; Wed, 02 Feb 2005 18:29:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwToQ-0006m1-F7 for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 18:21:30 -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 SAA25683 for ; Wed, 2 Feb 2005 18:21:23 -0500 (EST) Received: from vacation.karoshi.com ([198.32.6.68] helo=karoshi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwU6q-0006Mp-8u for rpsec@ietf.org; Wed, 02 Feb 2005 18:40:32 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j12NL5KN012174; Wed, 2 Feb 2005 23:21:05 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j12NL5Lq012171; Wed, 2 Feb 2005 23:21:05 GMT Date: Wed, 2 Feb 2005 23:21:05 +0000 From: bmanning@vacation.karoshi.com To: Blaine Christian Subject: Re: [RPSEC] some thoughts on requirements Message-ID: <20050202232105.GC11151@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rpsec@ietf.org, Tony Tauber , Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Wed, Feb 02, 2005 at 05:58:41PM -0500, Blaine Christian wrote: > > > yes, there has to be a provision for tracking the delegation of > > prefixes, and we need a scheme that parallels what folks do when they > > delegate, acquire prefixes via mergers or bankruptcy, etc. there > > should be no need for the RIRs to be involved in delegation that > > takes place after they have done initial assignments, except when a > > prefix is returned to them for reallocation. > > Just breezing through the thread and found this one... You are absolutely > correct. After initial delegation the prefix usage is the responsibility of > the operator who purchased the space. An additional point would be that the > registries, also, enforce adequate usage of the space before allocating more > to prevent gorging by operators. > er... rir's track delegations - when a prefix changes administrative and technical handles, the rir needs to know. remember, address space is not property that can be purchased. address space is delegated for responsible use and must be re-affirmed to the rir on a regular basis. legacy delegtions are a distinctly different matter. so in general, i strenuously disagree with both of you. i would encourage folks to make themselves aware of current address delegations policies ... www.arin.net is a good starting point. > > > > _______________________________________________ > 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 Wed Feb 2 18:42:55 2005 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 SAA27440 for ; Wed, 2 Feb 2005 18:42:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwURg-00070B-3w for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 19:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwU6j-00057Z-Lh; Wed, 02 Feb 2005 18:40:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwTze-0002EQ-M2 for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 18:33:06 -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 SAA26715 for ; Wed, 2 Feb 2005 18:33:01 -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 1CwUI6-0006gu-P9 for rpsec@ietf.org; Wed, 02 Feb 2005 18:52:11 -0500 Received: from [208.231.75.210] ([208.231.75.210]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j12NWMsh015872 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 2 Feb 2005 18:32:23 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 02 Feb 2005 18:32:16 -0500 Subject: Re: [RPSEC] some thoughts on requirements From: Blaine Christian To: Message-ID: In-Reply-To: <20050202232105.GC11151@vacation.karoshi.com.> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Tony Tauber , Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit >> > > er... rir's track delegations - when a prefix changes > administrative and technical handles, the rir needs to > know. remember, address space is not property that can be > purchased. address space is delegated for responsible use > and must be re-affirmed to the rir on a regular basis. > legacy delegtions are a distinctly different matter. > so in general, i strenuously disagree with both of you. Not sure why you disagree with me . I agree with you for the most part. However, I would say that address space is "leased" through membership fees at ARIN. I also agree that initial delegations are tracked through ARIN. But, If you read the ARIN policy it states that delegated blocks of a certain size must have a delegation within ARIN. It does not state that all blocks allocated to ISP customers must be delegated. The fact that the ARIN policy states something does not mean that every operator adheres to that policy (although I do). What typically happens is that if you do not follow the ARIN policies and they find out you end up getting cut off from further delegations until your behavior changes. Also, ARIN may track, to a small degree by AS number. In no way shape or form to they dictate which of my AS's I have to use it with (which means an entity that has several AS's or business units transfers things about with impunity). > > i would encourage folks to make themselves aware of current > address delegations policies ... www.arin.net is a good > starting point. > > >> >> >> >> _______________________________________________ >> 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 Wed Feb 2 18:52:05 2005 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 SAA28021 for ; Wed, 2 Feb 2005 18:52:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwUaY-0007GH-5s for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 19:11:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwU75-0005NY-Vi; Wed, 02 Feb 2005 18:40:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwU13-0002fl-9h for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 18: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 SAA26810 for ; Wed, 2 Feb 2005 18:34:28 -0500 (EST) Received: from vacation.karoshi.com ([198.32.6.68] helo=karoshi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwUJV-0006iX-KN for rpsec@ietf.org; Wed, 02 Feb 2005 18:53:38 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j12NYPKN012231; Wed, 2 Feb 2005 23:34:25 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j12NYP1N012228; Wed, 2 Feb 2005 23:34:25 GMT Date: Wed, 2 Feb 2005 23:34:25 +0000 From: bmanning@vacation.karoshi.com To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements Message-ID: <20050202233425.GD11151@vacation.karoshi.com.> References: <42009220.6080602@schlund.net> <20050202201210.GB11151@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: rpsec@ietf.org, bmanning@vacation.karoshi.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 > >> Loc-RIB. But, it is advantageous to advertise routes to neighbors, > >> and beyond, to influence the traffic that is forwarded to an AS, if > > ^--- try and (or might be better stated, suggest to > > a peer how 'they' (the immediate AS) want their peers to treat > > the prefix. It is not clear to me that there is -any- way using > > the BGP protocol to allow the originating AS to enforce any > > expected behaviour by an MIM-AS. so how is a receiving AS > > able to distinguish between the originating AS policy/desire > > and some MIM-AS who wants to inflict its own policies on the prefix. > > > >-- bill > > Bill, > > As we are developing a requirements document at this stage, it seems > appropriate to explore what is the intent of an AS in propagating an > advertisement, without yet asking how one can enforce that intent. looking carefully here is useful. > Because ASes are "autonomous" it's fair to say that AS A can't rely > on other ASes to propagate any advertisement A sends, since A does > not in general know the local policies of these other ASes, who may > choose to not propagate an advertisement, even if we assume that the > other ASes are operating "correctly." core bgp (as i remember it) allows me to take information/prefixes that I know (learned from static entries, IGP processes, or from other external neighbors) and pass on, to my neighbors, my willingness to accept packets for those prefixes. extentions to bgp have attempted to temper information i receive (AS striping/ packing) and information i send on (AS striping/packing, etc.) once my neighbor receives my willingness message, her local policies may completely over-ride my wishes/intent. and last i checked, anyone beyond my neighbor has no visability to my desired behviour... > But, I hope we can discover a shared perception of what constitutes > correct behavior in terms of route origination and propagation. If > there is no shared perception, that would suggest that ASes advertise > routes with no notion of the effect of the advertisements, which > seems hard to believe. > > Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 18:52:47 2005 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 SAA28137 for ; Wed, 2 Feb 2005 18:52:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwUbE-0007HG-N9 for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 19:11:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwU76-0005QE-Jb; Wed, 02 Feb 2005 18:40:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwU2F-0002ts-5h for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 18:35:47 -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 SAA26848 for ; Wed, 2 Feb 2005 18:35:42 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwUKh-0006jD-Ju for rpsec@ietf.org; Wed, 02 Feb 2005 18:54:51 -0500 Received: from [198.202.64.63] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j12NYXjh019431; Wed, 2 Feb 2005 18:34:36 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050202232105.GC11151@vacation.karoshi.com.> References: <20050202232105.GC11151@vacation.karoshi.com.> Date: Wed, 2 Feb 2005 18:34:08 -0500 To: bmanning@vacation.karoshi.com From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: cab78e1e39c4b328567edb48482b6a69 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 At 11:21 PM +0000 2/2/05, bmanning@vacation.karoshi.com wrote: >On Wed, Feb 02, 2005 at 05:58:41PM -0500, Blaine Christian wrote: >> >> > yes, there has to be a provision for tracking the delegation of >> > prefixes, and we need a scheme that parallels what folks do when they >> > delegate, acquire prefixes via mergers or bankruptcy, etc. there >> > should be no need for the RIRs to be involved in delegation that >> > takes place after they have done initial assignments, except when a >> > prefix is returned to them for reallocation. >> >> Just breezing through the thread and found this one... You are absolutely >> correct. After initial delegation the prefix usage is the responsibility of >> the operator who purchased the space. An additional point would be that the >> registries, also, enforce adequate usage of the space before allocating more >> to prevent gorging by operators. >> > > er... rir's track delegations - when a prefix changes > administrative and technical handles, the rir needs to > know. remember, address space is not property that can be > purchased. address space is delegated for responsible use > and must be re-affirmed to the rir on a regular basis. > legacy delegtions are a distinctly different matter. > so in general, i strenuously disagree with both of you. > > i would encourage folks to make themselves aware of current > address delegations policies ... www.arin.net is a good > starting point. Bill, I know that ARIN tracks further delegation by ISPs, but it uses the tracking as a means to ensure that a request from an ISP for more address blocks is justified. As a result, the feedback re delegation is not necessarily very fast, which would cause problems for our use of such delegation. Also, I was know sure if all the RIRs imposed similar requirements, or if their experience in the timeliness of such reporting is comparable to that of ARIN. So, in my defense, what is needed for routing security is a means of tracking address block delegation, transfers, etc. in a timely fashion which is likely to be more demanding than what the RIRs require. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 2 18:57:03 2005 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 SAA28536 for ; Wed, 2 Feb 2005 18:57:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwUfL-0007Ru-Vt for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 19:16:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwUL6-0002e5-7c; Wed, 02 Feb 2005 18:55:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwU9w-0007BF-Lk for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 18:43: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 SAA27489 for ; Wed, 2 Feb 2005 18:43:39 -0500 (EST) Received: from vacation.karoshi.com ([198.32.6.68] helo=karoshi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwUSP-000716-2x for rpsec@ietf.org; Wed, 02 Feb 2005 19:02:49 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j12NhZKN012286; Wed, 2 Feb 2005 23:43:35 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j12NhZKi012283; Wed, 2 Feb 2005 23:43:35 GMT Date: Wed, 2 Feb 2005 23:43:30 +0000 From: bmanning@vacation.karoshi.com To: Blaine Christian Subject: Re: [RPSEC] some thoughts on requirements Message-ID: <20050202234330.GF11151@vacation.karoshi.com.> References: <20050202232105.GC11151@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: rpsec@ietf.org, bmanning@vacation.karoshi.com, Tony Tauber , Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a On Wed, Feb 02, 2005 at 06:32:16PM -0500, Blaine Christian wrote: > > > er... rir's track delegations - when a prefix changes > > administrative and technical handles, the rir needs to > > know. remember, address space is not property that can be > > purchased. address space is delegated for responsible use > > and must be re-affirmed to the rir on a regular basis. > > legacy delegtions are a distinctly different matter. > > so in general, i strenuously disagree with both of you. > > Not sure why you disagree with me . I agree with you for the most > part. However, I would say that address space is "leased" through > membership fees at ARIN. > > I also agree that initial delegations are tracked through ARIN. But, If you > read the ARIN policy it states that delegated blocks of a certain size must > have a delegation within ARIN. It does not state that all blocks allocated > to ISP customers must be delegated. no... but they must be accounted for on a regular basis.. > The fact that the ARIN policy states something does not mean that every > operator adheres to that policy (although I do). true. > What typically happens is that if you do not follow the ARIN policies and > they find out you end up getting cut off from further delegations until your > behavior changes. from a more charitable view, ARIN insists on documentation before delegating more responsibility. > Also, ARIN may track, to a small degree by AS number. In no way shape or > form to they dictate which of my AS's I have to use it with (which means an > entity that has several AS's or business units transfers things about with > impunity). yes - arin looks for responsible use. not connectivity to some portion of the "Internet" > > > > > i would encourage folks to make themselves aware of current > > address delegations policies ... www.arin.net is a good > > starting point. > > > > > >> > >> > >> > >> _______________________________________________ > >> 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 Wed Feb 2 18:58:24 2005 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 SAA28672 for ; Wed, 2 Feb 2005 18:58:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwUgf-0007Tx-7s for rpsec-web-archive@ietf.org; Wed, 02 Feb 2005 19:17:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwUL7-0002ep-NJ; Wed, 02 Feb 2005 18:55:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwUC1-0007tk-Ab for rpsec@megatron.ietf.org; Wed, 02 Feb 2005 18:45:57 -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 SAA27627 for ; Wed, 2 Feb 2005 18:45:48 -0500 (EST) Received: from vacation.karoshi.com ([198.32.6.68] helo=karoshi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwUUT-00074Q-Oj for rpsec@ietf.org; Wed, 02 Feb 2005 19:04:58 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j12NjiKN012307; Wed, 2 Feb 2005 23:45:44 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j12Njix4012304; Wed, 2 Feb 2005 23:45:44 GMT Date: Wed, 2 Feb 2005 23:45:44 +0000 From: bmanning@vacation.karoshi.com To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements Message-ID: <20050202234544.GG11151@vacation.karoshi.com.> References: <20050202232105.GC11151@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: rpsec@ietf.org, bmanning@vacation.karoshi.com, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c > > So, in my defense, what is needed for routing security is a means of > tracking address block delegation, transfers, etc. in a timely > fashion which is likely to be more demanding than what the RIRs > require. indeed. and RIR whois data is not even close. :) > > Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 3 02:43:40 2005 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 CAA25513 for ; Thu, 3 Feb 2005 02:43:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwbwv-0004Uo-0q for rpsec-web-archive@ietf.org; Thu, 03 Feb 2005 03:02:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwbZY-0007bC-42; Thu, 03 Feb 2005 02:38:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwbYt-0007L6-Eh for rpsec@megatron.ietf.org; Thu, 03 Feb 2005 02:37: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 CAA25001 for ; Thu, 3 Feb 2005 02:37:58 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwbrP-0004Jf-Qy for rpsec@ietf.org; Thu, 03 Feb 2005 02:57:08 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CwbYq-0002Zw-UO; Thu, 03 Feb 2005 08:37:57 +0100 Message-ID: <4201D4D3.6050507@schlund.net> Date: Thu, 03 Feb 2005 08:37:55 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements References: <42009220.6080602@schlund.net> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0447329135==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0447329135== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5A4B0838C9AF0F3F5B0BCDAB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5A4B0838C9AF0F3F5B0BCDAB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephen Kent wrote: >> for me this is too broad: when I announce a route to a customer, >> I do not give the authorization to forward it to any other >> ASes, but only to customer ASes. > > > I see that Tony made the same observation, but an examination of the BGP > specs does not give any indication of this constraint as part of the > protocol. thats right; it's not in the specs because it only concerns the usage of BGP, not the (software) implementation. > how does one define "customer ASes" in an objective fashion? you hit the most difficult aspect :] Who is a customer and for which prefixes is an agreement between two providers. I even think coupling this to the word customer is wrong because it implies money. Although it used to be the case that peering implied "settlement-free" and transit implied "cost-based", this is not the case anymore. Peerings can cost money and transit can be free, I've seen all of them. The usage of customers and peers just makes this easier to explain because most people can work better with these terms. In reality its about announcement scopes: Gets the receiver of a route authorized to flood the route without limitation (this matches a transit provider receiving a route) or is there a limitation. It's hard to explain but for me - although Russ may be right that it's hard to implement today - it's one of the key aspects of routing security: Verification of origin authorization is meant to prevent that an attacker creates a route and by this attracts traffic and e.g. blackholes it. What does it help if you can verify that somebody was authorized to announce a route but any attacker can attract traffic to it by means of unauthorized readvertisements which has similar results as unauthorized origination: The attacker is capable of attracting (parts of) the traffic and can attack it. Origin Verification is necessary and good, but it's not the complete story. tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig5A4B0838C9AF0F3F5B0BCDAB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAdTWehvPYvDU0roRAhpmAKDE2tSGd1CaOX72NSzoN9Z45dmRiwCdHWal efZ7cOO4PjegFYNOStql/AA= =Unq/ -----END PGP SIGNATURE----- --------------enig5A4B0838C9AF0F3F5B0BCDAB-- --===============0447329135== 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 --===============0447329135==-- From rpsec-bounces@ietf.org Thu Feb 3 02:54:23 2005 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 CAA26180 for ; Thu, 3 Feb 2005 02:54:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwc7J-0004oY-GY for rpsec-web-archive@ietf.org; Thu, 03 Feb 2005 03:13:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwbn8-000270-CX; Thu, 03 Feb 2005 02:52:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwbkc-0001aD-Ru for rpsec@megatron.ietf.org; Thu, 03 Feb 2005 02:50:07 -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 CAA25941 for ; Thu, 3 Feb 2005 02:50:05 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.204] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwc36-0004gc-E1 for rpsec@ietf.org; Thu, 03 Feb 2005 03:09:15 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CwbkW-0003vA-RD; Thu, 03 Feb 2005 08:50:01 +0100 Message-ID: <4201D7A7.70502@schlund.net> Date: Thu, 03 Feb 2005 08:49:59 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White Subject: Re: [RPSEC] some thoughts on requirements References: <42009220.6080602@schlund.net> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: rpsec@ietf.org, Tony Tauber , Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0168947123==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0168947123== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE5248E9CF4503F7DBC2A47DB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE5248E9CF4503F7DBC2A47DB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Russ White wrote: > But now you're trying the advertising of routing information > (reachability) to forwarding, which brings us back to the forwarding > conundrum. If I can't prevent someone from forwarding traffic to me > along a certain path, implying I can't "!authorize" them to forward > traffic along that path, then what does the concept of "authorization" > mean. I'm in favor of dropping this argument "forwarding may not do the same as routing". Either we assume that forwarding and routing are tied and we go on trying to secure the routing layer or we accept that routing and forwarding are different worlds and then every minute we spend here is lost because securing routing doesn't secure forwarding anyway. And securing the forwarding behavior is what it's all about, isn't it? If we don't get to a decision, how we handle this point, this will impact the decision forever (it already does for months/years if I remember this well...) tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigE5248E9CF4503F7DBC2A47DB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAdeqehvPYvDU0roRAhI/AKCjJ8p1u/3jVILtrcOu2/DXIHEvQQCfciYH 1fawu46vHkvsBtnDNWBFJ54= =uiKo -----END PGP SIGNATURE----- --------------enigE5248E9CF4503F7DBC2A47DB-- --===============0168947123== 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 --===============0168947123==-- From rpsec-bounces@ietf.org Thu Feb 3 10:21:03 2005 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 KAA02047 for ; Thu, 3 Feb 2005 10:21:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwj5a-0000vc-9W for rpsec-web-archive@ietf.org; Thu, 03 Feb 2005 10:40:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwiYk-0004qE-Qe; Thu, 03 Feb 2005 10:06:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwiX3-0003R9-5y for rpsec@megatron.ietf.org; Thu, 03 Feb 2005 10:04: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 KAA29579 for ; Thu, 3 Feb 2005 10:04:30 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwipb-0000MZ-0h for rpsec@ietf.org; Thu, 03 Feb 2005 10:23:44 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9980E2D4FBA; Thu, 3 Feb 2005 10:03:53 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 68082-01-83; Thu, 3 Feb 2005 10:03:48 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D014B2D5376; Thu, 3 Feb 2005 09:40:47 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j13EelE17647; Thu, 3 Feb 2005 09:40:47 -0500 (EST) Date: Thu, 3 Feb 2005 09:40:47 -0500 From: Jeffrey Haas To: Tony Tauber Subject: Re: [RPSEC] some thoughts on requirements Message-ID: <20050203144047.GA17565@nexthop.com> References: <42009220.6080602@schlund.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: 0fa76816851382eb71b0a882ccdc29ac Tony, On Wed, Feb 02, 2005 at 03:30:06PM -0500, Tony Tauber wrote: > I want it so that traffic from beyond them might reach me. > In trying to figure whether it's implicit or not, I find myself > thinking that there's no way to make it _explicit_. Thus I reason > after the fact that it must be implicit. Generally, don't routing > protocols seek to propagate information as far as possible short of > causing loops and so forth? BGP will only accept information into the adj-rib-in for a given peer or place a route into the adj-rib-out if it passes a policy check. (See the decision process.) The default policy on routers shouldn't be confused with the default policy of BGP. As more than one operator has said, "BGP is all about policy". :-) The typical exercise of policy is obviously going to depend on what your business model and needs are: Edge ASes more often than not want their reachability to go as far as it can so they can receive traffic from as much of the Internet as they can. However, we know from data from organizations like CAIDA that there are parts of the Net that are unreachable because the routes aren't getting through to the appropriate places. Transit ASes that don't consider themselves part of the "core", more colloquially tier-2/3, provide transit services to the edge ASes but tend to also try to freely get traffic amongst their various connections as much as possible. Tier-1/"core" ASes exchange traffic almost solely based on contractual agreements and in some cases may limit traffic distribution on a customer<->core1<->core2<->customer basis. In general, as you approach tier-1, you increase the amount of policy applied for purposes of limiting route distribution. However, each tier may also use varying amounts of policy (and changes to path attributes) in an attempt to influence route selection so as to encourage certain traffic patterns. (I probably should have avoided the tier argument since no one can really define a "tier" even though it is somewhat implied based on the actual meshiness of the AS-graph. Such is the stuff that flames on NANOG are made.) My point is really that there isn't any implicit or explicit policy in the protocol, simply how it is used by various people. For the purpose of this discussion, we have one globally accepted policy knob, the NO_EXPORT (and it's kin) community that can attempt to limit the distribution of routes beyond the adjacent AS. This mechanism isn't a "hard" one as it can be ignored. There exists no common mechanism to limit route redistribution beyond the adjacent AS although the practice of packing an AS you don't own into the AS_PATH gives you this in some form. So, to support Russ, you may be authorized to originate some reachability, but current BGP mechanisms do not allow you to explicitly authorize a given AS to propagate your reachability nor do they permit you to explicitly deny authorization to propagate (or receive) your reachability. Strictly IMO, while it is a computationally feasible problem to put these limitations into the protocol, it is operationally a nightmare. For giggles, try to represent your explicit permit/deny policy in something reasonably abstract like RPSL and see what happens. :-) -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 3 17:39:28 2005 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 RAA00612 for ; Thu, 3 Feb 2005 17:39:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwpvz-0002Ro-BJ for rpsec-web-archive@ietf.org; Thu, 03 Feb 2005 17:58:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwpQI-0003CP-QW; Thu, 03 Feb 2005 17:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwp6J-0000cW-7Y for rpsec@megatron.ietf.org; Thu, 03 Feb 2005 17:05:23 -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 RAA24445 for ; Thu, 3 Feb 2005 17:05:20 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwpOs-0000L0-2d for rpsec@ietf.org; Thu, 03 Feb 2005 17:24:39 -0500 Received: from [198.202.64.179] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j13M46jh010204; Thu, 3 Feb 2005 17:04:35 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <4201D4D3.6050507@schlund.net> References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> Date: Thu, 3 Feb 2005 14:44:16 -0500 To: Stefan Mink From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 92df29fa99cf13e554b84c8374345c17 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: 00e94c813bef7832af255170dca19e36 Stefan, >Stephen Kent wrote: >>>for me this is too broad: when I announce a route to a customer, >>>I do not give the authorization to forward it to any other >>>ASes, but only to customer ASes. >> >> >>I see that Tony made the same observation, but an examination of >>the BGP specs does not give any indication of this constraint as >>part of the protocol. > >thats right; it's not in the specs because it only concerns >the usage of BGP, not the (software) implementation. > >>how does one define "customer ASes" in an objective fashion? > >you hit the most difficult aspect :] >Who is a customer and for which prefixes is an agreement >between two providers. I even think coupling this to the >word customer is wrong because it implies money. Although >it used to be the case that peering implied "settlement-free" >and transit implied "cost-based", this is not the case anymore. >Peerings can cost money and transit can be free, I've seen >all of them. The usage of customers and peers just makes this >easier to explain because most people can work better with >these terms. > >In reality its about announcement scopes: Gets the receiver of >a route authorized to flood the route without limitation (this >matches a transit provider receiving a route) or is there a >limitation. We need an objective way for one to characterize the set of ASes to which an advertisement is expected to be propagated. The NO_EXPORT community gives an easy answer when that attribute is present. if this attribute is not present, is there a standard way to use other community attributes to convey the notion that a speaker wants a neighbor to limit distribution of a route? if so, then we need to discuss this, if not, then it may be hard to define what constitutes secure operation for BGP, due to a lack of sufficient characterization of such operation. > >It's hard to explain but for me - although Russ may be right >that it's hard to implement today - it's one of the key aspects >of routing security: > > Verification of origin authorization is meant to prevent > that an attacker creates a route and by this attracts traffic > and e.g. blackholes it. > What does it help if you can verify that somebody was > authorized to announce a route but any attacker can > attract traffic to it by means of unauthorized readvertisements > which has similar results as unauthorized origination: > The attacker is capable of attracting (parts of) the > traffic and can attack it. > >Origin Verification is necessary and good, but it's not the >complete story. agreed: securing route origination is just part of the solution. we need to define what is and is not an "authorized" advertisement, so that any advertisements that are not authorized can be rejected and thus avoid the problem you cite. But, if we can't characterize what is and it not authorized, other than by saying "whatever ISPs agree to" then we don't have a good basis for putting into place mechanisms to allow ASes to detect and reject bogus advertisements. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 3 17:43:28 2005 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 RAA00979 for ; Thu, 3 Feb 2005 17:43:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwpzr-0002Zb-IK for rpsec-web-archive@ietf.org; Thu, 03 Feb 2005 18:02:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwpQL-0003Ga-JH; Thu, 03 Feb 2005 17:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwp6P-0000iU-Nt for rpsec@megatron.ietf.org; Thu, 03 Feb 2005 17:05:30 -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 RAA24538 for ; Thu, 3 Feb 2005 17:05:26 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwpP3-0000Ll-Ho for rpsec@ietf.org; Thu, 03 Feb 2005 17:24:45 -0500 Received: from [198.202.64.179] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j13M46jl010204; Thu, 3 Feb 2005 17:04:55 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050202233425.GD11151@vacation.karoshi.com.> References: <42009220.6080602@schlund.net> <20050202201210.GB11151@vacation.karoshi.com.> <20050202233425.GD11151@vacation.karoshi.com.> Date: Thu, 3 Feb 2005 16:39:24 -0500 To: bmanning@vacation.karoshi.com From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Bill, > > >> Because ASes are "autonomous" it's fair to say that AS A can't rely >> on other ASes to propagate any advertisement A sends, since A does >> not in general know the local policies of these other ASes, who may >> choose to not propagate an advertisement, even if we assume that the >> other ASes are operating "correctly." > > core bgp (as i remember it) allows me to take information/prefixes > that I know (learned from static entries, IGP processes, or > from other external neighbors) and pass on, to my neighbors, > my willingness to accept packets for those prefixes. extentions > to bgp have attempted to temper information i receive (AS striping/ > packing) and information i send on (AS striping/packing, etc.) the current spec recognizes the validity of adding your own AS multiple times, contiguously. it does not condone stripping of ASes, except to the extent aggregation calls for this, as defined in a fairly detailed way. However, the spec says essentially nothing about what constitutes legitimate route origination, which leaves some room for interpretation. until we agree upon a comprehensive description of what constitutes legitimate origination, we have a gap, but I don't think that gap allows arbitrary AS stripping, for the reason I cite below. > once my neighbor receives my willingness message, her local > policies may completely over-ride my wishes/intent. > and last i checked, anyone beyond my neighbor has no visability > to my desired behviour... > the neighbor can choose to not pass on your advertisement. but, various chunks of text in BGP say that if you advertise a route, and you are not the origin AS, then the route is supposed to reflect the path that UPDATEs traversed to yield the route. so, this does not condone arbitrary addition/deletion of ASes in a path you receive from neighbors. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 3 17:45:16 2005 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 RAA01248 for ; Thu, 3 Feb 2005 17:45:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwq1b-0002eI-K0 for rpsec-web-archive@ietf.org; Thu, 03 Feb 2005 18:04:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwpQM-0003HZ-Ep; Thu, 03 Feb 2005 17:26:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwp6a-0000oL-DO for rpsec@megatron.ietf.org; Thu, 03 Feb 2005 17:05: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 RAA24639 for ; Thu, 3 Feb 2005 17:05:37 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwpPE-0000MP-8L for rpsec@ietf.org; Thu, 03 Feb 2005 17:24:56 -0500 Received: from [198.202.64.179] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j13M46jn010204; Thu, 3 Feb 2005 17:05:01 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050203144047.GA17565@nexthop.com> References: <42009220.6080602@schlund.net> <20050203144047.GA17565@nexthop.com> Date: Thu, 3 Feb 2005 17:01:28 -0500 To: Jeffrey Haas From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: 082a9cbf4d599f360ac7f815372a6a15 Jeff, As you noted, there is not universal agreement on who is a tier N ISP, so none of the discussion that depends on such labels will allow us to derive security requirements that will have universal interpretation. (Still, it is helpful to have discussed the factors that motivate different behavior for different ASes.) >So, to support Russ, you may be authorized to originate some reachability, >but current BGP mechanisms do not allow you to explicitly authorize >a given AS to propagate your reachability nor do they permit you to >explicitly deny authorization to propagate (or receive) your reachability. Since I think we all agree that NO_EXPORT is a well understood way to express one form of an AS's intent re propagation of a route, I don't understand the later part of your conclusion above, i.e., expression of no authorization to propagate is explicit. We may argue about what the default behavior is supposed to be when NO_EXPORT is not present, but that is a debate about implicit, not explicit, authorization. Also, we should remember that there are various ways people deal with behavior that does not conform to explicit or implicit authorization. - sometimes we employ mechanisms designed to prevent behavior that is not authorized. for example, we may require a key for a lock on a door to prevent unauthorized access. - sometime we rely on the threat of detection and punishment to deter unauthorized behavior. law enforcement is often based on this model of dealing with unauthorized behavior. - sometimes we rely on remedial measures to punish unauthorized behavior. we may impose (future) preventative measures on an offender (incarceration of an offender or termination of a contract). So, when we discuss enforcement, it is important to remember that there are many forms enforcement may take. >Strictly IMO, while it is a computationally feasible problem to put >these limitations into the protocol, it is operationally a nightmare. >For giggles, try to represent your explicit permit/deny policy in >something reasonably abstract like RPSL and see what happens. :-) > it is fair to ask whether people can manage a proposed set of controls. if the expression of the controls becomes too complex, people will make mistakes that yield vulnerabilities, or that degrade service. that concern is why we came to the conclusion that incremental deployment of BGP security should be done via contiguous deployment, vs. trying to link secured "islands" through unsecured ASes. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 3 17:46:33 2005 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 RAA01536 for ; Thu, 3 Feb 2005 17:46:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwq2n-0002gR-J4 for rpsec-web-archive@ietf.org; Thu, 03 Feb 2005 18:05:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwpQN-0003IP-Sa; Thu, 03 Feb 2005 17:26:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwp6o-00018W-8J for rpsec@megatron.ietf.org; Thu, 03 Feb 2005 17:05: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 RAA24796 for ; Thu, 3 Feb 2005 17:05:51 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwpPQ-0000P5-D3 for rpsec@ietf.org; Thu, 03 Feb 2005 17:25:10 -0500 Received: from [198.202.64.179] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j13M46jj010204; Thu, 3 Feb 2005 17:04:46 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 3 Feb 2005 14:48:43 -0500 To: Blaine Christian From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 8b431ad66d60be2d47c7bfeb879db82c Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Blaine, > > > >> Because ASes are "autonomous" it's fair to say that AS A can't rely >> on other ASes to propagate any advertisement A sends, since A does >> not in general know the local policies of these other ASes, who may >> choose to not propagate an advertisement, even if we assume that the >> other ASes are operating "correctly." >> But, I hope we can discover a shared perception of what constitutes >> correct behavior in terms of route origination and propagation. If >> there is no shared perception, that would suggest that ASes advertise >> routes with no notion of the effect of the advertisements, which >> seems hard to believe. >> > >Let me try phrasing it this way... There is a consensual view of reality on >the Internet WRT BGP. That view is that a certain netblock is reachable as >advertised by a EBGP neighbor AS. The only thing, currently, we can be >absolutely sure of is that our neighbor advertised a prefix and that it >"looks" like it traversed a set of AS's. It is common perception that your >prefix traversed that set of AS's and that, if you were to have a view of >the route table in each AS, you would see that prefix. In most cases that >view would be correct. However, the AS numbers and prefixes are bound >together loosely. Perhaps, if we could take the term AS out of the realm of >BGP then it might apply quite neatly to our situation. > >It is clear that a set of networks under common administration could be >considered an autonomous system without necessarily having a single AS. A >common example might be my old network which used many AS numbers and >distributed prefixes between them. I could say that the network itself >(including all AS's) was an autonomous system. right. we need to accommodate the situation where there is a common administrative entity even though multiple AS numbers are used. >Should we try to decrease our focus on AS path in general and talk about an >autonomous system as a network (or collection of networks) under common >administration? I suspect everyone can agree on the establishment of a >"path" from origination point to the local device as a valid component of a >secured prefix exchange infrastructure (or can we?). After all, in any >system, if we don't know how the prefix came to us how can we be comfortable >with it? I think we can't ignore AS numbers in a path, because route selection is influenced by path length. so, we have to be able to detect if a path has been artificially shortened to attract traffic. BGP explicitly allows paths to be padded in a well defined way, to convey the notion of a backup path, so path length seems to be important. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 3 18:39:45 2005 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 SAA07209 for ; Thu, 3 Feb 2005 18:39:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwqsK-0004FE-4n for rpsec-web-archive@ietf.org; Thu, 03 Feb 2005 18:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwqU2-0003mY-2T; Thu, 03 Feb 2005 18:33:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwqLy-0001Xd-VH for rpsec@megatron.ietf.org; Thu, 03 Feb 2005 18:25:39 -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 SAA06164 for ; Thu, 3 Feb 2005 18:25:36 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwqec-0003rj-Qs for rpsec@ietf.org; Thu, 03 Feb 2005 18:44:56 -0500 Received: from [172.17.19.3] (helo=[172.17.19.3]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CwqLr-0007iJ-B1; Fri, 04 Feb 2005 00:25:31 +0100 Message-ID: <4202B2EB.8080100@schlund.net> Date: Fri, 04 Feb 2005 00:25:31 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA06164 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Stephen Kent wrote: > agreed: securing route origination is just part of the solution. > > we need to define what is and is not an "authorized" advertisement, so=20 > that any advertisements that are not authorized can be rejected and=20 > thus avoid the problem you cite. But, if we can't characterize what=20 > is and it not authorized, other than by saying "whatever ISPs agree=20 > to" then we don't have a good basis for putting into place mechanisms=20 > to allow ASes to detect and reject bogus advertisements. we would need the same as for origin verification: a database where the policy between two connected ISPs is stored, which is signed by both, so you can verify its authentic. RPSL contains some elements, but it does not go far enough: it does not contain the reannouncement scope of a route, just who gets which routes. Tsch=FC=DF Stefan _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 3 19:05:53 2005 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 TAA09691 for ; Thu, 3 Feb 2005 19:05:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwrHc-00050k-So for rpsec-web-archive@ietf.org; Thu, 03 Feb 2005 19:25:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwqtj-0002Sk-2N; Thu, 03 Feb 2005 19:00:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwqbj-0005op-6p for rpsec@megatron.ietf.org; Thu, 03 Feb 2005 18:41:55 -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 SAA07375 for ; Thu, 3 Feb 2005 18:41:52 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwquN-0004Iu-7w for rpsec@ietf.org; Thu, 03 Feb 2005 19:01:12 -0500 Received: from [198.202.64.179] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j13NfGjh014274; Thu, 3 Feb 2005 18:41:19 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <4202B2EB.8080100@schlund.net> References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> Date: Thu, 3 Feb 2005 18:41:11 -0500 To: Stefan Mink From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 At 12:25 AM +0100 2/4/05, Stefan Mink wrote: >Stephen Kent wrote: > >>agreed: securing route origination is just part of the solution. >> >>we need to define what is and is not an "authorized" advertisement, >>so that any advertisements that are not authorized can be rejected >>and thus avoid the problem you cite. But, if we can't characterize >>what is and it not authorized, other than by saying "whatever ISPs >>agree to" then we don't have a good basis for putting into place >>mechanisms to allow ASes to detect and reject bogus advertisements. > > >we would need the same as for origin verification: a database where >the policy between two connected ISPs is stored, which is signed >by both, so you can verify its authentic. >RPSL contains some elements, but it does not go far enough: >it does not contain the reannouncement scope of a route, just >who gets which routes. verifying origin ASes can be done reliably based on the simple, tree structured allocation structure that is used for handing out and transferring prefixes. the folks who have to "sign off" are authoritative for the data i question. I don't know if it is sufficient to have pairs of peers sign off on what their intent is re pairwise authorization to propagate routes. collusion between two peers, combined with a liberal interpretation of what constitutes legitimate route origination, might allow propagation of a lot of bogus routes. only if we impose stringent constraints on who can originate routes based on "implicit aggregation" might this be technically sound. also, I've been told that some (many?) ISPs consider local policy data to be private and might be reluctant to share it. Or do you think that this more limited aspect of local policy is sufficiently benign to not be a concern? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 3 22:57:35 2005 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 WAA29059 for ; Thu, 3 Feb 2005 22:57:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwutt-000313-2V for rpsec-web-archive@ietf.org; Thu, 03 Feb 2005 23:16:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwuZV-0004YH-At; Thu, 03 Feb 2005 22:55:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwuXT-0003RE-MS for rpsec@megatron.ietf.org; Thu, 03 Feb 2005 22:53:47 -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 WAA28770 for ; Thu, 3 Feb 2005 22:53:45 -0500 (EST) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwuqB-0002tU-HG for rpsec@ietf.org; Thu, 03 Feb 2005 23:13:07 -0500 Received: from comcast.net (h00045affd586.ne.client2.attbi.com[65.96.173.139]) by comcast.net (rwcrmhc11) with SMTP id <2005020403531301300k59kke>; Fri, 4 Feb 2005 03:53:13 +0000 Received: by comcast.net (sSMTP sendmail emulation); Thu, 3 Feb 2005 22:53:25 -0500 Date: Thu, 3 Feb 2005 22:53:23 -0500 From: Tony Tauber To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 On Thu, 3 Feb 2005, Stephen Kent wrote: > >Let me try phrasing it this way... There is a consensual view of > >reality on the Internet WRT BGP. That view is that a certain > >netblock is reachable as advertised by a EBGP neighbor AS. The > >only thing, currently, we can be absolutely sure of is that our > >neighbor advertised a prefix and that it "looks" like it traversed > >a set of AS's. It is common perception that your prefix traversed > >that set of AS's and that, if you were to have a view of the route > >table in each AS, you would see that prefix. In most cases that > >view would be correct. I'd like to some views from more operators about this bit. Do people rely on the contents and order of the AS path for troubleshooting (eg. calling up AS X and asking what they see in their BGP tables?) > >It is clear that a set of networks under common administration > >could be considered an autonomous system without necessarily having > >a single AS. A common example might be my old network which used > >many AS numbers and distributed prefixes between them. I could say > >that the network itself (including all AS's) was an autonomous > >system. > > right. we need to accommodate the situation where there is a common > administrative entity even though multiple AS numbers are used. I don't know how much we need to accomodate this situation, though we should try to take it into account. In my experience, (I don't know how UUnet did/does it), these ASs may be under unified administration, but they basically have standard BGP policy and configurations. IIRC, I know of some now-defunct networks that had some special policy hacks in place and I seem to recall IGP even being allowed to leak across the boundaries. I'd consider these to be hacks done at the perpetrator's folly. > I think we can't ignore AS numbers in a path, because route > selection is influenced by path length. so, we have to be able to > detect if a path has been artificially shortened to attract traffic. > BGP explicitly allows paths to be padded in a well defined way, to > convey the notion of a backup path, so path length seems to be > important. As above, operators need to weigh in here: Speaking as an operator, my experience has been that not only do ASs make decisions based on AS_PATH length, they make policy decisions based on the _contents_ thereof and even sometimes the _order_ of those contents. Operators, if you're out there, please register your thoughts. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 4 00:11:28 2005 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 AAA05171 for ; Fri, 4 Feb 2005 00:11:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cww3M-0005BO-8j for rpsec-web-archive@ietf.org; Fri, 04 Feb 2005 00:30:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwvcr-0000oB-2o; Fri, 04 Feb 2005 00:03:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwvYf-0007W6-U6 for rpsec@megatron.ietf.org; Thu, 03 Feb 2005 23:59:06 -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 XAA04073 for ; Thu, 3 Feb 2005 23:59:03 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwvrL-0004mk-Su for rpsec@ietf.org; Fri, 04 Feb 2005 00:18:26 -0500 Received: from comcast.net (h00045affd586.ne.client2.attbi.com[65.96.173.139]) by comcast.net (sccrmhc13) with SMTP id <20050204045832016004im11e>; Fri, 4 Feb 2005 04:58:32 +0000 Received: by comcast.net (sSMTP sendmail emulation); Thu, 3 Feb 2005 23:58:46 -0500 Date: Thu, 3 Feb 2005 23:58:45 -0500 From: Tony Tauber To: rpsec@ietf.org Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: 7655788c23eb79e336f5f8ba8bce7906 On Thu, 3 Feb 2005, Tony Tauber wrote: > In my experience, (I don't know how UUnet did/does it), these ASs > may be under unified administration, but they basically have > standard BGP policy and configurations. IIRC, I know of some > now-defunct networks that had some special policy hacks in place and > I seem to recall IGP even being allowed to leak across the > boundaries. I'd consider these to be hacks done at the > perpetrator's folly. I should clarify that I had first-hand knowledge of these now-defunct networks and it wasn't the hacks that did them in, it was the business. 8-) Though these hacks weren't my idea, I understand why they were done. Sometimes there's no other way than to hack. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 4 02:56:23 2005 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 CAA00412 for ; Fri, 4 Feb 2005 02:56:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwycz-0000eX-SL for rpsec-web-archive@ietf.org; Fri, 04 Feb 2005 03:15:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwyIg-0003qL-0x; Fri, 04 Feb 2005 02:54:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwyG5-0002Ku-Hf for rpsec@megatron.ietf.org; Fri, 04 Feb 2005 02:52:05 -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 CAA00133 for ; Fri, 4 Feb 2005 02:52:03 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwyYl-0000Wg-Va for rpsec@ietf.org; Fri, 04 Feb 2005 03:11:27 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CwyG0-0005Ja-1z; Fri, 04 Feb 2005 08:52:00 +0100 Message-ID: <420329A1.3010908@schlund.net> Date: Fri, 04 Feb 2005 08:52:01 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1117513235==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1117513235== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE0A35DD45456A27382F7940F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE0A35DD45456A27382F7940F Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Steve, Stephen Kent wrote: > also, I've been told that some (many?) ISPs consider local policy data > to be private and might be reluctant to share it. Or do you think that > this more limited aspect of local policy is sufficiently benign to not > be a concern? yes, thats indeed an concern and I'm looking at mechanisms to anonymize policy data but yet make it verifyable (e.g. via Brand certificates). On the other hand I have also learned over time that policy is only loosely correlated to money flows and the latter is, what providers don't want to share. E.g. lots of big providers "peer" (i.e. exchange only customer routes), but not settlement-free. So here, theres no commercial difference between peering and transit. The only difference is the readvertisement scope which per se can be verified to a certain extend by looking at the routing table... tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigE0A35DD45456A27382F7940F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCAymhehvPYvDU0roRArJIAKCHUbRStNQeBf77BSuqNWA6uUC6AgCgr16B NEQiObdJmVrThfkordIROzs= =eKW/ -----END PGP SIGNATURE----- --------------enigE0A35DD45456A27382F7940F-- --===============1117513235== 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 --===============1117513235==-- From rpsec-bounces@ietf.org Fri Feb 4 09:49:24 2005 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 JAA02421 for ; Fri, 4 Feb 2005 09:49:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx54l-0003T7-Qs for rpsec-web-archive@ietf.org; Fri, 04 Feb 2005 10:08:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx4gs-0007zI-Lf; Fri, 04 Feb 2005 09:44:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx4eJ-0006vb-P8 for rpsec@megatron.ietf.org; Fri, 04 Feb 2005 09:41: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 JAA01955 for ; Fri, 4 Feb 2005 09:41:29 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx4x6-0003GJ-OW for rpsec@ietf.org; Fri, 04 Feb 2005 10:00:57 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7CA732D4E79; Fri, 4 Feb 2005 09:41:00 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 66417-04-9; Fri, 4 Feb 2005 09:40:59 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5165E2D4E5E; Fri, 4 Feb 2005 09:40:59 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j14Eex921776; Fri, 4 Feb 2005 09:40:59 -0500 (EST) Date: Fri, 4 Feb 2005 09:40:59 +2244 From: Jeffrey Haas To: Tony Tauber Subject: Re: [RPSEC] some thoughts on requirements Message-ID: <19750325105604.GX3965@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 1.7 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 1.7 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a On Mon, Mar 24, 1975 at 07:08:29PM -0500, Tony Tauber wrote: > I'd like to some views from more operators about this bit. > Do people rely on the contents and order of the AS path for > troubleshooting (eg. calling up AS X and asking what they see in their > BGP tables?) Not solely based on AS_PATH, but I had previously used this information while troubleshooting routing issues as a "tier-3" network operator. :-) The looking glasses provide a lot of the data along with your own view of BGP to troubleshoot routing problems. The wise network operator will also do a lot of reliance on bidirectional traceroutes and correlation of the "problem" place using data from the RIRs (which is hopefully up to date) to trace the problem. If one is lucky, the two pieces of information correspond enough to call up the AS in question and ask for assistance. I've even used the contents of the AGGREGATOR field for purposes of trying to contact an AS about a problem. I found in that case that the IP portion of the field was actually more reliable than the AS portion. Note that all of this was before 1999. :-) > > right. we need to accommodate the situation where there is a common > > administrative entity even though multiple AS numbers are used. > > I don't know how much we need to accomodate this situation, though we > should try to take it into account. I think the problem is tractable but will be wildly dependant on the particular solution. > Speaking as an operator, my experience has been that not only do > ASs make decisions based on AS_PATH length, they make policy decisions > based on the _contents_ thereof and even sometimes the _order_ of > those contents. Order can be critical. To offer one of the examples I gave at a previous IETF bgpsecreq meeting, the ISP I used to work for would often make policy decisions that were roughly "Avoid this carrier-1's routes through this connection if it is adjacent to this AS because the use of that pipe is more costly. Prefer these routes based on this pair of adjacent ASes because the route goes to a critical website and is more stable." The lack of expressiveness in the regular expression languages for matching AS Paths in deployed BGPs is mostly tempered by the fact that AS_SETs are very uncommon. If you're to the point of trying to use an aggregate for policy purposes for shaping traffic, you're probably doomed in the first place. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 4 09:54:30 2005 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 JAA02761 for ; Fri, 4 Feb 2005 09:54:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx59d-0003an-Ch for rpsec-web-archive@ietf.org; Fri, 04 Feb 2005 10:13:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx4ny-0001G8-0c; Fri, 04 Feb 2005 09:51:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx4hM-00088m-1G for rpsec@megatron.ietf.org; Fri, 04 Feb 2005 09:44: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 JAA02102 for ; Fri, 4 Feb 2005 09:44:37 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx508-0003Li-0c for rpsec@ietf.org; Fri, 04 Feb 2005 10:04:05 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A81A82D48AE; Fri, 4 Feb 2005 09:44:07 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 65843-01-49; Fri, 4 Feb 2005 09:44:06 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 67A9F2D4890; Fri, 4 Feb 2005 09:44:06 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j14Ei6s21788; Fri, 4 Feb 2005 09:44:06 -0500 (EST) Date: Fri, 4 Feb 2005 09:44:06 +2245 From: Jeffrey Haas To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements Message-ID: <19750325105912.GY3965@nexthop.com> References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 1.7 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Stefan Mink , 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: 1.7 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Steve, On Mon, Mar 24, 1975 at 02:56:17PM -0500, Stephen Kent wrote: > also, I've been told that some (many?) ISPs consider local policy > data to be private and might be reluctant to share it. Or do you > think that this more limited aspect of local policy is sufficiently > benign to not be a concern? I find it likely that most of our proposed mechanisms will have positive benefits with regards to enforcing internal security policies. Consider the case where ISPs A and B are operating on a bilateral peering arrangement; they accept each others internal routes and also direct customer routes. So long as the security information that makes this valid between the two networks is entirely internal, external parties accidentally receiving the routes are likely to drop them since they can't be properly authenticated. > Steve -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 4 10:12:03 2005 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 KAA04544 for ; Fri, 4 Feb 2005 10:12:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx5Qg-0003xx-05 for rpsec-web-archive@ietf.org; Fri, 04 Feb 2005 10:31:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx56k-0000K7-MQ; Fri, 04 Feb 2005 10:10:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx4uQ-0002IV-63 for rpsec@megatron.ietf.org; Fri, 04 Feb 2005 09:58:10 -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 JAA03092 for ; Fri, 4 Feb 2005 09:58:07 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx5DC-0003fT-EO for rpsec@ietf.org; Fri, 04 Feb 2005 10:17:35 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 19D062D4D81; Fri, 4 Feb 2005 09:57:38 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 66755-02-20; Fri, 4 Feb 2005 09:57:36 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CD9712D4CE8; Fri, 4 Feb 2005 09:57:36 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j14Evaa21846; Fri, 4 Feb 2005 09:57:36 -0500 (EST) Date: Fri, 4 Feb 2005 09:57:36 +2245 From: Jeffrey Haas To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements Message-ID: <19750325111242.GZ3965@nexthop.com> References: <42009220.6080602@schlund.net> <20050203144047.GA17565@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 1.7 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 1.7 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Mon, Mar 24, 1975 at 01:16:34PM -0500, Stephen Kent wrote: > Since I think we all agree that NO_EXPORT is a well understood way to > express one form of an AS's intent re propagation of a route, I don't > understand the later part of your conclusion above, i.e., expression > of no authorization to propagate is explicit. To be clear then, you can't express your intent to "authorize or not authorize" distribution of your routes beyond a directly adjacent peer. In the chain of ASes A,B,C,D A can't say to C "don't send this to D". Some people would consider this a great feature to have. I wont argue that this feature is present. I also will agree that NO_EXPORT (and its kin) allow one to express authorization to readvertise the route you send to a peer. The point I'm largely trying to make is that when network operators are thinking about authorization to re-advertise, they may be thinking beyond the directly adjacent peer. > Steve -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 4 15:24:01 2005 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 PAA01199 for ; Fri, 4 Feb 2005 15:24:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxAId-0002h0-62 for rpsec-web-archive@ietf.org; Fri, 04 Feb 2005 15:43:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx9tQ-0000CB-LY; Fri, 04 Feb 2005 15:17:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx9rW-0006xe-IJ for rpsec@megatron.ietf.org; Fri, 04 Feb 2005 15:15:30 -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 PAA29831 for ; Fri, 4 Feb 2005 15:15:27 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxAAL-0002Oj-7l for rpsec@ietf.org; Fri, 04 Feb 2005 15:34:58 -0500 Received: from [198.202.64.237] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j14KEmjh025055; Fri, 4 Feb 2005 15:14:54 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <19750325111242.GZ3965@nexthop.com> References: <42009220.6080602@schlund.net> <20050203144047.GA17565@nexthop.com> <19750325111242.GZ3965@nexthop.com> Date: Fri, 4 Feb 2005 14:18:11 -0500 To: Jeffrey Haas From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: b19722fc8d3865b147c75ae2495625f2 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 At 9:57 AM +2245 2/4/05, Jeffrey Haas wrote: >On Mon, Mar 24, 1975 at 01:16:34PM -0500, Stephen Kent wrote: >> Since I think we all agree that NO_EXPORT is a well understood way to >> express one form of an AS's intent re propagation of a route, I don't >> understand the later part of your conclusion above, i.e., expression >> of no authorization to propagate is explicit. > >To be clear then, you can't express your intent to "authorize or not >authorize" distribution of your routes beyond a directly adjacent >peer. In the chain of ASes A,B,C,D A can't say to C "don't send this to D". yes. BGP does not provide a mechanism to express the notion of authorization re route propagation, beyond one's immediate neighbors. >Some people would consider this a great feature to have. I wont >argue that this feature is present. I also will agree that NO_EXPORT >(and its kin) allow one to express authorization to readvertise the route >you send to a peer. That's all I have said re this community. >The point I'm largely trying to make is that when network operators >are thinking about authorization to re-advertise, they may be thinking >beyond the directly adjacent peer. I don't dispute that it might be a nice capability for BGP to be able to express this, but I am not aware of a standard way to express that. If there is one, then we need to describe it and work on securing BGP relative to that capability. Or, we can say that this is something we would like to see in a BGP extension, and we can plan on how to secure the capability when it is developed. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 4 15:25:26 2005 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 PAA01357 for ; Fri, 4 Feb 2005 15:25:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxAJz-0002iI-OX for rpsec-web-archive@ietf.org; Fri, 04 Feb 2005 15:44:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx9tR-0000Cq-8b; Fri, 04 Feb 2005 15:17:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx9rW-0006xi-M5 for rpsec@megatron.ietf.org; Fri, 04 Feb 2005 15:15:30 -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 PAA29832 for ; Fri, 4 Feb 2005 15:15:28 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxAAL-0002Of-7p for rpsec@ietf.org; Fri, 04 Feb 2005 15:34:58 -0500 Received: from [198.202.64.237] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j14KEmjf025055; Fri, 4 Feb 2005 15:14:50 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <19750325105912.GY3965@nexthop.com> References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <19750325105912.GY3965@nexthop.com> Date: Fri, 4 Feb 2005 14:13:31 -0500 To: Jeffrey Haas From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 8abaac9e10c826e8252866cbe6766464 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f At 9:44 AM +2245 2/4/05, Jeffrey Haas wrote: >Steve, > >On Mon, Mar 24, 1975 at 02:56:17PM -0500, Stephen Kent wrote: >> also, I've been told that some (many?) ISPs consider local policy >> data to be private and might be reluctant to share it. Or do you >> think that this more limited aspect of local policy is sufficiently >> benign to not be a concern? > >I find it likely that most of our proposed mechanisms will have positive >benefits with regards to enforcing internal security policies. > >Consider the case where ISPs A and B are operating on a bilateral >peering arrangement; they accept each others internal routes and also >direct customer routes. So long as the security information that makes >this valid between the two networks is entirely internal, external >parties accidentally receiving the routes are likely to drop them >since they can't be properly authenticated. Jeff, I agree with your observation, but my question was addressing a different issue. My question was whether the oft-cited concern over disclosure of local policies by ISPs would preclude sharing the data he suggested might need to be shared to securely represent some localized route propagation authorization info. I may have misunderstood Stefan's suggestion. If one is merely sharing the data with neighbors, not putting it in repositories for more general sharing, then my question doesn't apply. steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 4 15:26:14 2005 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 PAA01495 for ; Fri, 4 Feb 2005 15:26:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxAKn-0002jw-Ae for rpsec-web-archive@ietf.org; Fri, 04 Feb 2005 15:45:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx9tR-0000DF-P2; Fri, 04 Feb 2005 15:17:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx9rk-00073H-VQ for rpsec@megatron.ietf.org; Fri, 04 Feb 2005 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 PAA29848 for ; Fri, 4 Feb 2005 15:15:42 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxAAb-0002Oz-4e for rpsec@ietf.org; Fri, 04 Feb 2005 15:35:13 -0500 Received: from [198.202.64.237] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j14KEmjj025055; Fri, 4 Feb 2005 15:14:59 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 4 Feb 2005 14:25:29 -0500 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Tony, > > > >It is clear that a set of networks under common administration >> >could be considered an autonomous system without necessarily having >> >a single AS. A common example might be my old network which used >> >many AS numbers and distributed prefixes between them. I could say >> >that the network itself (including all AS's) was an autonomous >> >system. >> >> right. we need to accommodate the situation where there is a common >> administrative entity even though multiple AS numbers are used. > >I don't know how much we need to accomodate this situation, though we >should try to take it into account. >In my experience, (I don't know how UUnet did/does it), these ASs may >be under unified administration, but they basically have standard BGP >policy and configurations. IIRC, I know of some now-defunct networks >that had some special policy hacks in place and I seem to recall IGP >even being allowed to leak across the boundaries. I'd consider these >to be hacks done at the perpetrator's folly. All I was suggesting is that if an ISP operates multiple ASes, then it seems OK for the ISP to express routes that become "imprecise" within the set of ASes the ISP controls. This does make life more complex, but I think it is manageable, if folks says that it is an important feature. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Feb 5 12:50:04 2005 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 MAA17286 for ; Sat, 5 Feb 2005 12:50:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxUNO-0004Lz-AU for rpsec-web-archive@ietf.org; Sat, 05 Feb 2005 13:09:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxU3U-00075o-HV; Sat, 05 Feb 2005 12:49:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxU24-0006xU-A1 for rpsec@megatron.ietf.org; Sat, 05 Feb 2005 12:47: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 MAA17181 for ; Sat, 5 Feb 2005 12:47:41 -0500 (EST) Received: from mail.enyo.de ([212.9.189.167]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxUL4-0004JP-Qd for rpsec@ietf.org; Sat, 05 Feb 2005 13:07:24 -0500 Received: from deneb.enyo.de ([212.9.189.171]) by albireo.enyo.de with esmtp id 1CxU1Q-0003Gc-U2; Sat, 05 Feb 2005 18:47:04 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.43) id 1CxU1P-0006PM-CJ; Sat, 05 Feb 2005 18:47:03 +0100 From: Florian Weimer To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> Date: Sat, 05 Feb 2005 18:47:03 +0100 In-Reply-To: (Stephen Kent's message of "Thu, 3 Feb 2005 18:41:11 -0500") Message-ID: <87fz0a6grs.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Stefan Mink , 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 * Stephen Kent: > verifying origin ASes can be done reliably based on the simple, tree > structured allocation structure that is used for handing out and > transferring prefixes. the folks who have to "sign off" are > authoritative for the data i question. Will this work in practice? Wouldn't it be reasonable to assume that all the cruft that ends up in RADB today would receive a certificate in the new era? In other words, is it likely that we'll have route registries with strong authentication and authorization (!) checks? What happens to PI and early registration space? Of course, it's possible to postulate a tree model and work from that, ending up with something that cryptographically prevents address space theft (with a few assumptions). However, I fear that the net as a whole would be better off with some mechanisms which puts more emphasis on detection and response (by trusted third parties or the legitimate address space owner). _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Feb 5 17:48:57 2005 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 RAA06110 for ; Sat, 5 Feb 2005 17:48:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxZ2d-0001Rl-Np for rpsec-web-archive@ietf.org; Sat, 05 Feb 2005 18:08:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxYiH-00046p-8f; Sat, 05 Feb 2005 17:47:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxYi0-0003zn-AN for rpsec@megatron.ietf.org; Sat, 05 Feb 2005 17:47: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 RAA05967 for ; Sat, 5 Feb 2005 17:47:17 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxZ14-0001PO-O6 for rpsec@ietf.org; Sat, 05 Feb 2005 18:07:03 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 05 Feb 2005 17:57:26 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-561.cisco.com [10.82.242.49]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j15Mkl1k006241 for ; Sat, 5 Feb 2005 17:46:47 -0500 (EST) Date: Sat, 5 Feb 2005 17:46:07 -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: c1c65599517f9ac32519d043c37c5336 Subject: [RPSEC] A Question on Authorization.... 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: 4d87d2aa806f79fed918a62e834505ca Y'all: I'm still somewhat confused by the different meanings of "authorize" being used on list, so I'd like to ask a couple of simple questions, to perhaps allow everyone to come to a little better understanding. Suppose we have this: A---B---C | | D---+ Now, suppose A has obtained 10.1.1.0/24 from D. A advertises this prefix to B, who then advertises it to C. I would like to know: -- Does A's advertisement to B, in the absence of any other communities, etc, authorize B to advertise 10.1.1.0/24 to C? -- Does A's advertisement to B, in the absence of any other communities, etc, authorize B to transit 10.1.1.0/24 from C to A? -- Suppose A were to use some technique, NO_EXPORT, an AS Path TTL, NO_PEER, redistribution communities, etc, etc, to prevent B from advertising 10.1.1.0/24 to C. Does this imply that A is _not_ authorizing B to transit for 10.1.1.0/24 from C to A? That if B does happen to transit traffic destined to 10.1.1.0/24 from C to A, it is "outside it's authorization limits?" If the answer to the last question is yes, is this the specific sort of thing people would like to be able to "authorize" in a system used to secure BGP--that B, in this case, is or is not authorized to transit for 10.1.1.0/24 from C to A? If the answer to the last question is no, what other meaning is there attached to the concept of "authorization?" In other words, if A authorizes B to send routing information to C, what does that mean, exactly, if it doesn't mean B is now authorized to transit for 10.1.1.0/24 between A and C? That C is authorized to send it to one of their peers, and nothing more? What can it mean to authorize a peer to send routing information to their peers, if not that the peer you're sending the routing information to is now authorized to transit for the prefixes you're sending? :-) 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 Feb 7 06:36:15 2005 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 GAA18256 for ; Mon, 7 Feb 2005 06:36:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy7V6-0005zp-65 for rpsec-web-archive@ietf.org; Mon, 07 Feb 2005 06:56:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy79x-0006UP-2s; Mon, 07 Feb 2005 06:34:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy78T-00066t-HE for rpsec@megatron.ietf.org; Mon, 07 Feb 2005 06:32:57 -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 GAA17990 for ; Mon, 7 Feb 2005 06:32:53 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy7Rp-0005v8-9R for rpsec@ietf.org; Mon, 07 Feb 2005 06:52:58 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1Cy78J-0007Ux-Hy; Mon, 07 Feb 2005 12:32:47 +0100 Message-ID: <420751E1.8070506@schlund.net> Date: Mon, 07 Feb 2005 12:32:49 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Tauber Subject: Re: [RPSEC] some thoughts on requirements References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0573808358==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0573808358== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE644E7D44E677893581E32D2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE644E7D44E677893581E32D2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tony Tauber wrote: > I'd like to some views from more operators about this bit. > Do people rely on the contents and order of the AS path for > troubleshooting (eg. calling up AS X and asking what they see in their > BGP tables?) it's one of ways you could go. Usually you deal with your direct neighbors, but if thats not sufficient, you may have to look deeper into the announcement path. > As above, operators need to weigh in here: > > Speaking as an operator, my experience has been that not only do > ASs make decisions based on AS_PATH length, they make policy decisions > based on the _contents_ thereof and even sometimes the _order_ of > those contents. I can confirm that. The order may not be that important, but the existance of an AS is. We use that to do "BGP TE", e.g. route all routes "behind ASX" over one specific provider, since that one has a faster path whereas the aspath length is identical for several providers... tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigE644E7D44E677893581E32D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCB1HhehvPYvDU0roRApKxAKC2VV3tV827skCEs2KvlTfh6XHa8gCfa+Tn dc9Soc/qeaj3nho6/0oLvFk= =gLGz -----END PGP SIGNATURE----- --------------enigE644E7D44E677893581E32D2-- --===============0573808358== 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 --===============0573808358==-- From rpsec-bounces@ietf.org Mon Feb 7 06:41:07 2005 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 GAA18580 for ; Mon, 7 Feb 2005 06:41:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy7Zo-00066V-IO for rpsec-web-archive@ietf.org; Mon, 07 Feb 2005 07:01:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy7El-0007A1-2m; Mon, 07 Feb 2005 06:39:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy7E4-000744-EF for rpsec@megatron.ietf.org; Mon, 07 Feb 2005 06:38: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 GAA18423 for ; Mon, 7 Feb 2005 06:38:41 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.204] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy7XR-000630-Dv for rpsec@ietf.org; Mon, 07 Feb 2005 06:58:46 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1Cy7E1-0003zw-O7; Mon, 07 Feb 2005 12:38:41 +0100 Message-ID: <42075343.7020605@schlund.net> Date: Mon, 07 Feb 2005 12:38:43 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Florian Weimer Subject: Re: [RPSEC] some thoughts on requirements References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> In-Reply-To: <87fz0a6grs.fsf@deneb.enyo.de> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1681893565==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1681893565== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4627C45BD1E6A3AE15338C4C" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4627C45BD1E6A3AE15338C4C Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Florian Weimer wrote: > Wouldn't it be reasonable to assume that all the cruft that ends up in > RADB today would receive a certificate in the new era? In other > words, is it likely that we'll have route registries with strong > authentication and authorization (!) checks? so far registries don't care about securing inter provider policies, because it's no registry business. All registry aspects can be secured via RPSS and AFAIK (only) RIPE is doing so... In my opinion the registries would be one of the best places to but authorization information because they should be neutral. tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig4627C45BD1E6A3AE15338C4C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCB1NDehvPYvDU0roRAlIXAJ4o3OuQAkGn+ISPEL/75n3oCJsPvgCgix2B 1WBAxFAnmVanRUEZ6N3gwMg= =AvoQ -----END PGP SIGNATURE----- --------------enig4627C45BD1E6A3AE15338C4C-- --===============1681893565== 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 --===============1681893565==-- From rpsec-bounces@ietf.org Mon Feb 7 07:18:02 2005 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 HAA21251 for ; Mon, 7 Feb 2005 07:18:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy89V-0006rT-Oe for rpsec-web-archive@ietf.org; Mon, 07 Feb 2005 07:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy7pR-0003NG-2m; Mon, 07 Feb 2005 07:17:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy7hd-0002Ob-J1 for rpsec@megatron.ietf.org; Mon, 07 Feb 2005 07:09:18 -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 HAA20244 for ; Mon, 7 Feb 2005 07:09:13 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy811-0006cK-6Z for rpsec@ietf.org; Mon, 07 Feb 2005 07:29:19 -0500 Received: from pc6 (1Cust37.tnt28.lnd4.gbr.da.uu.net [62.188.156.37]) by astro.systems.pipex.net (Postfix) with SMTP id EFEE2E000384; Mon, 7 Feb 2005 12:08:41 +0000 (GMT) Message-ID: <000701c50d05$1e227760$0601a8c0@pc6> From: "Tom Petch" To: "Russ White" , References: Subject: Re: [RPSEC] A Question on Authorization.... Date: Mon, 7 Feb 2005 12:05:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit I think that what you are asking about lies outside the scope of this work. The model for (most of) the past decade is that RIRs allocate to LIRs (Local Internet Registry) who can suballocate to Resellers. The LIR remains responsible for the allocation. And this suballocation is of Provider Aggregatable space so the LIR should advertise the allocation (or part thereof), the Reseller should not. So the authorization is implicit in the allocation and only goes from RIR to LIR, no further. (If an organisation wants to multihome, then it needs a Provider Independent allocation and this is handled differently; it is non-aggregatable and the RIR retains more control). This is the scheme I believe we should focus on. Of course the BGP4 specification allows much more complex schemes but that does not mean we have to secure them. (And legacy allocations predate this scheme and probably contain arrangements that are inimical to any security system:-( Terminology matters; 'owns' is wrong in this scheme, 'obtains' - as you use - depends on the semantics you have in mind:-) 'Allocates' is correct. My information is based on RIPE but I understand that AFNIC, APNIC, ARIN and LACNIC all follow the same principles. Tom Petch ----- Original Message ----- From: "Russ White" To: Sent: Saturday, February 05, 2005 11:46 PM Subject: [RPSEC] A Question on Authorization.... > Y'all: > > I'm still somewhat confused by the different meanings of "authorize" being > used on list, so I'd like to ask a couple of simple questions, to perhaps > allow everyone to come to a little better understanding. Suppose we have > this: > > A---B---C > | | > D---+ > > Now, suppose A has obtained 10.1.1.0/24 from D. A advertises this prefix to > B, who then advertises it to C. I would like to know: > > -- Does A's advertisement to B, in the absence of any other communities, > etc, authorize B to advertise 10.1.1.0/24 to C? > > -- Does A's advertisement to B, in the absence of any other communities, > etc, authorize B to transit 10.1.1.0/24 from C to A? > > -- Suppose A were to use some technique, NO_EXPORT, an AS Path TTL, > NO_PEER, redistribution communities, etc, etc, to prevent B from > advertising 10.1.1.0/24 to C. Does this imply that A is _not_ authorizing B > to transit for 10.1.1.0/24 from C to A? That if B does happen to transit > traffic destined to 10.1.1.0/24 from C to A, it is "outside it's > authorization limits?" > > If the answer to the last question is yes, is this the specific sort of > thing people would like to be able to "authorize" in a system used to > secure BGP--that B, in this case, is or is not authorized to transit for > 10.1.1.0/24 from C to A? > > If the answer to the last question is no, what other meaning is there > attached to the concept of "authorization?" In other words, if A authorizes > B to send routing information to C, what does that mean, exactly, if it > doesn't mean B is now authorized to transit for 10.1.1.0/24 between A and > C? That C is authorized to send it to one of their peers, and nothing more? > What can it mean to authorize a peer to send routing information to their > peers, if not that the peer you're sending the routing information to is > now authorized to transit for the prefixes you're sending? > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 7 17:12:59 2005 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 RAA04217 for ; Mon, 7 Feb 2005 17:12:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHRL-00018y-N7 for rpsec-web-archive@ietf.org; Mon, 07 Feb 2005 17:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyGLy-0006M8-0E; Mon, 07 Feb 2005 16:23:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyGBx-0005JH-Vm for rpsec@megatron.ietf.org; Mon, 07 Feb 2005 16:13:10 -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 QAA18577 for ; Mon, 7 Feb 2005 16:13:07 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyGVM-0004Uc-GK for rpsec@ietf.org; Mon, 07 Feb 2005 16:33:13 -0500 Received: from [172.17.19.3] (helo=[172.17.19.3]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CyGBr-00083i-F3; Mon, 07 Feb 2005 22:13:03 +0100 Message-ID: <4207D9DA.5040101@schlund.net> Date: Mon, 07 Feb 2005 22:12:58 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White , rpsec@ietf.org Subject: Re: [RPSEC] A Question on Authorization.... References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Hi Russ, Russ White wrote: > I'm still somewhat confused by the different meanings of "authorize" > being used on list, so I'd like to ask a couple of simple questions, > to perhaps allow everyone to come to a little better understanding. > Suppose we have this: > > A---B---C > | | > D---+ > > Now, suppose A has obtained 10.1.1.0/24 from D. A advertises this > prefix to B, who then advertises it to C. I would like to know: > > -- Does A's advertisement to B, in the absence of any other > communities, etc, authorize B to advertise 10.1.1.0/24 to C? This is only true in general, iff the readvertisement scope of B to C is not restricted (i.e. "transit-provider - customer" relationship) Otherwise it depends on the other relationships, e.g. if A-B is a transit provider - customer relationship ("down") and B-C is a customer - transit provider relationship ("up"), B is not authorized to readvertise the route to C. This is described by some people as the "valleyfreeness of the internet". > -- Does A's advertisement to B, in the absence of any other > communities, etc, authorize B to transit 10.1.1.0/24 from C to A? it's inevitably linked to the last question. If B is not authorized to readvertise the route to C, it's not authorized to transit traffic from C to A *on this path*. There may be others... > -- Suppose A were to use some technique, NO_EXPORT, an AS Path TTL, > NO_PEER, redistribution communities, etc, etc, to prevent B from > advertising 10.1.1.0/24 to C. Does this imply that A is _not_ > authorizing B to transit for 10.1.1.0/24 from C to A? That if B does > happen to transit traffic destined to 10.1.1.0/24 from C to A, it is > "outside it's authorization limits?" since BGP is currently not based on authorization (nobody has to demonstrate he's authorized to (re)advertise a prefix), the means described above are used to communicate "negative authorizations", i.e. "prohibitions". So A is trying to prevent B from readvertising the route and by this attract traffic for the route via the path "B-A". So the general response is: yes. > If the answer to the last question is yes, is this the specific sort > of thing people would like to be able to "authorize" in a system used > to secure BGP--that B, in this case, is or is not authorized to > transit for 10.1.1.0/24 from C to A? this is one of the cases, yes. The problem here is, that it's not a good idea to do it like this. If C is a single homed customer of B and A prevents B from readvertising the prefix *at all*, this means that C will have no route to 10.1.1.0/24 at all. Thats why in general it's probably more based on classes of readvertisement scopes ("customer-transit", "peering", "transit-customer"). So it's more restricting the readvertisement scope of B for this route to a minimum, i.e. to customers only... tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 7 17:26:29 2005 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 RAA06566 for ; Mon, 7 Feb 2005 17:26:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHeQ-0001rH-RF for rpsec-web-archive@ietf.org; Mon, 07 Feb 2005 17:46:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHDv-0002SP-KG; Mon, 07 Feb 2005 17:19:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyGme-0007SR-CF for rpsec@megatron.ietf.org; Mon, 07 Feb 2005 16:51:06 -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 QAA27729 for ; Mon, 7 Feb 2005 16:51:01 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyH66-0007MD-Kh for rpsec@ietf.org; Mon, 07 Feb 2005 17:11:11 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 07 Feb 2005 17:01:29 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-344.cisco.com [10.82.225.88]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j17LoS1k019082; Mon, 7 Feb 2005 16:50:28 -0500 (EST) Date: Mon, 7 Feb 2005 16:49:47 -0500 (Eastern Standard Time) From: Russ White To: Stefan Mink Subject: Re: [RPSEC] A Question on Authorization.... In-Reply-To: <4207D9DA.5040101@schlund.net> Message-ID: References: <4207D9DA.5040101@schlund.net> 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: e8a67952aa972b528dd04570d58ad8fe Cc: rpsec@ietf.org 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: f60d0f7806b0c40781eee6b9cd0b2135 >> I'm still somewhat confused by the different meanings of "authorize" being >> used on list, so I'd like to ask a couple of simple questions, to perhaps >> allow everyone to come to a little better understanding. Suppose we have >> this: >> >> A---B---C >> | | >> D---+ >> >> Now, suppose A has obtained 10.1.1.0/24 from D. A advertises this prefix to >> B, who then advertises it to C. I would like to know: >> -- Suppose A were to use some technique, NO_EXPORT, an AS Path TTL, >> NO_PEER, redistribution communities, etc, etc, to prevent B from >> advertising 10.1.1.0/24 to C. Does this imply that A is _not_ >> authorizing B to transit for 10.1.1.0/24 from C to A? That if B does >> happen to transit traffic destined to 10.1.1.0/24 from C to A, it is >> "outside it's authorization limits?" > > since BGP is currently not based on authorization (nobody has to > demonstrate he's authorized to (re)advertise a prefix), the means > described above are used to communicate "negative authorizations", i.e. > "prohibitions". So A is trying to prevent B from readvertising the route > and by this attract traffic for the route via the path "B-A". So the > general response is: yes. So, what you're really saying is you want to be able to say: "C is not authorized to transit 10.1.1.0/24." Saying: "A should be able to authorize B to transmit routing information to C" is a completely different problem, in reality. To see why this is: -- Suppose A is advertising 10.1.1.0/24 to B in such a way that B cannot readvertise it to C. According to your email above, this should mean that A is _not_ authorizing B to transit traffic from C. -- Suppose D is advertising 10.1.0.0/16 to B, and authorizes B to advertise 10.1.0.0/16 to D. D forwards traffic destined to hosts within 10.1.1.0/24 along the path to 10.1.0.0/16. C routes this traffic along the longest match, causing the traffic to flow to A, and thus B becomes a transit for traffic destined to 10.1.1.0/14, correct? Is B still not authorized to transit traffic for A, even though it is, in reality, doing so? How has A blocking its routing information from transiting B actually provided what you are saying you want--to block B from transiting traffic for 10.1.1.0/24 towards A? It doesn't appear that blocking the routing information has solved anything, in this case. So, it seems to me that it's better to actually state that BGP has no concept of authorization to transit, based on the advertisements in BGP itself. This might be a useful security feature to add (if it's even technically possible to add it), but it's not something BGP has at the moment, implicitely or explicitely. :-) 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 Feb 7 18:06:01 2005 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 SAA12089 for ; Mon, 7 Feb 2005 18:06:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyIGh-0003U0-Cm for rpsec-web-archive@ietf.org; Mon, 07 Feb 2005 18:26:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHgc-0006iN-RZ; Mon, 07 Feb 2005 17:48:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHXl-0004iU-S2 for rpsec@megatron.ietf.org; Mon, 07 Feb 2005 17:39: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 RAA07678 for ; Mon, 7 Feb 2005 17:39:42 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHrE-00028X-Oo for rpsec@ietf.org; Mon, 07 Feb 2005 17:59:54 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 07 Feb 2005 17:39:14 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-344.cisco.com [10.82.225.88]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j17MdB1k001219; Mon, 7 Feb 2005 17:39:12 -0500 (EST) Date: Mon, 7 Feb 2005 17:38:30 -0500 (Eastern Standard Time) From: Russ White To: Stefan Mink Subject: Re: [RPSEC] A Question on Authorization.... In-Reply-To: Message-ID: References: <4207D9DA.5040101@schlund.net> 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rpsec@ietf.org 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: cab78e1e39c4b328567edb48482b6a69 >>> I'm still somewhat confused by the different meanings of "authorize" being >>> used on list, so I'd like to ask a couple of simple questions, to perhaps >>> allow everyone to come to a little better understanding. Suppose we have >>> this: >>> >>> A---B---C >>> | | >>> D---+ >>> >>> Now, suppose A has obtained 10.1.1.0/24 from D. A advertises this prefix >>> to B, who then advertises it to C. I would like to know: > >>> -- Suppose A were to use some technique, NO_EXPORT, an AS Path TTL, >>> NO_PEER, redistribution communities, etc, etc, to prevent B from >>> advertising 10.1.1.0/24 to C. Does this imply that A is _not_ authorizing >>> B to transit for 10.1.1.0/24 from C to A? That if B does happen to transit >>> traffic destined to 10.1.1.0/24 from C to A, it is "outside it's >>> authorization limits?" >> >> since BGP is currently not based on authorization (nobody has to >> demonstrate he's authorized to (re)advertise a prefix), the means >> described above are used to communicate "negative authorizations", i.e. >> "prohibitions". So A is trying to prevent B from readvertising the route >> and by this attract traffic for the route via the path "B-A". So the >> general response is: yes. BTW, I'd really like some other folks to chime in on this answer. I want to understand what everyone thinks the meaning of "authorization" means in terms of BGP's readvertisement of routing information (not origination, just readvertisement). Thanks! :-) 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 Feb 7 18:38:19 2005 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 SAA16375 for ; Mon, 7 Feb 2005 18:38:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyIly-0004Q1-Lw for rpsec-web-archive@ietf.org; Mon, 07 Feb 2005 18:58:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyIJ6-0004iZ-Px; Mon, 07 Feb 2005 18:28:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyIDk-0000ig-SQ for rpsec@megatron.ietf.org; Mon, 07 Feb 2005 18:23: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 SAA15170 for ; Mon, 7 Feb 2005 18:23:05 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyIXF-00045n-0K for rpsec@ietf.org; Mon, 07 Feb 2005 18:43:17 -0500 Received: from [172.17.19.3] (helo=[172.17.19.3]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CyIDi-0001qB-MO; Tue, 08 Feb 2005 00:23:07 +0100 Message-ID: <4207F855.4010905@schlund.net> Date: Tue, 08 Feb 2005 00:23:01 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White Subject: Re: [RPSEC] A Question on Authorization.... References: <4207D9DA.5040101@schlund.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Russ White wrote: > D forwards traffic destined to hosts within 10.1.1.0/24 along the path > to 10.1.0.0/16. C routes this traffic along the longest match, causing > the traffic to flow to A, and thus B becomes a transit for traffic > destined to 10.1.1.0/14, correct? yes > Is B still not authorized to transit traffic for A, even though it is, > in reality, doing so? How has A blocking its routing information from > transiting B actually provided what you are saying you want--to block > B from transiting traffic for 10.1.1.0/24 towards A? It doesn't appear > that blocking the routing information has solved anything, in this case. You're right that in this case this wouldn't work thanks again to the concept of aggregation. On the other hand this does not mean to me that the concept is useless altogether, but that currently there may be some restrictions for aggregates and more specifices. This is due to the concept of routing based on destination address independently of the source address. Juniper routers (I'm not sure with GSRs) can handle several separate routing tables and here it would indeed be possible by using "filter based forwarding" to use different routing tables if there are different authorization schemes. So its entirely possible that current mechanisms have to be extended to implement complicated authorization schemes. I have actually discussed this two years ago with a provider to which we have a mixed peering and transit relationship. Here by means of different routing tables it would have been possible to forward peering traffic (his customers - my customers) using one table (and certain forwarding paths) and to forward transit traffic (rest of the internet - my customers) using another table and different forwarding paths. This is technically possible but we dropped it since it would have been a special solution and special solutions are hard to maintain... > So, it seems to me that it's better to actually state that BGP has no > concept of authorization to transit, based on the advertisements in > BGP itself. This might be a useful security feature to add (if it's > even technically possible to add it), but it's not something BGP has > at the moment, implicitely or explicitely. ACK tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 7 20:09:30 2005 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 UAA23392 for ; Mon, 7 Feb 2005 20:09:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyKCD-0006DL-1b for rpsec-web-archive@ietf.org; Mon, 07 Feb 2005 20:29:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyJp3-0007Kb-5S; Mon, 07 Feb 2005 20:05:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyJnC-0006a9-Uc for rpsec@megatron.ietf.org; Mon, 07 Feb 2005 20:03:51 -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 UAA23050 for ; Mon, 7 Feb 2005 20:03:48 -0500 (EST) Received: from vacation.karoshi.com ([198.32.6.68] helo=karoshi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyK6h-00065Y-HU for rpsec@ietf.org; Mon, 07 Feb 2005 20:24:00 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j1813TKN010977; Tue, 8 Feb 2005 01:03:29 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j1813TXO010974; Tue, 8 Feb 2005 01:03:29 GMT Date: Tue, 8 Feb 2005 01:03:29 +0000 From: bmanning@vacation.karoshi.com To: Russ White Subject: Re: [RPSEC] A Question on Authorization.... Message-ID: <20050208010329.GA10702@vacation.karoshi.com.> References: <4207D9DA.5040101@schlund.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Stefan Mink , 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.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 On Mon, Feb 07, 2005 at 05:38:30PM -0500, Russ White wrote: > > >>>I'm still somewhat confused by the different meanings of "authorize" > >>>being used on list, so I'd like to ask a couple of simple questions, to > >>>perhaps allow everyone to come to a little better understanding. Suppose > >>>we have this: > >>> > >>>A---B---C > >>>| | > >>>D---+ > >>> > >>>Now, suppose A has obtained 10.1.1.0/24 from D. A advertises this prefix > >>>to B, who then advertises it to C. I would like to know: > > > >>>-- Suppose A were to use some technique, NO_EXPORT, an AS Path TTL, > >>>NO_PEER, redistribution communities, etc, etc, to prevent B from > >>>advertising 10.1.1.0/24 to C. Does this imply that A is _not_ > >>>authorizing B to transit for 10.1.1.0/24 from C to A? That if B does > >>>happen to transit traffic destined to 10.1.1.0/24 from C to A, it is > >>>"outside it's authorization limits?" > >> > >>since BGP is currently not based on authorization (nobody has to > >>demonstrate he's authorized to (re)advertise a prefix), the means > >>described above are used to communicate "negative authorizations", i.e. > >>"prohibitions". So A is trying to prevent B from readvertising the route > >>and by this attract traffic for the route via the path "B-A". So the > >>general response is: yes. > > BTW, I'd really like some other folks to chime in on this answer. I want to > understand what everyone thinks the meaning of "authorization" means in > terms of BGP's readvertisement of routing information (not origination, > just readvertisement). > > Thanks! > > :-) > > Russ if a BGP process in a router has knowledge of a prefix, its "authorized" to propogate its knowledge (to the extent controled by local re-distribution policies). how it gains its knowledge (via iBGP, eBGP, some random IGP, or static entries that are manually configured and distributed into BGP... is generally -NOT- part of the BGP protocol spec. and even tho there are "knobs" to try and influence redistribution beyond the immediate peer, the locus of control is in that bi-lateral agreement that is the basis of BGP. Its not quite Alice/Bob, but its close... :) --bill _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 7 23:02:18 2005 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 XAA06747 for ; Mon, 7 Feb 2005 23:02:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyMtU-00016S-3q for rpsec-web-archive@ietf.org; Mon, 07 Feb 2005 23:22:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyMYz-0000ZV-Bv; Mon, 07 Feb 2005 23:01:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyMXX-0000Js-IG for rpsec@megatron.ietf.org; Mon, 07 Feb 2005 22:59:51 -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 WAA06581 for ; Mon, 7 Feb 2005 22:59:48 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyMr3-00012J-7d for rpsec@ietf.org; Mon, 07 Feb 2005 23:20:02 -0500 Received: from [10.84.130.245] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j183xDjf015264; Mon, 7 Feb 2005 22:59:14 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <87fz0a6grs.fsf@deneb.enyo.de> References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> Date: Mon, 7 Feb 2005 22:56:36 -0500 To: Florian Weimer From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 At 6:47 PM +0100 2/5/05, Florian Weimer wrote: >* Stephen Kent: > >> verifying origin ASes can be done reliably based on the simple, tree >> structured allocation structure that is used for handing out and >> transferring prefixes. the folks who have to "sign off" are >> authoritative for the data i question. > >Will this work in practice? > >Wouldn't it be reasonable to assume that all the cruft that ends up in >RADB today would receive a certificate in the new era? In other >words, is it likely that we'll have route registries with strong >authentication and authorization (!) checks? What happens to PI and >early registration space? This is a fair question, but the problems are a bit different from what I think you are suggesting. First, security for this process is not the same as security for submission of data to IRRs. Second, the PKI is easy to check for consistency, so it should be possible to detect many forms of problems. But, I agree that the legacy address space has to be cleaned up, something I believe ARIN is already working on. >Of course, it's possible to postulate a tree model and work from that, >ending up with something that cryptographically prevents address space >theft (with a few assumptions). However, I fear that the net as a >whole would be better off with some mechanisms which puts more >emphasis on detection and response (by trusted third parties or the >legitimate address space owner). A remedial approach to these problems is a legitimate strategy to consider, but preventative measures are certainly preferable, if feasible. There are instances today of bogus origination advertisements used to hide spam. Presumably one could detect this after the fact, but that would not prevent the spam transmission from happening. Also, unless we have a reference database for prefix allocations, it's hard to perform the detection well, or quickly. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 8 01:52:54 2005 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 BAA17219 for ; Tue, 8 Feb 2005 01:52:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyPYY-0004Fr-L8 for rpsec-web-archive@ietf.org; Tue, 08 Feb 2005 02:13:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyP72-0000NM-PP; Tue, 08 Feb 2005 01:44:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyP5p-0008S2-Vl for rpsec@megatron.ietf.org; Tue, 08 Feb 2005 01:43:26 -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 BAA16622 for ; Tue, 8 Feb 2005 01:43:25 -0500 (EST) Received: from smtp1.phx.gblx.net ([64.208.25.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyPPK-000453-QY for rpsec@ietf.org; Tue, 08 Feb 2005 02:03:38 -0500 Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.2/8.11.2) id j186hKN04510 for ; Mon, 7 Feb 2005 23:43:20 -0700 (MST) Received: from shell1.phx.gblx.net(64.208.25.102) via SMTP by smtp1.phx.gblx.net, id smtpdAAA_SayZi; Mon Feb 7 23:43:19 2005 Received: from localhost (guy@localhost) by shell1.phx.gblx.net (8.9.3+Sun/8.9.3) with ESMTP id XAA14360 for ; Mon, 7 Feb 2005 23:43:19 -0700 (MST) X-Authentication-Warning: shell1.phx.gblx.net: guy owned process doing -bs Date: Tue, 8 Feb 2005 01:43:19 -0500 (EST) From: Guy Tal X-X-Sender: guy@shell1.phx.gblx.net To: rpsec@ietf.org Subject: Re: [RPSEC] A Question on Authorization.... In-Reply-To: Message-ID: References: <4207D9DA.5040101@schlund.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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: 3e15cc4fdc61d7bce84032741d11c8e5 On Mon, 7 Feb 2005, Russ White wrote: > >>> I'm still somewhat confused by the different meanings of "authorize" being > >>> used on list, so I'd like to ask a couple of simple questions, to perhaps > >>> allow everyone to come to a little better understanding. Suppose we have > >>> this: > >>> > >>> A---B---C > >>> | | > >>> D---+ > >>> > >>> Now, suppose A has obtained 10.1.1.0/24 from D. A advertises this prefix > >>> to B, who then advertises it to C. I would like to know: > > > >>> -- Suppose A were to use some technique, NO_EXPORT, an AS Path TTL, > >>> NO_PEER, redistribution communities, etc, etc, to prevent B from > >>> advertising 10.1.1.0/24 to C. Does this imply that A is _not_ authorizing > >>> B to transit for 10.1.1.0/24 from C to A? That if B does happen to transit > >>> traffic destined to 10.1.1.0/24 from C to A, it is "outside it's > >>> authorization limits?" > >> > >> since BGP is currently not based on authorization (nobody has to > >> demonstrate he's authorized to (re)advertise a prefix), the means > >> described above are used to communicate "negative authorizations", i.e. > >> "prohibitions". So A is trying to prevent B from readvertising the route > >> and by this attract traffic for the route via the path "B-A". So the > >> general response is: yes. > > BTW, I'd really like some other folks to chime in on this answer. I want to > understand what everyone thinks the meaning of "authorization" means in > terms of BGP's readvertisement of routing information (not origination, > just readvertisement). I've seen many networks out there allow their customers to prepend AS or even deny certain prefixes to certain other networks by use of BGP communities. If a customer of one of those networks decides it doesn't want traffic from a certain network to traverse a certain upstream, the upstream must comply with that decision. Peers advertise routes to other peers with the intention of connecting their customers with their peers' customers. I would say in this relationship, the network in question should not advertise those routes to its other peers. Funny business aside, it's not in a network's best interests to transit one peer's traffic for free. This is usually reinforced in a contract as well, in which case the "should not" changes to "must not" or the network transitting the traffic will face depeering. Guy Tal Global Crossing Traffic Engineering _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 8 02:32:53 2005 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 CAA10573 for ; Tue, 8 Feb 2005 02:32:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyQBF-00056n-H6 for rpsec-web-archive@ietf.org; Tue, 08 Feb 2005 02:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyPpA-0007TB-Fp; Tue, 08 Feb 2005 02:30:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyPnx-0006jb-Bc for rpsec@megatron.ietf.org; Tue, 08 Feb 2005 02:29: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 CAA10315 for ; Tue, 8 Feb 2005 02:29:00 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyQ7U-000523-P7 for rpsec@ietf.org; Tue, 08 Feb 2005 02:49:14 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CyPnu-0004Dp-Cv; Tue, 08 Feb 2005 08:28:58 +0100 Message-ID: <42086A3C.40908@schlund.net> Date: Tue, 08 Feb 2005 08:29:00 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0103261557==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0103261557== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF4517D8E2BA79BE1621C01B0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4517D8E2BA79BE1621C01B0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephen Kent wrote: > A remedial approach to these problems is a legitimate strategy to > consider, but preventative measures are certainly preferable, if > feasible. There are instances today of bogus origination advertisements > used to hide spam. Presumably one could detect this after the fact, but > that would not prevent the spam transmission from happening. I fully agree. A routing security architecture that first permits everything and then checks for attacks is like checking for integrity/authenticity after you ordered products on an online-shop. It's just too late... I think it might be useful in the beginning to have some transition phases where checks are being done in parallel to usage, but the final model should check immediately and only propagate verified routing information... tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigF4517D8E2BA79BE1621C01B0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCCGo8ehvPYvDU0roRAi49AKClklYKw/skKuuiiefKZFF1WYxgXACeOIA3 o8lVFpzf6cm5KwvHnvZCDgI= =+P7B -----END PGP SIGNATURE----- --------------enigF4517D8E2BA79BE1621C01B0-- --===============0103261557== 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 --===============0103261557==-- From rpsec-bounces@ietf.org Tue Feb 8 05:07:37 2005 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 FAA21753 for ; Tue, 8 Feb 2005 05:07:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CySb2-0008Rn-TL for rpsec-web-archive@ietf.org; Tue, 08 Feb 2005 05:27:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CySGF-00046d-4o; Tue, 08 Feb 2005 05:06:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CySEF-0003rn-05 for rpsec@megatron.ietf.org; Tue, 08 Feb 2005 05:04:19 -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 FAA21601 for ; Tue, 8 Feb 2005 05:04:16 -0500 (EST) Received: from pilz.exp-math.uni-essen.de ([132.252.150.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CySXl-0008Nh-7s for rpsec@ietf.org; Tue, 08 Feb 2005 05:24:32 -0500 Received: from lomin.lomin.iem.uni-due.de (nlomin.exp-math.uni-essen.de [132.252.151.183]) by pilz.exp-math.uni-essen.de (8.12.10/8.12.8) with ESMTP id j18A3mlk064738; Tue, 8 Feb 2005 11:03:48 +0100 Received: by lomin.lomin.iem.uni-due.de (Postfix, from userid 1000) id 6944457CC4; Tue, 8 Feb 2005 11:03:42 +0100 (CET) Subject: Re: [RPSEC] A Question on Authorization.... From: Birger =?ISO-8859-1?Q?T=F6dtmann?= To: Russ White In-Reply-To: References: <4207D9DA.5040101@schlund.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Date: Tue, 08 Feb 2005 11:03:41 +0100 Message-Id: <1107857021.4244.40.camel@lomin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Am Montag, den 07.02.2005, 17:38 -0500 schrieb Russ White: [...] >=20 > BTW, I'd really like some other folks to chime in on this answer. I want = to=20 > understand what everyone thinks the meaning of "authorization" means in=20 > terms of BGP's readvertisement of routing information (not origination,=20 > just readvertisement). I think "authorization" always comes with an instance who grants it. And it also implies an enforcement decision, hopefully a deterministic one. Without both, authorization is an empty phrase. Unfortunately these accompanying characteristics are not easy to nail down here: - In your example A has obtained 10.1.1.0/24 from D. D in this case=20 implicitly authorizeses A to re-advertise the prefix. The design of the inter-domain routing system also implicitly authorizes A to=20 forward any traffic for 10.1.1.0/24 to D, be it from someone else or=20 A's own network. - A then re-advertises the prefix to B. Supposed it uses some mechanism like NO_EXPORT, A denies authorization to B to re-advertise the=20 prefix. In comes the enforcement decision: B now has a choice. Obviously, D not only authorized A to re-advertise its prefix, it=20 also may have *wanted* it to re-advertise the prefix through the =20 whole net. Instead, A denies this explicitly to B. So we possibly have conflicting policies here. B can now choose between three alternatives: - ignore any outside policies, follow your own (grant/deny authorization to yourself) - follow B's policy (authorization denied by B) - follow D's policy (authorization granted by D) BGP right now has no mechanism to assess rightfully who granted or denied authorization to re-advertise a prefix. It has no mechanism to show conflicting authorizations (that result from conflicting policies). And it also has no deterministic decision process that makes clear which authorization, if known, has to be followed at a certain point. IMHO, operators, not the BGP spec, set down some rules of their own to avoid complete chaos: - Check some external database (authorization granted / denied from trusted third party) - Follow authorization grants/denials from adjacent BGP peers (to be on good terms with the direct neighbor is always more important than to please someone who lives three blocks away) Regards, --=20 Birger T=F6dtmann Technik der Rechnernetze, Institut f=FCr Experimentelle Mathematik Universit=E4t Duisburg-Essen, Campus Essen email:btoedtmann@iem.uni-due.de skype:birger.toedtmann pgp:0x6FB166C9 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 8 09:40:09 2005 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 JAA13273 for ; Tue, 8 Feb 2005 09:40:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyWqp-00063A-JS for rpsec-web-archive@ietf.org; Tue, 08 Feb 2005 10:00:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyWRN-0004Sv-Sq; Tue, 08 Feb 2005 09:34:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyWMV-0002rH-CU for rpsec@megatron.ietf.org; Tue, 08 Feb 2005 09:29:07 -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 JAA12526 for ; Tue, 8 Feb 2005 09:29:06 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyWg4-0005ow-Ii for rpsec@ietf.org; Tue, 08 Feb 2005 09:49:23 -0500 Received: from [10.84.130.245] (col-dhcp33-244-158.bbn.com [128.33.244.158]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j18ESNjf002333; Tue, 8 Feb 2005 09:28:23 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 8 Feb 2005 09:24:38 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] A Question on Authorization.... 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: 6d95a152022472c7d6cdf886a0424dc6 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: 2857c5c041d6c02d7181d602c22822c8 At 5:46 PM -0500 2/5/05, Russ White wrote: >Y'all: > >I'm still somewhat confused by the different meanings of "authorize" >being used on list, so I'd like to ask a couple of simple questions, >to perhaps allow everyone to come to a little better understanding. >Suppose we have this: > >A---B---C >| | >D---+ > >Now, suppose A has obtained 10.1.1.0/24 from D. A advertises this >prefix to B, who then advertises it to C. I would like to know: > >-- Does A's advertisement to B, in the absence of any other >communities, etc, authorize B to advertise 10.1.1.0/24 to C? yes. >-- Does A's advertisement to B, in the absence of any other >communities, etc, authorize B to transit 10.1.1.0/24 from C to A? Authorization, as I have used the term on this list, refers to permission for an AS to forward an advertisement; it does not apply directly to an AS's willingness to forward traffic. However, the two are linked, i.e., it is inappropriate to advertise a prefix for traffic that you do not intend to forward to the destination. So, in this case, A should not advertise the /24 to B with an implicit authorization to further advertise that prefix, unless A has an agreement with B in which B agrees to forward transit traffic. >-- Suppose A were to use some technique, NO_EXPORT, an AS Path TTL, >NO_PEER, redistribution communities, etc, etc, to prevent B from >advertising 10.1.1.0/24 to C. Does this imply that A is _not_ >authorizing B to transit for 10.1.1.0/24 from C to A? That if B does >happen to transit traffic destined to 10.1.1.0/24 from C to A, it is >"outside it's authorization limits?" If A advertises the /24 to B with NO_EXPORT, then it is telling B to not forward that advertisement to anyone else. As noted above, authorization does not apply directly to forwarding, but yes, if B forwards this /24 traffic from C, then it would be acting in a fashion inconsistent with the advertisement from A. However, note that authorization for advertisements has not been suggested as a substitute for agreements between peers that define traffic forwarding constraints. >If the answer to the last question is yes, is this the specific sort >of thing people would like to be able to "authorize" in a system >used to secure BGP--that B, in this case, is or is not authorized to >transit for 10.1.1.0/24 from C to A? One can raise the question of whether it is desirable to enhance BGP to express the info now contained in peer agreements that are outside the scope of BGP. However, since some ISPs have expressed a desire to not propagate this sort of info, putting it into BGP advertisements may not be a good idea. >If the answer to the last question is no, what other meaning is >there attached to the concept of "authorization?" In other words, if >A authorizes B to send routing information to C, what does that >mean, exactly, if it doesn't mean B is now authorized to transit for >10.1.1.0/24 between A and C? That C is authorized to send it to one >of their peers, and nothing more? What can it mean to authorize a >peer to send routing information to their peers, if not that the >peer you're sending the routing information to is now authorized to >transit for the prefixes you're sending? Authorization for route advertisements provides several security benefits distinct from the issue you raise here. - route authorization protects an originating AS (A) from having other ASes accept routes for prefixes originated by A, as a result of bogus (unauthorized) advertisements by other ASes. this helps protect the traffic forwarded to A from ASes around the Internet, in terms of misrouting. - route authorization allows ASes to detect and reject bogus (unauthorized) routes. this is the complement of the above bullet, in that it tries to prevent unauthorized forwarding from the perspective of a senders of traffic, vs. a receiver. The question you asked is whether a peer is "authorized to transit [sic] for the prefixes you're sending?" Whether a peer will forward traffic for a specified prefix to you from other ASes is not a matter of "authorization" as we have described the term. It is a separate issue of a business agreement between the ASes in question. However, you are right to note that if AS A authorizes a peer (B) to advertise a prefix to other ASes, then A should do so only if it has an agreement with B to cause the traffic for the prefix to transit B. If A fails to have such an agreement, B should not propagate the advertisement, since doing so will likely cause traffic to come to B that B does not want to forward. Similary, A should not send such an advertisement to B unless there is a traffic forwarding agreement in place, as B will likely drop the traffic in the absence of such an agreement. So, yes, if A makes a mistake and advertises a prefix to B with implicit authorization to forward the advertisement, and if B propagates the advertisement, despite the lack of an agreement to forward the transit traffic for A, then traffic to A may fall on the floor. (Or, if B is so sloppy, it may be forwarded anyway :-)) However, these failure modes are a form of self-inflicted damage, done by A to A, with some "help" from B. The adverse effects are a lot more limited in scope than what results from propagation and acceptance of generic, bogus route advertisements. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 8 18:16:49 2005 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 SAA18815 for ; Tue, 8 Feb 2005 18:16:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyeuu-00086h-PL for rpsec-web-archive@ietf.org; Tue, 08 Feb 2005 18:37:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyeQP-0002kT-VS; Tue, 08 Feb 2005 18:05:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cye4j-0002x3-T3 for rpsec@megatron.ietf.org; Tue, 08 Feb 2005 17:43:18 -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 RAA09658 for ; Tue, 8 Feb 2005 17:43:15 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyeOP-0005b7-E0 for rpsec@ietf.org; Tue, 08 Feb 2005 18:03:38 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j18Mh2dU022525; Tue, 8 Feb 2005 17:43:02 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAA01ai0R; Tue Feb 8 17:42:58 2005 Date: Tue, 8 Feb 2005 17:42:56 -0500 From: Tony Tauber To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: 02ec665d00de228c50c93ed6b5e4fc1a On Mon, 7 Feb 2005, Stephen Kent wrote: > At 6:47 PM +0100 2/5/05, Florian Weimer wrote: > > > >Wouldn't it be reasonable to assume that all the cruft that ends up > >in RADB today would receive a certificate in the new era? In other > >words, is it likely that we'll have route registries with strong > >authentication and authorization (!) checks? What happens to PI > >and early registration space? > > This is a fair question, but the problems are a bit different from > what I think you are suggesting. First, security for this process is > not the same as security for submission of data to IRRs. Second, the > PKI is easy to check for consistency, so it should be possible to > detect many forms of problems. But, I agree that the legacy address > space has to be cleaned up, something I believe ARIN is already > working on. Just a point of clarification; there are two different types of registries that people seem to have in mind for this function: - The RADB (mentioned by Florian, above) is part of the IRR (Internet Routing Registry) the mission of which is to handle routing policy information. Let's call these type of things "Routing Registries". - The ARIN (mentioned by Steve, above) is an "RIR" (Regional Internet Registry). Others in this category are RIPE, APNIC, AFRINIC, and LACNIC. Their authority is delegated by ICANN and IANA (might be wrong on some small details and don't want to get into a political discussion). They in turn delegate authority to LIRs (Local Internet Registries) and end-user organizations. Let's call these "Numbering Registries". My goal isn't to come to some decision or even significantly discuss which (if either) type of entity becomes part of some future of BGP, but just to clarify thinking points. Feel free to correct any of what follows (or what has preceded). Some features of each are: - Routing Registries are designed to hold routing information. If I'm not mistaken, they have a flat and variably interconnected topology, ie. they share and import information among themselves in some way [that's not clear to me.] - Numbering Registries are designed to track IP address (and other) number utilization and assignment, including to prevent collisions in same. They have a [fairly] defined and hierarchichal topology. People may want to think, eventually, of what information might be needed in a secure BGP solution. Let's try not, however, to be limited in our thinking based on what exists today. Let's be pragmatic but not overly pessimistic. Again, feel free to clarify, correct, comment, [dis]agree, etc. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 8 18:39:07 2005 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 SAA22525 for ; Tue, 8 Feb 2005 18:39:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyfGU-0000X2-Pi for rpsec-web-archive@ietf.org; Tue, 08 Feb 2005 18:59:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyeuz-0007Ws-QS; Tue, 08 Feb 2005 18:37:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyemM-0004p9-Ao for rpsec@megatron.ietf.org; Tue, 08 Feb 2005 18:28:22 -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 SAA21608 for ; Tue, 8 Feb 2005 18:28:19 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyf62-0000DR-1o for rpsec@ietf.org; Tue, 08 Feb 2005 18:48:43 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5636A2D4AD8; Tue, 8 Feb 2005 18:23:40 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 70971-01-76; Tue, 8 Feb 2005 18:23:39 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 2B1662D4846; Tue, 8 Feb 2005 18:23:39 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j18NNcd13568; Tue, 8 Feb 2005 18:23:38 -0500 (EST) Date: Tue, 8 Feb 2005 18:23:38 +2245 From: Jeffrey Haas To: Tony Tauber Subject: Re: [RPSEC] some thoughts on requirements Message-ID: <19750329193844.GP3965@nexthop.com> References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 1.7 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 1.7 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 On Sat, Mar 29, 1975 at 01:58:02PM -0500, Tony Tauber wrote: > - Routing Registries are designed to hold routing information. > If I'm not mistaken, they have a flat and variably interconnected > topology, ie. they share and import information among themselves in > some way [that's not clear to me.] It's a bit worse than that. Each database can hold overlapping information with differing ownership. RPS-Auth and RPS-Dist were intended to clarify ownership of information and deal with distributing the information amongst the several registries. Effectively, anyone can have their own local registry of the entire Internet. You can also have your information registered and take other people's object as feeds via the various mirroring mechanisms. However, these mirrors tend to mirror an entire database. Things largely "work", but I suspect that certain operational practices will need to be clarified for this to work where we expect it to in the security infrastructure. > - Numbering Registries are designed to track IP address (and other) > number utilization and assignment, including to prevent collisions > in same. They have a [fairly] defined and hierarchichal topology. They're also generally at the level of initial assignment to an actual user of the address space. Items of convenience: o Providers like RIPE and APNIC use objects that also have significance as routing policy objects. o In some cases, the RIR and the IRR are the same. RIPE is an example of this. > Tony -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 9 09:21:32 2005 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 JAA04812 for ; Wed, 9 Feb 2005 09:21:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyt2Z-0008Kn-7z for rpsec-web-archive@ietf.org; Wed, 09 Feb 2005 09:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cysgy-0003fe-PI; Wed, 09 Feb 2005 09:19:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CysYW-0001mZ-OK for rpsec@megatron.ietf.org; Wed, 09 Feb 2005 09:11:00 -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 JAA04258 for ; Wed, 9 Feb 2005 09:10:58 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyssK-00089R-Eg for rpsec@ietf.org; Wed, 09 Feb 2005 09:31:29 -0500 Received: from pc6 (1Cust46.tnt2.lnd4.gbr.da.uu.net [62.188.131.46]) by ranger.systems.pipex.net (Postfix) with SMTP id 2950FE0002F5; Wed, 9 Feb 2005 14:10:23 +0000 (GMT) Message-ID: <033701c50ea8$71871560$0601a8c0@pc6> From: "Tom Petch" To: "Tony Tauber" References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> Subject: Re: [RPSEC] some thoughts on requirements Date: Wed, 9 Feb 2005 14:06:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit I think it worth adding a mention of AS number (alongside prefix) since without it, you cannot generate a BGP Update message:-) And a key part of BGP security is authorising the relationship between originating AS number and prefix ie I expect any security protocol to need access to an external database that contains information about organisational entities and their allocations of AS number and prefix. One issue is I haven't seen raised is whether or not BGP security should cater for private (as opposed to public) AS numbers. My take is not, that it is the 'public' BGP we should be securing and where private AS numbers are involved, then that is an issue internal to the organisation(s). A consequence of this is that if you have a public AS number, then you should be an LIR under the current setup so that the organisational entity and the allocation of prefix and AS number thereto is all in the 'Numbering Registry'. Tom Petch ----- Original Message ----- From: "Tony Tauber" To: "Stephen Kent" Cc: Sent: Tuesday, February 08, 2005 11:42 PM Subject: Re: [RPSEC] some thoughts on requirements > On Mon, 7 Feb 2005, Stephen Kent wrote: > > > At 6:47 PM +0100 2/5/05, Florian Weimer wrote: > > > > > >Wouldn't it be reasonable to assume that all the cruft that ends up > > >in RADB today would receive a certificate in the new era? In other > > >words, is it likely that we'll have route registries with strong > > >authentication and authorization (!) checks? What happens to PI > > >and early registration space? > > > > This is a fair question, but the problems are a bit different from > > what I think you are suggesting. First, security for this process is > > not the same as security for submission of data to IRRs. Second, the > > PKI is easy to check for consistency, so it should be possible to > > detect many forms of problems. But, I agree that the legacy address > > space has to be cleaned up, something I believe ARIN is already > > working on. > > Just a point of clarification; there are two different types of > registries that people seem to have in mind for this function: > > - The RADB (mentioned by Florian, above) is part of the IRR (Internet > Routing Registry) the mission of which is to handle routing policy > information. Let's call these type of things "Routing Registries". > > - The ARIN (mentioned by Steve, above) is an "RIR" (Regional Internet > Registry). Others in this category are RIPE, APNIC, AFRINIC, and LACNIC. > Their authority is delegated by ICANN and IANA (might be wrong on > some small details and don't want to get into a political discussion). > They in turn delegate authority to LIRs (Local Internet Registries) > and end-user organizations. Let's call these "Numbering Registries". > > My goal isn't to come to some decision or even significantly discuss > which (if either) type of entity becomes part of some future of BGP, > but just to clarify thinking points. Feel free to correct any of what > follows (or what has preceded). > > Some features of each are: > > - Routing Registries are designed to hold routing information. > If I'm not mistaken, they have a flat and variably interconnected > topology, ie. they share and import information among themselves in > some way [that's not clear to me.] > > - Numbering Registries are designed to track IP address (and other) > number utilization and assignment, including to prevent collisions > in same. They have a [fairly] defined and hierarchichal topology. > > People may want to think, eventually, of what information might be > needed in a secure BGP solution. Let's try not, however, to be > limited in our thinking based on what exists today. Let's be > pragmatic but not overly pessimistic. > > Again, feel free to clarify, correct, comment, [dis]agree, etc. > > Tony > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 9 10:25:19 2005 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 KAA10245 for ; Wed, 9 Feb 2005 10:25:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyu2E-0001LK-9e for rpsec-web-archive@ietf.org; Wed, 09 Feb 2005 10:45:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cytgx-0007TQ-Ef; Wed, 09 Feb 2005 10:23:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cytfr-00076t-DI for rpsec@megatron.ietf.org; Wed, 09 Feb 2005 10:22:39 -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 KAA09954 for ; Wed, 9 Feb 2005 10:22:37 -0500 (EST) Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cytzf-0001HO-Nv for rpsec@ietf.org; Wed, 09 Feb 2005 10:43:09 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D9EF02D4B1B; Wed, 9 Feb 2005 10:21:18 -0500 (EST) Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 40977-01-65; Wed, 9 Feb 2005 10:21:17 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8D2AB2D4B3E; Wed, 9 Feb 2005 10:21:17 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j19FLGl16135; Wed, 9 Feb 2005 10:21:17 -0500 (EST) Date: Wed, 9 Feb 2005 10:21:16 +2245 From: Jeffrey Haas To: Tom Petch Subject: Re: [RPSEC] some thoughts on requirements Message-ID: <19750330113622.GT3965@nexthop.com> References: <033701c50ea8$71871560$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <033701c50ea8$71871560$0601a8c0@pc6> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 1.7 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: rpsec@ietf.org, Tony Tauber X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 1.7 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Tom, On Sun, Mar 30, 1975 at 10:21:37AM +0100, Tom Petch wrote: > One issue is I haven't seen raised is whether or not BGP security should cater > for private (as opposed to public) AS numbers. My take is not, that it is the > 'public' BGP we should be securing and where private AS numbers are involved, > then that is an issue internal to the organisation(s). IMO, so long as our mechanism can account for authorization to a local registry, we should be able to use most of the same mechanisms. I think we've already agreed that our security mechanisms have to be able to deal with removing private AS numbers. (If not, we have further work to do.) A convenient side-effect is that if you don't remove the private AS numbers, you'll have an origin AS authentication failure and the routes will probably get dropped. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 9 14:47:42 2005 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 OAA05722 for ; Wed, 9 Feb 2005 14:47:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyy8G-0000Nt-28 for rpsec-web-archive@ietf.org; Wed, 09 Feb 2005 15:08:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyxWK-0004js-Lq; Wed, 09 Feb 2005 14:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyxJ2-0000KD-K3 for rpsec@megatron.ietf.org; Wed, 09 Feb 2005 14:15: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 OAA29204 for ; Wed, 9 Feb 2005 14:15:19 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyxct-0006xW-W6 for rpsec@ietf.org; Wed, 09 Feb 2005 14:35:52 -0500 Received: from [10.84.130.245] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j19JESjl029575; Wed, 9 Feb 2005 14:14:37 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> Date: Wed, 9 Feb 2005 14:04:41 -0500 To: Tony Tauber From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 7d33c50f3756db14428398e2bdedd581 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Tony, > > > > >People may want to think, eventually, of what information might be >needed in a secure BGP solution. Let's try not, however, to be >limited in our thinking based on what exists today. Let's be >pragmatic but not overly pessimistic. > >Again, feel free to clarify, correct, comment, [dis]agree, etc. As you noted, my comment focused on RIRs (and LIRs, etc.) since they are responsible for allocation of prefixes and of AS numbers, the data items of primary, initial concern here. They form the tree structured, authoritative system for allocation of these data items and that is what I think one needs to secure first, to create a basis for tracking which ASes are authorized to originate which prefixes. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 10 03:41:08 2005 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 DAA07121 for ; Thu, 10 Feb 2005 03:41:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzACo-0005WH-FN for rpsec-web-archive@ietf.org; Thu, 10 Feb 2005 04:01:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz9hS-00005q-9N; Thu, 10 Feb 2005 03:29:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz9fC-0007U3-Qf for rpsec@megatron.ietf.org; Thu, 10 Feb 2005 03:27:03 -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 DAA05993 for ; Thu, 10 Feb 2005 03:27:01 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.204] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz9zA-0005D6-9N for rpsec@ietf.org; Thu, 10 Feb 2005 03:47:41 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 3.35 #1) id 1Cz9ef-00011a-00; Thu, 10 Feb 2005 09:26:29 +0100 Message-ID: <420B1AB7.7070500@schlund.net> Date: Thu, 10 Feb 2005 09:26:31 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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="===============0636973900==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0636973900== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig65EA45A2DB6ADE63C678BF41" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig65EA45A2DB6ADE63C678BF41 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Stephen, Stephen Kent wrote: > As you noted, my comment focused on RIRs (and LIRs, etc.) since they are > responsible for allocation of prefixes and of AS numbers, the data items > of primary, initial concern here. They form the tree structured, > authoritative system for allocation of these data items and that is what > I think one needs to secure first, to create a basis for tracking which > ASes are authorized to originate which prefixes. if all RIRs were using RPSS, the registry system would be quite secure IMHO. It's not certificate based, but only based on the integrity of the RIR databases, but if you don't trust them, why would you trust any certificates (created based on the same data)? :) tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig65EA45A2DB6ADE63C678BF41 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCCxq3ehvPYvDU0roRAr/bAJ93CH6m/12X+K7yLlp6CHMrv0j5BgCeJX4p 3f4DB4JLGOPQ1Y9XYXyOI90= =p03D -----END PGP SIGNATURE----- --------------enig65EA45A2DB6ADE63C678BF41-- --===============0636973900== 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 --===============0636973900==-- From rpsec-bounces@ietf.org Thu Feb 10 13:21:35 2005 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 NAA23178 for ; Thu, 10 Feb 2005 13:21:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzJGf-00020M-0u for rpsec-web-archive@ietf.org; Thu, 10 Feb 2005 13:42:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzIro-0004mw-46; Thu, 10 Feb 2005 13:16:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzIqw-0004KB-UZ for rpsec@megatron.ietf.org; Thu, 10 Feb 2005 13:15:47 -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 NAA22697 for ; Thu, 10 Feb 2005 13:15:43 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzJB0-0001qK-RO for rpsec@ietf.org; Thu, 10 Feb 2005 13:36:31 -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 j1AIFFjf023187; Thu, 10 Feb 2005 13:15:15 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <420B1AB7.7070500@schlund.net> References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> <420B1AB7.7070500@schlund.net> Date: Thu, 10 Feb 2005 12:34:24 -0500 To: Stefan Mink From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 97adf591118a232206bdb5a27b217034 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d At 9:26 AM +0100 2/10/05, Stefan Mink wrote: >Hi Stephen, > >Stephen Kent wrote: >>As you noted, my comment focused on RIRs (and LIRs, etc.) since >>they are responsible for allocation of prefixes and of AS numbers, >>the data items of primary, initial concern here. They form the tree >>structured, authoritative system for allocation of these data items >>and that is what I think one needs to secure first, to create a >>basis for tracking which ASes are authorized to originate which >>prefixes. > >if all RIRs were using RPSS, the registry system would be quite >secure IMHO. It's not certificate based, but only based on the >integrity of the RIR databases, but if you don't trust them, why >would you trust any certificates (created based on the same data)? :) > > tschuess > Stefan I am not familiar with RPSS, so I cannot comment on the relative security of it vs. use of certs. However, as a rule of thumb, one achieves a greater level of security by storing signed data in a repository, than by trying to make the repository itself secure against insertion of bogus data or tampering with stored, valid data. Also, if one requires a repository to be distributed, there are substantial advantages to the use of certs and signed data, as a means of secure distribution of the data among multiple sites. Thus there seem to be substantial advantages to using certs and additional signed data (to represent which ASes the prefix holder has authorized to advertise its address blocks) in this context. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 10 17:52:38 2005 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 RAA02029 for ; Thu, 10 Feb 2005 17:52:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzNV0-0005NP-9a for rpsec-web-archive@ietf.org; Thu, 10 Feb 2005 18:13:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzMwG-0002E5-Cf; Thu, 10 Feb 2005 17:37:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzM1P-00077C-GN for rpsec@megatron.ietf.org; Thu, 10 Feb 2005 16:38:47 -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 QAA16274 for ; Thu, 10 Feb 2005 16:38:44 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.201] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzMLS-0008T2-Ii for rpsec@ietf.org; Thu, 10 Feb 2005 16:59:33 -0500 Received: from [172.17.19.3] (helo=[172.17.19.3]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CzM1K-0000rM-Hl; Thu, 10 Feb 2005 22:38:42 +0100 Message-ID: <420BD45A.2070003@schlund.net> Date: Thu, 10 Feb 2005 22:38:34 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> <420B1AB7.7070500@schlund.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Stephen Kent wrote: > I am not familiar with RPSS, so I cannot comment on the relative > security of it vs. use of certs. However, as a rule of thumb, this line is a little bit inconsistent ;) > one achieves a greater level of security by storing signed data in a > repository, than by trying to make the repository itself secure > against insertion of bogus data or tampering with stored, valid data. you only get a greater level of security because an attacker can not change data on the database system without everybody noticing it. Otherwise I don't see an advantage vs. fetching the data via TLS. So this addresses system security, but not routing security. > Also, if one requires a repository to be distributed, there are > substantial advantages to the use of certs and signed data, as a means > of secure distribution of the data among multiple sites. > > Thus there seem to be substantial advantages to using certs and > additional signed data (to represent which ASes the prefix holder has > authorized to advertise its address blocks) in this context. the advantage of certificates vs. fetched data out of a secure database is that you can forward it to somebody else and he check its authenticity. Nevertheless this is already an optimization of a solved problem. If every RIR would use RPSS and the databases would include legacy space, we would have a mechanism to check for unauthorized originations. Otherwise certificates couldn't solve the problem... On the other hand the verification of readvertisements is not adressed by any security architecture and is not possible today. So we should first try to find means to change that instead of trying to make something better, because "verification of origination authorization is just the beginning of routing security" ;-) tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 10 17:59:40 2005 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 RAA03302 for ; Thu, 10 Feb 2005 17:59:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzNbo-0005hu-VV for rpsec-web-archive@ietf.org; Thu, 10 Feb 2005 18:20:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzN8O-0003N4-B5; Thu, 10 Feb 2005 17:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzMs7-00067T-0S for rpsec@megatron.ietf.org; Thu, 10 Feb 2005 17:33:15 -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 RAA28729 for ; Thu, 10 Feb 2005 17:33:12 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzNCC-0004Em-T6 for rpsec@ietf.org; Thu, 10 Feb 2005 17:54:01 -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 j1AMWcVZ008548; Thu, 10 Feb 2005 17:32:39 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <420BD45A.2070003@schlund.net> References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> <420B1AB7.7070500@schlund.net> <420BD45A.2070003@schlund.net> Date: Thu, 10 Feb 2005 16:53:46 -0500 To: Stefan Mink From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: b7b9551d71acde901886cc48bfc088a6 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: 10ba05e7e8a9aa6adb025f426bef3a30 At 10:38 PM +0100 2/10/05, Stefan Mink wrote: >Stephen Kent wrote: > >>I am not familiar with RPSS, so I cannot comment on the relative >>security of it vs. use of certs. However, as a rule of thumb, > > >this line is a little bit inconsistent ;) not much :-) > >>one achieves a greater level of security by storing signed data in >>a repository, than by trying to make the repository itself secure >>against insertion of bogus data or tampering with stored, valid >>data. > > >you only get a greater level of security because an attacker can not change >data on the database system without everybody noticing it. Otherwise >I don't see >an advantage vs. fetching the data via TLS. the differences are more significant. if one fetches the data via a TLS-protected connection, you are only authenticating the entity who connected, but the repository is responsible for enforcing access controls on who make what changes, and there are many ways this can go awry. If one stores signed data, and each user verifies the data signatures and the hierarchic delegation, then the users are guaranteed to detect tampering. Thus one need not rely as much on good security administration by the repository operators. > >So this addresses system security, but not routing security. yes. this is a system security issue in support of routing security. it is an issue of how to secure the infrastructure that represents prefix allocation and origin AS authorization. > >>Also, if one requires a repository to be distributed, there are >>substantial advantages to the use of certs and signed data, as a >>means of secure distribution of the data among multiple sites. >> >>Thus there seem to be substantial advantages to using certs and >>additional signed data (to represent which ASes the prefix holder >>has authorized to advertise its address blocks) in this context. > > >the advantage of certificates vs. fetched data out of a secure >database is that you can forward >it to somebody else and he check its authenticity. Nevertheless this >is already an optimization >of a solved problem. If every RIR would use RPSS and the databases >would include legacy >space, we would have a mechanism to check for unauthorized >originations. Otherwise >certificates couldn't solve the problem... Let me ask a question about an analogous (though not perfectly analogous) system, DNS. We have developed DNSSEC, relying on signatures to secure DNS records, because that technology allows us to reduce reliance on secure management of each DNS server, and it allows us to distribute DNS data securely, via caching. DNS is analogous in that it too is a hierarchic system with clear lines of authorization, that makes it conceptually easy for users to retrieve the records, signatures, and matching keys to verify record authenticity. Do you see this as an optimization too? >On the other hand the verification of readvertisements is not >adressed by any security >architecture and is not possible today. So we should first try to >find means to change >that instead of trying to make something better, because >"verification of origination >authorization is just the beginning of routing security" ;-) verification of advertisements is what I would like to see. I thought this thread of the discussion was addressing the question of how one could could provide a secure infrastructure to represent prefix allocation/delegation and subsequent authorization of an As to advertise itself as the origin for a prefix. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 10 18:12:56 2005 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 SAA05550 for ; Thu, 10 Feb 2005 18:12:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzNoe-0006Dr-0q for rpsec-web-archive@ietf.org; Thu, 10 Feb 2005 18:33:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzNIh-0008Oz-MF; Thu, 10 Feb 2005 18:00:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzN9j-0004WA-3z for rpsec@megatron.ietf.org; Thu, 10 Feb 2005 17:51:27 -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 RAA01824 for ; Thu, 10 Feb 2005 17:51:24 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.204] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzNTo-0005It-EV for rpsec@ietf.org; Thu, 10 Feb 2005 18:12:13 -0500 Received: from [172.17.19.3] (helo=[172.17.19.3]) by mxintern.kundenserver.de with esmtp (Exim 3.35 #1) id 1CzN95-0003oT-00; Thu, 10 Feb 2005 23:50:47 +0100 Message-ID: <420BE53F.5020204@schlund.net> Date: Thu, 10 Feb 2005 23:50:39 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> <420B1AB7.7070500@schlund.net> <420BD45A.2070003@schlund.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Stephen Kent wrote: > Let me ask a question about an analogous (though not perfectly > analogous) system, DNS. We have developed DNSSEC, relying on > signatures to secure DNS records, because that technology allows us to > reduce reliance on secure management of each DNS server, and it allows > us to distribute DNS data securely, via caching. DNS is analogous in > that it too is a hierarchic system with clear lines of authorization, > that makes it conceptually easy for users to retrieve the records, > signatures, and matching keys to verify record authenticity. Do you > see this as an optimization too? You are right with that one! The reason why I didn't see a difference is that the whois-system of RIPE for routing data is not distributed but AFAIK in the ARIN region it is (SWIP/RWHOIS). If you have a central authoritative system, certificates don't give you a big advantage over data fetched via TLS. In a distributed system, this gets more complex and certificates make more sense. tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 10 21:36:14 2005 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 VAA20024 for ; Thu, 10 Feb 2005 21:36:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzQzQ-0001o5-BA for rpsec-web-archive@ietf.org; Thu, 10 Feb 2005 21:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzQdX-0002Wf-R9; Thu, 10 Feb 2005 21:34:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzQcN-0002Jx-Hu for rpsec@megatron.ietf.org; Thu, 10 Feb 2005 21:33:15 -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 VAA19900 for ; Thu, 10 Feb 2005 21:33:13 -0500 (EST) Received: from mxsf09.cluster1.charter.net ([209.225.28.209]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzQwU-0001kT-DJ for rpsec@ietf.org; Thu, 10 Feb 2005 21:54:03 -0500 Received: from mxip06.cluster1.charter.net (mxip06a.cluster1.charter.net [209.225.28.136]) by mxsf09.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j1B2WbPI019303 for ; Thu, 10 Feb 2005 21:32:38 -0500 Received: from 66-215-182-64.riv-mres.charterpipeline.net (HELO [192.168.0.100]) (66.215.182.64) by mxip06.cluster1.charter.net with ESMTP; 10 Feb 2005 21:32:38 -0500 X-Ironport-AV: i="3.88,194,1102309200"; d="scan'208"; a="595167526:sNHT13080284" Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: rpsec@ietf.org From: Georgos Siganos Date: Thu, 10 Feb 2005 18:32:35 -0800 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: [RPSEC] An evaluation of whether an IRR(RIPE) can be used to detect abnormal routing. 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: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Hello, For my research, I examined how useful RIPE can be as the foundation of a reactive based system for routing security. Basically, the question we tried to answer is what can happen today? Is there anything better we can do other than wait for a secure BGP protocol. For a time period of 10 days, we analyzed the routing table and the updates that router rrc03 (RIS router at AMS-IX) received. We focus only on the prefixes that RIPE administers. We found that using the RIPE registry, we can validate the origin AS for 97% of the unique prefix,origin tuples. Additionally, for approximately 60% of the ASes that register policies in RIPE, we can not find any deviation between the registered policies and actual routing. You can find more details in our paper at: http://www.cs.ucr.edu/~siganos/papers/security.pdf Do you believe that reactive based systems can be a viable short term solution? For example, RIPE is working towards a similar direction with the MyASN project. They don't use the information that exists in their registry, instead ISPs need to explicitly register the prefixes they want to monitor. I hope you find my work relevant to your working group. Please let me know if you have any comments or suggestions. Thanks, Georgos Siganos The paper that describes how you can extract the policies from IRR can be found at: http://www.cs.ucr.edu/~siganos/papers/Nemecis.pdf You can find a demo of my tool at: http://ira.cs.ucr.edu:8080/Nemecis _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 11 10:11:52 2005 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 KAA05034 for ; Fri, 11 Feb 2005 10:11:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czcmm-0000Zw-LQ for rpsec-web-archive@ietf.org; Fri, 11 Feb 2005 10:32:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzcPz-0006Cv-5w; Fri, 11 Feb 2005 10:09:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzcLu-0004cJ-0z for rpsec@megatron.ietf.org; Fri, 11 Feb 2005 10:05:02 -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 KAA04005 for ; Fri, 11 Feb 2005 10:05:00 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czcg7-0000MC-Mf for rpsec@ietf.org; Fri, 11 Feb 2005 10:25:56 -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 j1BF4JVf003881; Fri, 11 Feb 2005 10:04:24 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <420BE53F.5020204@schlund.net> References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> <420B1AB7.7070500@schlund.net> <420BD45A.2070003@schlund.net> <420BE53F.5020204@schlund.net> Date: Fri, 11 Feb 2005 09:35:32 -0500 To: Stefan Mink From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: ea4ac80f790299f943f0a53be7e1a21a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 At 11:50 PM +0100 2/10/05, Stefan Mink wrote: >Stephen Kent wrote: > >>Let me ask a question about an analogous (though not perfectly >>analogous) system, DNS. We have developed DNSSEC, relying on >>signatures to secure DNS records, because that technology allows us >>to reduce reliance on secure management of each DNS server, and it >>allows us to distribute DNS data securely, via caching. DNS is >>analogous in that it too is a hierarchic system with clear lines of >>authorization, that makes it conceptually easy for users to >>retrieve the records, signatures, and matching keys to verify >>record authenticity. Do you see this as an optimization too? > > >You are right with that one! The reason why I didn't see a >difference is that the >whois-system of RIPE for routing data is not distributed but AFAIK in the >ARIN region it is (SWIP/RWHOIS). If you have a central authoritative system, >certificates don't give you a big advantage over data fetched via TLS. In a >distributed system, this gets more complex and certificates make more sense. > > tschuess > Stefan I think that we will need to be able to distribute the data about prefix holders and origin AS authorization, to ensure a reasonable level of availability, hence my suggestion that certs and signed data are a preferred approach. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Feb 12 11:01:38 2005 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 LAA11658 for ; Sat, 12 Feb 2005 11:01:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D002j-0005d4-5M for rpsec-web-archive@ietf.org; Sat, 12 Feb 2005 11:22:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czzfm-0005Ec-ER; Sat, 12 Feb 2005 10:59:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czzen-000513-TA for rpsec@megatron.ietf.org; Sat, 12 Feb 2005 10:58:06 -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 KAA11434 for ; Sat, 12 Feb 2005 10:58:03 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzzzE-0005a2-8M for rpsec@ietf.org; Sat, 12 Feb 2005 11:19:13 -0500 Received: from pc6 (1Cust64.tnt30.lnd3.gbr.da.uu.net [62.188.122.64]) by ranger.systems.pipex.net (Postfix) with SMTP id 75493E00025C; Sat, 12 Feb 2005 15:57:28 +0000 (GMT) Message-ID: <002001c51112$e3b99100$0601a8c0@pc6> From: "Tom Petch" To: "Stefan Mink" References: <42009220.6080602@schlund.net><4201D4D3.6050507@schlund.net><4202B2EB.8080100@schlund.net><87fz0a6grs.fsf@deneb.enyo.de><420B1AB7.7070500@schlund.net> <420BD45A.2070003@schlund.net> Subject: Re: [RPSEC] some thoughts on requirements Date: Sat, 12 Feb 2005 15:53:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Tom Petch ----- Original Message ----- From: "Stefan Mink" To: "Stephen Kent" Cc: Sent: Thursday, February 10, 2005 10:38 PM Subject: Re: [RPSEC] some thoughts on requirements > the advantage of certificates vs. fetched data out of a secure database > is that you can forward > it to somebody else and he check its authenticity. Nevertheless this is > already an optimization > of a solved problem. If every RIR would use RPSS and the databases would > include legacy space, There is a project, ERX (Early Registration transfer), which has been alluded to before, to transfer central registry information from ARIN, who inherited it from InterNIC, to RIRs. The project page (for RIPE, one of the recipients) is http://www.ripe.net/db/erx/erx-ip/ while the project outline is at http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-db-erx/ (My experience is that these links work sometimes:-). This project does go into resolving disputes about allocations ie it goes beyond the administrative work of putting the right data in the right RIR. (Personally, though, I do fear that at the end of it there will still be a hard core of items for which resolution will prove too difficult, that those who have been doing it their way for decades will prove hard to bring into the 21st century). _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Feb 12 11:02:45 2005 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 LAA11715 for ; Sat, 12 Feb 2005 11:02:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D003n-0005e9-V9 for rpsec-web-archive@ietf.org; Sat, 12 Feb 2005 11:23:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czzfm-0005Eh-Sf; Sat, 12 Feb 2005 10:59:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czzen-000514-TB for rpsec@megatron.ietf.org; Sat, 12 Feb 2005 10:58:06 -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 KAA11438 for ; Sat, 12 Feb 2005 10:58:03 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzzzE-0005a3-9n for rpsec@ietf.org; Sat, 12 Feb 2005 11:19:13 -0500 Received: from pc6 (1Cust64.tnt30.lnd3.gbr.da.uu.net [62.188.122.64]) by ranger.systems.pipex.net (Postfix) with SMTP id 45D02E0002F0; Sat, 12 Feb 2005 15:57:31 +0000 (GMT) Message-ID: <002101c51112$e4adb500$0601a8c0@pc6> From: "Tom Petch" To: "Stefan Mink" , "Stephen Kent" References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> <420B1AB7.7070500@schlund.net> <420BD45A.2070003@schlund.net> <420BE53F.5020204@schlund.net> Subject: Re: [RPSEC] some thoughts on requirements Date: Sat, 12 Feb 2005 15:54:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit I do see this as a discussion on implementation (or design) details rather than requirements ie great to have - later. ie the requirement is (something like) to have access to an external database which securely associates AS number(s), prefix - and IMHO an organisational entity ie it is not enough to tie AS number and prefix together, we need to tie them into a something or someone. Where the data comes from, how it is stored, even whether or not it currently exists, seems to come later; assuming we reach agreement on requirements:-) Tom Petch ----- Original Message ----- From: "Stephen Kent" To: "Stefan Mink" Cc: Sent: Friday, February 11, 2005 3:35 PM Subject: Re: [RPSEC] some thoughts on requirements > At 11:50 PM +0100 2/10/05, Stefan Mink wrote: > >Stephen Kent wrote: > > > >>Let me ask a question about an analogous (though not perfectly > >>analogous) system, DNS. We have developed DNSSEC, relying on > >>signatures to secure DNS records, because that technology allows us > >>to reduce reliance on secure management of each DNS server, and it > >>allows us to distribute DNS data securely, via caching. DNS is > >>analogous in that it too is a hierarchic system with clear lines of > >>authorization, that makes it conceptually easy for users to > >>retrieve the records, signatures, and matching keys to verify > >>record authenticity. Do you see this as an optimization too? > > > > > >You are right with that one! The reason why I didn't see a > >difference is that the > >whois-system of RIPE for routing data is not distributed but AFAIK in the > >ARIN region it is (SWIP/RWHOIS). If you have a central authoritative system, > >certificates don't give you a big advantage over data fetched via TLS. In a > >distributed system, this gets more complex and certificates make more sense. > > > > tschuess > > Stefan > > I think that we will need to be able to distribute the data about > prefix holders and origin AS authorization, to ensure a reasonable > level of availability, hence my suggestion that certs and signed data > are a preferred approach. > > Steve > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Feb 12 15:39:50 2005 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 PAA29612 for ; Sat, 12 Feb 2005 15:39:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D04Ny-0002Mq-GN for rpsec-web-archive@ietf.org; Sat, 12 Feb 2005 16:01:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D040j-0006rf-2g; Sat, 12 Feb 2005 15:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D03we-0005pV-Cq for rpsec@megatron.ietf.org; Sat, 12 Feb 2005 15:32: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 PAA28949 for ; Sat, 12 Feb 2005 15:32:46 -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 1D04H7-00023t-T9 for rpsec@ietf.org; Sat, 12 Feb 2005 15:53:59 -0500 Received: from [208.231.75.210] ([208.231.75.210]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j1CKW6sh011497 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 12 Feb 2005 15:32:10 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 12 Feb 2005 15:32:01 -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: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [RPSEC] Draft updates 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Folks, I am about to make pre-conference updates to the draft. So far, the most extensive set of recommendations come from Steve in his email entitled "some thoughts on requirements" (and I will do my best to incorporate them). If you have suggested text for the draft please forward this coming week! Please, for the sake of my fingers, I do not want to see a wholesale revision of the document. Just suggested additions/changes/drops. Preferrable with the text to be replaced/deleted cited or the insertion point indicated. I am making an exception for Steve . Regards, Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 14 09:31:26 2005 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 JAA07698 for ; Mon, 14 Feb 2005 09:31:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0hau-0003cM-6K for rpsec-web-archive@ietf.org; Mon, 14 Feb 2005 09:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0h5l-0000gQ-P5; Mon, 14 Feb 2005 09:20:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0h2p-0000DT-A7 for rpsec@megatron.ietf.org; Mon, 14 Feb 2005 09:17:47 -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 JAA06416 for ; Mon, 14 Feb 2005 09:17:45 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0hNf-0003G1-62 for rpsec@ietf.org; Mon, 14 Feb 2005 09:39:20 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j1EEHiwE011937 for ; Mon, 14 Feb 2005 09:17:44 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAALAa4rw; Mon Feb 14 09:17:27 2005 Date: Mon, 14 Feb 2005 09:17:25 -0500 From: Tony Tauber To: rpsec@ietf.org Subject: Re: [RPSEC] Generic Threats Draft WG Last Call In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: e5ba305d0e64821bf3d8bc5d3bb07228 Working Group Last Call for the Generic Threats document has now passed and the document will now be passed to the IESG. Thanks, Tony On Sun, 30 Jan 2005, Tony Tauber wrote: > Date: Sun, 30 Jan 2005 23:04:56 -0500 > From: Tony Tauber > To: rpsec@ietf.org > Subject: [RPSEC] Generic Threats Draft WG Last Call > > Hi all, > > Since Sandy Murphy presented the most recent updates to the Generic > Threats doc > (http://ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-07.txt) > at the last meeting, we're due for a Working Group Last Call on it. > > Please send any feedback, pro or con, to the list by Monday, 2/14/2005. > > Thanks, > > Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 14 11:16:09 2005 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 LAA18192 for ; Mon, 14 Feb 2005 11:16:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0jEH-0005xD-O2 for rpsec-web-archive@ietf.org; Mon, 14 Feb 2005 11:37:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0ioA-0003Bt-Jo; Mon, 14 Feb 2005 11:10:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0iip-0002S7-1B for rpsec@megatron.ietf.org; Mon, 14 Feb 2005 11:05:15 -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 LAA17197 for ; Mon, 14 Feb 2005 11:05:12 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0j3f-0005hW-IW for rpsec@ietf.org; Mon, 14 Feb 2005 11:26:48 -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 j1EG4Z6D016340; Mon, 14 Feb 2005 11:04:38 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <002101c51112$e4adb500$0601a8c0@pc6> References: <42009220.6080602@schlund.net> <4201D4D3.6050507@schlund.net> <4202B2EB.8080100@schlund.net> <87fz0a6grs.fsf@deneb.enyo.de> <420B1AB7.7070500@schlund.net> <420BD45A.2070003@schlund.net> <420BE53F.5020204@schlund.net> <002101c51112$e4adb500$0601a8c0@pc6> Date: Mon, 14 Feb 2005 10:54:51 -0500 To: Tom Petch From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV 0.82/706/Sun Feb 13 19:14:02 2005 on aragorn X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 At 3:54 PM +0100 2/12/05, Tom Petch wrote: >I do see this as a discussion on implementation (or design) details >rather than >requirements ie great to have - later. good point. > >ie the requirement is (something like) to have access to an external database >which securely associates AS number(s), prefix - and IMHO an organisational >entity ie it is not enough to tie AS number and prefix together, we >need to tie >them into a something or someone. we need to articulate the motivations for each binding. for example, to address bogus advertisements of prefix origination, one needs three kinds of bindings. - One set represents the allocation of prefixes from IANA->RIR->NIR/LIR->ISP to track these allocations to organizations. - one set binds AS numbers to organizations. this one and the previous bindings might be done together, as suggested in RFC 3779. - one set represents authorization by a prefix holder of an AS to advertise the prefix as being originated by the AS (hence the need for the previous set of AS-to-organization) bindings >Where the data comes from, how it is stored, even whether or not it currently >exists, seems to come later; assuming we reach agreement on requirements:-) > >Tom Petch the question of where the data comes from is important, to the extent that we have authoritative sources for this data. if one chooses to not take this into account, the result is more general, but it is also much more vulnerable to failures in "trust models." Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 14 11:38:42 2005 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 LAA19880 for ; Mon, 14 Feb 2005 11:38:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0ja7-0006QS-8H for rpsec-web-archive@ietf.org; Mon, 14 Feb 2005 12:00:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0jAp-0005k8-Tl; Mon, 14 Feb 2005 11:34:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0j9o-0005ec-T1 for rpsec@megatron.ietf.org; Mon, 14 Feb 2005 11:33:09 -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 LAA19452 for ; Mon, 14 Feb 2005 11:33:05 -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 1D0jUe-0006If-NO for rpsec@ietf.org; Mon, 14 Feb 2005 11:54:43 -0500 Received: from [208.231.75.210] ([208.231.75.210]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j1EGVvsh008207 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 14 Feb 2005 11:32:20 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 14 Feb 2005 11:31:51 -0500 Subject: Re: [RPSEC] some thoughts on requirements From: Blaine Christian To: Stephen Kent , Tom Petch 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: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit > the question of where the data comes from is important, to the extent > that we have authoritative sources for this data. if one chooses to > not take this into account, the result is more general, but it is > also much more vulnerable to failures in "trust models." All, I have been toying with language to the effect that a SHOULD (or maybe even a MUST) is that the means of identifying authorization should be confined to the individual routers. In other words, as in today's model, the routers should only require local knowledge of their current peers in order to become a functioning part of the network. The attempt is to avoid issues with requiring the purchase of yet more external servers and to avoid implementation/bringup issues. Anyone have thoughts on that? _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 14 11:54:51 2005 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 LAA21312 for ; Mon, 14 Feb 2005 11:54:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0jpl-0006ok-3f for rpsec-web-archive@ietf.org; Mon, 14 Feb 2005 12:16:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0jSX-0007yH-5B; Mon, 14 Feb 2005 11:52:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0jPd-0007OL-Pj for rpsec@megatron.ietf.org; Mon, 14 Feb 2005 11:49:30 -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 LAA20779 for ; Mon, 14 Feb 2005 11:49:26 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0jkU-0006eM-Q3 for rpsec@ietf.org; Mon, 14 Feb 2005 12:11:04 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 14 Feb 2005 12:01:09 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,199,1102309200"; d="scan'208"; a="36905693:sNHT19842304" Received: from russpc.Whitehouse.intra (rtp-vpn1-275.cisco.com [10.82.225.19]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1EGmshG004161; Mon, 14 Feb 2005 11:48:55 -0500 (EST) Date: Mon, 14 Feb 2005 11:48:14 -0500 (Eastern Standard Time) From: Russ White To: Blaine Christian Subject: Re: [RPSEC] some thoughts on requirements 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: rpsec@ietf.org, Tom Petch , Stephen Kent 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: e5ba305d0e64821bf3d8bc5d3bb07228 >> the question of where the data comes from is important, to the extent >> that we have authoritative sources for this data. if one chooses to not >> take this into account, the result is more general, but it is also much >> more vulnerable to failures in "trust models." > > All, I have been toying with language to the effect that a SHOULD (or > maybe even a MUST) is that the means of identifying authorization should > be confined to the individual routers. In other words, as in today's > model, the routers should only require local knowledge of their current > peers in order to become a functioning part of the network. The attempt > is to avoid issues with requiring the purchase of yet more external > servers and to avoid implementation/bringup issues. I think you would then limit yourself to solutions that require replacing all the routers before you could use the security system.... And before you could call and entire AS "secure," every router in the AS would need to be replaced. I would say this is contrary to the MUSTs in the area of incremental deployment. :-) 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 Feb 14 12:34:31 2005 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 MAA25158 for ; Mon, 14 Feb 2005 12:34:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0kS8-0007mo-UX for rpsec-web-archive@ietf.org; Mon, 14 Feb 2005 12:56:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0k0x-0004gv-P6; Mon, 14 Feb 2005 12:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0jur-0003i9-AY for rpsec@megatron.ietf.org; Mon, 14 Feb 2005 12:21: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 MAA23968 for ; Mon, 14 Feb 2005 12:21:42 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0kFi-0007T5-PO for rpsec@ietf.org; Mon, 14 Feb 2005 12:43:20 -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 j1EHKwkJ021109; Mon, 14 Feb 2005 12:20:58 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 14 Feb 2005 12:20:53 -0500 To: Blaine Christian From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 At 11:31 AM -0500 2/14/05, Blaine Christian wrote: > > the question of where the data comes from is important, to the extent >> that we have authoritative sources for this data. if one chooses to >> not take this into account, the result is more general, but it is >> also much more vulnerable to failures in "trust models." > >All, I have been toying with language to the effect that a SHOULD (or maybe >even a MUST) is that the means of identifying authorization should be >confined to the individual routers. In other words, as in today's model, >the routers should only require local knowledge of their current peers in >order to become a functioning part of the network. The attempt is to avoid >issues with requiring the purchase of yet more external servers and to avoid >implementation/bringup issues. > >Anyone have thoughts on that? Blaine, I'm not quite sure how to interpret your comments above. One interpretation is that the routers ought not need to access any external repositories for the data needed to verify authorization to originate a prefix. That seems reasonable to me, since each AS operator could acquire the data from repositories, process it as needed, and then push the results to the routers in the AS. Is that what you had in mind? If so, then it's somewhat orthogonal to my comments, which address the security relevant infrastructure sources of the data, but not the means of internal distribution within an AS. One could argue that there is an overlap here, in that one could choose to avoid the question of whether each AS operator gets the data from an authoritative infrastructure, or via pairwise "trust" models. But, as I noted above, if one avoids that decision, the results are very different in terms of the ultimate security of the system. So, I don't suggest ignoring this part of the question. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 14 12:50:13 2005 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 MAA26694 for ; Mon, 14 Feb 2005 12:50:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0khK-0008Bc-Lf for rpsec-web-archive@ietf.org; Mon, 14 Feb 2005 13:11:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0kFb-0006Rq-2f; Mon, 14 Feb 2005 12:43:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0kDf-0006Fd-JA for rpsec@megatron.ietf.org; Mon, 14 Feb 2005 12:41:12 -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 MAA25840 for ; Mon, 14 Feb 2005 12:41:08 -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 1D0kYX-0007wK-0g for rpsec@ietf.org; Mon, 14 Feb 2005 13:02:46 -0500 Received: from [208.231.75.210] ([208.231.75.210]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j1EHe8sh008968 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 14 Feb 2005 12:40:19 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 14 Feb 2005 12:40:03 -0500 Subject: Re: [RPSEC] some thoughts on requirements From: Blaine Christian To: Stephen Kent 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: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit > Is that what you had in mind? If so, then it's somewhat orthogonal to > my comments, which address the security relevant infrastructure > sources of the data, but not the means of internal distribution > within an AS. One could argue that there is an overlap here, in that > one could choose to avoid the question of whether each AS operator > gets the data from an authoritative infrastructure, or via pairwise > "trust" models. But, as I noted above, if one avoids that decision, > the results are very different in terms of the ultimate security of > the system. So, I don't suggest ignoring this part of the question. The problem that I have is that if the routers need to visit an external repository to become part of the network then, in times of crisis, the external repositories can become rather large single points of failures. Initial router configuration is different than a reboot due to kernel failure etc... Forgetting that we might preclude certain solutions (Russ I saw your email as well). What SHOULD the right answer be? I am an advocate of the network being able to discover itself without the need to refer to external systems (that may rely on that network to come up). _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 14 13:28:34 2005 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 NAA00274 for ; Mon, 14 Feb 2005 13:28:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0lIS-0000cA-Sp for rpsec-web-archive@ietf.org; Mon, 14 Feb 2005 13:50:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0kvB-0002Pk-4R; Mon, 14 Feb 2005 13:26:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0kpH-0001MZ-Kr for rpsec@megatron.ietf.org; Mon, 14 Feb 2005 13:20:03 -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 NAA29367 for ; Mon, 14 Feb 2005 13:20:00 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0lA9-0000Nt-FV for rpsec@ietf.org; Mon, 14 Feb 2005 13:41:38 -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 j1EIJOkJ024682; Mon, 14 Feb 2005 13:19:25 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 14 Feb 2005 13:19:09 -0500 To: Blaine Christian From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: cab78e1e39c4b328567edb48482b6a69 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 At 12:40 PM -0500 2/14/05, Blaine Christian wrote: > > Is that what you had in mind? If so, then it's somewhat orthogonal to >> my comments, which address the security relevant infrastructure >> sources of the data, but not the means of internal distribution >> within an AS. One could argue that there is an overlap here, in that >> one could choose to avoid the question of whether each AS operator >> gets the data from an authoritative infrastructure, or via pairwise >> "trust" models. But, as I noted above, if one avoids that decision, >> the results are very different in terms of the ultimate security of >> the system. So, I don't suggest ignoring this part of the question. > >The problem that I have is that if the routers need to visit an external >repository to become part of the network then, in times of crisis, the >external repositories can become rather large single points of failures. >Initial router configuration is different than a reboot due to kernel >failure etc... Note that I suggested a model where the AS operator would push the authorization data to the routers, not that the routers would fetch it. It's it fair to day that one needs to configure a fair amount of data into a e-BGP router? if so, is it fair to say that when you bring it up you want to have a net management workstation download most of the data, including this sort of data? The data in these repositories need not be especially quickly updated. That's what makes the data in them suitable for distribution via a repository. So, in this case, we're discussing who owns what AS numbers, who has been allocation which prefixes, and who has been authorized to originate which prefixes. The first two bindings change fairly slowly, don't they? The last one represents agreements between prefix holders and AS operators, and also should be fairly static. This suggests that a router need not have up to the minute data for this, right? >Forgetting that we might preclude certain solutions (Russ I saw your email >as well). What SHOULD the right answer be? I am an advocate of the network >being able to discover itself without the need to refer to external systems >(that may rely on that network to come up). The network can discover its neighbors but e-BGP routers need to be loaded with policy data. This authorization data is used, like policy data, to help make decisions re accepting routes. So, on that light, it would seem reasonable to require an ability to inject the origin authorization data into an e-BGP router before it can operate. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 15 07:02:25 2005 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 HAA22173 for ; Tue, 15 Feb 2005 07:02:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D11kS-0002SD-GF for rpsec-web-archive@ietf.org; Tue, 15 Feb 2005 07:24:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D11NH-0001k2-TF; Tue, 15 Feb 2005 07:00:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D11Jj-000185-H7 for rpsec@megatron.ietf.org; Tue, 15 Feb 2005 06:56:35 -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 GAA21733 for ; Tue, 15 Feb 2005 06:56:32 -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 1D11el-0002JV-0P for rpsec@ietf.org; Tue, 15 Feb 2005 07:18:19 -0500 Received: from [208.231.75.210] ([208.231.75.210]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j1FBtQsh027124 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 15 Feb 2005 06:55:50 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 15 Feb 2005 06:55:20 -0500 Subject: Re: [RPSEC] some thoughts on requirements From: Blaine Christian To: Stephen Kent 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: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit > Note that I suggested a model where the AS operator would push the > authorization data to the routers, not that the routers would fetch > it. It's it fair to day that one needs to configure a fair amount of > data into a e-BGP router? For each individual peer it runs somewhere around 5-10 lines. There are, of course, notable exceptions exist where thousand line prefix lists are required. >if so, is it fair to say that when you > bring it up you want to have a net management workstation download > most of the data, including this sort of data? When we first program the router it is usually done with scripts etc... After that, it accretes. We save the configurations regularly so if we have to rebuild the router we can do so with a reasonable chance of getting it right . >The data in these > repositories need not be especially quickly updated. That's what > makes the data in them suitable for distribution via a repository. > So, in this case, we're discussing who owns what AS numbers, who has > been allocation which prefixes, and who has been authorized to > originate which prefixes. The first two bindings change fairly > slowly, don't they? I would agree that the EBGP peer to "prefix list" binding changes slowly, in most cases. >The last one represents agreements between prefix > holders and AS operators, and also should be fairly static. This > suggests that a router need not have up to the minute data for this, > right? This may be where we want to discuss more. Let's say I have 1000 routers go down due to a bug. I have had this happen and, in one case, I had an engineer do it for me. My concern is that the scale of the system required to recover configurations in the thousands of lines for those routers is not really tenable (more economic than technical). I can tell you what will happen in todays environment. Someone will make it an economic trade off and that system will be large enough to bring up about 20 routers "quickly" but when it has 1k routers all establishing sessions to download bits it will be brought to it's knees. Alternatively, if each router has the internal resources to bring itself up just by talking to it's neighbors we do not have a bandwidth/cpu issue to deal with in one location. I would say this model is more like a grid computing/distributed computing model where adjacent nodes manage their relationships and the "result" of the computation between all the nodes is the "Internet" > >> Forgetting that we might preclude certain solutions (Russ I saw your email >> as well). What SHOULD the right answer be? I am an advocate of the network >> being able to discover itself without the need to refer to external systems >> (that may rely on that network to come up). > > The network can discover its neighbors but e-BGP routers need to be > loaded with policy data. This authorization data is used, like policy > data, to help make decisions re accepting routes. So, on that light, > it would seem reasonable to require an ability to inject the origin > authorization data into an e-BGP router before it can operate. > Currently, the routers are "pre-loaded" with policy data. If they go away for a time they can come back without having to talk to anyone but their neighbors. I gather that a few folks are interested in making this a system that requires external connectivity before BGP routing can begin. I can tell you that I routinely pull all bits that require anything more external than establishing communications with neighbors from router/switch configurations. A key example would be FQDNs. I have had vendors that seem to rely on external DNS in order for their systems to discover internal processes. This just adds more moving parts to the system and creates ongoing issues. I would hate to see the same type of thing happen to BGP. Now, I still believe the concept of authorization can work in a distributed system. However, it really should work in a manner that does not require external sources to recover from outages or maintenance. Regards, Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 15 08:14:02 2005 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 IAA28774 for ; Tue, 15 Feb 2005 08:14:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D12rk-0004K8-FR for rpsec-web-archive@ietf.org; Tue, 15 Feb 2005 08:35:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D12Pb-0000vJ-Tg; Tue, 15 Feb 2005 08:06:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D12OV-0000ci-Mx for rpsec@megatron.ietf.org; Tue, 15 Feb 2005 08:05:35 -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 IAA27993 for ; Tue, 15 Feb 2005 08:05:34 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D12jV-000467-Bb for rpsec@ietf.org; Tue, 15 Feb 2005 08:27:20 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 15 Feb 2005 08:17:22 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,85,1107752400"; d="scan'208"; a="37023524:sNHT20068268" Received: from russpc.Whitehouse.intra (rtp-vpn2-145.cisco.com [10.82.240.145]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1FD4vhG020688; Tue, 15 Feb 2005 08:04:58 -0500 (EST) Date: Tue, 15 Feb 2005 08:04:18 -0500 (Eastern Standard Time) From: Russ White To: Blaine Christian Subject: Re: [RPSEC] some thoughts on requirements 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rpsec@ietf.org, Stephen Kent 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: b19722fc8d3865b147c75ae2495625f2 > Currently, the routers are "pre-loaded" with policy data. If they go > away for a time they can come back without having to talk to anyone but > their neighbors. I gather that a few folks are interested in making this > a system that requires external connectivity before BGP routing can > begin. I can tell you that I routinely pull all bits that require > anything more external than establishing communications with neighbors > from router/switch configurations. A key example would be FQDNs. I have > had vendors that seem to rely on external DNS in order for their systems > to discover internal processes. This just adds more moving parts to the > system and creates ongoing issues. I would hate to see the same type of > thing happen to BGP. What you're talking about here, though, is two different definitions of "external." One is external to your routing domain (outside the BGP AS), the other is outside the box itself. I agree that any proposed system must be able to reside entirely within an AS, once you have your certificates/etc. I don't agree that we should require it to be completely installed on each single box, with no outside support ever allowed for that box. :-) 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 Tue Feb 15 09:00:53 2005 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 JAA02201 for ; Tue, 15 Feb 2005 09:00:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D13b5-0005Kd-TT for rpsec-web-archive@ietf.org; Tue, 15 Feb 2005 09:22:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13DN-0005xr-S8; Tue, 15 Feb 2005 08:58:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13CX-0005tV-73 for rpsec@megatron.ietf.org; Tue, 15 Feb 2005 08:57:17 -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 IAA01968 for ; Tue, 15 Feb 2005 08:57:15 -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 1D13XZ-0005Fk-MK for rpsec@ietf.org; Tue, 15 Feb 2005 09:19:02 -0500 Received: from [208.231.75.210] ([208.231.75.210]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j1FDsSsh028492 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Tue, 15 Feb 2005 08:54:31 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 15 Feb 2005 08:54:22 -0500 Subject: Re: [RPSEC] some thoughts on requirements 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: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit > What you're talking about here, though, is two different definitions of > "external." One is external to your routing domain (outside the BGP AS), > the other is outside the box itself. I agree that any proposed system must > be able to reside entirely within an AS, once you have your > certificates/etc. I don't agree that we should require it to be completely > installed on each single box, with no outside support ever allowed for that > box. I understand the thought. And I know why you would want to allow for it. I just think it can put us into a world of hurt if we make every router in a 1k node network go back to a single system to discover their brain. It just seems like it can be done better, safer, and operationally more likely to succeed. Is there any way we can word it such that is strongly NOT recommended to create the need for external systems? While leaving a miniscule amount of hemp with which to hang folks if they really need to hang themselves? _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 15 09:12:32 2005 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 JAA03172 for ; Tue, 15 Feb 2005 09:12:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D13mK-0005bF-87 for rpsec-web-archive@ietf.org; Tue, 15 Feb 2005 09:34:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13Ma-0006oF-Ty; Tue, 15 Feb 2005 09:07:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13Im-0006TE-0w for rpsec@megatron.ietf.org; Tue, 15 Feb 2005 09:03: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 JAA02398 for ; Tue, 15 Feb 2005 09:03: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 1D13do-0005NK-EN for rpsec@ietf.org; Tue, 15 Feb 2005 09:25:29 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 15 Feb 2005 09:15:33 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,85,1107752400"; d="scan'208"; a="37029793:sNHT1382917640" Received: from russpc.Whitehouse.intra (rtp-vpn2-145.cisco.com [10.82.240.145]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1FD38hG000869; Tue, 15 Feb 2005 08:03:09 -0500 (EST) Date: Tue, 15 Feb 2005 09:02:28 -0500 (Eastern Standard Time) From: Russ White To: Blaine Christian Subject: Re: [RPSEC] some thoughts on requirements 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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rpsec@ietf.org, Stephen Kent 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: 7baded97d9887f7a0c7e8a33c2e3ea1b >> What you're talking about here, though, is two different definitions of >> "external." One is external to your routing domain (outside the BGP AS), >> the other is outside the box itself. I agree that any proposed system must >> be able to reside entirely within an AS, once you have your >> certificates/etc. I don't agree that we should require it to be completely >> installed on each single box, with no outside support ever allowed for that >> box. > > I understand the thought. And I know why you would want to allow for it. > I just think it can put us into a world of hurt if we make every router > in a 1k node network go back to a single system to discover their brain. > It just seems like it can be done better, safer, and operationally more > likely to succeed. Then you would need to plan, and distribute the workload. You don't log to the routers themselves, do you? :-) > Is there any way we can word it such that is strongly NOT recommended to > create the need for external systems? While leaving a miniscule amount > of hemp with which to hang folks if they really need to hang themselves? I would say you should strongly suggest not relying on devices outside the local routing domain, and that it would be nice for a security system not to require boxes outside the router. To a large degree, it's going to depend on implementation more than specification, in the real world. Economic tradeoffs are going to end up being more important than the 1k router down situation.... :-) 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 Tue Feb 15 09:58:35 2005 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 JAA07372 for ; Tue, 15 Feb 2005 09:58:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D14Uw-0006j7-Q9 for rpsec-web-archive@ietf.org; Tue, 15 Feb 2005 10:20:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D145s-0004iP-MQ; Tue, 15 Feb 2005 09:54:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D145M-0004cF-7k for rpsec@megatron.ietf.org; Tue, 15 Feb 2005 09:53: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 JAA06967 for ; Tue, 15 Feb 2005 09:53:53 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D14QO-0006cQ-5R for rpsec@ietf.org; Tue, 15 Feb 2005 10:15:41 -0500 Received: from pc6 (1Cust176.tnt24.lnd4.gbr.da.uu.net [62.188.151.176]) by ranger.systems.pipex.net (Postfix) with SMTP id 8ACDBE0001D8; Tue, 15 Feb 2005 14:53:19 +0000 (GMT) Message-ID: <00ff01c51365$6a94f9e0$0601a8c0@pc6> From: "Tom Petch" To: "Blaine Christian" , References: Subject: Re: [RPSEC] Draft updates Date: Tue, 15 Feb 2005 14:51:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit What I have seen recently is a lively discussion about what the requirements should be but I don't see much consensus and that leaves me unsure of the value of updating this I-D at this stage. For example, I have no sense of agreement about the scope, such as to include or exclude - IPv6 - communities - the 'internal' use of BGP with confederations, route reflectors, private AS etc - VPN, capabilities, etc etc Another topic that came up was trust, what you mean by hierarchic, distrilbuted etc. I have a very clear understanding of trust based on Windows 2000 forests but I don't know if your terminology is the same as mine:-) (I think you need to explain this or put in a normative reference to a document that does). And then there is the thorny question of address allocation where the I-D talks of allocation (fine), delegation (mmm), ownership (no!). I would like to build on the current system of IANA-RIR-LIR, of PI and PA, allocation and sub-allocation, and to identify and incorporate rather than cater for other (hopefully) legacy systems. Tom Petch ----- Original Message ----- From: "Blaine Christian" To: Sent: Saturday, February 12, 2005 9:32 PM Subject: [RPSEC] Draft updates > Folks, > > I am about to make pre-conference updates to the draft. So far, the most > extensive set of recommendations come from Steve in his email entitled "some > thoughts on requirements" (and I will do my best to incorporate them). If > you have suggested text for the draft please forward this coming week! > > Please, for the sake of my fingers, I do not want to see a wholesale > revision of the document. Just suggested additions/changes/drops. > Preferrable with the text to be replaced/deleted cited or the insertion > point indicated. > > I am making an exception for Steve . > > Regards, > > Blaine > > > > > > _______________________________________________ > 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 Feb 15 14:19:52 2005 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 OAA24421 for ; Tue, 15 Feb 2005 14:19:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D18Zq-0005Ac-14 for rpsec-web-archive@ietf.org; Tue, 15 Feb 2005 14:41:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15Ve-00042O-Ce; Tue, 15 Feb 2005 11:25:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D159b-0007uI-2k for rpsec@megatron.ietf.org; Tue, 15 Feb 2005 11:02:23 -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 LAA23892 for ; Tue, 15 Feb 2005 11:02:20 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D15Ue-0002ZH-HN for rpsec@ietf.org; Tue, 15 Feb 2005 11:24:09 -0500 Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1FG12kJ009870; Tue, 15 Feb 2005 11:01:03 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 15 Feb 2005 10:37:49 -0500 To: Blaine Christian From: Stephen Kent Subject: Re: [RPSEC] some thoughts on requirements 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: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Blaine, Thanks for the thoughtful comments on router config data sources, persistence, etc. While I think about your comments here are a couple of observations: - I thought the focus of this discussion was purely on authorization re prefix origination. Are we on the same page here? Just wanted to check since your message alluded to authorization data at the end, without qualification. - getting prefix authorization data from a neighbor inside an AS should be a viable approach, from a security standpoint. For example, an AS operator could download prefix authorization data from one or more repositories, verify the data, and processes it into a convenient form for the routers in the AS. Then, it could sign the data and push it to the routers. Each router could verify the signature on the package received from the NOC. This would be an infrequent (e.g., daily) operation, using a long term public key from the NOC, so it would not be computationally burdensome nor would it be hard to put this public key in place. This would allow one router to acquire the prefix authorization data from a neighbor and still be able to verify that it came from the AS operator, by checking the signature. (The timeliness of the data cannot be established so easily if the router looses all state, but the residual vulnerability seems tolerable given that the source for the data is another router within the same AS, and that the NOC can verify the version of the data at a later time, through management protocols.) Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 15 15:06:24 2005 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 PAA03938 for ; Tue, 15 Feb 2005 15:06:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Ir-0007y0-88 for rpsec-web-archive@ietf.org; Tue, 15 Feb 2005 15: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 1D18YR-0006uh-S5; Tue, 15 Feb 2005 14:40:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D171V-00081T-No for rpsec@megatron.ietf.org; Tue, 15 Feb 2005 13:02:09 -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 NAA00020 for ; Tue, 15 Feb 2005 13:02:06 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17MY-0005jx-2C for rpsec@ietf.org; Tue, 15 Feb 2005 13:23:57 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j1FI1XFI006776; Tue, 15 Feb 2005 13:01:33 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAA2YaWUm; Tue Feb 15 13:01:24 2005 Date: Tue, 15 Feb 2005 13:01:23 -0500 From: Tony Tauber To: Russ White Subject: Re: [RPSEC] some thoughts on requirements In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Tue, 15 Feb 2005, Russ White wrote: > >> What you're talking about here, though, is two different > >> definitions of "external." One is external to your routing domain > >> (outside the BGP AS), the other is outside the box itself. I > >> agree that any proposed system must be able to reside entirely > >> within an AS, once you have your certificates/etc. I don't agree > >> that we should require it to be completely installed on each > >> single box, with no outside support ever allowed for that box. > > > > I understand the thought. And I know why you would want to allow > > for it. I just think it can put us into a world of hurt if we > > make every router in a 1k node network go back to a single system > > to discover their brain. It just seems like it can be done > > better, safer, and operationally more likely to succeed. I don't think anyone's suggesting the router can't become useful until it talks to some external system. As Steve suggested, there's much about routers which is statically configured and stored so they can come up and become useful. Some information changes slowly and you could take the last checkpoint you stored on-board and start to try and check it once you've gotten up and running. > Then you would need to plan, and distribute the workload. You don't > log to the routers themselves, do you? :-) > > > Is there any way we can word it such that is strongly NOT > > recommended to create the need for external systems? While > > leaving a miniscule amount of hemp with which to hang folks if > > they really need to hang themselves? > > I would say you should strongly suggest not relying on devices > outside the local routing domain, and that it would be nice for a > security system not to require boxes outside the router. To a large > degree, it's going to depend on implementation more than > specification, in the real world. Economic tradeoffs are going to > end up being more important than the 1k router down situation.... Agree that it might be an implementation detail. I'll try to think up text that describes the desire, though. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 15 22:03:42 2005 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 WAA22117 for ; Tue, 15 Feb 2005 22:03:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Fol-0003av-VG for rpsec-web-archive@ietf.org; Tue, 15 Feb 2005 22:25:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1FPa-0006WA-Td; Tue, 15 Feb 2005 21:59:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1FMm-0005dR-DD for rpsec@megatron.ietf.org; Tue, 15 Feb 2005 21:56: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 VAA21459 for ; Tue, 15 Feb 2005 21:56:38 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Fhv-0003OX-Mf for rpsec@ietf.org; Tue, 15 Feb 2005 22:18:33 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j1G2uW9h013681; Tue, 15 Feb 2005 21:56:32 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAAczaayA; Tue Feb 15 21:56:23 2005 Date: Tue, 15 Feb 2005 21:56:23 -0500 From: Tony Tauber To: Tom Petch Subject: Re: [RPSEC] Draft updates In-Reply-To: <00ff01c51365$6a94f9e0$0601a8c0@pc6> Message-ID: References: <00ff01c51365$6a94f9e0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Tue, 15 Feb 2005, Tom Petch wrote: > What I have seen recently is a lively discussion about what the > requirements should be but I don't see much consensus and that > leaves me unsure of the value of updating this I-D at this stage. > > For example, I have no sense of agreement about the scope, such as > to include or exclude > - IPv6 > - communities > - the 'internal' use of BGP with confederations, route reflectors, > private AS etc > - VPN, capabilities, etc etc I agree that these points need more clarification. > Another topic that came up was trust, what you mean by hierarchic, > distrilbuted etc. I have a very clear understanding of trust based > on Windows 2000 forests but I don't know if your terminology is the > same as mine:-) (I think you need to explain this or put in a > normative reference to a document that does). Much agreement that I'd like to understand more about this topic and associated vocabulary. (I'm all about vocabulary.) > And then there is the thorny question of address allocation where > the I-D talks of allocation (fine), delegation (mmm), ownership > (no!). I would like to build on the current system of IANA-RIR-LIR, > of PI and PA, allocation and sub-allocation, and to identify and > incorporate rather than cater for other (hopefully) legacy systems. > > Tom Petch Perhaps aligning with RFC 2050 (Registry Allocation Guidelines) could help here. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 18 11:25:55 2005 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 LAA01456 for ; Fri, 18 Feb 2005 11:25:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2BIi-0008S0-SN for rpsec-web-archive@ietf.org; Fri, 18 Feb 2005 11:48:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D29tr-0005WP-Ve; Fri, 18 Feb 2005 10:18:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D29rD-00042W-KW for rpsec@megatron.ietf.org; Fri, 18 Feb 2005 10:15:51 -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 KAA13918 for ; Fri, 18 Feb 2005 10:15:50 -0500 (EST) Received: from llmail.ll.mit.edu ([129.55.12.40] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2ACt-0003CT-5C for rpsec@ietf.org; Fri, 18 Feb 2005 10:38:16 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j1IFFmZ8011475 for ; Fri, 18 Feb 2005 10:15:48 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAAPOa4Hv; Fri Feb 18 10:15:34 2005 Date: Fri, 18 Feb 2005 10:17:36 -0500 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: 8ac499381112328dd60aea5b1ff596ea Subject: [RPSEC] Send Agenda items for IETF-62 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: d17f825e43c9aed4fd65b7edddddec89 Please get these in to Russ and me within a week. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 22 17:28:01 2005 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 RAA01217 for ; Tue, 22 Feb 2005 17:28:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3isF-0004xl-Pk for rpsec-web-archive@ietf.org; Tue, 22 Feb 2005 17:51:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3MRn-0004q5-Cb; Mon, 21 Feb 2005 17:54:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Kci-0006CI-5w; Mon, 21 Feb 2005 15:57:44 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14520; Mon, 21 Feb 2005 15:57:42 -0500 (EST) Message-Id: <200502212057.PAA14520@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 21 Feb 2005 15:57:42 -0500 Cc: rpsec@ietf.org Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-bgpsecrec-01.txt X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF. Title : BGP Security Requirements Author(s) : B. Christian Filename : draft-ietf-rpsec-bgpsecrec-01.txt Pages : 15 Date : 2005-2-21 The security of BGP is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routed system, is more complex. This document describes a set of requirements for securing BGP, including securing peering relationships between BGP speakers, and authenticating the routing information carried within BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rpsec-bgpsecrec-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-21152109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-bgpsecrec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21152109.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From rpsec-bounces@ietf.org Wed Feb 23 21:29:55 2005 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 VAA05848 for ; Wed, 23 Feb 2005 21:29:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4986-0007xY-UC for rpsec-web-archive@ietf.org; Wed, 23 Feb 2005 21:53:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3t3Q-0000Ub-0Y; Wed, 23 Feb 2005 04:43:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3t3J-0000U0-9g for rpsec@megatron.ietf.org; Wed, 23 Feb 2005 04:43: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 EAA22839 for ; Wed, 23 Feb 2005 04:43:20 -0500 (EST) Received: from postfix4-2.free.fr ([213.228.0.176]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3tPm-0004XV-4Z for rpsec@ietf.org; Wed, 23 Feb 2005 05:06:48 -0500 Received: from cerbere (unknown [82.227.0.102]) by postfix4-2.free.fr (Postfix) with ESMTP id D7D9A2BEED8 for ; Wed, 23 Feb 2005 10:43:14 +0100 (CET) Received: from jjp by cerbere with local (Exim 3.36 #1 (Debian)) id 1D3t3h-00007E-00 for ; Wed, 23 Feb 2005 10:43:53 +0100 Date: Wed, 23 Feb 2005 10:43:53 +0100 From: Jean-Jacques Puig To: rpsec@ietf.org Message-ID: <20050223094352.GA429@cerbere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [RPSEC] draft-ietf-rpsec-generic-requirements-01.txt X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi ! We recently uploaded a new version of the requirements document. This is mainly a 'refresh' of the repository. I personaly think that, given the state of advancement of the document, we should wait for feedback from IESG regarding the threats document. Moreover, evolution of the BGP requirements may underline tendancies that we should mirror in the generic requirements. Anyway, comments are always welcome. -- Jean-Jacques Puig _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 24 04:11:16 2005 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 EAA21195 for ; Thu, 24 Feb 2005 04:11:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4FOa-0007md-Me for rpsec-web-archive@ietf.org; Thu, 24 Feb 2005 04:34:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4F1a-000881-Ub; Thu, 24 Feb 2005 04:11:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4F1X-00083y-Kt for rpsec@megatron.ietf.org; Thu, 24 Feb 2005 04:11: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 EAA21178 for ; Thu, 24 Feb 2005 04:11:05 -0500 (EST) Resent-From: jeanjacques.puig@free.fr Received: from postfix4-2.free.fr ([213.228.0.176]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4FOP-0007m3-Gn for rpsec@ietf.org; Thu, 24 Feb 2005 04:34:45 -0500 Received: from cerbere (unknown [82.227.0.102]) by postfix4-2.free.fr (Postfix) with ESMTP id 4704B2BEF77 for ; Thu, 24 Feb 2005 10:11:06 +0100 (CET) Received: from jjp by cerbere with local (Exim 3.36 #1 (Debian)) id 1D4F29-00006V-00 for ; Thu, 24 Feb 2005 10:11:45 +0100 Resent-Date: Thu, 24 Feb 2005 10:11:45 +0100 Resent-Message-ID: <20050224091145.GA401@cerbere> Resent-To: rpsec@ietf.org Date: Wed, 23 Feb 2005 10:43:53 +0100 From: Jean-Jacques Puig To: rpsec@ietf.org Message-ID: <20050223094352.GA429@cerbere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [RPSEC] draft-ietf-rpsec-generic-requirements-01.txt X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi ! We recently uploaded a new version of the requirements document. This is mainly a 'refresh' of the repository. I personaly think that, given the state of advancement of the document, we should wait for feedback from IESG regarding the threats document. Moreover, evolution of the BGP requirements may underline tendancies that we should mirror in the generic requirements. Anyway, comments are always welcome. -- Jean-Jacques Puig _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec