From mailman-bounces@ietf.org Sat Jan 1 07: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 HAA14459 for ; Sat, 1 Jan 2005 07:16:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkiNQ-0008FQ-7v for rpsec-web-archive@ietf.org; Sat, 01 Jan 2005 07:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkgOU-0007J5-7X for rpsec-web-archive@ietf.org; Sat, 01 Jan 2005 05:21:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rpsec-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:08:08 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rpsec-web-archive@ietf.org: List Password // URL ---- -------- rpsec@ietf.org lLFY https://www1.ietf.org/mailman/options/rpsec/rpsec-web-archive%40ietf.org From rpsec-bounces@ietf.org Wed Jan 5 13:03: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 NAA26268 for ; Wed, 5 Jan 2005 13:03:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFiR-0006TH-4P for rpsec-web-archive@ietf.org; Wed, 05 Jan 2005 13:17:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFOQ-0000Gx-Em; Wed, 05 Jan 2005 12:56:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFND-00005Z-Sj for rpsec@megatron.ietf.org; Wed, 05 Jan 2005 12:55: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 MAA25759 for ; Wed, 5 Jan 2005 12:55:04 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFZp-0005o8-Gw for rpsec@ietf.org; Wed, 05 Jan 2005 13:08:10 -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 j05HsRjh012484; Wed, 5 Jan 2005 12:54:29 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 5 Jan 2005 11:53:27 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) 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: ccfb4541e989aa743998098cd315d0fd Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e > > >>Do you mean to say that correct BGP behavior allows an a speaker to >>originate a prefix when the AS in which the speaker operates is not >>the owner of the prefix nor has the owner authorized the >>advertisement in any fashion? > >Can you explain what you mean by "owner" here? The AS authorized to >advertise the prefix, or the AS authorized to advertise a superset >of that same address space (the aggregate)? If I "own" 10.1.0.0/16, >and I assign 10.1.1.0/24 to some other AS, may I still advertise >10.1.0.0/16? Or, must I break up the /16, and advertise 254 /24's, >now that I've given one of the address blocks within the /16 away? If an AS 1 receives a /16 allocation, it can delegate a subset of that address space, e.g., a /24, to a subscriber. AS 1 need not break up its remaining address space into discrete blocks when it advertises it, but the subscriber to whom the /24 was delegated does need to explicitly authorize itself, or another AS, to originate the /24. When I rea an earlier version of your individual submission I-D, it argued that this shows the inability of path advertisements to securely propagate info about who owns what. But the arguments you present are fairly narrowly constructed, and I think they ignore the syste context that we both agree is an important element of a viable security solution. The missing piece of the puzzle, as you might say is that there is a need for every AS to be aware of the delegations that have taken place, so that traffic for a subscriber with the /24 is not misrouted to AS 1, as it advertises the /16 that encompasses the /24. >If you think about the answers to these questions, you'll see why >you cannot make the assumption you're making above. On the contrary, having thought about the issues in detail, we engineered a solution that seems to address them. We can argue about the viability of a particular solution approach when we are discussing such solutions, but at this stage of requirements development, we ought to focus on the the basis for security requirements more than on the viability of candidate approaches. >>I think we all understand that there is a difference between >>forwarding and routing and thus propagation of a route does not >>ensure that traffic will flow over that route. However, the purpose >>of advertising a route to a neighbor is to make the neighbor aware >>that the advertiser is willing to accept traffic for the indicated >>prefixes, and that if such traffic is sent to the advertiser, then >>the traffic will be forwarded to the the indicated origin AS. >>That's what I believe is true, and your comment above in now way >>relates to the notion of > >That's specifically what's not true in a real routing system. Again, >if I advertise 10.1.0.0/16 with a path of {1, 2}, I'm implying that >traffic destined to 10.1.1.1 will "terminate" in AS 2. In fact, it >may terminate three or four or more AS hops away, there's no way to >tell at all where that traffic is going to terminate. > >The advertisement 10.1.0.0/16 {1, 2} actually implies AS 1 has a >path to 10.1.0.0/16 it learned from AS 2. It does not imply that AS >1 will use this path to forward traffic, nor does it imply that AS 2 >has agreed to transit traffic to every possible destination within >10.1.0.0/16. > >>You still have not answered the question of what you mean by a path >>"existing." If you mean there are communication links between ASes, >>then say so. If you mean that there is local policy in each along >>the path that states that traffic for an indicated prefix will be >>forwarded to the origin AS if received from the indicated neighbor, >>say so. If you mean something else, say so. > >I mean a logical path exists that corresponds to the as path listed >in the update. You cannot prove or imply policy along that path. > >>>-- Was the update actually originated by/forwarded along this path >>> (which only applies to some form of non-repudiation, and nothing else)? >> >>As I have said several times, apparently to no avail, this is not >>NR. But yes, I agree that this is a separable question from the >>bullet immediately above. > >Which is why I said "something like non-repudiation," since I don't >know of a better term to use in this context. But, I think we >understand what we are talking about, even if I'm using the wrong >term to describe it. :-) > >>>-- Am I authorized to use this path (outside the set of questions >>> answerable within BGP today)? >> >>I don't know what you are trying to say here. > >Exactly what it asks. Given the update 10.1.0.0/16 {1, 2}, am I >authorized to transmit traffic to the advertising peer (presumably >in AS 1) towards the destination 10.1.1.1? I contend you simply >cannot know the answer to that question. Given that same update, can >I know that traffic will follow the AS Path in the update to reach >10.1.1.1? I cannot know the answer to that question, either. The BGP spec clearly says that a speaker receiving the advertisement in your example is authorized to send traffic for 10.1.1.1 to AS 1, absent any more specific advertisements that encompass 10.1.1.1 or any local policy that causes you to reject the advertisement. BGP also says that yes, that the proper interpretation of the advertisement in your example is that if you send traffic for the indicated NLRI to AS 1, it will forward the traffic to AS 2. We both know that there can be conditions that will cause this to not be true, but the BGP spec is very clear on how a speaker is supposed to interpret the path in a route. In the memo I just prepared, I cite several passages from the spec that reinforce this. Are we to ignore this spec, which is about to become a full standard, as we develop security requirements that purport to be for BGP? > >>>Trying to munge all of this into a single requirement simply >>>muddies the problem, and takes away the designer's ability to >>>address them in various ways. >> >>the issue is not whether one can identify these as distinct >>questions that can be asked about a path or a route. The question >>we are addressing is what does BGP say about paths and routes, does >>IT ask these questions, and does it make the distinctions you have >>made above, when the BGP route computation algorithm is executed? > >Then you would restrict the available solutions to only those that >secure BGP as a bag of bits, rather than asking what it is that BGP >is trying to express, and securing the database as a database. I am NOT focusing on the bits and ignoring the context in which they are interpreted. I think we both agree that the important thing to do is to secure BGP routing. I am focusing on what the BGP spec says are MUSTS/SHALLS and SHOULDS, as a starting point for security requirements. That seems to be the logical place to start. What I think you are doing is suggesting that one can articulate a set of requirements that are further abstracted from the protocol spec. That may be a viable approach, but if we pursue it, I think it is incumbent on you to show how the more abstract requirements encompass all the features that the protocol mandates and that are security relevant. Otherwise the more abstract requirements appear arbitrary. >Again, I think the correct questions we should ask when writing the >requirements are: > >-- Can I prove a path exists? we need a very precise definition of what these words mean. also, I'm not sure the word "prove" is ideal here. >-- Can I prove I'm authorized to use the path? > > (This question, in a sense, is a superset of the question: does every > AS along the path have policies set so they will pass traffic I forward > along this path to every possible destination within in the address > block carried in the update). I almost agree with the initial wording, but your more detailed explanation makes me less comfortable. BGP distinguishes what an AS advertises vs. what is local data that need not be disclosed to other ASes. The wording above, because it includes local policy info, suggests that it requires disclosure of local info, and that does not like a suitable basis for a requirement. >-- Can I prove traffic I forward along this path will actually use it? "prove" definitely seems like a bad choice of term here. BGP does says that the proper interpretation of an advertisement is that the ASes along the path will forward traffic consistent with the NLRI along the advertised path. However, detecting whether traffic flows as advertised is outside the scope of BGP per se. Our security goal for BGP should be to provide speakers with the necessary mechanisms and infrastructure to enable them to verify the authorization or legitimacy (or whatever term we decide is appropriate here) of advertisements, so that when each speaker makes a decision on whether to accept a route, it does so with authorized/legitimate inputs. Given the autonomous nature of the routing system elements, this seems to be the best one can do from a preventative, vs. remedial, security perspective. > >If I can't prove one of these questions is answerable, then it makes >no sense to build a requirement for a given security system to prove >them, right? Again, I don't "proof" is an appropriate term to be using here, so I can't agree with this statement. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 5 13:04: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 NAA26318 for ; Wed, 5 Jan 2005 13:04:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFj5-0006U3-WC for rpsec-web-archive@ietf.org; Wed, 05 Jan 2005 13:17:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFOQ-0000HG-Tf; Wed, 05 Jan 2005 12:56:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFND-00005b-Ut for rpsec@megatron.ietf.org; Wed, 05 Jan 2005 12:55: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 MAA25761 for ; Wed, 5 Jan 2005 12:55:04 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFZp-0005oF-Jj for rpsec@ietf.org; Wed, 05 Jan 2005 13:08:10 -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 j05HsRjj012484; Wed, 5 Jan 2005 12:54:31 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 5 Jan 2005 12:38:01 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 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="===============0061878045==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 --===============0061878045== Content-Type: multipart/alternative; boundary="============_-1107174827==_ma============" --============_-1107174827==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:52 AM -0500 12/29/04, Russ White wrote: >>>We are clearly talking past each other. You are saying: "This is >>>the way BGP works, what BGP assumes." But, you're pushing into BGP >>>the concept of "authorization," which is a matter of policy, and >>>isn't part of BGP. Beyond this, you say "modulo aggregation." >>>That's a hole in the scheme large enough to drive a truck through, >>>honestly. >> >>BGP is a policy-driven system, Russ. The whole point of local >>policy databases is to enable an AS to impose its local policies on >>the route determination process, to down select from all the paths >>that physically exist, to the subset that each AS wants to >>advertise to other ASes. I'm sorry that you have an aversion to the >>word 'authorization" but it is implicit in the design of BGP. > >Again, we are clearly talking past each other. You're trying to >secure the BGP update as a bag of bits. I'm saying to look beyond >that bag of bits, and see what's in there. It doesn't matter if I've >securely transmitted a bag of bits from point a to point b, with all >the things in that bag intact. > >BGP doesn't operate that way. BGP operates on routing information. >Secure the routing information, not the process used to transmit the >routing information. Lower layer security mechanisms do operate as you suggest, e.g., when one uses the TCP/MD5 checksum or IPsec for point to point security between a pair of speakers, they do see just a bag of bits. But I am not looking at the data in an Update message as bits w/o context. We are both trying to secure BGP in the larger context of a routing system. I think the major difference in what you and I propose is based on different goals that are still consistent with securing routing as a system. For example, I am emphasizing the need to verify Updates because BGP is defined largely in terms of the processing and generation of Updates. Thay also represent the means by which speakers learn what purports to be the realtime status of paths. So, if one wants to create an environment in which speakers have confidence in the realtime status of paths, vs. static information about Internet topology, one needs some means of securing Update processing. In contrast, what I think you are trying to do is to bound the extent to which bogus Updates can differ from static topologies that represent a mix of extant links between ASes and local AS policies that determine what traffic can traverse which links. This goal would reduce the extent to which misconfiguration or an attack can adversely affect routing, but this strategy would still allow a speaker to accept as valid an Update that is not only not current, but maybe one that was never even generated by a legitimate speaker. That's a technically easier goal, but it yields a less secure outcome. Moreover, if there are practical issues re what information ASes have to disclose to achieve this more limited goal, then we may be facing just as hard a problem as if we try to enable speakers to verify Updates more precisely. >>I say "modulo aggregation" not because I think we can ignore >>aggregation, but because it is easier to make concise statements >>about correct operation if one first omits aggregation. We >>certainly need to include it in the requirements and in solutions, >>but it's good practice to deal with the common, simple cases first, >>the move on to the harder ones. > >Aggregation is the common case. Aggregation is more common than >non-aggregation in the real world. You're subsituting "common" for >"simple." Yes, it's simpler to secure BGP without aggregation, but >if aggregation then proves the mechanism you've used to secure BGP >untrue, or makes certain claims non-provable, then you need to start >with aggregation, and work from there. It has been a while since I looked at BGP data in detail, but when we examined Updates in detail a while ago, we saw very little aggregation, very little use of AS sets, etc. Still, I agree with your point that any viable solution must accommodate aggregation. What I said was that it is easier to make simple, concise statements about the correctness of Updates w/o aggregation. That does not mean that one cannot make statements about Update correctness that accommodate aggregation. The statements just tend to become more complex. > >>There is no question that, when legitimate aggregation occurs, the >>path contained in the Update no longer contains all of the ASes >>that were present prior to aggregation. So, yes, it is accurate to >>say that the path seen by ASes past the aggregation point omits >>some of the ASes that were in the path prior to aggregation. But >>your claim that this proves your point that the aggregated path >>does not exist, is not true. > >*sigh* > >Steve, when I send routing information, I'm not sending an update. >I'm sending a prefix and a set of attributes. BGP will unbundle >these, and send them, in a possibly different form, to a set of >peers. You're applying security to the wrong part of the process. Russ, when you use BGP to send routing info you do it only via an Update. The way an Update is processed to effect changes in the Adj-RIBN-In and maybe in the Loc-RIB, which in turn may cause an Update to be emitted, is dictated by the BGP spec, in a very details, three phase algorithm. The spec indicates what values from the received Update are used in updating these RIBs and it places constraints on how new Updates are created, based on the contents of the RIBs. It does not say that a speaker can cobble together a new Update in an arbitrary fashion. For example, if an attribute is defined as transitive, then the values in it are propagated in an Update that is generated based on the RIB entry that was updated using the attribute. There are complex rules describing how route aggregation is to be performed, and a mandatory, minimum algorithm for performing aggregation. >I don't see any way to solve this argument. You will always treat >BGP as a bag of bits, and I will always look beyond the bag of bits >at how routing works, in the real world. Russ, please do not engage in personal attacks in this technical debate. It's both offensive and inaccurate for you to assert that you know how I view BGP security, in a pejorative fashion, while claiming the technical high ground for your perspective. Steve --============_-1107174827==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] Thoughts on BGP Security Req's Draft (I)
At 10:52 AM -0500 12/29/04, Russ White wrote:
We are clearly talking past each other. You are saying: "This is the way BGP works, what BGP assumes." But, you're pushing into BGP the concept of "authorization," which is a matter of policy, and isn't part of BGP. Beyond this, you say "modulo aggregation." That's a hole in the scheme large enough to drive a truck through, honestly.

BGP is a policy-driven system, Russ. The whole point of local policy databases is to enable an AS to impose its local policies on the route determination process, to down select from all the paths that physically exist, to the subset that each AS wants to advertise to other ASes. I'm sorry that you have an aversion to the word 'authorization" but it is implicit in the design of BGP.

Again, we are clearly talking past each other. You're trying to secure the BGP update as a bag of bits. I'm saying to look beyond that bag of bits, and see what's in there. It doesn't matter if I've securely transmitted a bag of bits from point a to point b, with all the things in that bag intact.
BGP doesn't operate that way. BGP operates on routing information. Secure the routing information, not the process used to transmit the routing information.

Lower layer security mechanisms do operate as you suggest, e.g., when one uses the TCP/MD5 checksum or IPsec for point to point security between a pair of speakers, they do see just a bag of bits. But I am not looking at the data in an Update message as bits w/o context. We are both trying to secure BGP in the larger context of a routing system.

I think the major difference in what you and I propose is based on different goals that are still consistent with securing routing as a system.  For example, I am emphasizing the need to verify Updates because BGP is defined largely in terms of the processing and generation of Updates. Thay also represent the means by which speakers learn what purports to be the realtime status of paths. So, if one wants to create an environment in which speakers have confidence in the realtime status of paths, vs. static information about Internet topology, one needs some means of securing Update processing.

In contrast, what I think you are trying to do is to bound the extent to which bogus Updates can differ from static topologies that represent a mix of extant links between ASes and local AS policies that determine what traffic can traverse which links. This goal would reduce the extent to which misconfiguration or an attack can adversely affect routing, but this strategy would still allow a speaker to accept as valid an Update that is not only not current, but maybe one that was never even generated by a legitimate speaker. That's a technically easier goal, but it yields a less secure outcome. Moreover, if there are practical issues re what information ASes have to disclose to achieve this more limited goal, then we may be facing just as hard a problem as if we try to enable speakers to verify Updates more precisely.


I say "modulo aggregation" not because I think we can ignore aggregation, but because it is easier to make concise statements about correct operation if one first omits aggregation. We certainly need to include it in the requirements and in solutions, but it's good practice to deal with the common, simple cases first, the move on to the harder ones.

Aggregation is the common case. Aggregation is more common than non-aggregation in the real world. You're subsituting "common" for "simple." Yes, it's simpler to secure BGP without aggregation, but if aggregation then proves the mechanism you've used to secure BGP untrue, or makes certain claims non-provable, then you need to start with aggregation, and work from there.

It has been a while since I looked at BGP data in detail, but when we examined Updates in detail a while ago, we saw very little aggregation, very little use of AS sets, etc.  Still, I agree with your point that any viable solution must accommodate aggregation. What I said was that it is easier to make simple, concise statements about the correctness of Updates w/o aggregation. That does not mean that one cannot make statements about Update correctness that accommodate aggregation. The statements just tend to become more complex.


There is no question that, when legitimate aggregation occurs, the path contained in the Update no longer contains all of the ASes that were present prior to aggregation. So, yes, it is accurate to say that the path seen by ASes past the aggregation point omits some of the ASes that were in the path prior to aggregation. But your claim that this proves your point that the aggregated path does not exist, is not true.

*sigh*

Steve, when I send routing information, I'm not sending an update. I'm sending a prefix and a set of attributes. BGP will unbundle these, and send them, in a possibly different form, to a set of peers. You're applying security to the wrong part of the process.

Russ, when you use BGP to send routing info you do it only via an Update. The way an Update is processed to effect changes in the Adj-RIBN-In and maybe in the Loc-RIB, which in turn may cause an Update to be emitted, is dictated by the BGP spec, in a very details, three phase algorithm. The spec indicates what values from the received Update are used in updating these RIBs and it places constraints on how new Updates are created, based on the contents of the RIBs. It does not say that a speaker can cobble together a new Update in an arbitrary fashion. For example, if an attribute is  defined as transitive, then the values in it are propagated in an Update that is generated based on the RIB entry that was updated using the attribute. There are complex rules describing how route aggregation is to be performed, and a mandatory, minimum algorithm for performing aggregation.

I don't see any way to solve this argument. You will always treat BGP as a bag of bits, and I will always look beyond the bag of bits at how routing works, in the real world.

Russ, please do not engage in personal attacks in this technical debate. It's both offensive and inaccurate for you to assert that you know how I view BGP security, in a pejorative fashion, while claiming the technical high ground for your perspective.

Steve
--============_-1107174827==_ma============-- --===============0061878045== 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 --===============0061878045==-- From rpsec-bounces@ietf.org Wed Jan 5 13:05: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 NAA26381 for ; Wed, 5 Jan 2005 13:05:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFjk-0006fo-MU for rpsec-web-archive@ietf.org; Wed, 05 Jan 2005 13:18:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFOR-0000HR-AJ; Wed, 05 Jan 2005 12:56:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFNE-00005d-93 for rpsec@megatron.ietf.org; Wed, 05 Jan 2005 12:55: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 MAA25765 for ; Wed, 5 Jan 2005 12:55:04 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFZp-0005oL-Ep for rpsec@ietf.org; Wed, 05 Jan 2005 13:08:10 -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 j05HsRjl012484 for ; Wed, 5 Jan 2005 12:54:33 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 5 Jan 2005 12:54:20 -0500 To: rpsec@ietf.org From: Stephen Kent X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d5cbd3d5548af56dbea64a1d182f942 Subject: [RPSEC] a note from the BGP4 spec X-BeenThere: rpsec@ietf.org 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="===============2057089608==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0807e85f6792b2e267100df15b13cd9b --===============2057089608== Content-Type: multipart/alternative; boundary="============_-1107174825==_ma============" --============_-1107174825==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable =46olks I made a pass through the current version of=20 BGP-4, the document that is about to be published=20 as a full standard. I tried to extract quotes=20 that deal with what I see as significant security=20 issues for BGP, based on what the spec says are=20 MUSTS/SHALLS and, in some cases, SHOULDS. I do=20 have a couple of questions in this memo, areas=20 where I as not quite sure what the spec means, of=20 where I am not certain how implementations have=20 chosen to deals with some subtle aspects of the=20 spec. I'm looking for feedback on this memo, as=20 a way of making progress on some of the issues=20 that Russ and I have been debating. In the Abstract: The primary function of a BGP speaking system is=20 to exchange network reachability information with=20 other BGP systems. This network reachability=20 information includes information on the list of=20 Autonomous Systems (ASs) that reachability=20 information traverses. This information is=20 sufficient to construct a graph of AS=20 connectivity for this reachability from which=20 routing loops may be pruned and some policy=20 decisions at the AS level may be enforced. To me this says that BGP embodies the notion that=20 an Update nominally traverses the path that it=20 contains, although we all agree that there will=20 be exceptions, e.g., due to path aggregation. Later the abstract says: BGP-4 also introduces mechanisms which allow=20 aggregation of routes, including aggregation of=20 AS paths. This is an explicit declaration of route=20 aggregation, and an indirect mention of address=20 aggregation. In the Summary of Operation section (3.1) of the document: In the context of this document we assume that a=20 BGP speaker advertises to its peers only those=20 routes that it itself uses (in this context a BGP=20 speaker is said to "use" a BGP route if it is the=20 most preferred BGP route and is used in=20 forwarding). All other cases are outside the=20 scope of this document. This text states what it claims is the=20 association between routes that a speaker=20 advertises and the forwarding function that the=20 speaker performs. Your gave an example of an AS=20 advertising a route that contains an AS set=20 constructed to cause another AS to reject the=20 route. In that case I think you said that one of=20 more AS set elements was artificially introduced=20 to influence those ASes from accepting the route.=20 This would seem to violate this part of the BGP=20 spec, since the AS advertising this route does=20 not "use" (forward traffic via) the indicated=20 route, right? In Section 4.3, the definition of the UPDATE=20 message format, in describing the AS-PATH, the=20 text says: The path segment type is a 1-octet long field=20 with the following values defined: Value Segment Type 1 AS_SET: unordered set of ASs a route in the UPDATE message has traversed 2 AS_SEQUENCE: ordered set of ASs a route in the UPDATE message has traversed Note that for both AS sequences and for AS sets,=20 the specs says that they refer to a route that=20 the UPDATE has traversed. This is why I have=20 emphasized the need for the security requirements=20 document to include this, i.e., the spec=20 explicitly says that this is how BGP is supposed=20 to work. Yes, we know that there are exceptions=20 to this general rule, but this text suggests=20 that, to first order, there should be a simple,=20 verifiable relationship between an advertised AS=20 path and the path traversed by the UPDATEs that=20 contributed to the creation of the path. MED is defined here as well, and it is=20 non-transitive. That means that BGP security need=20 not worry about imposing any transitive security=20 measures to protect this attribute. AGGREGATOR is defined here. It is transitive, and=20 identifies the last AS (and the BGP speaker in=20 that AS) that formed an aggregate route contained=20 in an UPDATE. Note that the text discusses inclusion of=20 multiple destinations in the NLRI of one UPDATE,=20 saying: An UPDATE message can advertise at most one set=20 of path attributes, but multiple destinations,=20 provided that the destinations share these=20 attributes. All path attributes contained in a=20 given UPDATE message apply to all destinations=20 carried in the NLRI field of the UPDATE message. This says that an AS violates the spec if, for=20 example, it includes prefixes in the NLRI that=20 are not reachable via the path in the UPDATE.=20 However, it does not state that all of the=20 destinations contained in an advertised prefix=20 are reachable via the advertised path. This is=20 because subsets of address blocks are often=20 further delegated. I think there is an implicit=20 statement here that an AS must become aware of=20 the delegation (e.g., via receipt of an=20 advertisement from an AS representing the=20 delegated subsets, or via static configuration=20 info) in order to properly route/forward traffic=20 for such destinations. Section 9.1.4 discusses=20 the issue of overlapping routes and says: The set of destinations described by the overlap=20 represents a portion of the less specific route=20 that is feasible, but is not currently in use.=20 If a more specific route is later withdrawn, the=20 set of destinations described by the overlap will=20 still be reachable using the less specific route. To me this says that, absent knowledge of a more=20 specific route, a speaker should route traffic=20 based on its knowledge of a less specific route,=20 which is the only thing it can do under those=20 circumstances. This seems to leave open the=20 possibility of configuring a speaker so that even=20 if no feasible route to a more specific prefix is=20 advertised, the speaker can choose to not use the=20 less specific route. For example that is what one=20 would want a speaker to do if the speaker knew=20 that the more specific prefix were originated by=20 a neighbor with no connections to other ASes. So,=20 a combination of configuration info and UPDATE=20 processing is needed to prevent misrouting of=20 traffic for more specific prefixes, in general. In section 5, the text says: Once a BGP peer has updated any well-known=20 attributes, it MUST pass these attributes in any=20 updates it transmits to its peers. This says clearly that path attributes are=20 transitive, passing from Adj-RIB-In to Loc-RIB to=20 Adj-RIB-Out. It does not say that a speaker can=20 arbitrarily modify the attributes received via an=20 UPDATE when the speaker generates a new UPDATE=20 based on that input. In 5.1.2 the text restates the notion that the AS=20 path in an UPDATE has traversed the ASes listed=20 in the path: AS_PATH is a well-known mandatory attribute. This=20 attribute identifies the autonomous systems=20 through which routing information carried in this=20 UPDATE message has passed. This section also describes how a speaker is=20 supposed to modify the AS path data from a=20 received UPDATE, by adding its own AS number to=20 the sequence as the last element, when sending an=20 UPDATE to an external BGP peer. If the speaker=20 originates a route, then is creates a new AS path=20 with its own AS number as the only element.=20 (Note that this text does not allow an originator=20 to create an AS set as the last element.) The end=20 of this subsection explicitly allows for adding=20 multiple instances of the ASes own number; this=20 is not seen by the spec as conflicting the notion=20 of the UPDATE having traversed the path it=20 contains, e.g., indicating a loop. Section 5.1.6 discuses the atomic aggregate=20 attribute, and how it is used when an speaker=20 aggregates routes. The text states that a speaker=20 MUST NOT make any of the advertised prefixes in=20 the NLRI more specific, which seems like a good=20 candidate for security requirements relative to=20 UPDATEs that contain this attribute. The text also notes that inclusion of this=20 attribute creates an exception to the general=20 rule that the path in an UPDATE reflects the path=20 that the UPDATE traversed: A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute needs to be aware of the fact that the=20 actual path to destinations, as specified in the=20 NLRI of the route, while having the loop-free=20 property, may not be the path specified in the=20 AS_PATH attribute of the route. To me this says that, except where noted by the=20 BGP spec, the security requirements should make=20 it a goal to be able to check that the advertised=20 path is the one traversed by the UPDATE. Later,=20 section 9.1.4 seems to suggest that use of this=20 attribute is now discouraged. If so, then we have=20 fewer reasons for paths in UPDATEs to deviate=20 from the paths the UPDATEs traversed. If not,=20 then we have an explicit indicator of aggregation=20 and an associated check to make. Section 5.1.7 discusses the Aggregator attribute,=20 but this attribute is optional, so security=20 requirements can address it, but only in terms of=20 "if present =8A" Section 9 describes UPDATE message handling. It=20 defines the algorithm that says how a speaker=20 processes received UPDATEs, when the "Decision=20 Process" is executed, and how UPDATEs are=20 constructed when the decision process calls for=20 emitting an UPDATE. Text at the beginning of this section requires=20 that all (optional, mandatory, and discretionary)=20 transitive attributes be "retained for=20 propagation to other BGP speakers." This=20 reinforces the notion that UPDATEs emitted by a=20 speaker are constructed by taking received=20 UPDATEs received by the speaker and processing=20 them as specified in this section. Section 9.1 describes the Decision Process, i.e.,=20 the three phase algorithm that selects routes for=20 advertisement to peers (and for internal use). It=20 uses the Adj-RIB-Ins and the PIB as inputs, the=20 Loc-RIB as the intermediate database, and the=20 Adj-RIB-Outs as the target databases that act as=20 drivers of Updates sent to specific peers. It=20 includes a description of how and when a speaker=20 may choose to perform aggregation. The text notes that "It is critical that BGP=20 speakers within an AS do not make conflicting=20 decisions regarding route selection that would=20 cause forwarding loops to occur." The proposed=20 security requirements goal of partial deployment=20 of a BGP security solution within a single AS may=20 run afoul of this warning; speakers running the a=20 secure BGP implementation may reach different=20 decisions from ones running "vanilla" BGP in the=20 same AS. That's why I suggested that we not make=20 it a requirement to be able to deploy a BGP=20 security solution incrementally within an AS. Section 9.1.4 describes how a speaker deals with=20 overlapping routes, a topic we have discussed on=20 numerous occasions. It explicitly allows a=20 speaker to aggregate a more and a less specific=20 route into a single advertisement, if both routes=20 have the same next hop. If an aggregated route is=20 advertised, there are two choices: - include all ASes used to form the aggregate in an AS set - add the atomic aggregate attribute to the route The text advises that the atomic aggregate=20 attribute is informational, given the current=20 state of CIDR support, and I interpret this to=20 mean that the first option is the one that is=20 most commonly employed. Is that true? If so, then=20 all the ASes involved in forming the aggregate=20 are present and can be used in verifying the=20 legitimacy of the aggregation. If not, then the=20 atomic aggregate attribute should be present and=20 at least it serves as an explicit flag to say=20 that the advertised route is an exception to the=20 general rule. It is not clear from the spec what checks a=20 speaker can/should perform for a route flagged=20 with this attribute, and the text makes it clear=20 that this is a case in which the path in the=20 UPDATE is not necessarily representative of the=20 path via which the contributing UPDATEs flowed.=20 Still, there is an obvious security-relevant=20 check that this text describes, i.e., a speaker=20 is expressly prohibited from deaggregating NLRI=20 that appears in a route with the atomic aggregate=20 attribute. Section 9.2.2.1 and 9.2.2.2 discusses aggregation=20 of NLRI and AS path data, with most of the=20 details in the latter section. The wording re=20 NLRI aggregation is a bit vague: In cases where there is a correspondence between=20 the address structure and the systems under=20 control of an autonomous system administrator, it=20 will be possible to reduce the size of the NLRI=20 carried in the UPDATE messages. Does this mean anything other than a speaker can=20 be configured to aggregate prefixes when the AS=20 operator is responsible for the component=20 prefixes, and if they are "adjacent" in the=20 address space? Does anyone have a clearer=20 statement of this that can be traced to previous=20 versions of to other RFCs? The rules for aggregating routes are complex and=20 I'm not sure I understand them completely. The=20 easiest case is when two routes learned by a=20 speaker for different NLRI have exactly the same=20 path. In that case one can construct a new route=20 that includes the NLRI from both routes. When=20 combining routes with different path attributes,=20 but the same NLRI, I think the rules say that the=20 path advertised as a result of aggregation must=20 satisfy the following criteria - every AS that appears in the resulting=20 aggregated path must appear in all of the routes=20 that contributed to the aggregated route. - all AS sets in the result must appear in=20 at least one of the paths that was aggregated,=20 and no duplicate AS sets can appear in the=20 aggregated route. - the order of every pair of individual=20 ASes (sequence elements, not sets) in the result=20 does no violate the ordering of these ASes in any=20 of the paths that were aggregated and where they=20 were present. - an individual AS may be replicated in the=20 aggregated route only if the copies are adjacent=20 (i.e., no loops can be introduced). There are additional rules about how to deal with=20 the atomic and aggregator attributes if present=20 in any of the routes to be aggregated. These=20 rules for route aggregation appear to provide=20 more precise constraints than in section 9.1. I=20 suggest that our security requirements call for=20 measures to enforce these rules, since BGP goes=20 to such great length to specify them. The subsection ends with an algorithm that=20 conforms to the rules, and another algorithm is=20 presented in appendix F.6. I have a question: Do=20 BGP implementations use these algorithms, or is=20 there diversity in the ways that aggregated=20 routes are constructed, in practice? Section 9.4 briefly describes route origination,=20 but it does not see to provide useful constraints=20 that we can employ in developing security=20 requirements. It primarily refers to IGP-acquired=20 routes, which are outside the scope of BGP=20 security measures. --============_-1107174825==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable a note from the BGP4 spec
Folks

I made a pass through the current version of BGP-4, the document that is about to be published as a full standard. I tried to extract quotes that deal with what I see as significant security issues for BGP, based on what the spec says are MUSTS/SHALLS and, in some cases, SHOULDS. I do have a couple of questions in this memo, areas where I as not quite sure what the spec means, of where I am not certain how implementations have chosen to deals with some subtle aspects of the spec.  I'm looking for feedback on this memo, as a way of making progress  on some of the issues that Russ and I have been debating.
 

In the Abstract:

The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity for this reachability from which routing loops may be pruned and some policy decisions at the AS level may be enforced.

To me this says that BGP embodies the notion that an Update nominally traverses the path that it contains, although we all agree that there will be exceptions, e.g., due to path aggregation.

Later the abstract says:

BGP-4 also introduces mechanisms which allow aggregation of routes, including aggregation of AS paths.

This is an explicit declaration of route aggregation, and an indirect mention of address aggregation.


In the Summary of Operation section (3.1) of the document:

In the context of this document we assume that a BGP speaker advertises to its peers only those routes that it itself uses (in this context a BGP speaker is said to "use" a BGP route if it is the most preferred BGP route and is used in forwarding). All other cases are outside the scope of this document.

This text states what it claims is the association between routes that a speaker advertises and the forwarding function that the speaker performs. Your gave an example of an AS advertising a route that contains an AS set constructed to cause another AS to reject the route. In that case I think you said that one of more AS set elements was artificially introduced to influence those ASes from accepting the route. This would seem to violate this part of the BGP spec, since the AS advertising this route does not "use" (forward traffic via) the indicated route, right?


In Section 4.3, the definition of the UPDATE message format, in describing the AS-PATH, the text says:

The path segment type is a 1-octet long field with the following values defined:


     Value      Segment Type


       1         AS_SET: unordered set of ASs a route in the
                    UPDATE message has traversed


       2         AS_SEQUENCE: ordered set of ASs a route in
                    the UPDATE message has traversed

Note that for both AS sequences and for AS sets, the specs says that they refer to a route that the UPDATE has traversed. This is why I have emphasized the need for the security requirements document to include this, i.e., the spec explicitly says that this is how BGP is supposed to work. Yes, we know that there are exceptions to this general rule, but this text suggests that, to first order, there should be a simple, verifiable relationship between an advertised AS path and the path traversed by the UPDATEs that contributed to the creation of the path.

MED is defined here as well, and it is non-transitive. That means that BGP security need not worry about imposing any transitive security measures to protect this attribute.

AGGREGATOR is defined here. It is transitive, and identifies the last AS (and the BGP speaker in that AS) that formed an aggregate route contained in an UPDATE.

Note that the text discusses inclusion of multiple destinations in the NLRI of one UPDATE, saying:

An UPDATE message can advertise at most one set of path attributes, but multiple destinations, provided that the destinations share these attributes. All path attributes contained in a given UPDATE message apply to all destinations carried in the NLRI field of the UPDATE message.

This says that an AS violates the spec if, for example, it includes prefixes in the NLRI that are not reachable via the path in the UPDATE. However, it does not state that all of the destinations contained in an advertised prefix are reachable via the advertised path. This is because subsets of address blocks are often further delegated. I think there is an implicit statement here that an AS must become aware of the delegation (e.g., via receipt of an advertisement from an AS representing the delegated subsets, or via static configuration info) in order to properly route/forward traffic for such destinations. Section 9.1.4 discusses the issue of overlapping routes and says:

The set of destinations described by the overlap represents a portion of the less specific route that is feasible, but is not currently in use.  If a more specific route is later withdrawn, the set of destinations described by the overlap will still be reachable using the less specific route.

To me this says that, absent knowledge of a more specific route, a speaker should route traffic based on its knowledge of a less specific route, which is the only thing it can do under those circumstances. This seems to leave open the possibility of configuring a speaker so that even if no feasible route to a more specific prefix is advertised, the speaker can choose to not use the less specific route. For example that is what one would want a speaker to do if the speaker knew that the more specific prefix were originated by a neighbor with no connections to other ASes. So, a combination of configuration info and UPDATE processing is needed to prevent misrouting of traffic for more specific prefixes, in general.

In section 5, the text says:

Once a BGP peer has updated any well-known attributes, it MUST pass these attributes in any updates it transmits to its peers.

This says clearly that path attributes are transitive, passing from Adj-RIB-In to Loc-RIB to Adj-RIB-Out. It does not say that a speaker can arbitrarily modify the attributes received via an UPDATE when the speaker generates a new UPDATE based on that input.

In 5.1.2 the text restates the notion that the AS path in an UPDATE has traversed the ASes listed in the path:

AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems through which routing information carried in this UPDATE message has passed.

This section also describes how a speaker is supposed to modify the AS path data from a received UPDATE, by adding its own AS number to the sequence as the last element, when sending an UPDATE to an external BGP peer. If the speaker originates a route, then is creates a new AS path with its own AS number as the only element.  (Note that this text does not allow an originator to create an AS set as the last element.) The end of this subsection explicitly allows for adding multiple instances of the ASes own number; this is not seen by the spec as conflicting the notion of the UPDATE having traversed the path it contains, e.g., indicating a loop.

Section 5.1.6 discuses the atomic aggregate attribute, and how it is used when an speaker aggregates routes. The text states that a speaker MUST NOT make any of the advertised prefixes in the NLRI more specific, which seems like a good candidate for security requirements relative to UPDATEs that contain this attribute.

The text also notes that inclusion of this attribute creates an exception to the general rule that the path in an UPDATE reflects the path that the UPDATE traversed:

A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute needs to be aware of the fact that the actual path to destinations, as specified in the NLRI of the route, while having the loop-free property, may not be the path specified in the AS_PATH attribute of the route.

To me this says that, except where noted by the BGP spec, the security requirements should make it a goal to be able to check that the advertised path is the one traversed by the UPDATE. Later, section 9.1.4 seems to suggest that use of this attribute is now discouraged. If so, then we have fewer reasons for paths in UPDATEs to deviate from the paths the UPDATEs traversed. If not, then we have an explicit indicator of aggregation and an associated check to make.

Section 5.1.7 discusses the Aggregator attribute, but this attribute is optional, so security requirements can address it, but only in terms of "if present =8A"

Section 9 describes UPDATE message handling. It defines the algorithm that says how a speaker processes received UPDATEs, when the "Decision Process" is executed, and how UPDATEs are constructed when the decision process calls for emitting an UPDATE.

Text at the beginning of this section requires that all (optional, mandatory, and discretionary) transitive attributes be "retained for propagation to other BGP speakers." This reinforces the notion that UPDATEs emitted by a speaker are constructed by taking received UPDATEs received by the speaker and processing them as specified in this section.

Section 9.1 describes the Decision Process, i.e., the three phase algorithm that selects routes for advertisement to peers (and for internal use). It uses the Adj-RIB-Ins and the PIB as inputs, the Loc-RIB as the intermediate database, and the Adj-RIB-Outs as the target databases that act as drivers of Updates sent to specific peers. It includes a description of how and when a speaker may choose to perform aggregation.

The text notes that "It is critical that BGP speakers within an AS do not make conflicting decisions regarding route selection that would cause forwarding loops to occur." The proposed security requirements goal of partial deployment of a BGP security solution within a single AS may run afoul of this warning; speakers running the a secure BGP implementation may reach different decisions from ones running "vanilla" BGP in the same AS. That's why I suggested that we not make it a requirement to be able to deploy a BGP security solution incrementally within an AS.

Section 9.1.4 describes how a speaker deals with overlapping routes, a topic we have discussed on numerous occasions. It explicitly allows a speaker to aggregate a more and a less specific route into a single advertisement, if both routes have the same next hop. If an aggregated route is advertised, there are two choices:
-  include all ASes used to form the aggregate in an AS set
-       add the atomic aggregate attribute to the route

The text advises that the atomic aggregate attribute is informational, given the current state of CIDR support, and I interpret this to mean that the first option is the one that is most commonly employed. Is that true? If so, then all the ASes involved in forming the aggregate are present and can be used in verifying the legitimacy of the aggregation. If not, then the atomic aggregate attribute should be present and at least it serves as an explicit flag to say that the advertised route is an exception to the general rule.

It is not clear from the spec what checks a speaker can/should perform for a route flagged with this attribute, and the text makes it clear that this is a case in which the path in the UPDATE is not necessarily representative of the path via which the contributing UPDATEs flowed. Still, there is an obvious security-relevant check that this text describes, i.e., a speaker is expressly prohibited from deaggregating NLRI that appears in a route with the atomic aggregate attribute.

Section 9.2.2.1 and 9.2.2.2 discusses aggregation of NLRI and AS path data, with most of the details in the latter section. The wording re NLRI aggregation is a bit vague:

In cases where there is a correspondence between the address structure and the systems under control of an autonomous system administrator, it will be possible to reduce the size of the NLRI carried in the UPDATE messages.

Does this mean anything other than a speaker can be configured to aggregate prefixes when the AS operator is responsible for the component prefixes, and if they are "adjacent" in the address space? Does anyone have a clearer statement of this that can be traced to previous versions of to other RFCs?

The rules for aggregating routes are complex and I'm not sure I understand them completely. The easiest case is when two routes learned by a speaker for different NLRI have exactly the same path. In that case one can construct a new route that includes the NLRI from both routes. When combining routes with different path attributes, but the same NLRI, I think the rules say that the path advertised as a result of aggregation must satisfy the following criteria
-       every AS that appears in the resulting aggregated path must appear in all of the routes that contributed to the aggregated route.
-      all AS sets in the result must appear in at least one of the paths that was aggregated, and no duplicate AS sets can appear in the aggregated route.
-   the order of every pair of individual ASes (sequence elements, not sets) in the result does no violate the ordering of these ASes in any of the paths that were aggregated and where they were present.
-        an individual AS may be replicated in the aggregated route only if the copies are adjacent (i.e., no loops can be introduced).

There are additional rules about how to deal with the atomic and aggregator attributes if present in any of the routes to be aggregated. These rules for route aggregation appear to provide more precise constraints than in section 9.1. I suggest that our security requirements call for measures to enforce these rules, since BGP goes to such great length to specify them.

The subsection ends with an algorithm that conforms to the rules, and another algorithm is presented in appendix F.6. I have a question: Do BGP implementations use these algorithms, or is there diversity in the ways that aggregated routes are constructed, in practice?

Section 9.4 briefly describes route origination, but it does not see to provide useful constraints that we can employ in developing security requirements. It primarily refers to IGP-acquired routes, which are outside the scope of BGP security measures.
--============_-1107174825==_ma============-- --===============2057089608== 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 --===============2057089608==-- From rpsec-bounces@ietf.org Wed Jan 5 13:06: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 NAA26509 for ; Wed, 5 Jan 2005 13:06:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFl2-0006hZ-0S for rpsec-web-archive@ietf.org; Wed, 05 Jan 2005 13:19:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFOR-0000HY-Kb; Wed, 05 Jan 2005 12:56:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFNO-00005m-5I for rpsec@megatron.ietf.org; Wed, 05 Jan 2005 12:55: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 MAA25778 for ; Wed, 5 Jan 2005 12:55:14 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFa0-0005om-Fj for rpsec@ietf.org; Wed, 05 Jan 2005 13:08: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 j05HsRjn012484; Wed, 5 Jan 2005 12:54:35 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 5 Jan 2005 12:49:31 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) 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: 10d3e4e3c32e363f129e380e644649be 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: b5d20af10c334b36874c0264b10f59f1 At 10:58 AM -0500 12/29/04, Russ White wrote: >>>-- The wording I've suggested will allow soBGP, S-BGP, IRV, and >>>SPV to meet them, I think. >> >>In contrast, what I see in your wording is explicitly designed to >>accommodate only soBGP! > >In other words, you believe that S-BGP doesn't prove the things I've >suggested as requirements? I didn't say that. I have not tried to see if your characterization of requirements is one that can be satisfied by S-BGP. What concerns me is that, in many cases, the proposed requirements are not directly traceable to the BGP specs, and they do seem to match the model adopted by soBGP. >What I believe is this: The requirements, as I've suggested them, >and as the current draft reads, can be met by S-BGP, IRV, SPV, and, >by chance, soBGP, as well. You're claim is that you can get "more >security" than what's in the current draft, and in my wording. SPV parallels S-BGP in many ways, so it is probably fair to say that both would be able to meet similarly stated requirements, except when one considers performance issues. IRV seems analogous parallel to soBGP, and so the same statement can probably be made for that pair or proposals. But, the best answers to the question of solution/requirements compatibility probably will come from the proponents of each approach, not from others. My observation is that some of the proposed requirements appear to be solution-motivated, rather than being derived from the BGP spec. For example, BGP has no notion of a reference topology that reflects "valid" routes on a global scale and that can be accessed by speakers to determine whether to accept a route in an Update. BGP does allow for local policy filters, but these are intended to reflect locally known topology info, something that is feasible for each AS to know about it's neighbors. So, my complaint about some of the requirements is that they seem to favor specific solutions or classes of solutions rather than being solution neutral and derived from the BGP spec itself. >My counter to this is your claim for "more security" falls apart >when you consider the way routing really works, including >aggregation. Your counter claim is that aggregation doesn't >matter--secure the process, not the data, because, magically, >securing the process always secures the data. Russ, I did NOT say that aggregation does not matter. Of course it does. What I said was that the simplest characterization of Udate validity does not accommodate some forms of aggregation. That does not mean that one cannot provide more complex statements of validity that do capture the various forms of aggregation. >I know which I prefer--secure the data, not the process. Secure the >data with the reality of aggregation in mind, with the way the >protocol is implemented and deployed as fundamental assumptions. There is certainly merit in the notion of ensuring the accuracy of the data, irrespective of the process by which the accuracy is established. If we can find a way to express that, without favoring one solution technology over another then I concur. But, the text proposed so far does not do that, in my opinion. I think that the BGP spec needs to be the basis for security requirements for BGP. >The wordings I've suggested allow any security system proposed to >claim "more security in specific case x," and it also leaves the >community free to evaluate that claim of "more security" in light of >the real world. I believe this is an acceptable compromise position, >in the long run, and the only way these drafts will move forward. I'm all in favor of moving forward, and compromise is sometime the only way to do that. But the current text is unacceptable, for the reasons I cited above. > >Would you like to move forward, or stay in the same argument for the >rest of forever? What I would like is to see proposed requirements that are traceable to the BGP spec and that do not favor any specific solution technology. To that end I have prepared a memo based on the latest BGP I-D (the one about to be issued as the full standard version RFC for BGP), which tries to capture security-relevant requirements from the text, and to relate them to some of the discussions we have been having. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 5 13:07: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 NAA26690 for ; Wed, 5 Jan 2005 13:07:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFm4-0006jQ-4c for rpsec-web-archive@ietf.org; Wed, 05 Jan 2005 13:20:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFOT-0000Hk-8E; Wed, 05 Jan 2005 12:56:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmFNP-00005t-Mm for rpsec@megatron.ietf.org; Wed, 05 Jan 2005 12:55: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 MAA25781 for ; Wed, 5 Jan 2005 12:55:16 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmFa2-0005op-1d for rpsec@ietf.org; Wed, 05 Jan 2005 13:08:22 -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 j05HsRjf012484; Wed, 5 Jan 2005 12:54:27 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 5 Jan 2005 11:27:24 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] BGP Req's Draft, Section 6 (III) 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: bdc523f9a54890b8a30dd6fd53d5d024 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: 3002fc2e661cd7f114cb6bae92fe88f1 At 4:38 PM -0500 12/28/04, Russ White wrote: >>6. Update Verification >> >>Update verification refers to the ability of a receiver to >>determine that a received Update is accurate, in terms of the >>identities of the ASes in the path attribute, the NLRI contained in >>the Update, and any other attributes used as inputs for route >>computation. Update verification entails several subsidiary >>security requirements that derive from the characteristics a >>receiver assumes is true of an Update in a non-hostile environment: > >>- the AS listed as the origin originated the Update, and the >>NLRI in the Update is "owned' by this AS. (need to modify this to >>take into account address aggregation) > >With aggregation, this sort of verification simply isn't possible. >Aggregation is the exception that proves the entire concept wrong, >IMHO. Aggregation comes in various flavors, so we need to be more precise in discussing what types of aggregation cause this simple statement to be wrong. For example, if a speaker aggregates NLRI from several routes with identical paths, as allowed by BGP, then the statement is still accurate, since, by definition, the paths were identical and thus has the same origin AS. If routes with different origin ASes are aggregated and the new route shows an AS as the origin, composed from all of the origins of the original routes, the statement is still true, if one interprets it appropriately for AS sets. If a speaker combines routes and makes itself the origin in an aggregated advertisement, then you are right that the real origins are no longer displayed in the aggregated route, and thus the statement above is not accurate. But, in that case I think BGP says that the atomic aggregator attribute is present, which alerts other speakers that the advertised route no longer reflects the true origin. One can reword the simple statement to accommodate this case. Are there other forms of aggregation that BGP specifies and that cause the origin AS in an UPDATE to be "different" and that provide no warning to other speakers? > >>- Each AS that appears in the path processed the Update and >>forwarded the Update to the next AS in the path (modulo any ASes >>removed from the path due to aggregation). > >You can't prove this, so it's impossible to make it a requirement. Two observations here: - the BGP spec makes essentially this statement in several places. I went back and reread the BGP spec in detail over the holidays, based on our discussions. As a result, I prepared a brief analysis of the BGP spec that quotes this and other, security-relevant text that I think should be considered as a basis for the security requirements document. - the S-BGP work we have done shows how to provide speakers with the info necessary to verify the bullet above, so I have to differ with your comment that one "cannot prove ..." > >>- If a no_export community attribute was included in the Update >>by an AS along the path, the attribute has not been removed to >>enable forwarding beyond what was intended by the AS than inserted >>it. > >I don't see how you can prove this one.... Again, this is a BGP spec reqirement, so it seems reasonable to make it a part of the security requirements. Moreover, we were able to provide a speaker with the ability to verify this property in S-BGP, so I again have to disagree with your comment about ones ability to "prove" this. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 5 16:14: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 QAA16937 for ; Wed, 5 Jan 2005 16:14:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmIhH-00054N-CS for rpsec-web-archive@ietf.org; Wed, 05 Jan 2005 16:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmI0j-00050F-FW; Wed, 05 Jan 2005 15:44:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmHyh-0003xF-Cg; Wed, 05 Jan 2005 15:41:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09859; Wed, 5 Jan 2005 15:41:57 -0500 (EST) Message-Id: <200501052041.PAA09859@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 05 Jan 2005 15:41:56 -0500 Cc: rpsec@ietf.org Subject: [RPSEC] I-D ACTION: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.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --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 : Generic Security Requirements for Routing Protocols Author(s) : D. McPherson, et al. Filename : draft-ietf-rpsec-generic-requirements-01.txt Pages : 48 Date : 2005-1-5 Routing protocols are subject to threats and attacks that can harm individual users or network operations as a whole. This document describes a generic set of security requirements for routing protocols and routing systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-generic-requirements-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-generic-requirements-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-generic-requirements-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-1-5153200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-generic-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-generic-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-5153200.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 Jan 5 16:29: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 QAA20283 for ; Wed, 5 Jan 2005 16:29:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmIvF-0008Oz-96 for rpsec-web-archive@ietf.org; Wed, 05 Jan 2005 16:42:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmIdN-0001O5-Py; Wed, 05 Jan 2005 16:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmI4x-0006yi-OA for rpsec@megatron.ietf.org; Wed, 05 Jan 2005 15:48:29 -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 PAA10171 for ; Wed, 5 Jan 2005 15:48:25 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmIHY-0007h1-Lw for rpsec@ietf.org; Wed, 05 Jan 2005 16:01:31 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 05 Jan 2005 15:47:50 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-422.cisco.com [10.82.217.168]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j05KlkW1028931; Wed, 5 Jan 2005 15:47:46 -0500 (EST) Date: Wed, 5 Jan 2005 15:47:06 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) 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: cab78e1e39c4b328567edb48482b6a69 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: 0ddefe323dd869ab027dbfff7eff0465 > What I would like is to see proposed requirements that are traceable to > the BGP spec and that do not favor any specific solution technology. To > that end I have prepared a memo based on the latest BGP I-D (the one > about to be issued as the full standard version RFC for BGP), which tries > to capture security-relevant requirements from the text, and to relate > them to some of the discussions we have been having. In other words, the only acceptable solution, to you, is to secure the process, and hope the data is magically secured by securing the process. The requirements should state what information must be verifiable, and in what way, for the system to be considered secure. I've tried to give several examples of this, but you either don't understand them, or move the discussion directly back to soBGP vs S-BGP, which I've completely avoided in all the phases here. For instance, if you were considering credit card information, would you consider securing the data--the siganture, the authorization, and the card number, etc.? Or would you consider securing the process--the paper the reciept is on, the color of the signing pen, etc? I would take the description of the system, as it operates, attempt to pull out the data that needs ot be secured, and then write a set of requirements around that data. You are, on the other hand, saying the only legitimate security is that which "follows the processing of the original information," without reference to the information itself. As long as we talk past each other, we will never get past this disagreement. You either have to look at a security system as trying to secure the data within the system, or securing the process of handling that data. It seems to me that you would rathe focus on one--securing the process--over the over--securing the data--simply because it fits the model of the security solution you've already proposed. I prefer the one that allows the maximum flexibility in designing any given security system, and letting operators and designers determine their own tradeoffs when designing and deploying a solution at some point in the future. :-) 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 Jan 5 17:17:41 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 RAA25256 for ; Wed, 5 Jan 2005 17:17:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmJg1-0000dL-1I for rpsec-web-archive@ietf.org; Wed, 05 Jan 2005 17:30:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmJPr-0000H9-OL; Wed, 05 Jan 2005 17:14:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmJLS-0006XQ-3q for rpsec@megatron.ietf.org; Wed, 05 Jan 2005 17:09: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 RAA24172 for ; Wed, 5 Jan 2005 17:09:31 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmJXw-0007AS-2q for rpsec@ietf.org; Wed, 05 Jan 2005 17:22:39 -0500 Received: from [IPv6:2002:52c0:5a1b:1::1] ([IPv6:2002:52c0:5a1b:1::1]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j05M8pW2054262 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Jan 2005 23:08:52 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> Content-Transfer-Encoding: quoted-printable From: Iljitsch van Beijnum Subject: Re: [RPSEC] a note from the BGP4 spec Date: Wed, 5 Jan 2005 23:09:06 +0100 To: Stephen Kent X-Mailer: Apple Mail (2.619) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 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: d008c19e97860b8641c1851f84665a75 Content-Transfer-Encoding: quoted-printable On 5-jan-05, at 18:54, Stephen Kent wrote: >> The primary function of a BGP speaking system is to exchange network=20= >> reachability information with other BGP systems. This network=20 >> reachability information includes information on the list of=20 >> Autonomous Systems (ASs) that reachability information traverses. > To me this says that BGP embodies the notion that an Update nominally=20= > traverses the path that it contains It "contains information on", which isn't exactly the same thing. > although we all agree that there will be exceptions, e.g., due to path=20= > aggregation. Not sure if we agree on this... (See below) >> BGP-4 also introduces mechanisms which allow aggregation of routes,=20= >> including aggregation of AS paths. Yuck! Is this supposed to be an update of RFC 1771? At the very least=20 they should remove implicit references to BGP3!?! >> In the context of this document we assume that a BGP speaker=20 >> advertises to its peers only those routes that it itself uses (in=20 >> this context a BGP speaker is said to "use" a BGP route if it is the=20= >> most preferred BGP route and is used in forwarding). All other cases=20= >> are outside the scope of this document. > This text states what it claims is the association between routes that=20= > a speaker advertises and the forwarding function that the speaker=20 > performs. Your You =3D ? > gave an example of an AS advertising a route that contains an AS set=20= > constructed to cause another AS to reject the route. In that case I=20 > think you said that one of more AS set elements was artificially=20 > introduced to influence those ASes from accepting the route. This=20 > would seem to violate this part of the BGP spec, since the AS=20 > advertising this route does not "use" (forward traffic via) the=20 > indicated route, right? Is there a definition of "route"? I think it means "NLRI + path=20 attributes", in which case there is no violation. (At least not on the=20= router level; it's not impossible that an AS advertises a certain route=20= but packets follow another.) > Note that for both AS sequences and for AS sets, the specs says that=20= > they refer to a route that the UPDATE has traversed. This is why I=20 > have emphasized the need for the security requirements document to=20 > include this, i.e., the spec explicitly says that this is how BGP is=20= > supposed to work. I think this type of aggregation is obsolete. I don't follow IDR, but I=20= believe their mission here is to describe the current situation, and=20 since this stuff is out there they can't remove it. However, IMNSHO it=20= would be a huge mistake to address this stuff in a secure version of=20 BGP since it means tons of headaches for something that nobody (for a=20 very large class of "nobody") uses. (Might be good to scan the global=20 routing table for AS sets and atomic aggregates, though.) >> An UPDATE message can advertise at most one set of path attributes,=20= >> but multiple destinations, provided that the destinations share these=20= >> attributes. All path attributes contained in a given UPDATE message=20= >> apply to all destinations carried in the NLRI field of the UPDATE=20 >> message. > This says that an AS violates the spec if, for example, it includes=20 > prefixes in the NLRI that are not reachable via the path in the=20 > UPDATE. Why would anyone advertise reachability for unreachable destination=20 NLRI? Not that advertisement guarantees reachability. >> The set of destinations described by the overlap represents a portion=20= >> of the less specific route that is feasible, but is not currently in=20= >> use. ??? No idea what this means... > This seems to leave open the possibility of configuring a speaker so=20= > that even if no feasible route to a more specific prefix is=20 > advertised, the speaker can choose to not use the less specific route. How? The only way this could happen is if there is a packet filter or a=20= non-BGP route that gets in the way. Both are outside the scope. > For example that is what one would want a speaker to do if the speaker=20= > knew that the more specific prefix were originated by a neighbor with=20= > no connections to other ASes. So, a combination of configuration info=20= > and UPDATE processing is needed to prevent misrouting of traffic for=20= > more specific prefixes, in general. How is BGP supposed to know this stuff? And how are other ASes supposed=20= to evaluate this AS' claims? Doesn't make sense. You advertise, you=20 route untill you hit a directly connected interface (which could be=20 null0 of course). > Section 5.1.6 discuses the atomic aggregate attribute, and how it is=20= > used when an speaker aggregates routes. The text states that a speaker=20= > MUST NOT make any of the advertised prefixes in the NLRI more specific (remember this) > The text notes that "It is critical that BGP speakers within an AS do=20= > not make conflicting decisions regarding route selection that would=20 > cause forwarding loops to occur." Critical is an understatement. > The proposed security requirements goal of partial deployment of a BGP=20= > security solution within a single AS may run afoul of this warning;=20 > speakers running the a secure BGP implementation may reach different=20= > decisions from ones running "vanilla" BGP in the same AS. That's why I=20= > suggested that we not make it a requirement to be able to deploy a BGP=20= > security solution incrementally within an AS. I'm not sure if that's reasonable. (Ever try to upgrade an AS with 600=20= routers?) Mandating AS-level flag days also isn't necessary, I don't=20 think: the requirement here is that routers don't select CONFLICTING=20 routes. It is perfectly legal for one router to reject routes another=20 router wants to use. So the secure routers simply use a smaller subset=20= of all possible routers (the verifiable ones). So if router A is secure and sees paths 1 and 3, and router B is=20 insecure and sees path 2, with path 1 being the worst and path 3 being=20= the best, and only path 1 is verifiable, A will select path 1 (2 and 3=20= aren't secure) but B will select 2 because it is "better" than 1. B=20 would ideally select 3, but this isn't allowed because that would=20 create a loop. It's also something that can't happen because A only=20 sends 1 to B as 1 is the one it uses itself. > If an aggregated route is advertised, there are two choices: > -=A0 include all ASes used to form the aggregate in an AS set > -=A0=A0=A0=A0=A0=A0 add the atomic aggregate attribute to the route Don't feel like looking it up, but isn't it both rather than either? >> In cases where there is a correspondence between the address=20 >> structure and the systems under control of an autonomous system=20 >> administrator, it will be possible to reduce the size of the NLRI=20 >> carried in the UPDATE messages. If you say so... Not sure what they're getting at. > The rules for aggregating routes are complex and I'm not sure I=20 > understand them completely. I think the part that you're overlooking is that all of this is nothing=20= more than a way for BGP4 and BGP3 to coexist. In order to gain the CIDR=20= benefits before the very last AS is upgraded to BGP4, BGP4=20 implementations can aggregate routes that are sourced by a BGP3 AS. So=20= if AS X has 192.0.0.0/20 but they run BGP3 so they announce 16 /24s, AS=20= Y can turn this into a single CIDR route. Conversely, CIDR routes can=20 be broken down into classful routes for BGP3 consumption. Since the=20 aggregation wreaks havoc on the AS path, an AS_SET is added that=20 includes all the ASes that aren't in the new path, and the=20 ATOMIC_AGGREGATE attribute is added to make sure the CIDR route isn't=20 broken down into a bunch of classful routers with a now shorter AS=20 path. (The more specifics with short AS paths would suck all the=20 traffic away from the real destination.) All of this is COMPLETELY obsolete. I believe these mechanisms are=20 still in use to aggregate intra-AS routes (which isn't really=20 appropriate) but if anyone is using this inter-AS, I don't see how they=20= can be doing something legit.= _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 5 18:47: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 SAA05093 for ; Wed, 5 Jan 2005 18:47:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmL4Y-0002fS-7B for rpsec-web-archive@ietf.org; Wed, 05 Jan 2005 19:00:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmKoT-0005gN-26; Wed, 05 Jan 2005 18:43:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmKmD-0005KM-27 for rpsec@megatron.ietf.org; Wed, 05 Jan 2005 18:41: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 SAA04778 for ; Wed, 5 Jan 2005 18:41:13 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmKyn-0000gd-5o for rpsec@ietf.org; Wed, 05 Jan 2005 18:54:22 -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 j05NeVjf001563; Wed, 5 Jan 2005 18:40:32 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> Date: Wed, 5 Jan 2005 18:40:25 -0500 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] a note from the BGP4 spec 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: fb93e867a11a29ac1dc5018706b412ac 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: 453b1bfcf0292bffe4cab90ba115f503 At 11:09 PM +0100 1/5/05, Iljitsch van Beijnum wrote: >On 5-jan-05, at 18:54, Stephen Kent wrote: > >>>The primary function of a BGP speaking system is to exchange >>>network reachability information with other BGP systems. This >>>network reachability information includes information on the list >>>of Autonomous Systems (ASs) that reachability information >>>traverses. > >>To me this says that BGP embodies the notion that an Update >>nominally traverses the path that it contains > >It "contains information on", which isn't exactly the same thing. You're right that the wording is slightly different here, but later parts of the document make precisely the statement I made, so I don't feel too bad about this one example not being perfectly aligned. Anyway, how would you characterize "contains information on?" > >>although we all agree that there will be exceptions, e.g., due to >>path aggregation. > >Not sure if we agree on this... (See below) OK, I'll read on ... > >>>BGP-4 also introduces mechanisms which allow aggregation of >>>routes, including aggregation of AS paths. > >Yuck! Is this supposed to be an update of RFC 1771? At the very >least they should remove implicit references to BGP3!?! Hey, it's not my document :-) > >>>In the context of this document we assume that a BGP speaker >>>advertises to its peers only those routes that it itself uses (in >>>this context a BGP speaker is said to "use" a BGP route if it is >>>the most preferred BGP route and is used in forwarding). All other >>>cases are outside the scope of this document. > >>This text states what it claims is the association between routes >>that a speaker advertises and the forwarding function that the >>speaker performs. Your > >You = ? sorry, the "your" here refers to Russ. When I started to assemble the memo it was in response to one of Russ's messages. Then, at the end, I decided to send it as a separate message to the list. > >>gave an example of an AS advertising a route that contains an AS >>set constructed to cause another AS to reject the route. In that >>case I think you said that one of more AS set elements was >>artificially introduced to influence those ASes from accepting the >>route. This would seem to violate this part of the BGP spec, since >>the AS advertising this route does not "use" (forward traffic via) >>the indicated route, right? > >Is there a definition of "route"? I think it means "NLRI + path >attributes", in which case there is no violation. (At least not on >the router level; it's not impossible that an AS advertises a >certain route but packets follow another.) yes, a route is NLRI plus path info. We agree that it is possible that the path taken by traffic will diverge from the advertised route, but the cited text in the BGP spec says that this should not be the case. certainly the text in the spec does not condone advertising a route with bogus AS entries as a means of preventing some AS from accepting the route. > >>Note that for both AS sequences and for AS sets, the specs says >>that they refer to a route that the UPDATE has traversed. This is >>why I have emphasized the need for the security requirements >>document to include this, i.e., the spec explicitly says that this >>is how BGP is supposed to work. > >I think this type of aggregation is obsolete. I don't follow IDR, >but I believe their mission here is to describe the current >situation, and since this stuff is out there they can't remove it. >However, IMNSHO it would be a huge mistake to address this stuff in >a secure version of BGP since it means tons of headaches for >something that nobody (for a very large class of "nobody") uses. >(Might be good to scan the global routing table for AS sets and >atomic aggregates, though.) After sending the message I asked a colleague to look at 2004 RV data and see how often the atomic aggregate and aggregator attribute shows up. The answer, based on examining about 3 months of data (so far) is that about 6-8% of the Updates had the atomic attribute and 7-9% had aggregator. So about 14-16% of all Updates had one or the other form of aggregation indicated. RPSEC and IDR are both in the routing area, not the operations area. So, I do think that the BGP spec is the appropriate starting place for a security requirements document that says it is for BGP. > >>>An UPDATE message can advertise at most one set of path >>>attributes, but multiple destinations, provided that the >>>destinations share these attributes. All path attributes contained >>>in a given UPDATE message apply to all destinations carried in the >>>NLRI field of the UPDATE message. > >>This says that an AS violates the spec if, for example, it includes >>prefixes in the NLRI that are not reachable via the path in the >>UPDATE. > >Why would anyone advertise reachability for unreachable destination >NLRI? Not that advertisement guarantees reachability. I was just noting some things that BGP explicitly says are no-nos and thus things that we should consider as security requirements. > >>>The set of destinations described by the overlap represents a >>>portion of the less specific route that is feasible, but is not >>>currently in use. > >??? No idea what this means... This is the text from the spec, and I too thought it was less than crystal clear. > >>This seems to leave open the possibility of configuring a speaker >>so that even if no feasible route to a more specific prefix is >>advertised, the speaker can choose to not use the less specific >>route. > >How? The only way this could happen is if there is a packet filter >or a non-BGP route that gets in the way. Both are outside the scope. Right. But people do use filters (or local policy, or whatever one chooses to call it) to protect themselves against such errors or attacks, don't they? BGP does make explicit provision for such local overrides of BGP-supplied routes and so it does seem reasonable, from a system security perspective, to consider what can be done to provide info in a secure fashion to facilitate configuring these policies. I think this is a big part of what Russ has advocated, and I agree that there is a need for such data in security solutions. It's just a matter of the extent to which such data is relied upon, and how one ensures its accuracy./. > >>For example that is what one would want a speaker to do if the >>speaker knew that the more specific prefix were originated by a >>neighbor with no connections to other ASes. So, a combination of >>configuration info and UPDATE processing is needed to prevent >>misrouting of traffic for more specific prefixes, in general. > >How is BGP supposed to know this stuff? And how are other ASes >supposed to evaluate this AS' claims? Doesn't make sense. You >advertise, you route untill you hit a directly connected interface >(which could be null0 of course). Again, I think this falls under the heading of local policy/filter data. The IRR model is designed to provide data of this sort, but it lacks suitable security controls to make it as reliable as one would want, i think. > >>Section 5.1.6 discuses the atomic aggregate attribute, and how it >>is used when an speaker aggregates routes. The text states that a >>speaker MUST NOT make any of the advertised prefixes in the NLRI >>more specific > >(remember this) > >>The text notes that "It is critical that BGP speakers within an AS >>do not make conflicting decisions regarding route selection that >>would cause forwarding loops to occur." > >Critical is an understatement. > > >>The proposed security requirements goal of partial deployment of a >>BGP security solution within a single AS may run afoul of this >>warning; speakers running the a secure BGP implementation may reach >>different decisions from ones running "vanilla" BGP in the same AS. >>That's why I suggested that we not make it a requirement to be able >>to deploy a BGP security solution incrementally within an AS. > >I'm not sure if that's reasonable. (Ever try to upgrade an AS with >600 routers?) Mandating AS-level flag days also isn't necessary, I >don't think: the requirement here is that routers don't select >CONFLICTING routes. It is perfectly legal for one router to reject >routes another router wants to use. So the secure routers simply use >a smaller subset of all possible routers (the verifiable ones). if one were deploying security software in an AS, one could first deploy it to al the routers, but not enable use of th security features until it was fully deployed. I admit to having never configured ANY router. However, when BBN ran the Arpanet and the Defense Data Network, we updated packet switch software remotely, in each switch in the net, then turned on new features in all of them, via remote management, in a very short time. Admittedly those nets were 200+ switches, not 600, but the principle was the same, i.e, tolerating transient routing instability in a net during the time it takes to turn on the new features. Still, you are right that if one could ensure that the security software selected a subset of the routes being used by the other routers, that would not conflict with the requirement I cited. >So if router A is secure and sees paths 1 and 3, and router B is >insecure and sees path 2, with path 1 being the worst and path 3 >being the best, and only path 1 is verifiable, A will select path 1 >(2 and 3 aren't secure) but B will select 2 because it is "better" >than 1. B would ideally select 3, but this isn't allowed because >that would create a loop. It's also something that can't happen >because A only sends 1 to B as 1 is the one it uses itself. I didn't follow your example in detail. I am willing to believe that partial deployment within an AS might be OK, but I do worry that there are a lot of ways for it to fail. > >>If an aggregated route is advertised, there are two choices: >> - include all ASes used to form the aggregate in an AS set >> - add the atomic aggregate attribute to the route > >Don't feel like looking it up, but isn't it both rather than either? > >>>In cases where there is a correspondence between the address >>>structure and the systems under control of an autonomous system >>>administrator, it will be possible to reduce the size of the NLRI >>>carried in the UPDATE messages. > >If you say so... Not sure what they're getting at. this is another puzzling piece of text, and it's one that I really do want to better understand. > >>The rules for aggregating routes are complex and I'm not sure I >>understand them completely. > >I think the part that you're overlooking is that all of this is >nothing more than a way for BGP4 and BGP3 to coexist. In order to >gain the CIDR benefits before the very last AS is upgraded to BGP4, >BGP4 implementations can aggregate routes that are sourced by a BGP3 >AS. So if AS X has 192.0.0.0/20 but they run BGP3 so they announce >16 /24s, AS Y can turn this into a single CIDR route. Conversely, >CIDR routes can be broken down into classful routes for BGP3 >consumption. Since the aggregation wreaks havoc on the AS path, an >AS_SET is added that includes all the ASes that aren't in the new >path, and the ATOMIC_AGGREGATE attribute is added to make sure the >CIDR route isn't broken down into a bunch of classful routers with a >now shorter AS path. (The more specifics with short AS paths would >suck all the traffic away from the real destination.) > >All of this is COMPLETELY obsolete. I believe these mechanisms are >still in use to aggregate intra-AS routes (which isn't really >appropriate) but if anyone is using this inter-AS, I don't see how >they can be doing something legit. I was not aware of the backwards compatibility motivation you cite for the rules. Also, the statistics I noted above on how often atomic still appears in Updates suggest that there are a number of operators who may not realize why the attribute is no longer needed. Without your explanation of the context, the rules seemed appropriate, i.e., they seem to state reasonable constraints on how to construct an aggregated route given various routes as inputs. Are you saying that there are no constraints now on how a speaker is supposed to create an aggregated route from the routes a speaker receives from its peers? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 5 19:33: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 TAA07857 for ; Wed, 5 Jan 2005 19:33:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmLng-0004ma-GS for rpsec-web-archive@ietf.org; Wed, 05 Jan 2005 19:46:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmLZk-0000mi-BM; Wed, 05 Jan 2005 19:32:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmLSP-0007pC-Gz for rpsec@megatron.ietf.org; Wed, 05 Jan 2005 19:24:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07477 for ; Wed, 5 Jan 2005 19:24:49 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmLf1-0002dD-9E for rpsec@ietf.org; Wed, 05 Jan 2005 19:37:59 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 05 Jan 2005 19:36:01 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-519.cisco.com [10.82.218.10]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j060OEW1022750; Wed, 5 Jan 2005 19:24:15 -0500 (EST) Date: Wed, 5 Jan 2005 19:23:35 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] a note from the BGP4 spec In-Reply-To: Message-ID: References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> 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: 4b800b1eab964a31702fa68f1ff0e955 Cc: rpsec@ietf.org, Iljitsch van Beijnum 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: d8ae4fd88fcaf47c1a71c804d04f413d > yes, a route is NLRI plus path info. We agree that it is possible that > the path taken by traffic will diverge from the advertised route, but the > cited text in the BGP spec says that this should not be the case. > certainly the text in the spec does not condone advertising a route with > bogus AS entries as a means of preventing some AS from accepting the > route. What you've not acknowledged is the problem is more extensive than this. The NLRI in the udpate is also aggregated, and the aggregate may contain information about routes the originator of the aggregate does not have authorization to advertise. The problem is, you want this: If you assign a prefix to someone else, they should always advertise that longer prefix past any possible aggregation. In the real world, this is false. The _point_ of aggregation is for this not to be true. > RPSEC and IDR are both in the routing area, not the operations area. So, > I do think that the BGP spec is the appropriate starting place for a > security requirements document that says it is for BGP. This is a non-sequitor. There are many paths to security, only one of which involves securing the process by which information is handled. Based on your statement, the routing area must never consider the application of any protocol it is involved in. Rather, it's all a matter of algorithms and packet descriptions, and no question of application, deployment, or implementation should enter into the discussion. However, if you actually look at the requirements for a protocol to become a standard, at least three documents are required: -- A protocol specification. -- An implementation report. -- A report on field experience with the protocol, in actual deployments. > Without your explanation of the context, the rules seemed appropriate, > i.e., they seem to state reasonable constraints on how to construct an > aggregated route given various routes as inputs. Are you saying that > there are no constraints now on how a speaker is supposed to create an > aggregated route from the routes a speaker receives from its peers? In reality, most aggregates are not generated by creating an aggregate using the rules in the BGP specification. In fact, most aggregates are originated by simply advertising the shorter prefix aggregate, and filtering the longer prefix prefixes within the aggregate's space. For instance, in Cisco configuration terms: ip route 10.1.0.0 255.255.0.0 null0 ! router bgp xxxx redistribute static And then the appropriate filter to kill off everything within 10.1/16, minus those routes your customers have asked you not to aggregate. This doesn't violate the BGP specification in any way, and creates an aggregate without an AS SET. This is what I think we mean when we say the AS SET isn't often used in real world BGP deployments. It's not that people don't use it, it's just that the majority of people don't, and the common usage is moving away from using AS SETs rather than towards it. :-) 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 Thu Jan 6 10:18:10 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 KAA15043 for ; Thu, 6 Jan 2005 10:18:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmZbh-00005W-Ii for rpsec-web-archive@ietf.org; Thu, 06 Jan 2005 10:31:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmZJZ-00043Q-NS; Thu, 06 Jan 2005 10:12:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmZDv-0000g2-Mn for rpsec@megatron.ietf.org; Thu, 06 Jan 2005 10:06: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 KAA13492 for ; Thu, 6 Jan 2005 10:06:49 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmZQY-0001rH-WF for rpsec@ietf.org; Thu, 06 Jan 2005 10:20:05 -0500 Received: from [IPv6:2002:52c0:5a1b:1::1] ([IPv6:2002:52c0:5a1b:1::1]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j06F5uW2065422 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Jan 2005 16:06:03 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <80096BB9-5FF4-11D9-BA2A-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] a note from the BGP4 spec Date: Thu, 6 Jan 2005 16:06:10 +0100 To: Stephen Kent X-Mailer: Apple Mail (2.619) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit On 6-jan-05, at 0:40, Stephen Kent wrote: > yes, a route is NLRI plus path info. We agree that it is possible that > the path taken by traffic will diverge from the advertised route, but > the cited text in the BGP spec says that this should not be the case. But how can this be enforced? > After sending the message I asked a colleague to look at 2004 RV data > and see how often the atomic aggregate and aggregator attribute shows > up. The answer, based on examining about 3 months of data (so far) is > that about 6-8% of the Updates had the atomic attribute and 7-9% had > aggregator. So about 14-16% of all Updates had one or the other form > of aggregation indicated. So no overlap? Strange. And this is much more than I expected. >>> That's why I suggested that we not make it a requirement to be able >>> to deploy a BGP security solution incrementally within an AS. >> I'm not sure if that's reasonable. (Ever try to upgrade an AS with >> 600 routers?) Mandating AS-level flag days also isn't necessary, I >> don't think: the requirement here is that routers don't select >> CONFLICTING routes. It is perfectly legal for one router to reject >> routes another router wants to use. So the secure routers simply use >> a smaller subset of all possible routers (the verifiable ones). > if one were deploying security software in an AS, one could first > deploy it to al the routers, but not enable use of th security > features until it was fully deployed. I should hope so. :-) > I admit to having never configured ANY router. Smart move. Leave this to the trained professionals... > However, when BBN ran the Arpanet and the Defense Data Network, we > updated packet switch software remotely, in each switch in the net, > then turned on new features in all of them, via remote management, in > a very short time. Admittedly those nets were 200+ switches, not 600, > but the principle was the same, i.e, tolerating transient routing > instability in a net during the time it takes to turn on the new > features. The trouble is that the internet as a whole is orders of magnitude larger than the ARPANET. Even single tier-1 networks are considerably larger than the ARPANET. And they are in competition, so it's important to not tick off customers with lengthy downtimes for maintenance. > Still, you are right that if one could ensure that the security > software selected a subset of the routes being used by the other > routers, that would not conflict with the requirement I cited. Ok. >> So if router A is secure and sees paths 1 and 3, and router B is >> insecure and sees path 2, with path 1 being the worst and path 3 >> being the best, and only path 1 is verifiable, A will select path 1 >> (2 and 3 aren't secure) but B will select 2 because it is "better" >> than 1. B would ideally select 3, but this isn't allowed because that >> would create a loop. It's also something that can't happen because A >> only sends 1 to B as 1 is the one it uses itself. > I didn't follow your example in detail. I am willing to believe that > partial deployment within an AS might be OK, but I do worry that there > are a lot of ways for it to fail. (With "sees" I mean "receives from an external AS.) I imagine that people will want to run the security stuff in some sort of "monitor" mode first, so that they get to see which routes would be rejected without them actually being rejected yet. Going from nothing to completely secure in one big leap would be too much for most people, I imagine. Also, an important problem is going to be the routing information that is in fact good, but can't be verified as such. Especially in the beginning this will be a large class because people have to get the hang of the new system. >>> If an aggregated route is advertised, there are two choices: >>> - include all ASes used to form the aggregate in an AS set >>> - add the atomic aggregate attribute to the route >> Don't feel like looking it up, but isn't it both rather than either? Answer: yes most of the time. See section 9.1.4 of RFC 1771. >> I think the part that you're overlooking is that all of this is >> nothing more than a way for BGP4 and BGP3 to coexist. In order to >> gain the CIDR benefits before the very last AS is upgraded to BGP4, >> BGP4 implementations can aggregate routes that are sourced by a BGP3 >> AS. [...] > I was not aware of the backwards compatibility motivation you cite for > the rules. I'm starting to doubt myself now... I can't find any source for this information: it's not in the RFCs or in Internet Routing Architectures. So either it must have been in something more obscure or I came up with this explanation on my own without realizing it... > Also, the statistics I noted above on how often atomic still appears > in Updates suggest that there are a number of operators who may not > realize why the attribute is no longer needed. > Without your explanation of the context, the rules seemed appropriate, > i.e., they seem to state reasonable constraints on how to construct an > aggregated route given various routes as inputs. Are you saying that > there are no constraints now on how a speaker is supposed to create an > aggregated route from the routes a speaker receives from its peers? As Russ said, most aggregates aren't generated using aggregate creation mechanisms, but simply by sourcing the aggregate as a new prefix and filtering out the more specifics. I'll even go further and claim that most aggregates aren't really aggregates, but people getting address space from an ISP's PA block and then announcing this space under their own AS. Obviously the entire PA block will also be announced under the ISP's AS. Usually, the ISP in question will also propagate the more specific. (If they didn't, there wouldn't be any incoming traffic through this ISP as the more specific points to another ISP.) Now all of this non-RFC-compliant aggregation works without any problems because of the longest match first rule. However, if we want to have the actual aggregation benefits, we need to get rid of the more specifics. The problem with this is that if you do this in one AS, the next AS is probably going to hear the aggregate and the more specific from different sources. I.e.: sourceAS / \ ISPA ISPB \ / ISPC | (inet) Assuming ISP A has 96.0.0.0/8 and the source AS announces 96.96.96.0/24. So if ISP A doesn't propagate the /24 to the ISP C, ISP C will see the /8 from A and the /24 from B. In the current situation ISP C will allow both the /8 and the /24 through, so there is no aggregation as seen by anyone behind ISP C. With aggressive aggregation, the /24 would go away (to come back when the /8 disappears, one hopes) but then the link over ISP becomes useless. So what we really want is for ISP C to compare the AS path and/or other metrics and select the path over B if this is better, but ignore this path and use the aggregate if A is better. (C would still most likely only propagate the aggregate downstream, though.) The BGP RFC allows for this, and mandates that the ISP B AS is listed in an AS_SET for the aggregate, and that the ATOMIC_AGGREGATE attribute is added as an indication of what's going on. However, unless I'm mistaken, all current implementations take the longest match first rule as gospel, so none of this comes into play. So to answer your question: if noone is listening, it doesn't matter if what you're saying is wrong. So in practice there are no limitations on how you can aggregate. Of course this will have to change when we add security, because we can't allow an unauthorized source to originate an aggregate. However, this doesn't mean only the holder of the address space gets to aggregate: people may trust others to aggregate for them. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 6 10:40: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 KAA16963 for ; Thu, 6 Jan 2005 10:40:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmZwu-0003SS-SW for rpsec-web-archive@ietf.org; Thu, 06 Jan 2005 10:53:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmZhy-0004LO-4T; Thu, 06 Jan 2005 10:37:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmZeX-0003cc-FI for rpsec@megatron.ietf.org; Thu, 06 Jan 2005 10:34:21 -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 KAA16541 for ; Thu, 6 Jan 2005 10:34:19 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmZrG-000060-Eo for rpsec@ietf.org; Thu, 06 Jan 2005 10:47:35 -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 j06FJ7jk027634; Thu, 6 Jan 2005 10:19:49 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> Date: Thu, 6 Jan 2005 10:11:16 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] a note from the BGP4 spec X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: rpsec@ietf.org, Iljitsch van Beijnum X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1504777416==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 --===============1504777416== Content-Type: multipart/alternative; boundary="============_-1107097710==_ma============" --============_-1107097710==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 7:23 PM -0500 1/5/05, Russ White wrote: >>yes, a route is NLRI plus path info. We agree that it is possible >>that the path taken by traffic will diverge from the advertised >>route, but the cited text in the BGP spec says that this should not >>be the case. certainly the text in the spec does not condone >>advertising a route with bogus AS entries as a means of preventing >>some AS from accepting the route. > >What you've not acknowledged is the problem is more extensive than >this. The NLRI in the udpate is also aggregated, and the aggregate >may contain information about routes the originator of the aggregate >does not have authorization to advertise. The last phrase above is very worrisome. if the speaker has included NLRI that it "does not have authorization to advertise" then this seems to be both a violation of the spirit (if not the letter) of the BGP spec, and it seems impossible to provide coherent security for the system if one wants to permit such behavior. Obviously, in the worst case, if we define a security system that allows a speaker to advertise NLRI without any notion of authorization, then we implicitly allow advertisements that can result in black holes, etc. So, there must be a better way to characterize what we want in terms of "valid" advertisements. >The problem is, you want this: If you assign a prefix to someone >else, they should always advertise that longer prefix past any >possible aggregation. > >In the real world, this is false. The _point_ of aggregation is for >this not to be true. The point of aggregation is to reduce the size of routing tables and to reduce the size of Updates, while still providing accurate routing data. It's OK to create an aggregate that encompasses a longer prefix, so long as doing so does not misrepresent what the speaker has been authorized to advertise, either via direct or transitive authorization by the prefix holders. >>RPSEC and IDR are both in the routing area, not the operations >>area. So, I do think that the BGP spec is the appropriate starting >>place for a security requirements document that says it is for BGP. > >This is a non-sequitor. There are many paths to security, only one >of which involves securing the process by which information is >handled. Russ, you continue to ignore what I say, and instead substitute what you want to argue about. I made a simple statement, which is not at all a non-sequitor. What I said was almost a tautology, i.e., one should define security for a protocol starting with the definition of the protocol. >Based on your statement, the routing area must never consider the >application of any protocol it is involved in. Rather, it's all a >matter of algorithms and packet descriptions, and no question of >application, deployment, or implementation should enter into the >discussion. However, if you actually look at the requirements for a >protocol to become a standard, at least three documents are required: > >-- A protocol specification. >-- An implementation report. >-- A report on field experience with the protocol, in actual deployments. The criteria for standards advancement tries to ensure that the protocol, as defined in the first document, is capable of being implemented in an interoperable fashion (based on experience reported in the second document). If field experience shows that the spec does not match what is deployed and interoperable, then the spec needs to change. For example, if one finds that a specified feature is not implemented and thus has not bee demonstrated to be interoperable, the feature cannot be retained as a MUST in the spec as the spec is advanced. The third document is not a substitute for a revised spec. >>Without your explanation of the context, the rules seemed >>appropriate, i.e., they seem to state reasonable constraints on how >>to construct an aggregated route given various routes as inputs. >>Are you saying that there are no constraints now on how a speaker >>is supposed to create an aggregated route from the routes a speaker >>receives from its peers? > >In reality, most aggregates are not generated by creating an >aggregate using the rules in the BGP specification. In fact, most >aggregates are originated by simply advertising the shorter prefix >aggregate, and filtering the longer prefix prefixes within the >aggregate's space. For instance, in Cisco configuration terms: > >ip route 10.1.0.0 255.255.0.0 null0 >! >router bgp xxxx > redistribute static > >And then the appropriate filter to kill off everything within >10.1/16, minus those routes your customers have asked you not to >aggregate. This doesn't violate the BGP specification in any way, >and creates an aggregate without an AS SET. Tow observations: - if the aggregation is done in a way inconsistent with the cited rules, that that would seem to be non-compliant, and it calls into question why the BGP-4 spec is being advanced with the rules still in it. - the example above is lacking context, and its expressed in CLI jargon that I don't speak, so it does not help explain your point to me. please try again. >This is what I think we mean when we say the AS SET isn't often used >in real world BGP deployments. It's not that people don't use it, >it's just that the majority of people don't, and the common usage is >moving away from using AS SETs rather than towards it. I said that we did not see many AS SETs when we analyzed BGP data a few years ago, so we are not disagreeing on that point. One thing that is missing from this discussion if a simple, clear characterization of what you assert are the allowed ways for speakers or ASes to perform aggregation, and why each way is reasonable, in a system context. It would be preferable if there were RFCs that you could cite to justify the behaviors you describe, so that we have an objective basis for evaluating them. Is your concern that there is no way to do this, algorithmically, and thus you emphasize examining the outcome of route propagation rather that defining the rules that characterize allowed aggregation, etc? Steve --============_-1107097710==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] a note from the BGP4 spec
At 7:23 PM -0500 1/5/05, Russ White wrote:
yes, a route is NLRI plus path info. We agree that it is possible that the path taken by traffic will diverge from the advertised route, but the cited text in the BGP spec says that this should not be the case. certainly the text in the spec does not condone advertising a route with bogus AS entries as a means of preventing some AS from accepting the route.

What you've not acknowledged is the problem is more extensive than this. The NLRI in the udpate is also aggregated, and the aggregate may contain information about routes the originator of the aggregate does not have authorization to advertise.

The last phrase above is very worrisome. if the speaker has included NLRI that it "does not have authorization to advertise" then this seems to be both a violation of the spirit (if not the letter) of the BGP spec, and it seems impossible to provide coherent security for the system if one wants to permit such behavior. Obviously, in the worst case, if we define a security system that allows a speaker to advertise NLRI without any notion of authorization, then we implicitly allow advertisements that can result in black holes, etc. So, there must be a better way to characterize what we want in terms of "valid" advertisements.

The problem is, you want this: If you assign a prefix to someone else, they should always advertise that longer prefix past any possible aggregation.

In the real world, this is false. The _point_ of aggregation is for this not to be true.

The point of aggregation is to reduce the size of routing tables and to reduce the size of Updates, while still providing accurate routing data. It's OK to create an aggregate that encompasses a longer prefix, so long as doing so does not misrepresent what the speaker has been authorized to advertise, either via direct or transitive authorization by the prefix holders.

RPSEC and IDR are both in the routing area, not the operations area. So, I do think that the BGP spec is the appropriate starting place for a security requirements document that says it is for BGP.

This is a non-sequitor. There are many paths to security, only one of which involves securing the process by which information is handled.

Russ, you continue to ignore what I say, and instead substitute what you want to argue about. I made a simple statement, which is not at all a non-sequitor. What I said was almost a tautology, i.e., one should define security for a protocol starting with the definition of the protocol.

Based on your statement, the routing area must never consider the application of any protocol it is involved in. Rather, it's all a matter of algorithms and packet descriptions, and no question of application, deployment, or implementation should enter into the discussion. However, if you actually look at the requirements for a protocol to become a standard, at least three documents are required:

-- A protocol specification.
-- An implementation report.
-- A report on field experience with the protocol, in actual deployments.

The criteria for standards advancement tries to ensure that the protocol, as defined in the first document, is capable of being implemented in an interoperable fashion (based on experience reported in the second document). If field experience shows that the spec does not match what is deployed and interoperable, then the spec needs to change. For example, if one finds that a specified feature is not implemented and thus has not bee demonstrated to be interoperable, the feature cannot be retained as a MUST in the spec as the spec is advanced. The third document is not a substitute for a revised spec.

Without your explanation of the context, the rules seemed appropriate, i.e., they seem to state reasonable constraints on how to construct an aggregated route given various routes as inputs. Are you saying that there are no constraints now on how a speaker is supposed to create an aggregated route from the routes a speaker receives from its peers?

In reality, most aggregates are not generated by creating an aggregate using the rules in the BGP specification. In fact, most aggregates are originated by simply advertising the shorter prefix aggregate, and filtering the longer prefix prefixes within the aggregate's space. For instance, in Cisco configuration terms:

ip route 10.1.0.0 255.255.0.0 null0
!
router bgp xxxx
 redistribute static

And then the appropriate filter to kill off everything within 10.1/16, minus those routes your customers have asked you not to aggregate. This doesn't violate the BGP specification in any way, and creates an aggregate without an AS SET.

Tow observations:
        - if the aggregation is done in a way inconsistent with the cited rules, that that would seem to be non-compliant, and it calls into question why the BGP-4 spec is being advanced with the rules still in it.

        - the example above is lacking context, and its expressed in CLI jargon that I don't speak, so it does not help explain your point to me. please try again.

This is what I think we mean when we say the AS SET isn't often used in real world BGP deployments. It's not that people don't use it, it's just that the majority of people don't, and the common usage is moving away from using AS SETs rather than towards it.

I said that we did not see many AS SETs when we analyzed BGP data a few years ago, so we are not disagreeing on that point.

One thing that is missing from this discussion if a simple, clear characterization of what you assert are the allowed ways for speakers or ASes to perform aggregation, and why each way is reasonable, in a system context.  It would be preferable if there were RFCs that you could cite to justify the behaviors you describe, so that we have an objective basis for evaluating them. Is your concern that there is no way to do this, algorithmically, and thus you emphasize examining the outcome of route propagation rather that defining the rules that characterize allowed aggregation, etc?

Steve
--============_-1107097710==_ma============-- --===============1504777416== 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 --===============1504777416==-- From rpsec-bounces@ietf.org Thu Jan 6 11:35: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 LAA21012 for ; Thu, 6 Jan 2005 11:35:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmaog-0002nM-AB for rpsec-web-archive@ietf.org; Thu, 06 Jan 2005 11:48:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmaW5-0001ta-6T; Thu, 06 Jan 2005 11:29:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmaTm-0001Aw-Cs for rpsec@megatron.ietf.org; Thu, 06 Jan 2005 11:27: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 LAA20572 for ; Thu, 6 Jan 2005 11:27:16 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmagY-0005ws-G7 for rpsec@ietf.org; Thu, 06 Jan 2005 11:40:33 -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 j06GQZjj001907; Thu, 6 Jan 2005 11:26:38 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> Date: Thu, 6 Jan 2005 10:11:16 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] a note from the BGP4 spec X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: rpsec@ietf.org, Iljitsch van Beijnum X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1681904640==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 --===============1681904640== Content-Type: multipart/alternative; boundary="============_-1107093700==_ma============" --============_-1107093700==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 7:23 PM -0500 1/5/05, Russ White wrote: >>yes, a route is NLRI plus path info. We agree that it is possible >>that the path taken by traffic will diverge from the advertised >>route, but the cited text in the BGP spec says that this should not >>be the case. certainly the text in the spec does not condone >>advertising a route with bogus AS entries as a means of preventing >>some AS from accepting the route. > >What you've not acknowledged is the problem is more extensive than >this. The NLRI in the udpate is also aggregated, and the aggregate >may contain information about routes the originator of the aggregate >does not have authorization to advertise. The last phrase above is very worrisome. if the speaker has included NLRI that it "does not have authorization to advertise" then this seems to be both a violation of the spirit (if not the letter) of the BGP spec, and it seems impossible to provide coherent security for the system if one wants to permit such behavior. Obviously, in the worst case, if we define a security system that allows a speaker to advertise NLRI without any notion of authorization, then we implicitly allow advertisements that can result in black holes, etc. So, there must be a better way to characterize what we want in terms of "valid" advertisements. >The problem is, you want this: If you assign a prefix to someone >else, they should always advertise that longer prefix past any >possible aggregation. > >In the real world, this is false. The _point_ of aggregation is for >this not to be true. The point of aggregation is to reduce the size of routing tables and to reduce the size of Updates, while still providing accurate routing data. It's OK to create an aggregate that encompasses a longer prefix, so long as doing so does not misrepresent what the speaker has been authorized to advertise, either via direct or transitive authorization by the prefix holders. >>RPSEC and IDR are both in the routing area, not the operations >>area. So, I do think that the BGP spec is the appropriate starting >>place for a security requirements document that says it is for BGP. > >This is a non-sequitor. There are many paths to security, only one >of which involves securing the process by which information is >handled. Russ, you continue to ignore what I say, and instead substitute what you want to argue about. I made a simple statement, which is not at all a non-sequitor. What I said was almost a tautology, i.e., one should define security for a protocol starting with the definition of the protocol. >Based on your statement, the routing area must never consider the >application of any protocol it is involved in. Rather, it's all a >matter of algorithms and packet descriptions, and no question of >application, deployment, or implementation should enter into the >discussion. However, if you actually look at the requirements for a >protocol to become a standard, at least three documents are required: > >-- A protocol specification. >-- An implementation report. >-- A report on field experience with the protocol, in actual deployments. The criteria for standards advancement tries to ensure that the protocol, as defined in the first document, is capable of being implemented in an interoperable fashion (based on experience reported in the second document). If field experience shows that the spec does not match what is deployed and interoperable, then the spec needs to change. For example, if one finds that a specified feature is not implemented and thus has not bee demonstrated to be interoperable, the feature cannot be retained as a MUST in the spec as the spec is advanced. The third document is not a substitute for a revised spec. >>Without your explanation of the context, the rules seemed >>appropriate, i.e., they seem to state reasonable constraints on how >>to construct an aggregated route given various routes as inputs. >>Are you saying that there are no constraints now on how a speaker >>is supposed to create an aggregated route from the routes a speaker >>receives from its peers? > >In reality, most aggregates are not generated by creating an >aggregate using the rules in the BGP specification. In fact, most >aggregates are originated by simply advertising the shorter prefix >aggregate, and filtering the longer prefix prefixes within the >aggregate's space. For instance, in Cisco configuration terms: > >ip route 10.1.0.0 255.255.0.0 null0 >! >router bgp xxxx > redistribute static > >And then the appropriate filter to kill off everything within >10.1/16, minus those routes your customers have asked you not to >aggregate. This doesn't violate the BGP specification in any way, >and creates an aggregate without an AS SET. Tow observations: - if the aggregation is done in a way inconsistent with the cited rules, that that would seem to be non-compliant, and it calls into question why the BGP-4 spec is being advanced with the rules still in it. - the example above is lacking context, and its expressed in CLI jargon that I don't speak, so it does not help explain your point to me. please try again. >This is what I think we mean when we say the AS SET isn't often used >in real world BGP deployments. It's not that people don't use it, >it's just that the majority of people don't, and the common usage is >moving away from using AS SETs rather than towards it. I said that we did not see many AS SETs when we analyzed BGP data a few years ago, so we are not disagreeing on that point. One thing that is missing from this discussion if a simple, clear characterization of what you assert are the allowed ways for speakers or ASes to perform aggregation, and why each way is reasonable, in a system context. It would be preferable if there were RFCs that you could cite to justify the behaviors you describe, so that we have an objective basis for evaluating them. Is your concern that there is no way to do this, algorithmically, and thus you emphasize examining the outcome of route propagation rather that defining the rules that characterize allowed aggregation, etc? Steve --============_-1107093700==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] a note from the BGP4 spec
At 7:23 PM -0500 1/5/05, Russ White wrote:
yes, a route is NLRI plus path info. We agree that it is possible that the path taken by traffic will diverge from the advertised route, but the cited text in the BGP spec says that this should not be the case. certainly the text in the spec does not condone advertising a route with bogus AS entries as a means of preventing some AS from accepting the route.

What you've not acknowledged is the problem is more extensive than this. The NLRI in the udpate is also aggregated, and the aggregate may contain information about routes the originator of the aggregate does not have authorization to advertise.

The last phrase above is very worrisome. if the speaker has included NLRI that it "does not have authorization to advertise" then this seems to be both a violation of the spirit (if not the letter) of the BGP spec, and it seems impossible to provide coherent security for the system if one wants to permit such behavior. Obviously, in the worst case, if we define a security system that allows a speaker to advertise NLRI without any notion of authorization, then we implicitly allow advertisements that can result in black holes, etc. So, there must be a better way to characterize what we want in terms of "valid" advertisements.

The problem is, you want this: If you assign a prefix to someone else, they should always advertise that longer prefix past any possible aggregation.

In the real world, this is false. The _point_ of aggregation is for this not to be true.

The point of aggregation is to reduce the size of routing tables and to reduce the size of Updates, while still providing accurate routing data. It's OK to create an aggregate that encompasses a longer prefix, so long as doing so does not misrepresent what the speaker has been authorized to advertise, either via direct or transitive authorization by the prefix holders.

RPSEC and IDR are both in the routing area, not the operations area. So, I do think that the BGP spec is the appropriate starting place for a security requirements document that says it is for BGP.

This is a non-sequitor. There are many paths to security, only one of which involves securing the process by which information is handled.

Russ, you continue to ignore what I say, and instead substitute what you want to argue about. I made a simple statement, which is not at all a non-sequitor. What I said was almost a tautology, i.e., one should define security for a protocol starting with the definition of the protocol.

Based on your statement, the routing area must never consider the application of any protocol it is involved in. Rather, it's all a matter of algorithms and packet descriptions, and no question of application, deployment, or implementation should enter into the discussion. However, if you actually look at the requirements for a protocol to become a standard, at least three documents are required:

-- A protocol specification.
-- An implementation report.
-- A report on field experience with the protocol, in actual deployments.

The criteria for standards advancement tries to ensure that the protocol, as defined in the first document, is capable of being implemented in an interoperable fashion (based on experience reported in the second document). If field experience shows that the spec does not match what is deployed and interoperable, then the spec needs to change. For example, if one finds that a specified feature is not implemented and thus has not bee demonstrated to be interoperable, the feature cannot be retained as a MUST in the spec as the spec is advanced. The third document is not a substitute for a revised spec.

Without your explanation of the context, the rules seemed appropriate, i.e., they seem to state reasonable constraints on how to construct an aggregated route given various routes as inputs. Are you saying that there are no constraints now on how a speaker is supposed to create an aggregated route from the routes a speaker receives from its peers?

In reality, most aggregates are not generated by creating an aggregate using the rules in the BGP specification. In fact, most aggregates are originated by simply advertising the shorter prefix aggregate, and filtering the longer prefix prefixes within the aggregate's space. For instance, in Cisco configuration terms:

ip route 10.1.0.0 255.255.0.0 null0
!
router bgp xxxx
 redistribute static

And then the appropriate filter to kill off everything within 10.1/16, minus those routes your customers have asked you not to aggregate. This doesn't violate the BGP specification in any way, and creates an aggregate without an AS SET.

Tow observations:
        - if the aggregation is done in a way inconsistent with the cited rules, that that would seem to be non-compliant, and it calls into question why the BGP-4 spec is being advanced with the rules still in it.

        - the example above is lacking context, and its expressed in CLI jargon that I don't speak, so it does not help explain your point to me. please try again.

This is what I think we mean when we say the AS SET isn't often used in real world BGP deployments. It's not that people don't use it, it's just that the majority of people don't, and the common usage is moving away from using AS SETs rather than towards it.

I said that we did not see many AS SETs when we analyzed BGP data a few years ago, so we are not disagreeing on that point.

One thing that is missing from this discussion if a simple, clear characterization of what you assert are the allowed ways for speakers or ASes to perform aggregation, and why each way is reasonable, in a system context.  It would be preferable if there were RFCs that you could cite to justify the behaviors you describe, so that we have an objective basis for evaluating them. Is your concern that there is no way to do this, algorithmically, and thus you emphasize examining the outcome of route propagation rather that defining the rules that characterize allowed aggregation, etc?

Steve
--============_-1107093700==_ma============-- --===============1681904640== 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 --===============1681904640==-- From rpsec-bounces@ietf.org Thu Jan 6 11:36: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 LAA21074 for ; Thu, 6 Jan 2005 11:36:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmapf-0002oM-IL for rpsec-web-archive@ietf.org; Thu, 06 Jan 2005 11:49:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmaW5-0001u6-Og; Thu, 06 Jan 2005 11:29:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmaUB-0001NB-0H for rpsec@megatron.ietf.org; Thu, 06 Jan 2005 11:27:43 -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 LAA20682 for ; Thu, 6 Jan 2005 11:27:40 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmagw-0005xV-9d for rpsec@ietf.org; Thu, 06 Jan 2005 11:40:57 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2005 11:38:58 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-306.cisco.com [10.82.217.52]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j06GR5DY015843; Thu, 6 Jan 2005 11:27:05 -0500 (EST) Date: Thu, 6 Jan 2005 11:26:26 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] a note from the BGP4 spec In-Reply-To: Message-ID: References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> 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: 36c793b20164cfe75332aa66ddb21196 Cc: rpsec@ietf.org, Iljitsch van Beijnum 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: 1676547e4f33b5e63227e9c02bd359e3 >> What you've not acknowledged is the problem is more extensive than this. >> The NLRI in the udpate is also aggregated, and the aggregate may contain >> information about routes the originator of the aggregate does not have >> authorization to advertise. > > The last phrase above is very worrisome. if the speaker has included NLRI > that it "does not have authorization to advertise" then this seems to be > both a violation of the spirit (if not the letter) of the BGP spec, and > it seems impossible to provide coherent security for the system if one > wants to permit such behavior. Obviously, in the worst case, if we define > a security system that allows a speaker to advertise NLRI without any > notion of authorization, then we implicitly allow advertisements that can > result in black holes, etc. So, there must be a better way to > characterize what we want in terms of "valid" advertisements. ISP A "owns" 10.1.0.0/16. They allocate 10.1.1.0/24 to their customer, so the customer now "owns" 10.1.1.0/24. How do you "stop" the ISP from advertising 10.1.0.0/16 at this point, as a part of the /16? If the ISP doesn't have an advertisement for 10.1.1.0/24, then the ISP is disallowed from advertising 10.1.0.0/16, because they don't have authorization for _every component_ of that aggregate? Obviously, you don't. Address block ownership overlaps in the same way aggregation overlaps. I think I've said this several times on this thread. This single fact invalidates the entire concept of securing BGP as a "set of processes," and forces you to look at how to secure the data itself, in some meaningful way. > The point of aggregation is to reduce the size of routing tables and to > reduce the size of Updates, while still providing accurate routing data. > It's OK to create an aggregate that encompasses a longer prefix, so long > as doing so does not misrepresent what the speaker has been authorized to > advertise, either via direct or transitive authorization by the prefix > holders. Again, how do you _prove_ this? You can't, beacause it's impossible. The entire draft "Considerations in Validating the Path in BGP" proves this through examples. I've not seen a single refutation of those arguments, here or elsewhere. The ambiguous concept of ownership of address space combined with the ability to filter longer prefix matches and advertise an aggregate you didn't originate make this impossible to prove. Can you show otherwise? >> This is a non-sequitor. There are many paths to security, only one of >> which involves securing the process by which information is handled. > > Russ, you continue to ignore what I say, and instead substitute what you > want to argue about. I made a simple statement, which is not at all a > non-sequitor. What I said was almost a tautology, i.e., one should define > security for a protocol starting with the definition of the protocol. No, you should define security for a system based on what information within the system needs to be secured, and leave flexibility about how to secure those pieces of data. Once again, this is akin to securing credit card transactions by working from the process used to handle credit card transactions, rather than starting from the data you need to be secured. >> And then the appropriate filter to kill off everything within 10.1/16, >> minus those routes your customers have asked you not to aggregate. This >> doesn't violate the BGP specification in any way, and creates an aggregate >> without an AS SET. > > Tow observations: > - if the aggregation is done in a way inconsistent with the cited > rules, that that would seem to be non-compliant, and it calls into > question why the BGP-4 spec is being advanced with the rules still in it. You missed the point that this isn't out of compliance. This is perfectly normal. If I own 10.1.0.0/16, I can originate it any way I want to. I'm not restricted to including the AS' of anyone advertising a longer prefix falling within that shorter prefix. In fact, the entire concept of an "aggregate" is muddying the discussion, somewhat. There are overlapping prefixes. Sometimes they represent aggregates, sometimes they don't. You're taking a very procedural approach to the problem, and missing a lot of the actual core of the actual problem. > One thing that is missing from this discussion if a simple, clear > characterization of what you assert are the allowed ways for speakers or > ASes to perform aggregation, and why each way is reasonable, in a system > context. It would be preferable if there were RFCs that you could cite to > justify the behaviors you describe, so that we have an objective basis > for evaluating them. Is your concern that there is no way to do this, > algorithmically, and thus you emphasize examining the outcome of route > propagation rather that defining the rules that characterize allowed > aggregation, etc? If I "own" an address block, I'm authorized to advertise it. You're trying to get to the point of saying: -- If you don't have an advertisement for every suballocation under your allocation, authorizing you to advertise each possible piece of that aggregate, then you can't advertise that aggregate. -- Even if you have every one of these advertisements, you MUST include the AS of every AS you've received such "authorization" from. This, essentially, means: You can't aggregate to provide the security you're claiming we should require in the draft. The concept of "transitive authorization," in the terms you're trying to apply it BGP, simply doesn't exist. You can point out all sorts of phrases and comments in the draft, but you have to temper these statements with the actual operation of BGP in the real world, with real address ownership concepts, real aggregation, and real route origination policies. :-) 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 Thu Jan 6 11:37: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 LAA21203 for ; Thu, 6 Jan 2005 11:37:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmaqr-0003H7-Hc for rpsec-web-archive@ietf.org; Thu, 06 Jan 2005 11:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmaW7-0001vH-8G; Thu, 06 Jan 2005 11:29:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmaUc-0001OL-Cu for rpsec@megatron.ietf.org; Thu, 06 Jan 2005 11:28: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 LAA20688 for ; Thu, 6 Jan 2005 11:28:08 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmahO-0005y0-Pk for rpsec@ietf.org; Thu, 06 Jan 2005 11:41:25 -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 j06GQZjf001907; Thu, 6 Jan 2005 11:26:36 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 6 Jan 2005 11:26:30 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) 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: 6e922792024732fb1bb6f346e63517e4 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: 9a2be21919e71dc6faef12b370c4ecf5 At 3:47 PM -0500 1/5/05, Russ White wrote: >>What I would like is to see proposed requirements that are >>traceable to the BGP spec and that do not favor any specific >>solution technology. To that end I have prepared a memo based on >>the latest BGP I-D (the one about to be issued as the full standard >>version RFC for BGP), which tries to capture security-relevant >>requirements from the text, and to relate them to some of the >>discussions we have been having. > >In other words, the only acceptable solution, to you, is to secure >the process, and hope the data is magically secured by securing the >process. I think this is an grossly unfair characterization. BGP is a protocol, which defines of formats for messages and an algorithm for processing these messages, in the context of local databases. If we define security for BGP in terms of generating the "right" routes even when the systems is under attack, we need to begin with the process that generates the routes under benign conditions. I agree that one may be able to generate rules for characterizing what routes are authorized/valid/... independent of the process by which they are generated. BUT, if you want to do that, rather than focusing on securing the process, the burden is on you to show that the results are equivalent. >The requirements should state what information must be verifiable, >and in what way, for the system to be considered secure. I've tried >to give several examples of this, but you either don't understand >them, or move the discussion directly back to soBGP vs S-BGP, which >I've completely avoided in all the phases here. For instance, if you >were considering credit card information, would you consider >securing the data--the siganture, the authorization, and the card >number, etc.? Or would you consider securing the process--the paper >the reciept is on, the color of the signing pen, etc? You have provided some analogies, but I noted some problems with them. Your example above, I fear, is similarly flawed. In the credit card space there are valid accounts and authorized users. The primary security goal here is to ensure that charges are associated with valid accounts and incurred on behalf of authorized users. That's the high level security goal and it is very much independent of process. It applies whether the cards are used in card present or MOTO transactions. But, the standards that exist for the credit card industry do not strike me as analogous to those for BGP. They relate to formats for CC numbers, card size, mag stripe format, and low-level security mechanisms for communication. These standards address different ways of using credit cards in different contexts, and none of them happen to overlap with the examples you cite above, e.g., credit slip paper and pen color! >I would take the description of the system, as it operates, attempt >to pull out the data that needs ot be secured, and then write a set >of requirements around that data. You are, on the other hand, saying >the only legitimate security is that which "follows the processing >of the original information," without reference to the information >itself. I am saying that the definition of how BGP routing is supposed to work needs to be based on the BGP spec. Its an IETF standard and an objective basis from which to work. What IETF standard description of "the system" would you propose to use as the basis for developing security requirements for BGP? >As long as we talk past each other, we will never get past this >disagreement. You either have to look at a security system as trying >to secure the data within the system, or securing the process of >handling that data. > >It seems to me that you would rathe focus on one--securing the >process--over the over--securing the data--simply because it fits >the model of the security solution you've already proposed. I prefer >the one that allows the maximum flexibility in designing any given >security system, and letting operators and designers determine their >own tradeoffs when designing and deploying a solution at some point >in the future. We both have prejudices in approaching this problem. One can fairly say that I used the BGP spec as the basis for developing the security requirements model that we then addressed with S-BGP. Likewise, you adopted an operations-oriented view of security when you developed soBGP. That does not make either approach intrinsically valid or invalid. But, what you refer to as an approach that allows for "maximum flexibility ..." just happens to be the same one you used, and so it does reflect that bias, and that is a problem. We have a fundamental disagreement about what constitutes a legitimate basis for deriving BGP security requirements. I understand your point of view, but I disagree. Since you are co-chair of this WG you have an obvious conflict of interest problem in trying to resolve this at the WG chair level. Perhaps the right thing to do at this stage is to bring the issue to the attention of the IESG. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 6 12:03: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 MAA24515 for ; Thu, 6 Jan 2005 12:03:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmbFl-0002Tf-9x for rpsec-web-archive@ietf.org; Thu, 06 Jan 2005 12:16:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmavH-00024c-NL; Thu, 06 Jan 2005 11:55:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmatC-0000qo-M8 for rpsec@megatron.ietf.org; Thu, 06 Jan 2005 11:53: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 LAA23198 for ; Thu, 6 Jan 2005 11:53:32 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmb5y-0004IT-AS for rpsec@ietf.org; Thu, 06 Jan 2005 12:06:49 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2005 12:04:50 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-306.cisco.com [10.82.217.52]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j06GqwW1000799; Thu, 6 Jan 2005 11:52:58 -0500 (EST) Date: Thu, 6 Jan 2005 11:52:18 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) 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: 2.6 (++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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: 2.6 (++) X-Scan-Signature: 386e0819b1192672467565a524848168 > You have provided some analogies, but I noted some problems with them. > Your example above, I fear, is similarly flawed. > > In the credit card space there are valid accounts and authorized users. > The primary security goal here is to ensure that charges are associated > with valid accounts and incurred on behalf of authorized users. That's > the high level security goal and it is very much independent of process. > It applies whether the cards are used in card present or MOTO > transactions. > > But, the standards that exist for the credit card industry do not strike > me as analogous to those for BGP. They relate to formats for CC numbers, > card size, mag stripe format, and low-level security mechanisms for > communication. These standards address different ways of using credit > cards in different contexts, and none of them happen to overlap with the > examples you cite above, e.g., credit slip paper and pen color! And I disagree, perhaps because I'm a routing geek. :-) BGP is, specifically, a "communications process." BGP is not the _only_ path through which you can get routing information. It interacts with other routing processes, and other sources of routing information, including things like manual configuration, traffic optimizers, intrusion systems, and a host of other systems. So, to me, BGP is exactly like the standards you discuss in the credit card industry. It specifies things like the type of paper and color of pen (packet format), the process whereby you set up a connection to accept credit card information (peering process), etc. I separate the data from the process, because I work with routing protocols every day. In fact, I think routing is much less rigerous than people looking in from the outside imagine, especially when reading the specs. Information is placed in a set of BGP tables, which is then filtered, prodded, modified, etc, and then placed in the routing table. It's more of an SQL merge rather than a strict "put this there." This is then prodded, and placed in a forwarding table, possibly in a completely different format. Routes carry communities which impact the policy of the receiver, routes are filtered, and their attributes are changed. Sometimes one route is advertised based on the existance of another route. Longer prefixes are sometimes allowed through an "aggregation point," routes are re-originated rather than aggregated, and a number of other things can happen in the real world. > I am saying that the definition of how BGP routing is supposed to work > needs to be based on the BGP spec. Its an IETF standard and an objective > basis from which to work. What IETF standard description of "the system" > would you propose to use as the basis for developing security > requirements for BGP? The real world, preferrably. > We both have prejudices in approaching this problem. One can fairly say > that I used the BGP spec as the basis for developing the security > requirements model that we then addressed with S-BGP. Likewise, you > adopted an operations-oriented view of security when you developed soBGP. > That does not make either approach intrinsically valid or invalid. And at some point, the WG has to decide which of these two models is valid. I believe that I've made a strong case to consider the operational use as a valid model, because of gaps in the alternative model. > We have a fundamental disagreement about what constitutes a legitimate > basis for deriving BGP security requirements. I understand your point of > view, but I disagree. Since you are co-chair of this WG you have an > obvious conflict of interest problem in trying to resolve this at the WG > chair level. Perhaps the right thing to do at this stage is to bring the > issue to the attention of the IESG. I believe I've been more than fair in every discussion, and attempted to simply discuss the models at hand, in terms of requirements. If you believe it should be taken before the IESG, I would encourage you to do so. I believe a review of the email threads will show that I've attempted, on every occasion, to bring in all possible solutions, and argue from a technical, rather than a procedural, standpoint, about which model is best. I've seen no technical argument about why the model based on the specification is best, other than simply stating it is. :-) 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 Thu Jan 6 14:59: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 OAA10706 for ; Thu, 6 Jan 2005 14:59:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cme04-0006yo-4E for rpsec-web-archive@ietf.org; Thu, 06 Jan 2005 15:12:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmddo-0003y2-VC; Thu, 06 Jan 2005 14:49:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmdd1-0003VY-T6 for rpsec@megatron.ietf.org; Thu, 06 Jan 2005 14:49: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 OAA08929 for ; Thu, 6 Jan 2005 14:49:02 -0500 (EST) Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmdpr-0006Hd-RY for rpsec@ietf.org; Thu, 06 Jan 2005 15:02:20 -0500 Received: from [IPv6:2002:52c0:5a1b:1::1] ([IPv6:2002:52c0:5a1b:1::1]) (authenticated bits=0) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id j06JlTW2068725 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Jan 2005 20:47:33 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) Date: Thu, 6 Jan 2005 20:47:45 +0100 To: Stephen Kent X-Mailer: Apple Mail (2.619) X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit On 6-jan-05, at 17:26, Stephen Kent wrote: > BGP is a protocol, which defines of formats for messages and an > algorithm for processing these messages, in the context of local > databases. If we define security for BGP in terms of generating the > "right" routes even when the systems is under attack, we need to begin > with the process that generates the routes under benign conditions. > I agree that one may be able to generate rules for characterizing what > routes are authorized/valid/... independent of the process by which > they are generated. BUT, if you want to do that, rather than focusing > on securing the process, the burden is on you to show that the results > are equivalent. Aren't there really just two things that we want/need protection against: 1. Someone sourcing a prefix that doesn't belong to them This is the easy part: some magic PKI dust solves this part real good. 2. Someone announcing reachability to a prefix or AS that they shouldn't announce This is the tricky part. How do we know when someone is announcing reachability illegitimately? We can't go by the source, both because of the information explosion this causes and a wealth of practical issues, and also because even if the source says that AS X isn't supposed to be in their transit path, the destination may feel otherwise so the path turns out OK anyway. Note that both soBGP and S-BGP (when I last looked at them) didn't have mechanisms to handle this properly. All other bad stuff that an attacker could make happen by subverting BGP can also happen for legitimate reasons, so I don't see how we can realistically protect against that. There is one other thing, though: it would be very nice if we could somehow determine whether traffic we send over a certain route actually makes it to the destination AS. This would be incredibly helpful even for regular misconfiguration and other routine brokenness, but also in the cases where an attacker solicits traffic but doesn't forward it to the real destination. > In the credit card space there are valid accounts and authorized > users. The primary security goal here is to ensure that charges are > associated with valid accounts and incurred on behalf of authorized > users. That's the high level security goal and it is very much > independent of process. It applies whether the cards are used in card > present or MOTO transactions. If we make the credit card owner an AS and make a payment a route, then we want traffic = money to follow legitimate routes, not fake ones. Pretty similar. :-) > I am saying that the definition of how BGP routing is supposed to work > needs to be based on the BGP spec. Its an IETF standard and an > objective basis from which to work. With just one tiny flaw: the standard doesn't fully describe what's out there in the real world. I believe IDR is trying to remedy this, but I'm not sure about how successful their efforts are. (Moving target and all.) _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 6 17:29: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 RAA00795 for ; Thu, 6 Jan 2005 17:29:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmgKj-0005ZW-Tu for rpsec-web-archive@ietf.org; Thu, 06 Jan 2005 17: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 1Cmfzr-0005w6-B2; Thu, 06 Jan 2005 17:20:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmfwd-0004as-Ow for rpsec@megatron.ietf.org; Thu, 06 Jan 2005 17:17: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 RAA00069 for ; Thu, 6 Jan 2005 17:17:25 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmg9V-0005L8-2r for rpsec@ietf.org; Thu, 06 Jan 2005 17:30:45 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j06MFqjf022120; Thu, 6 Jan 2005 17:15:52 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> Date: Thu, 6 Jan 2005 17:15:45 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] a note from the BGP4 spec 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: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: rpsec@ietf.org, Iljitsch van Beijnum X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 At 11:26 AM -0500 1/6/05, Russ White wrote: >>>What you've not acknowledged is the problem is more extensive than >>>this. The NLRI in the udpate is also aggregated, and the aggregate >>>may contain information about routes the originator of the >>>aggregate does not have authorization to advertise. >> >>The last phrase above is very worrisome. if the speaker has >>included NLRI that it "does not have authorization to advertise" >>then this seems to be both a violation of the spirit (if not the >>letter) of the BGP spec, and it seems impossible to provide >>coherent security for the system if one wants to permit such >>behavior. Obviously, in the worst case, if we define a security >>system that allows a speaker to advertise NLRI without any notion >>of authorization, then we implicitly allow advertisements that can >>result in black holes, etc. So, there must be a better way to >>characterize what we want in terms of "valid" advertisements. > >ISP A "owns" 10.1.0.0/16. They allocate 10.1.1.0/24 to their >customer, so the customer now "owns" 10.1.1.0/24. How do you "stop" >the ISP from advertising 10.1.0.0/16 at this point, as a part of the >/16? If the ISP doesn't have an advertisement for 10.1.1.0/24, then >the ISP is disallowed from advertising 10.1.0.0/16, because they >don't have authorization for _every component_ of that aggregate? You would not want to stop ISP A from advertising the /16. It is authorized to do so by its initial allocation of this prefix from an RIR or IANA. I'm not sure where you have derived the notion that the ISP is not authorized to advertise the /16 because of its allocation of the /24 to a subscriber. This is certainly NOT an S-BGP concept. The words you are using suggest to me that you have a vague notion of what I mean when I speak about authorization, but that notion is inaccurate. I think several of my previous messages have included text that make clear that this sort of allocation by an ISP is NOT a problem. >Obviously, you don't. Address block ownership overlaps in the same >way aggregation overlaps. I think I've said this several times on >this thread. This single fact invalidates the entire concept of >securing BGP as a "set of processes," and forces you to look at how >to secure the data itself, in some meaningful way. I'm sorry to have to say this, Russ, but you are just plain wrong here. It seems to me that the problem is that you think you understand what I mean what I talk about authorization, but you have some misconceptions and that is coloring what you say. >>The point of aggregation is to reduce the size of routing tables >>and to reduce the size of Updates, while still providing accurate >>routing data. It's OK to create an aggregate that encompasses a >>longer prefix, so long as doing so does not misrepresent what the >>speaker has been authorized to advertise, either via direct or >>transitive authorization by the prefix holders. > >Again, how do you _prove_ this? You can't, beacause it's impossible. >The entire draft "Considerations in Validating the Path in BGP" >proves this through examples. I've not seen a single refutation of >those arguments, here or elsewhere. The ambiguous concept of >ownership of address space combined with the ability to filter >longer prefix matches and advertise an aggregate you didn't >originate make this impossible to prove. Can you show otherwise? Your individual contribution I-D makes arguments based on assumptions about what one can infer from examining path data as transmitted in BGP. That's fair, but it ignores the potential to augment that data based on data that a speaker received but did not normally include in an Update, and on the ability to distribute relatively static data via external means. The real world environment to which you frequently refer relies on externally distributed data to help mitigate errors and malicious Update data (e.g., IRRs), so the idea of relying on such data is both consistent with the BGP spec (the PIB) and with deployment practice. So, I don't understand why you persist in ignoring that obvious source of additional inputs to the route computation process, if it is secured and the data is distributed in this fashion is consistent with the dynamics characteristic of such a distribution process. >>>This is a non-sequitor. There are many paths to security, only one >>>of which involves securing the process by which information is >>>handled. >> >>Russ, you continue to ignore what I say, and instead substitute >>what you want to argue about. I made a simple statement, which is >>not at all a non-sequitor. What I said was almost a tautology, >>i.e., one should define security for a protocol starting with the >>definition of the protocol. > >No, you should define security for a system based on what >information within the system needs to be secured, and leave >flexibility about how to secure those pieces of data. Once again, >this is akin to securing credit card transactions by working from >the process used to handle credit card transactions, rather than >starting from the data you need to be secured. Sorry, but this attempted analogy is still flawed and does not warrant further discussion. >>>And then the appropriate filter to kill off everything within >>>10.1/16, minus those routes your customers have asked you not to >>>aggregate. This doesn't violate the BGP specification in any way, >>>and creates an aggregate without an AS SET. >> >>Tow observations: > >> - if the aggregation is done in a way inconsistent with the >>cited rules, that that would seem to be non-compliant, and it calls >>into question why the BGP-4 spec is being advanced with the rules >>still in it. > >You missed the point that this isn't out of compliance. This is >perfectly normal. If I own 10.1.0.0/16, I can originate it any way I >want to. I'm not restricted to including the AS' of anyone >advertising a longer prefix falling within that shorter prefix. > >In fact, the entire concept of an "aggregate" is muddying the >discussion, somewhat. There are overlapping prefixes. Sometimes they >represent aggregates, sometimes they don't. You're taking a very >procedural approach to the problem, and missing a lot of the actual >core of the actual problem. YOU are the one who keeps making arguments based on aggregation examples! if you think that they are muddying the discussion, don't use them. >>One thing that is missing from this discussion if a simple, clear >>characterization of what you assert are the allowed ways for >>speakers or ASes to perform aggregation, and why each way is >>reasonable, in a system context. It would be preferable if there >>were RFCs that you could cite to justify the behaviors you >>describe, so that we have an objective basis for evaluating them. >>Is your concern that there is no way to do this, algorithmically, >>and thus you emphasize examining the outcome of route propagation >>rather that defining the rules that characterize allowed >>aggregation, etc? > >If I "own" an address block, I'm authorized to advertise it. You're >trying to get to the point of saying: > >-- If you don't have an advertisement for every suballocation under >your allocation, authorizing you to advertise each possible piece of >that aggregate, then you can't advertise that aggregate. I have never said that, so this is an erroneous characterization of my position. >-- Even if you have every one of these advertisements, you MUST >include the AS of every AS you've received such "authorization" from. This too is wrong. What you seem to be doing is stating YOUR interpretation of my comments. Don't do that; it's a waste of everyone's time, and it's annoying. >This, essentially, means: You can't aggregate to provide the >security you're claiming we should require in the draft. The concept >of "transitive authorization," in the terms you're trying to apply >it BGP, simply doesn't exist. I hate to see the discussion degrade to this level again, but your statement is just wrong. It's wrong for reasons I have cited in the past and which do not merit restating here, since you appear to ignore them. >You can point out all sorts of phrases and comments in the draft, >but you have to temper these statements with the actual operation of >BGP in the real world, with real address ownership concepts, real >aggregation, and real route origination policies. As best I can tell, you have a seriously flawed perception of what I have said, which causes you to make arguments that are not valid criticisms of the positions I have espoused. Nonetheless, the central issue is whether we are going to generate BGP security requirements based on IETF standards, or to use characterizations of "real world" BGP that have no basis in IETF standards track documentation. I vote for door #1. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 6 17:29: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 RAA00954 for ; Thu, 6 Jan 2005 17:29:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmgLV-0005bd-2r for rpsec-web-archive@ietf.org; Thu, 06 Jan 2005 17:43:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmfzr-0005wB-OU; Thu, 06 Jan 2005 17:20:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmfwd-0004au-Te for rpsec@megatron.ietf.org; Thu, 06 Jan 2005 17:17: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 RAA00067 for ; Thu, 6 Jan 2005 17:17:25 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmg9V-0005LA-2K for rpsec@ietf.org; Thu, 06 Jan 2005 17:30:45 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j06MFqjh022120; Thu, 6 Jan 2005 17:15:54 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 6 Jan 2005 15:59:37 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 2.6 (++) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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: 2.6 (++) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede At 11:52 AM -0500 1/6/05, Russ White wrote: >>You have provided some analogies, but I noted some problems with >>them. Your example above, I fear, is similarly flawed. >> >>In the credit card space there are valid accounts and authorized >>users. The primary security goal here is to ensure that charges are >>associated with valid accounts and incurred on behalf of authorized >>users. That's the high level security goal and it is very much >>independent of process. It applies whether the cards are used in >>card present or MOTO transactions. >> >>But, the standards that exist for the credit card industry do not >>strike me as analogous to those for BGP. They relate to formats for >>CC numbers, card size, mag stripe format, and low-level security >>mechanisms for communication. These standards address different >>ways of using credit cards in different contexts, and none of them >>happen to overlap with the examples you cite above, e.g., credit >>slip paper and pen color! > >And I disagree, perhaps because I'm a routing geek. :-) > >BGP is, specifically, a "communications process." BGP is not the >_only_ path through which you can get routing information. It >interacts with other routing processes, and other sources of routing >information, including things like manual configuration, traffic >optimizers, intrusion systems, and a host of other systems. The BGP spec recognizes inputs from BGP, IGPs, EGP (historically), and manual configuration. If your configuration gets info from the other sources your cite above, that are not in the BGP spec, they fall under the manual/local configuration umbrella. >So, to me, BGP is exactly like the standards you discuss in the >credit card industry. It specifies things like the type of paper and >color of pen (packet format), the process whereby you set up a >connection to accept credit card information (peering process), etc. >I separate the data from the process, because I work with routing >protocols every day. as a security geek, I'll have to say that we just disagree on the validity of your analogy :-) >In fact, I think routing is much less rigerous than people looking >in from the outside imagine, especially when reading the specs. >Information is placed in a set of BGP tables, which is then >filtered, prodded, modified, etc, and then placed in the routing >table. It's more of an SQL merge rather than a strict "put this >there." This is then prodded, and placed in a forwarding table, >possibly in a completely different format. So you're saying that BGP, as deployed and operated, bears only scant resemblance to the IETF spec for the protocol. if so, then I certainly think an attempt to generate security requirements for the system you describe belongs in a WG under the operations area, not in the area where the BGP spec is maintained. >Routes carry communities which impact the policy of the receiver, >routes are filtered, and their attributes are changed. Sometimes one >route is advertised based on the existance of another route. Longer >prefixes are sometimes allowed through an "aggregation point," >routes are re-originated rather than aggregated, and a number of >other things can happen in the real world. > >>I am saying that the definition of how BGP routing is supposed to >>work needs to be based on the BGP spec. Its an IETF standard and an >>objective basis from which to work. What IETF standard description >>of "the system" would you propose to use as the basis for >>developing security requirements for BGP? > >The real world, preferrably. so, I take this concise response to mean that you have no IETF standards documents to cite. >>We both have prejudices in approaching this problem. One can >>fairly say that I used the BGP spec as the basis for developing the >>security requirements model that we then addressed with S-BGP. >>Likewise, you adopted an operations-oriented view of security when >>you developed soBGP. That does not make either approach >>intrinsically valid or invalid. > >And at some point, the WG has to decide which of these two models is >valid. I believe that I've made a strong case to consider the >operational use as a valid model, because of gaps in the alternative >model. more precisely, because of your perception of gaps in a standards-based model. >>We have a fundamental disagreement about what constitutes a >>legitimate basis for deriving BGP security requirements. I >>understand your point of view, but I disagree. Since you are >>co-chair of this WG you have an obvious conflict of interest >>problem in trying to resolve this at the WG chair level. Perhaps >>the right thing to do at this stage is to bring the issue to the >>attention of the IESG. > >I believe I've been more than fair in every discussion, and >attempted to simply discuss the models at hand, in terms of >requirements. > >If you believe it should be taken before the IESG, I would encourage >you to do so. I believe a review of the email threads will show that >I've attempted, on every occasion, to bring in all possible >solutions, and argue from a technical, rather than a procedural, >standpoint, about which model is best. I've seen no technical >argument about why the model based on the specification is best, >other than simply stating it is. At least we agree on the appropriateness of trying to resolve this at a higher level of IETF management. I'll take the action to initiate an IESG level review of the basic question of what should be the basis for the security requirements that this WG is chartered to develop. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 6 18:28: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 SAA05845 for ; Thu, 6 Jan 2005 18:28:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmhFq-0007OO-ML for rpsec-web-archive@ietf.org; Thu, 06 Jan 2005 18:41:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmh1q-0006Ox-1x; Thu, 06 Jan 2005 18:26:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmgz4-00058M-6U for rpsec@megatron.ietf.org; Thu, 06 Jan 2005 18:24: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 SAA05609 for ; Thu, 6 Jan 2005 18:23:59 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmhBt-0007HL-5M for rpsec@ietf.org; Thu, 06 Jan 2005 18:37:20 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2005 18:35:20 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn3-306.cisco.com [10.82.217.52]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j06NNPDY017359; Thu, 6 Jan 2005 18:23:26 -0500 (EST) Date: Thu, 6 Jan 2005 18:22:44 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] a note from the BGP4 spec In-Reply-To: Message-ID: References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> 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: b22590c27682ace61775ee7b453b40d3 Cc: rpsec@ietf.org, Iljitsch van Beijnum 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: b1c41982e167b872076d0018e4e1dc3c >> ISP A "owns" 10.1.0.0/16. They allocate 10.1.1.0/24 to their customer, >> so the customer now "owns" 10.1.1.0/24. How do you "stop" the ISP from >> advertising 10.1.0.0/16 at this point, as a part of the /16? If the ISP >> doesn't have an advertisement for 10.1.1.0/24, then the ISP is >> disallowed from advertising 10.1.0.0/16, because they don't have >> authorization for _every component_ of that aggregate? > > You would not want to stop ISP A from advertising the /16. It is > authorized to do so by its initial allocation of this prefix from an RIR > or IANA. I'm not sure where you have derived the notion that the ISP is > not authorized to advertise the /16 because of its allocation of the /24 > to a subscriber. This is certainly NOT an S-BGP concept. The words you > are using suggest to me that you have a vague notion of what I mean when > I speak about authorization, but that notion is inaccurate. I think > several of my previous messages have included text that make clear that > this sort of allocation by an ISP is NOT a problem. >> If I "own" an address block, I'm authorized to advertise it. You're trying >> to get to the point of saying: >> >> -- If you don't have an advertisement for every suballocation under your >> allocation, authorizing you to advertise each possible piece of that >> aggregate, then you can't advertise that aggregate. > > I have never said that, so this is an erroneous characterization of my > position. > >> -- Even if you have every one of these advertisements, you MUST include the >> AS of every AS you've received such "authorization" from. > > This too is wrong. What you seem to be doing is stating YOUR interpretation > of my comments. Don't do that; it's a waste of everyone's time, and it's > annoying. > >> This, essentially, means: You can't aggregate to provide the security >> you're claiming we should require in the draft. The concept of "transitive >> authorization," in the terms you're trying to apply it BGP, simply doesn't >> exist. > > I hate to see the discussion degrade to this level again, but your statement > is just wrong. It's wrong for reasons I have cited in the past and which do > not merit restating here, since you appear to ignore them. I'm not ignoring them, I'm simply taking the sum total of what you're saying and reaching logical conclusions. If we can only take the BGP specification as our basis, then suppose I have this: -- A owns 10.1.0.0/16. -- A suballocates 10.1.1.0/24 to B. -- C receives an update containing 10.1.0.0/16 from A. How can C prove that B has authorized A to advertise 10.1.1.0/24, which happens to be a part of 10.1.0.0/16? If we go solely on the BGP specification, then A _must_ place B in it's AS SET, correct? But, what if it's reoriginating the route, rather than aggregating using a mechanism specified in the BGP specification? How do we handle it when B explicitely refuses to allow A to advertise 10.1.1.0/24? Should A be forced to not advertise 10.1.0.0/16? I've not seen an explaination for how the authorization "chain" actually works in this case. You state that A shouldn't stop advertising 10.1.0.0/16 (above), but 10.1.1.0/24 is _contained within_ that address space. It's no good to say that A isn't actually advertising 10.1.1.0/24, because it most certainly is advertising 10.1.1.0/24, as a part of 10.1.0.0/16. There's no way around that, because routers will forward a packet towards 10.1.1.1 to 10.1.0.0/16 just as readily as they will to 10.1.1.0/24. You even stated, in an earlier email: > If the speaker has included NLRI that it "does not have authorization to > advertise" then this seems to be both a violation of the spirit (if not > the letter) of the BGP spec, and it seems impossible to provide coherent > security for the system if one wants to permit such behavior. Clearly such situations exist, I've just described one, above, and the draft I've pointed you to has specific examples. As long as we can agree that 10.1.1.0/24 is a part of 10.1.0.0/16 (and I'll assume we can agree on that point, at least), then what you've described above occurs on a regular basis within the Internet today. What I'm describing falls outside the BGP specification, but within the system as a whole. This strikes me as a strong justification for basing security requirements on the way things really work, rather than the BGP specification itself. So, at worst, I'm confused. I'm not ignoring you, I'm not trying to misconstrue your statements, I just don't understand how you're argument refutes the real world examples I've given. I take your statements at face value, and try to understand how they actually apply, based on my understanding of routing, address allocation, and the other elements of any large internetwork as a working system. > As best I can tell, you have a seriously flawed perception of what I have > said, which causes you to make arguments that are not valid criticisms of > the positions I have espoused. Nonetheless, the central issue is whether > we are going to generate BGP security requirements based on IETF > standards, or to use characterizations of "real world" BGP that have no > basis in IETF standards track documentation. I vote for door #1. And I believe, as I've stated and shown many times (in fact, just above), using the "objective standard" of BGP to build these security requirements leaves holes. Regardless of your attempts at striking at me personally, Steve, I don't see how you can get around building a set of requirements based on what exists, rather than the BGP specification, which is only part of the way things really work. The BGP specification doesn't specify, for instance, how address blocks will be allocated, by whom, and under what conditions. The BGP specification doesn't specify how the capabilities within the protocol will actually be configured and used, for instance, for filtering and origination of routes. I still don't see a technical argument proving using the BGP specification as the sole basis for defining security requirements is the right way to go about building a security requirements document. Simply saying my arguments are invalid doesn't get me anywhere, I need you to explain why they are invalid. Refute my examples, explain how the authorization chain works in the example above. :-) 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 Fri Jan 7 16:55: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 QAA02158 for ; Fri, 7 Jan 2005 16:55:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn2Hn-00073J-GF for rpsec-web-archive@ietf.org; Fri, 07 Jan 2005 17:08:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn23r-0004te-HI; Fri, 07 Jan 2005 16:54:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn22w-0004gU-B0 for rpsec@megatron.ietf.org; Fri, 07 Jan 2005 16:53:29 -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 QAA02095 for ; Fri, 7 Jan 2005 16:53:23 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn2Fz-0006ou-Fo for rpsec@ietf.org; Fri, 07 Jan 2005 17:06: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 j07Lngjf012671; Fri, 7 Jan 2005 16:49:43 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> Date: Fri, 7 Jan 2005 16:39:45 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] a note from the BGP4 spec X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 Cc: rpsec@ietf.org, Iljitsch van Beijnum X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0142063546==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 --===============0142063546== Content-Type: multipart/alternative; boundary="============_-1106987917==_ma============" --============_-1106987917==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Russ, > >I'm not ignoring them, I'm simply taking the sum total of what >you're saying and reaching logical conclusions. If we can only take >the BGP specification as our basis, then suppose I have this: > > -- A owns 10.1.0.0/16. > -- A suballocates 10.1.1.0/24 to B. > > -- C receives an update containing 10.1.0.0/16 from A. How can C prove > that B has authorized A to advertise 10.1.1.0/24, which happens to be a > part of 10.1.0.0/16? The BGP spec deals with processing Updates, and does not address the infrastructure that supports address allocation, as we both know. But, BGP does make explicit provision for use of locally configured policy data that can augment what a speaker/AS knows, independent of what is received via Updates. So, if one focuses on security requirements derived from the spec, one is free to address the question of how C can be made aware of info such as the sub-allocation of the /24 from A to B, based on such locally configured data, in a secure fashion. I think it fair to say that BGP defines Updates as the means to convey dynamic data about routes, whereas locally configured policy info is viewed as a means of conveying more static data that can affect route selection. Thus, when one considers the types of data that should be distributed external to BGP, for local configuration, that data should be similarly static. >If we go solely on the BGP specification, then A _must_ place B in >it's AS SET, correct? But, what if it's reoriginating the route, >rather than aggregating using a mechanism specified in the BGP >specification? The BGP spec allows A to originate the /16. It would also be OK to create a issue a separate Update, with B as the origin, for the /24. But, I don't think the spec mandates this. I'm not sure what the term "re-originating" means, so I don't know how to interpret the second part of your question. >How do we handle it when B explicitely refuses to allow A to >advertise 10.1.1.0/24? Should A be forced to not advertise >10.1.0.0/16? BGP does NOT say that A is not supposed to advertise the /16 just because a sub-allocation out of the /16 is no longer reachable via A. I cited specific text from the BGP spec that deals with this, in my memo so I will not bother restating the reasoning here. >I've not seen an explaination for how the authorization "chain" >actually works in this case. You state that A shouldn't stop >advertising 10.1.0.0/16 (above), but 10.1.1.0/24 is _contained >within_ that address space. It's no good to say that A isn't >actually advertising 10.1.1.0/24, because it most certainly is >advertising 10.1.1.0/24, as a part of 10.1.0.0/16. There's no way >around that, because routers will forward a packet towards 10.1.1.1 >to 10.1.0.0/16 just as readily as they will to 10.1.1.0/24. Routers will forward packets based on the most specific advertisements they learn. So, yes, IF a router does not learn about a path for a /24 that is no longer reachable via the AS path that terminates at the holder of the /16 that subsumes the /24, then the traffic will be routed to the /16. That is precisely what BGP says should happen, even though it may cause packets to be routed to an As that will discard them. Thus, from a security perspective, our goal is to find ways to enable the holder of the /24 to make other ASes aware of the fact that the holder of the /16 is no longer authorized to advertise this specific prefix. And, of course, we need to do it in a fashion consistent with the BGP spec. >You even stated, in an earlier email: > >>If the speaker has included NLRI that it "does not have >>authorization to advertise" then this seems to be both a violation >>of the spirit (if not the letter) of the BGP spec, and it seems >>impossible to provide coherent security for the system if one wants >>to permit such behavior. > >Clearly such situations exist, I've just described one, above, and >the draft I've pointed you to has specific examples. As long as we >can agree that 10.1.1.0/24 is a part of 10.1.0.0/16 (and I'll assume >we can agree on that point, at least), then what you've described >above occurs on a regular basis within the Internet today. What I'm >describing falls outside the BGP specification, but within the >system as a whole. By quoting my words out of the larger context of the discussion, they do give the impression you cite. The holder of a prefix is authorized to advertise the whole prefix, period. I think my comment, that you cited above, was addressing an example in which you were suggesting that an AS could arbitrarily advertise prefixes without any form of authorization. The response I just provided above (in this message) explains what I think BGP states. >This strikes me as a strong justification for basing security >requirements on the way things really work, rather than the BGP >specification itself. see the comments I provided above, to counter the analysis, and thus refute this inference. >So, at worst, I'm confused. I'm not ignoring you, I'm not trying to >misconstrue your statements, I just don't understand how you're >argument refutes the real world examples I've given. I take your >statements at face value, and try to understand how they actually >apply, based on my understanding of routing, address allocation, and >the other elements of any large internetwork as a working system. well we all get confused at times and we all forget things that have been said earlier, so I don't mean to be unduly harsh in that regard. So, I'll try to restate what I think the BGP spec says, in regard to this specific topic: 1. BGP calls for routers to route packets based on the combination of the advertisements received via Updates, and via locally configured information, with the later having precedence over the former. 2. A router is expected to route traffic based on the longest prefix (known to the router) that matches the traffic destination address. So, your /24 vs. /16 example is addressed by these two simple rules. It does say that misrouting can occur, e.g., if an AS is not aware of the fact that a /24 is no longer reachable via a path that terminates at the (subsuming) /16 holder's AS. That's a limitation of the protocol design, and I believe that this is precisely what happens in practice. To the extent that ASes are configured with externally provided info that tells them that, for example, the holder of the /24 no longer authorizes the AS that originates, then they can avoid this problem. But, static routes to distant ASes are not very attractive, so there are clear limitations to using local policy info to address this problem. However, an intermediate measure it to make available information about which ASes are authorized to originate which prefixes, based on both the address allocation hierarchy AND on subsequent sub-allocations, so that speakers can use this locally configured info as part of the process for deciding whether to accept a route. >>As best I can tell, you have a seriously flawed perception of what >>I have said, which causes you to make arguments that are not valid >>criticisms of the positions I have espoused. Nonetheless, the >>central issue is whether we are going to generate BGP security >>requirements based on IETF standards, or to use characterizations >>of "real world" BGP that have no basis in IETF standards track >>documentation. I vote for door #1. > >And I believe, as I've stated and shown many times (in fact, just >above), using the "objective standard" of BGP to build these >security requirements leaves holes. I think my responses to your comments refute this assertion. >Regardless of your attempts at striking at me personally, Steve, I >don't see how you can get around building a set of requirements >based on what exists, rather than the BGP specification, which is >only part of the way things really work. The BGP specification >doesn't specify, for instance, how address blocks will be allocated, >by whom, and under what conditions. The BGP specification doesn't >specify how the capabilities within the protocol will actually be >configured and used, for instance, for filtering and origination of >routes. I have not attempting to "[strike] you personally," Russ. if I had, there probably would be bruises :-) We agree that BGP does not discuss how addresses are allocated. And, yes, that is an important aspect of how routing works and how secure routing must work. But, BGP does take address allocation into account, e.g., a big difference between BGP-4 and 3 is the reliance in CIDR allocation, which is prominently mentioned in the spec. And, BGP makes application of local policies an important part of the route selection and advertisement algorithm. It leaves the details up to local managers and vendors. So what? >I still don't see a technical argument proving using the BGP >specification as the sole basis for defining security requirements >is the right way to go about building a security requirements >document. Simply saying my arguments are invalid doesn't get me >anywhere, I need you to explain why they are invalid. Refute my >examples, explain how the authorization chain works in the example >above. I have explained how authorization works, every time you have requested. if you can't understand why using the spec for a protocol is the appropriate primary basis for developing security requirements for that protocol, I'm afraid I a at a loss to help. Steve --============_-1106987917==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] a note from the BGP4 spec
Russ,

        <SNIP>
I'm not ignoring them, I'm simply taking the sum total of what you're saying and reaching logical conclusions. If we can only take the BGP specification as our basis, then suppose I have this:

  -- A owns 10.1.0.0/16.
  -- A suballocates 10.1.1.0/24 to B.

  -- C receives an update containing 10.1.0.0/16 from A. How can C prove
  that B has authorized A to advertise 10.1.1.0/24, which happens to be a
  part of 10.1.0.0/16?

The BGP spec deals with processing Updates, and does not address the infrastructure that supports address allocation, as we both know. But, BGP does make explicit provision for use of locally configured policy data that can augment what a speaker/AS knows, independent of what is received via Updates. So, if one focuses on security requirements derived from the spec, one is free to address the question of how C can be made aware of info such as the sub-allocation of the /24 from A to B, based on such locally configured data, in a secure fashion. I think it fair to say that BGP defines Updates as the means to convey dynamic data about routes, whereas locally configured policy info is viewed as a means of conveying more static data that can affect route selection. Thus, when one considers the types of data that should be distributed external to BGP, for local configuration, that data should be similarly static.

If we go solely on the BGP specification, then A _must_ place B in it's AS SET, correct? But, what if it's reoriginating the route, rather than aggregating using a mechanism specified in the BGP specification?

The BGP spec allows A to originate the /16. It would also be OK to create a issue a separate Update, with B as the origin, for the /24. But, I don't think the spec mandates this. I'm not sure what the term "re-originating" means, so I don't know how to interpret the second part of your question.

How do we handle it when B explicitely refuses to allow A to advertise 10.1.1.0/24? Should A be forced to not advertise 10.1.0.0/16?

BGP does NOT say that A is not supposed to advertise the /16 just because a sub-allocation out of the /16 is no longer reachable via A. I cited specific text from the BGP spec that deals with this, in my memo so I will not bother restating the reasoning here.

I've not seen an explaination for how the authorization "chain" actually works in this case. You state that A shouldn't stop advertising 10.1.0.0/16 (above), but 10.1.1.0/24 is _contained within_ that address space. It's no good to say that A isn't actually advertising 10.1.1.0/24, because it most certainly is advertising 10.1.1.0/24, as a part of 10.1.0.0/16. There's no way around that, because routers will forward a packet towards 10.1.1.1 to 10.1.0.0/16 just as readily as they will to 10.1.1.0/24.

Routers will forward packets based on the most specific advertisements they learn. So, yes, IF a router does not learn about a path for a /24 that is no longer reachable via the AS path that terminates at the holder of the /16 that subsumes the /24, then the traffic will be routed to the /16. That is precisely what BGP says should happen, even though it may cause packets to be routed to an As that will discard them. Thus, from a security perspective, our goal is to find ways to enable the holder of the /24 to make other ASes aware of the fact that the holder of the /16 is no longer authorized to advertise this specific prefix. And, of course, we need to do it in a fashion consistent with the BGP spec.

You even stated, in an earlier email:
If the speaker has included NLRI that it "does not have authorization to advertise" then this seems to be both a violation of the spirit (if not the letter) of the BGP spec, and it seems impossible to provide coherent security for the system if one wants to permit such behavior.

Clearly such situations exist, I've just described one, above, and the draft I've pointed you to has specific examples. As long as we can agree that 10.1.1.0/24 is a part of 10.1.0.0/16 (and I'll assume we can agree on that point, at least), then what you've described above occurs on a regular basis within the Internet today. What I'm describing falls outside the BGP specification, but within the system as a whole.

By quoting my words out of the larger context of the discussion, they do give the impression you cite. The holder of a prefix is authorized to advertise the whole prefix, period. I think my comment, that you cited above, was addressing an example in which you were suggesting that an AS could arbitrarily advertise prefixes without any form of authorization. The response I just provided above (in this message) explains what I think BGP states.

This strikes me as a strong justification for basing security requirements on the way things really work, rather than the BGP specification itself.

see the comments I provided above, to counter the analysis, and thus refute this inference.

So, at worst, I'm confused. I'm not ignoring you, I'm not trying to misconstrue your statements, I just don't understand how you're argument refutes the real world examples I've given. I take your statements at face value, and try to understand how they actually apply, based on my understanding of routing, address allocation, and the other elements of any large internetwork as a working system.

well  we all get confused at times and we all forget things that have been said earlier, so I don't mean to be unduly harsh in that regard.  So, I'll try to restate what I think the BGP spec says, in regard to this specific topic:

        1. BGP calls for routers to route packets based on the combination of the advertisements received via Updates, and via locally configured information, with the later having precedence over the former.

        2. A router is expected to route traffic based on the longest prefix (known to the router) that matches the traffic destination address.

So, your /24 vs. /16 example is addressed by these two simple rules. It does say that misrouting can occur, e.g., if an AS is not aware of the fact that a /24 is no longer reachable via a path that terminates at the (subsuming) /16 holder's AS. That's a limitation of the protocol design, and I believe that this is precisely what happens in practice. To the extent that ASes are configured with externally provided info that tells them that, for example, the holder of the /24 no longer authorizes the AS that originates, then they can avoid this problem. But, static routes to distant ASes are not very attractive, so there are clear limitations to using local policy info to address this problem. However, an intermediate measure it to make available information about which ASes are authorized to originate which prefixes, based on both the address allocation hierarchy AND on subsequent sub-allocations, so that speakers can use this locally configured info as part of the process for deciding whether to accept a route.

As best I can tell, you have a seriously flawed perception of what I have said, which causes you to make arguments that are not valid criticisms of the positions I have espoused.  Nonetheless, the central issue is whether we are going to generate BGP security requirements based on IETF standards, or to use characterizations of "real world" BGP that have no basis in IETF standards track documentation. I vote for door #1.

And I believe, as I've stated and shown many times (in fact, just above), using the "objective standard" of BGP to build these security requirements leaves holes.

I think my responses to your comments refute this assertion.

Regardless of your attempts at striking at me personally, Steve, I don't see how you can get around building a set of requirements based on what exists, rather than the BGP specification, which is only part of the way things really work. The BGP specification doesn't specify, for instance, how address blocks will be allocated, by whom, and under what conditions. The BGP specification doesn't specify how the capabilities within the protocol will actually be configured and used, for instance, for filtering and origination of routes.

I have not attempting to "[strike] you personally," Russ. if I had, there probably would be bruises :-)

We agree that BGP does not discuss  how addresses are allocated. And, yes, that is an important aspect of how routing works and how secure routing must work. But, BGP does take address allocation into account, e.g., a big difference between BGP-4 and 3 is the reliance in CIDR allocation,  which is prominently mentioned in the spec. And, BGP makes application of local policies an important part of the route selection and advertisement algorithm. It leaves the details up to local managers and vendors. So what?

I still don't see a technical argument proving using the BGP specification as the sole basis for defining security requirements is the right way to go about building a security requirements document. Simply saying my arguments are invalid doesn't get me anywhere, I need you to explain why they are invalid. Refute my examples, explain how the authorization chain works in the example above.

I have explained how authorization works, every time you have requested.

if you can't understand why using the spec for a protocol is the appropriate primary basis for developing security requirements for that protocol, I'm afraid I a at a loss to help.

Steve
--============_-1106987917==_ma============-- --===============0142063546== 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 --===============0142063546==-- From rpsec-bounces@ietf.org Fri Jan 7 17:13: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 RAA03288 for ; Fri, 7 Jan 2005 17:13:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn2ZB-0008Qa-F2 for rpsec-web-archive@ietf.org; Fri, 07 Jan 2005 17:26:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn2L7-0000MC-KK; Fri, 07 Jan 2005 17:12:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn2JP-0008LL-4E for rpsec@megatron.ietf.org; Fri, 07 Jan 2005 17:10: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 RAA03089 for ; Fri, 7 Jan 2005 17:10:24 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn2WR-00087F-OJ for rpsec@ietf.org; Fri, 07 Jan 2005 17:23:57 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 07 Jan 2005 17:09:52 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-580.cisco.com [10.82.226.68]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j07M9oDY027335; Fri, 7 Jan 2005 17:09:51 -0500 (EST) Date: Fri, 7 Jan 2005 17:09:09 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] a note from the BGP4 spec In-Reply-To: Message-ID: References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> 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: cd3fc8e909678b38737fc606dec187f0 Cc: rpsec@ietf.org, Iljitsch van Beijnum 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: 21be852dc93f0971708678c18d38c096 > The BGP spec deals with processing Updates, and does not address the > infrastructure that supports address allocation, as we both know. Which is a strong justification to base the requirements on deployed systems, as they operate, rather than the BGP specification itself. >> If we go solely on the BGP specification, then A _must_ place B in it's AS >> SET, correct? But, what if it's reoriginating the route, rather than >> aggregating using a mechanism specified in the BGP specification? > > The BGP spec allows A to originate the /16. It would also be OK to create a > issue a separate Update, with B as the origin, for the /24. But, I don't > think the spec mandates this. I'm not sure what the term "re-originating" > means, so I don't know how to interpret the second part of your question. Re-origination, in this context, means that A is advertising the /16, rather than the aggregate. >> How do we handle it when B explicitely refuses to allow A to advertise >> 10.1.1.0/24? Should A be forced to not advertise 10.1.0.0/16? > > BGP does NOT say that A is not supposed to advertise the /16 just because > a sub-allocation out of the /16 is no longer reachable via A. I cited > specific text from the BGP spec that deals with this, in my memo so I > will not bother restating the reasoning here. The /24 is a _part_ of the /16. Since the /24 is a _part_ of the /16, how does A advertise the /16 without advertising the /24? IF A cannot advertise the /16 without including the /24, and A does not have authorization to advertise the /24, then it _cannot_ advertise the /16. I think you're missing the point that the /24 is contained within the /16. > Routers will forward packets based on the most specific advertisements > they learn. So, yes, IF a router does not learn about a path for a /24 > that is no longer reachable via the AS path that terminates at the holder > of the /16 that subsumes the /24, then the traffic will be routed to the > /16. That is precisely what BGP says should happen, even though it may > cause packets to be routed to an As that will discard them. Thus, from a > security perspective, our goal is to find ways to enable the holder of > the /24 to make other ASes aware of the fact that the holder of the /16 > is no longer authorized to advertise this specific prefix. And, of > course, we need to do it in a fashion consistent with the BGP spec. How can you gaurentee this? Will you force BGP speakers to forward updates with longer length prefixes than the updates they already have? Can you explain a system where A and B are both forced to readvertise the /24, and C can tell if they aren't? >> You even stated, in an earlier email: >> >>> If the speaker has included NLRI that it "does not have authorization to >>> advertise" then this seems to be both a violation of the spirit (if not >>> the letter) of the BGP spec, and it seems impossible to provide coherent >>> security for the system if one wants to permit such behavior. >> >> Clearly such situations exist, I've just described one, above, and the >> draft I've pointed you to has specific examples. As long as we can agree >> that 10.1.1.0/24 is a part of 10.1.0.0/16 (and I'll assume we can agree on >> that point, at least), then what you've described above occurs on a regular >> basis within the Internet today. What I'm describing falls outside the BGP >> specification, but within the system as a whole. > > By quoting my words out of the larger context of the discussion, they do > give the impression you cite. The holder of a prefix is authorized to > advertise the whole prefix, period. I think my comment, that you cited > above, was addressing an example in which you were suggesting that an AS > could arbitrarily advertise prefixes without any form of authorization. > The response I just provided above (in this message) explains what I > think BGP states. Again, look at what I said above. The /24 is _contained within_ the /16. If A is advertising the /16, which _contains_ the /24, then it is advertising space it's not authorized to advertise. Which then relates back to your statement above, and is the reason I quoted it. > see the comments I provided above, to counter the analysis, and thus > refute this inference. And I've just refuted your comments above. :-) > 1. BGP calls for routers to route packets based on the combination > of the advertisements received via Updates, and via locally configured > information, with the later having precedence over the former. Actually, BGP doesn't call for anything about forwarding or routing. BGP describes how to build a local database, from which you can build a forwarding table. > 2. A router is expected to route traffic based on the longest > prefix (known to the router) that matches the traffic destination > address. That's not in the BGP spec, either, as far as I know. > So, your /24 vs. /16 example is addressed by these two simple rules. It > does say that misrouting can occur, e.g., if an AS is not aware of the > fact that a /24 is no longer reachable via a path that terminates at the > (subsuming) /16 holder's AS. That's a limitation of the protocol design, > and I believe that this is precisely what happens in practice. Yes, but it breaks the concept of authorization you're claiming to have proven. You have two choices: -- You provide authorization for the update. -- You provide authorization for the information in the update. In the first case, you have to realize that BGP doesn't treat an update as an "atomic thing." The update contains data that's received, processed, and readvertised. The update itself is a meaningless thing within BGP, a transport mechanism. What's important is the data within the update. And the data shows that the concept of authorization you're trying to state is possible, simply isn't possible. > I think my responses to your comments refute this assertion. I disagree. Once again, you're treating the BGP update as an "atomic thing" that you can somehow secure. I think the nature of the data carried _must_ be considered. You're somehow equating "validating" the update with "validating" the information in the update. > We agree that BGP does not discuss how addresses are allocated. And, yes, > that is an important aspect of how routing works and how secure routing > must work. But, BGP does take address allocation into account, e.g., a > big difference between BGP-4 and 3 is the reliance in CIDR allocation, > which is prominently mentioned in the spec. And, BGP makes application of > local policies an important part of the route selection and advertisement > algorithm. It leaves the details up to local managers and vendors. So > what? If allocation is important, and it's outside the BGP specification, then clearly basing the requirements document on the specification only looks at a part of the solution. > I have explained how authorization works, every time you have requested. Only from the perspective of the updates. You've not explained it from the perspective of the data within the update. You're probably going to say the data's not in the BGP specification, the updates are. My point exactly--by ignoring the questions we can ask about the data, you're missing the biggest part of the problem. > if you can't understand why using the spec for a protocol is the > appropriate primary basis for developing security requirements for that > protocol, I'm afraid I a at a loss to help. And, I'm at the same impasse. If you can't understand why using the specification fails to adress/ask the fundamental questions we can and should be asking, then I'm at a loss, as well. :-) 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 Fri Jan 7 18:43:20 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 SAA08497 for ; Fri, 7 Jan 2005 18:43:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn3yQ-00061u-92 for rpsec-web-archive@ietf.org; Fri, 07 Jan 2005 18:56:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn3kF-0003F2-9u; Fri, 07 Jan 2005 18:42:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn3j4-00032F-H6 for rpsec@megatron.ietf.org; Fri, 07 Jan 2005 18:41: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 SAA08398 for ; Fri, 7 Jan 2005 18:40:59 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn3w6-0005lr-44 for rpsec@ietf.org; Fri, 07 Jan 2005 18:54:33 -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 j07NeQjf016594; Fri, 7 Jan 2005 18:40:27 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <80096BB9-5FF4-11D9-BA2A-000A95CD987A@muada.com> References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> <80096BB9-5FF4-11D9-BA2A-000A95CD987A@muada.com> Date: Fri, 7 Jan 2005 18:40:15 -0500 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] a note from the BGP4 spec 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: fe105289edd72640d9f392da880eefa2 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: 025f8c5000216988bfe31585db759250 At 4:06 PM +0100 1/6/05, Iljitsch van Beijnum wrote: >On 6-jan-05, at 0:40, Stephen Kent wrote: > >>yes, a route is NLRI plus path info. We agree that it is possible >>that the path taken by traffic will diverge from the advertised >>route, but the cited text in the BGP spec says that this should not >>be the case. > >But how can this be enforced? BGP security cannot enforce a match between forwarding and routing. The best it can do is to help secure the data used in the route computation process, so that IF the speaker is relying on the correspondence between routing and forwarding, then it is making use of valid routing data in making routing decisions. > >>After sending the message I asked a colleague to look at 2004 RV >>data and see how often the atomic aggregate and aggregator >>attribute shows up. The answer, based on examining about 3 months >>of data (so far) is that about 6-8% of the Updates had the atomic >>attribute and 7-9% had aggregator. So about 14-16% of all Updates >>had one or the other form of aggregation indicated. > >So no overlap? Strange. And this is much more than I expected. Do you mean overlap in the sense of both attributes appearing in the same Update? I asked my colleague to look for either attribute, and he gave me stats based on that request. I'll go back and ask him to see how often an Update contains both attributes. > >>However, when BBN ran the Arpanet and the Defense Data Network, we >>updated packet switch software remotely, in each switch in the net, >>then turned on new features in all of them, via remote management, >>in a very short time. Admittedly those nets were 200+ switches, >>not 600, but the principle was the same, i.e, tolerating transient >>routing instability in a net during the time it takes to turn on >>the new features. > >The trouble is that the internet as a whole is orders of magnitude >larger than the ARPANET. Even single tier-1 networks are >considerably larger than the ARPANET. And they are in competition, >so it's important to not tick off customers with lengthy downtimes >for maintenance. no argument there. but the issue would seem to be how bad would the disruption be while the routers in a single, large AS, switched over. If, as you suggested, routers not yet running in secure mode and routers that have switched over can coexist for a prolonged period, while the latter select a non-conflicting subset of the routes used by the former, then why should the disruption for a fast changeover be awful? > >>>So if router A is secure and sees paths 1 and 3, and router B is >>>insecure and sees path 2, with path 1 being the worst and path 3 >>>being the best, and only path 1 is verifiable, A will select path >>>1 (2 and 3 aren't secure) but B will select 2 because it is >>>"better" than 1. B would ideally select 3, but this isn't allowed >>>because that would create a loop. It's also something that can't >>>happen because A only sends 1 to B as 1 is the one it uses itself. > >>I didn't follow your example in detail. I am willing to believe >>that partial deployment within an AS might be OK, but I do worry >>that there are a lot of ways for it to fail. > >(With "sees" I mean "receives from an external AS.) > >I imagine that people will want to run the security stuff in some >sort of "monitor" mode first, so that they get to see which routes >would be rejected without them actually being rejected yet. Going >from nothing to completely secure in one big leap would be too much >for most people, I imagine. I agree entirely. When we built the first firewalls in the late 80's we allowed them to be run in a mode where we logged traffic that would be dropped if "a given rule set were enabled, to allow folks to become comfortable with the effect of turning on the rules. The same thing would be appropriate here. > >Also, an important problem is going to be the routing information >that is in fact good, but can't be verified as such. Especially in >the beginning this will be a large class because people have to get >the hang of the new system. Right. incremental deployment means that you will get a mix of verified and unverified routing info, and we need to have simple rules on how to deal with this mix, and to report exceptions in an effort to help tune the rules. > >>I was not aware of the backwards compatibility motivation you cite >>for the rules. > >I'm starting to doubt myself now... I can't find any source for this >information: it's not in the RFCs or in Internet Routing >Architectures. So either it must have been in something more obscure >or I came up with this explanation on my own without realizing it... it would be nice to know the rationale. who do you think we should ask, Yakov? > >>Also, the statistics I noted above on how often atomic still >>appears in Updates suggest that there are a number of operators who >>may not realize why the attribute is no longer needed. > >>Without your explanation of the context, the rules seemed >>appropriate, i.e., they seem to state reasonable constraints on how >>to construct an aggregated route given various routes as inputs. >>Are you saying that there are no constraints now on how a speaker >>is supposed to create an aggregated route from the routes a speaker >>receives from its peers? > >As Russ said, most aggregates aren't generated using aggregate >creation mechanisms, but simply by sourcing the aggregate as a new >prefix and filtering out the more specifics. I'm afraid I don't understand how to interpret those words. Could you rephrase this, maybe add more detail and an example? Oh, never mind, I see you're provided a great example below. Thanks. >I'll even go further and claim that most aggregates aren't really >aggregates, but people getting address space from an ISP's PA block >and then announcing this space under their own AS. Obviously the >entire PA block will also be announced under the ISP's AS. Usually, >the ISP in question will also propagate the more specific. (If they >didn't, there wouldn't be any incoming traffic through this ISP as >the more specific points to another ISP.) I understand that mechanism, which does not seem like aggregation to me, and which is easy to accommodate, by having the ISP that hands out the address space to a subscriber record that in a suitable, secure, fashion, that the subscriber can use to then authorize another ISP to originate the delegated prefix. >Now all of this non-RFC-compliant aggregation works without any >problems because of the longest match first rule. However, if we >want to have the actual aggregation benefits, we need to get rid of >the more specifics. The problem with this is that if you do this in >one AS, the next AS is probably going to hear the aggregate and the >more specific from different sources. I.e.: > > sourceAS > / \ >ISPA ISPB > \ / > ISPC > | > (inet) > >Assuming ISP A has 96.0.0.0/8 and the source AS announces 96.96.96.0/24. and, ISP B announces the /24 to C, because that's what sourceAS announces to it, right? >So if ISP A doesn't propagate the /24 to the ISP C, ISP C will see >the /8 from A and the /24 from B. In the current situation ISP C >will allow both the /8 and the /24 through, so there is no >aggregation as seen by anyone behind ISP C. With aggressive >aggregation, the /24 would go away (to come back when the /8 >disappears, one hopes) but then the link over ISP becomes useless. >So what we really want is for ISP C to compare the AS path and/or >other metrics and select the path over B if this is better, but >ignore this path and use the aggregate if A is better. (C would >still most likely only propagate the aggregate downstream, though.) On one hand its OK for ISP C to propagate only the /8, because C is a valid AS to route to both the /8 and the /24. The question, relative to the BGP spec, is what AS is advertised as the origin. It's legitimate to advertise just A, since it IS the "owner" for the /8, and nobody downstream would know the difference if they didn't know, independently, that the /24 had been delegated to sourceAS. if they did know this fact, then they might be justifiably suspicious of the advertisement, unless there was some way for them to know that sourceAs was still connected to A. Another possibility would be to advertise an AS set with A and ISPB as the origin, which would at least be consistent with external knowledge of sourceAS's delegation and its subsequent authorization of ISPB to advertise the /24. A more interesting situation arises if source AS has another path to the rest of the Internet, say via ISPD, which does not connect back to ISPC. Now if C advertises just the /8, and not the /24, traffic for sourceAS will not flow via ISPC IF other ASes learn of the /24 for sourceAS via ISPD. In that case, ISPC needs to advertise the /24, not just the /8, to enable both paths to sourceAS, right? >The BGP RFC allows for this, and mandates that the ISP B AS is >listed in an AS_SET for the aggregate, and that the ATOMIC_AGGREGATE >attribute is added as an indication of what's going on. However, >unless I'm mistaken, all current implementations take the longest >match first rule as gospel, so none of this comes into play. So, if the /24 is not aggregated this works fine for both your example and my slightly more elaborate one, even if nobody pays attention to the ATOMIC_AGGREGATE attribute. yes, I understand. >So to answer your question: if noone is listening, it doesn't matter >if what you're saying is wrong. So in practice there are no >limitations on how you can aggregate. nice "if a tree falls in the forest ..." analogy! But, if no one listens, all sorts of mayhem can occur, and we do see that happening sometimes. >Of course this will have to change when we add security, because we >can't allow an unauthorized source to originate an aggregate. >However, this doesn't mean only the holder of the address space gets >to aggregate: people may trust others to aggregate for them. I'll try to briefly explain what S-BGP calls for in cases like this, as an example of how we addressed this sort of issue. (As an aside, I really dislike the use of the term "trust" in this context. If we start thinking in terms of trust relationships among ISPs, then we create opportunities for a security failure or a config error at one ISP to affect many others. Instead I like to think in terms of the authoritative sources of info for different forms of info. so, for example we have IANA and RIRs as sources for prefix and AS # allocations, and ISPs as sources for sub-allocations of prefixes. Prefix holders, both ISPs of subscribers, are sources for authorizing ASes to advertise prefixes.) In S-BGP, when ISPA allocated the /24 to sourceAS, it generated a cert for sourceAS expressing this allocation. ISPA would already have a cert that contained the /8 allocation from the RIR or IANA, or whoever allocated the /8 to ISPA. Thus the allocation of the /24 to sourceAS is OK, relative to the PKI model that we proposed, and that matches the address allocation (not advertisement) hierarchy. Now, sourceAs, when it signs up with ISPB, issues a digitally signed blob, called an address attestation, to ISPB, which is the way than an address holder explicitly authorizes a specified AS to originate a prefix. ISPA issues an address attestation to itself, to advertise the /8 that it holds. sourceAS also issues an address attestation to ISPA for the /24, to authorizing ISPA to still orignate the /24. (This is appropriate because sourceAS might have taken its business elsewhere and thus we nee to know whether ISPA is still authorized by the current holder of the /24 to originate it.) The address attestations could be sent via Updates, but it seemed a waste t space to do so, because every AS potentially needs to be able to verify every address attestation for every routable prefix. So, S-BGP calls for distribution of this (signed) data via repositories. This also seems reasonable since the rate of change of this data is not that fast, i.e., address holders do not change the ISPs they authorized to originate their prefixes very frequently. Now ISPA and ISPB send their advertisements to ISPC. ISPC, using data from the statically distributed address attestation database, sees that both A and B are authorized to originate the /24, and ISPA is authorized to originate the /8, so it accepts the advertisements from both. Now, when ISPC sends an advertisement to other ASes, there is the question of who is advertised as the origin. If either A or B or both appear, other ASes will accept that, because the address attestations support all of these assertions about who can originate the /24. If, using my example, there is an ISPD that souceAS authorizes to originate the /24, then then there would be an entry in the address attestation database for that ISP as well. Thus ASes receiving advertisements from both C and D would view A, B, and D as legitimate origins for the /24. Note, however, that if sourceAS left ISPA, and no longer wanted that ISP to originate the /24, all sourceAs has to do is withdraw the address attestation for A. Then, A could advertise the /8, but, due to the longer match rule, the /24 advertised through B and D would take precedence, as one would want. One can ask what other ASes would do if they fail to receive advertisements for the /24 from B or D. BGP says that a speaker will route based on a less specific prefix UNLESS it is aware of the existence of the more specific prefix. The knowledge of the more specific prefix is normally via Updates, but the local policy feature admits the potential to manually acquire info about a more specific prefixes. Use of IRR databases is an example of how to do this today, though very imperfectly. In S-BGP, the address attestation database represents a source for configuring the info of what ASes are authorized by prefix holders to advertise which prefixes. Thus provides a way for ASes to decide if they want to route the /24 traffic to A, even when they know that ASes other than A are authorized to originate the /24, and A is not so authorized. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 7 18:45: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 SAA08553 for ; Fri, 7 Jan 2005 18:45:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn40H-0006Gz-7N for rpsec-web-archive@ietf.org; Fri, 07 Jan 2005 18:58:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn3kF-0003F7-Ps; Fri, 07 Jan 2005 18:42:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn3j4-00032G-MT for rpsec@megatron.ietf.org; Fri, 07 Jan 2005 18:41: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 SAA08401 for ; Fri, 7 Jan 2005 18:40:59 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn3w9-0005lt-LP for rpsec@ietf.org; Fri, 07 Jan 2005 18:54:34 -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 j07NeQjh016594; Fri, 7 Jan 2005 18:40:28 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 7 Jan 2005 18:30:38 -0500 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] Thoughts on BGP Security Req's Draft (I) 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: b132cb3ed2d4be2017585bf6859e1ede 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.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 At 8:47 PM +0100 1/6/05, Iljitsch van Beijnum wrote: >On 6-jan-05, at 17:26, Stephen Kent wrote: > >>BGP is a protocol, which defines of formats for messages and an >>algorithm for processing these messages, in the context of local >>databases. If we define security for BGP in terms of generating the >>"right" routes even when the systems is under attack, we need to >>begin with the process that generates the routes under benign >>conditions. > >>I agree that one may be able to generate rules for characterizing >>what routes are authorized/valid/... independent of the process by >>which they are generated. BUT, if you want to do that, rather than >>focusing on securing the process, the burden is on you to show that >>the results are equivalent. > >Aren't there really just two things that we want/need protection against: > >1. Someone sourcing a prefix that doesn't belong to them > >This is the easy part: some magic PKI dust solves this part real good. It's not trivial, as my example in another message shows, but it is largely a matter of a PKI plus other signed stuff to accommodate the issue of not only who holds/owns a prefix, but who that holder authorizes to advertise it. >2. Someone announcing reachability to a prefix or AS that they >shouldn't announce > >This is the tricky part. How do we know when someone is announcing >reachability illegitimately? We can't go by the source, both because >of the information explosion this causes and a wealth of practical >issues, and also because even if the source says that AS X isn't >supposed to be in their transit path, the destination may feel >otherwise so the path turns out OK anyway. > >Note that both soBGP and S-BGP (when I last looked at them) didn't >have mechanisms to handle this properly. well, I can't speak for soBGP, but this is certainly what we attempted to do in S-BGP. I think we defined a way to do it, but it isn't free in terms of memory and computational costs. In talking with folks like Randy Bush, I learned that some of the estimates we made for memory were too conservative, so it might not be so bad in that regard. Also, now that there are some opportunities for using elliptic curve crypto w/o the sort of licensing problems that causes us to avoid it originally, we could reduce the amount of space that signatures occupy and speed up processing as well. (Folks at Dartmouth suggested use of ECC, but until patent issues were resolved it didn't seem to be a viable path.) On the down side, experience with worms has shown that the computational costs can deviate from the average by more than we had expected, so one still worries about the computation costs of S-BGP. Other proposals, that have appeared in the literature have worse performance problems. For example, some folks have expressed enthusiasm for SPV. But careful analysis of the SPV mechanisms suggests that it requires carriage and storage of signature data that is about 5 times bigger than for S-BGP! Also, the 20-fold performance improvement claimed (relative to S-BGP) does not take into account the signature deferral heuristic proposed for S-BGP in later work, which would significantly reduce the apparent benefits claimed by SPV. >All other bad stuff that an attacker could make happen by subverting >BGP can also happen for legitimate reasons, so I don't see how we >can realistically protect against that. yes, given the great flexibility allowed by the local policy feature of BGP, it's hard to put very tight bounds on what is advertised. >There is one other thing, though: it would be very nice if we could >somehow determine whether traffic we send over a certain route >actually makes it to the destination AS. This would be incredibly >helpful even for regular misconfiguration and other routine >brokenness, but also in the cases where an attacker solicits traffic >but doesn't forward it to the real destination. I see that as a monitoring aspect of security analogous to IDS use in an enterprise security environment. It's a useful feature to detect some forms of attacks, but not all, e.g., if one reroutes traffic to facilitate passive or active wiretapping, monitoring to detect whether the destination receives traffic will not detect such rerouting. >>In the credit card space there are valid accounts and authorized >>users. The primary security goal here is to ensure that charges are >>associated with valid accounts and incurred on behalf of authorized >>users. That's the high level security goal and it is very much >>independent of process. It applies whether the cards are used in >>card present or MOTO transactions. > >If we make the credit card owner an AS and make a payment a route, >then we want traffic = money to follow legitimate routes, not fake >ones. Pretty similar. :-) We might care about the path a payment takes IF we are concerned about disclosure of the CC number, or for privacy purposes. But, that's quite a stretch for an analogy. Also, note that real threats to credit card abuse in the Internet context generally do not arise due to communication security failures (e.g., failure to protect the CC # en route), but rather arise because of the entity to whom we disclose the numbers (e.g., a bad web site). >>I am saying that the definition of how BGP routing is supposed to >>work needs to be based on the BGP spec. Its an IETF standard and an >>objective basis from which to work. > >With just one tiny flaw: the standard doesn't fully describe what's >out there in the real world. I believe IDR is trying to remedy this, >but I'm not sure about how successful their efforts are. (Moving >target and all.) Depending on the motivation for the deviations from the standard, this may or may not be a good justification for adopting other bases for security requirements. After all, some spammers attack BGP successfully, maybe often enough, to count as real world deviation from the standard. Do we want to accommodate that in a security requirement :-) ? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 12 10:36: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 KAA22567 for ; Wed, 12 Jan 2005 10:36:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cokm3-0000BO-HK for rpsec-web-archive@ietf.org; Wed, 12 Jan 2005 10: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 1CokT1-0000oX-HG; Wed, 12 Jan 2005 10:31:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CokNM-0006wV-AC for rpsec@megatron.ietf.org; Wed, 12 Jan 2005 10:25:38 -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 KAA21576 for ; Wed, 12 Jan 2005 10:25:34 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CokbM-0008MC-Js for rpsec@ietf.org; Wed, 12 Jan 2005 10:40:07 -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 j0CFOtjf012903; Wed, 12 Jan 2005 10:24:56 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <6A979F78-5F66-11D9-BA2A-000A95CD987A@muada.com> Date: Wed, 12 Jan 2005 10:24:46 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] a note from the BGP4 spec 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, Iljitsch van Beijnum X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 At 5:09 PM -0500 1/7/05, Russ White wrote: >>The BGP spec deals with processing Updates, and does not address >>the infrastructure that supports address allocation, as we both >>know. > >Which is a strong justification to base the requirements on deployed >systems, as they operate, rather than the BGP specification itself. No, it's a justification for keeping in mind the role of the infrastructure in developing the security requirements. Warning label: "Do not discard baby with bath water." >>>How do we handle it when B explicitely refuses to allow A to >>>advertise 10.1.1.0/24? Should A be forced to not advertise >>>10.1.0.0/16? >> >>BGP does NOT say that A is not supposed to advertise the /16 just >>because a sub-allocation out of the /16 is no longer reachable via >>A. I cited specific text from the BGP spec that deals with this, in >>my memo so I will not bother restating the reasoning here. > >The /24 is a _part_ of the /16. Since the /24 is a _part_ of the >/16, how does A advertise the /16 without advertising the /24? IF A >cannot advertise the /16 without including the /24, and A does not >have authorization to advertise the /24, then it _cannot_ advertise >the /16. I have explained how I interpret what the BGP spec says when there are overlapping prefixes, and I cited the relevant text. I don't know what more I can do to explain this, Russ. Looking at the rest of your message, we seem to be rehashing questions for which I fee I have provided detailed responses, often with cites to relevant BGP spec text in support of my answers. This it does not seem a good use of my time or yours, or of the members of the WG to continue in this discussion, in this fashion. I will prepare a message the IESG raising the issues we both agreed need to be resolved before we can progress. I'll copy the list on the message, and when we get a resolution to this issue, then, hopefully, we can make progress. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 20 10:43: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 KAA07602 for ; Thu, 20 Jan 2005 10:43:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrejD-0001W0-K7 for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 11:00:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CreOn-0000h8-Q3; Thu, 20 Jan 2005 10:39:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CreLl-0000Jy-4I for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 10:35: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 KAA07174 for ; Thu, 20 Jan 2005 10:35:54 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrebP-0001LR-C9 for rpsec@ietf.org; Thu, 20 Jan 2005 10:52:10 -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 j0KFZHjj012985; Thu, 20 Jan 2005 10:35:20 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Thu, 20 Jan 2005 10:35:01 -0500 To: rpsec@ietf.org From: Stephen Kent X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: Stephen Kent Subject: [RPSEC] proposed message to the IESG X-BeenThere: rpsec@ietf.org 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="===============0509671715==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 --===============0509671715== Content-Type: multipart/alternative; boundary="============_-1105887186==_ma============" --============_-1105887186==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Folks, Here is the text I plan to send to the IESG, based on previous list discussions. Please let me know if anyone would like changes or additions to the text, so it can be sent to the IESG soon. Thanks, Steve -------- Members of the IESG: I a writing this message, with the concurrence of the WG chairs, because the RPSEC working group has reached an impasse in our efforts to develop a security requirements document for BGP. Specifically, the WG has not been able to agree on the appropriate basis for deriving the requirements. I have argued that the current version of the BGP spec (XXX) should form the primary basis for developing security requirements for BGP. This is not to say that all aspects of these requirements must be derived from that document, but that it should provide the base rationale for deriving most requirements. Some requirements, e.g., having to do with deployment and performance considerations, cannot be derived from the BGP spec. For these requirements it is appropriate and necessary to rely on operational experience, published analyses, etc. In contrast, Russ White, a co-chair of the WG and a contributor to this RPSEC document, has asserted that operational experience should be the primary driver for the requirements document. Russ has stated that the BGP spec cited above does not accurately reflect BGP implementation and deployment patterns, and thus is not a suitable basis for the security requirements document that the WG is slated to develop. In our discussions on the WG list, I cited a number of quotes from the BGP spec in support of the sort of requirements that I think the document should embody. Russ has stated that many of these do not reflect BGP implementation and deployment, hence his insistence on a different basis for requirements development. I have objected because Russ has not been able to cite IETF-approved documents that describe the basis he supports. I feel this disagreement in RPSEC raises a serious issues since this version of the BGP spec is slated to become a full standard. BGP is a product of the IDR WG, part of the same area (Routing) where the RPSEC work is taking place. It seems inappropriate for the IETF to adopt a BGP security requirements document that employs rationale that conflicts with the BGP spec, especially when both are developed in the same area. If the IESG agrees that a BGP requirements document developed in the Routing area should be based on the BGP spec produced by the same area, then it may be necessary to revisit the current version of the BGP spec to address the topics that Russ has identified as not consistent with BGP implementation and practice. Alternatively, the IESG might decide that the BGP security requirements document should be based primarily on operational considerations, in which case I suggest that the WG is more appropriately homed in the Operations (vs. Routing) area, and the focus might be a BCP-style document. Thanks for taking the time to review this matter. Steve Kent --============_-1105887186==_ma============ Content-Type: text/html; charset="us-ascii" proposed message to the IESG
Folks,

Here is the text I plan to send to the IESG, based on previous list discussions.  Please let me know if anyone would like changes or additions to the text, so it can be sent to the IESG soon.

Thanks,

Steve
--------

Members of the IESG:

I a writing this message, with the concurrence of the WG chairs, because the RPSEC working group has reached an impasse in our efforts to develop a security requirements document for BGP. Specifically, the WG has not been able to agree on the appropriate basis for deriving the requirements.

I have argued that the current version of the BGP spec (XXX) should form the primary basis for developing security requirements for BGP. This is not to say that all aspects of these requirements must be derived from that document, but that it should provide the base rationale for deriving most requirements. Some requirements, e.g., having to do with deployment and performance considerations, cannot be derived from the BGP spec. For these requirements it is appropriate and necessary to rely on operational experience, published analyses, etc.
In contrast, Russ White, a co-chair of the WG and a contributor to this RPSEC document, has asserted that operational experience should be the primary driver for the requirements document. Russ has stated that the BGP spec cited above does not accurately reflect BGP implementation and deployment patterns, and thus is not a suitable basis for the security requirements document that the WG is slated to develop. 

In our discussions on the WG list, I cited a number of quotes from the BGP spec in support of the sort of requirements that I think the document should embody. Russ has stated that many of these do not reflect BGP implementation and deployment, hence his insistence on a different basis for requirements development. I have objected because Russ has not been able to cite IETF-approved documents that describe the basis he supports.

I feel this disagreement in RPSEC raises a serious issues since this version of the BGP spec is slated to become a full standard. BGP is a product of the IDR WG, part of the same area (Routing) where the RPSEC work is taking place. It seems inappropriate for the IETF to adopt a BGP security requirements document that employs rationale that conflicts with the BGP spec, especially when both are developed in the same area.

If the IESG agrees that a BGP requirements document developed in the Routing area should be based on the BGP spec produced  by the same area, then it may be necessary to revisit the current version of the BGP spec to address the topics that Russ has identified as not consistent with BGP implementation and practice. Alternatively, the IESG might decide that the BGP security requirements document should be based primarily on operational considerations, in which case I suggest that the WG is more appropriately homed in the Operations (vs. Routing) area, and the focus might be a BCP-style document.


Thanks for taking the time to review this matter.

Steve Kent
--============_-1105887186==_ma============-- --===============0509671715== 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 --===============0509671715==-- From rpsec-bounces@ietf.org Thu Jan 20 11:25: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 LAA11053 for ; Thu, 20 Jan 2005 11:25:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrfN9-0002jw-QD for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 11:41:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrezD-00084d-Nt; Thu, 20 Jan 2005 11:16:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cretz-0006tr-1r for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 11:11: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 LAA10061 for ; Thu, 20 Jan 2005 11:11:16 -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 1Crf9f-0002Lz-Kh for rpsec@ietf.org; Thu, 20 Jan 2005 11:27:33 -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 j0KGAYDH005699 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Thu, 20 Jan 2005 11:10:34 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 20 Jan 2005 11:10:27 -0500 Subject: Re: [RPSEC] proposed message to the IESG 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: f66b12316365a3fe519e75911daf28a8 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: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Hello Steve, I am concerned about your assertion that the draft does not follow the BGP spec. I have avoided stepping into the fray with you and Russ going at it. But can you clarify, for me, exactly what parts of the BGP spec are being ignored or changed in this draft? I have been working with BGP for many years and I could not find a spot where the document did not match reality or the needs of the operators. This document is intended to present a set of requirements from the operator community to the folks creating the standards (which is why it is tracking towards informational). Regards, Blaine On 1/20/05 10:35 AM, "Stephen Kent" wrote: > Folks, > > Here is the text I plan to send to the IESG, based on previous list > discussions. Please let me know if anyone would like changes or additions to > the text, so it can be sent to the IESG soon. > > Thanks, > > Steve > -------- > > Members of the IESG: > > I a writing this message, with the concurrence of the WG chairs, because the > RPSEC working group has reached an impasse in our efforts to develop a > security requirements document for BGP. Specifically, the WG has not been able > to agree on the appropriate basis for deriving the requirements. > > I have argued that the current version of the BGP spec (XXX) should form the > primary basis for developing security requirements for BGP. This is not to say > that all aspects of these requirements must be derived from that document, but > that it should provide the base rationale for deriving most requirements. Some > requirements, e.g., having to do with deployment and performance > considerations, cannot be derived from the BGP spec. For these requirements it > is appropriate and necessary to rely on operational experience, published > analyses, etc. > In contrast, Russ White, a co-chair of the WG and a contributor to this RPSEC > document, has asserted that operational experience should be the primary > driver for the requirements document. Russ has stated that the BGP spec cited > above does not accurately reflect BGP implementation and deployment patterns, > and thus is not a suitable basis for the security requirements document that > the WG is slated to develop. > > In our discussions on the WG list, I cited a number of quotes from the BGP > spec in support of the sort of requirements that I think the document should > embody. Russ has stated that many of these do not reflect BGP implementation > and deployment, hence his insistence on a different basis for requirements > development. I have objected because Russ has not been able to cite > IETF-approved documents that describe the basis he supports. > > I feel this disagreement in RPSEC raises a serious issues since this version > of the BGP spec is slated to become a full standard. BGP is a product of the > IDR WG, part of the same area (Routing) where the RPSEC work is taking place. > It seems inappropriate for the IETF to adopt a BGP security requirements > document that employs rationale that conflicts with the BGP spec, especially > when both are developed in the same area. > > If the IESG agrees that a BGP requirements document developed in the Routing > area should be based on the BGP spec produced by the same area, then it may > be necessary to revisit the current version of the BGP spec to address the > topics that Russ has identified as not consistent with BGP implementation and > practice. Alternatively, the IESG might decide that the BGP security > requirements document should be based primarily on operational considerations, > in which case I suggest that the WG is more appropriately homed in the > Operations (vs. Routing) area, and the focus might be a BCP-style document. > > > Thanks for taking the time to review this matter. > > Steve Kent > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 20 14:20: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 OAA27075 for ; Thu, 20 Jan 2005 14:20:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cri7B-0007nc-C5 for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 14:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crhes-0006d4-Qd; Thu, 20 Jan 2005 14:07:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrhYq-0004ny-C3 for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 14:01: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 OAA25215 for ; Thu, 20 Jan 2005 14:01:39 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrhoY-00077v-Og for rpsec@ietf.org; Thu, 20 Jan 2005 14:17:56 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Jan 2005 14:08:51 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-135.cisco.com [10.82.240.135]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0KI16oB024748 for ; Thu, 20 Jan 2005 13:01:06 -0500 (EST) Date: Thu, 20 Jan 2005 14:00:25 -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: 769a46790fb42fbb0b0cc700c82f7081 Subject: [RPSEC] proposed message to the IESG 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: 538aad3a3c4f01d8b6a6477ca4248793 > In contrast, Russ White, a co-chair of the WG and a contributor to this > RPSEC document, has asserted that operational experience should be the > primary driver for the requirements document. Russ has stated that the > BGP spec cited above does not accurately reflect BGP implementation and > deployment patterns, and thus is not a suitable basis for the security > requirements document that the WG is slated to develop. Rephrase this to: Russ White.... believes the specifications requirement should be based on an analysis of what is provable within an internetwork using BGP as its routing protocol, rather than the proving the processes within the BGP specification have been followed, specifically. I don't claim the BGP spec is wrong, just that the important questions aren't about process, but how the information in the system matches reality. -- > Russ has stated that many of these do not reflect BGP implementation and > deployment, hence his insistence on a different basis for requirements > development. I have objected because Russ has not been able to cite > IETF-approved documents that describe the basis he supports. See above. It's not a matter of citing other specifications. Many of the things which need to be secured are outside IETF specifications to begin with. For instance, the authorization to advertise a specific block of addresses is completely outside the BGP specification, since the BGP specification doesn't cover such things as how to get an address block, etc. And yet, I think we all agree that this is a critical requirement. -- > It seems inappropriate for the IETF to adopt a BGP security requirements > document that employs rationale that conflicts with the BGP spec, > especially when both are developed in the same area. Could you please cite a specific instance where the requirements document actually contradicts the BGP specification? :-) 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 Thu Jan 20 14:23: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 OAA27252 for ; Thu, 20 Jan 2005 14:23:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cri9g-0007r2-9Z for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 14:39:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crhfe-0006t0-Hn; Thu, 20 Jan 2005 14:08:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crhch-00062b-7A for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 14:05: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 OAA25960 for ; Thu, 20 Jan 2005 14:05: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 1CrhsP-0007OE-7D for rpsec@ietf.org; Thu, 20 Jan 2005 14:21:54 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5A3432D4A7F; Thu, 20 Jan 2005 14:05:06 -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 96915-01-46; Thu, 20 Jan 2005 14:05:05 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 2EBC82D4A7E; Thu, 20 Jan 2005 14:05:05 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0KJ54222662; Thu, 20 Jan 2005 14:05:04 -0500 (EST) Date: Thu, 20 Jan 2005 14:05:04 +1837 From: Jeffrey Haas To: Blaine Christian Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <19740802192832.GZ15303@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: 2.1 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: 2.1 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Blaine, On Fri, Aug 02, 1974 at 11:33:55AM -0500, Blaine Christian wrote: > I am concerned about your assertion that the draft does not follow the BGP > spec. I have avoided stepping into the fray with you and Russ going at it. Work responsibilities have kept me from commenting on this thread directly, but I've had some offline conversations with a few people. My specific concern is that the key items of contention between Russ and Steve get summarized and presented to the IESG. I do think Steve is being a bit overly broad regarding "following the spec", but I also think Russ has been a bit overly broad in some of his comments about the spec and reality not matching up. I will take a moment to state on this list that many of the items under contention are items I also had contention with Russ on the bgpsecreq list. Steve doesn't stand alone on many of them. Some of the items under contention are "what elements of the BGP-4 protocol are we trying to secure" and "does securing this element actually provide security". There are also operational conflicts, namely centralization of the security infrastructure (vs. distributed) and also (forgive me if I'm misusing the term) trust anchors. I believe many of the operational issues can be addressed in the solution-space portion of this exercise. However, it may be necessary to articulate the problem-space sufficiently to allow various choices to be made. However, the elements of security within the protocol are under contention. This is where I'd suggest focusing the IESG's attention. To give a specific example, the value of securing the AS_PATH and the method by which is secured. I highly recommend that the bgpsecreq content be made available if it is not already available. > Blaine -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 20 15:14:36 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 PAA01457 for ; Thu, 20 Jan 2005 15:14:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrixC-0000fD-JQ for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 15:30:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CriVo-0001Pj-ME; Thu, 20 Jan 2005 15:02:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CriOB-0006ka-6u for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 14:54: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 OAA29065 for ; Thu, 20 Jan 2005 14:54:41 -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 1Cridu-00005v-Qz for rpsec@ietf.org; Thu, 20 Jan 2005 15:10: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 j0KJr7DH008364 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Thu, 20 Jan 2005 14:53:08 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 20 Jan 2005 14:53:00 -0500 Subject: Re: [RPSEC] proposed message to the IESG From: Blaine Christian To: Jeffrey Haas Message-ID: In-Reply-To: <19740802192832.GZ15303@nexthop.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Hi Jeff, That makes sense. What I have been trying to do, at least on a personal level, is be completely agnostic on the solution and focus on the needs of the folks running existing BGP implementations. Steve/Russ/Jeff, can we give one more shot at discussion with a bit more participation on my part? I truly have no side in this. Except, perhaps, the side of the operators. If we have to go to mediation I think we should provide a good chunk of detail on the specific issues under contention. If the BGP spec is violated by the draft then we need to highlight the specific section that violates the spec. If the content of the draft is such that it belongs in a separate working group then we need to identify why it does not match with the rpsec charter. I do recall seeing some thoughts that perhaps this draft is focused on a specific solution. If I could get the exact text that appears to do that along with the explanation (I apologize if someone has to redo this) I would appreciate it. The draft is a working group document now and is available at http://www.ietf.org/html.charters/rpsec-charter.html This is still a draft and belongs to the entire working group! So if we have a chorus of voices on the thread saying something needs to be changed I am happy to do so. Regards, Blaine On 1/19/05 2:28 PM, "Jeffrey Haas" wrote: > Blaine, > > On Fri, Aug 02, 1974 at 11:33:55AM -0500, Blaine Christian wrote: >> I am concerned about your assertion that the draft does not follow the BGP >> spec. I have avoided stepping into the fray with you and Russ going at it. > > Work responsibilities have kept me from commenting on this thread > directly, but I've had some offline conversations with a few people. > > My specific concern is that the key items of contention between Russ > and Steve get summarized and presented to the IESG. I do think Steve > is being a bit overly broad regarding "following the spec", but I > also think Russ has been a bit overly broad in some of his comments > about the spec and reality not matching up. > > I will take a moment to state on this list that many of the > items under contention are items I also had contention with Russ on > the bgpsecreq list. Steve doesn't stand alone on many of them. > > Some of the items under contention are "what elements of the BGP-4 protocol > are we trying to secure" and "does securing this element actually provide > security". There are also operational conflicts, namely centralization > of the security infrastructure (vs. distributed) and also (forgive > me if I'm misusing the term) trust anchors. > > I believe many of the operational issues can be addressed in the > solution-space portion of this exercise. However, it may be necessary > to articulate the problem-space sufficiently to allow various choices > to be made. > > However, the elements of security within the protocol are under > contention. This is where I'd suggest focusing the IESG's attention. > To give a specific example, the value of securing the AS_PATH and > the method by which is secured. > > I highly recommend that the bgpsecreq content be made available > if it is not already available. > >> Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 20 15:45: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 PAA04156 for ; Thu, 20 Jan 2005 15:45:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrjRW-0001YD-4V for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 16:02:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crizw-0003yG-AU; Thu, 20 Jan 2005 15:33:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrimG-00055s-Md for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 15:19:36 -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 PAA02106 for ; Thu, 20 Jan 2005 15:19:34 -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 1Crj1z-0000mg-B4 for rpsec@ietf.org; Thu, 20 Jan 2005 15:35:52 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id EBDA82D4A98; Thu, 20 Jan 2005 15:19:03 -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 02507-01-90; Thu, 20 Jan 2005 15:18:59 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 769692D4C45; Thu, 20 Jan 2005 15:18:45 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0KKIjE22939; Thu, 20 Jan 2005 15:18:45 -0500 (EST) Date: Thu, 20 Jan 2005 15:18:45 -0500 From: Jeffrey Haas To: Blaine Christian Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050120201845.GB22790@nexthop.com> References: <19740802192832.GZ15303@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: 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Blaine, On Thu, Jan 20, 2005 at 02:53:00PM -0500, Blaine Christian wrote: > Steve/Russ/Jeff, can we give one more shot at discussion with a bit more > participation on my part? I truly have no side in this. Except, perhaps, > the side of the operators. Might I suggest starting with any thread that has a tree width > 4. :-) > If we have to go to mediation I think we should provide a good chunk of > detail on the specific issues under contention. If I might make a suggestion, it would probably be best if you (or, in this case, not the parties under contention) make an attempt to summarize the items of contention and the argument to either side. If you, as an informed person, are unable to untangle the nature of the items under contention, each side has failed to make themselves clear. There's no sense in asking IESG to do this for us. > If the BGP spec is violated > by the draft then we need to highlight the specific section that violates > the spec. This is also one of the items under contention. Our general desire is not change the properties of BGP in general or specific. For example, the reluctance to touch the format of the Update message immediately precludes certain solution-spaces (or has a very good chance of doing so). More important, IMO, is to make sure we don't violate the semantics of the information currently carry in BGP-4; rather, we should make sure we only extend them. The implicit meaning of some of the protocol semantics are part of the contention. Unfortunately, so is BGP-4's relationship with CIDR and address allocation and delegation strategies. > Blaine -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 20 16:59: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 QAA15724 for ; Thu, 20 Jan 2005 16:59:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crkag-0005NE-W8 for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 17:15:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrjZc-0004if-DA; Thu, 20 Jan 2005 16:10:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrjP9-0007kj-OG for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 15:59: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 PAA05308 for ; Thu, 20 Jan 2005 15:59:45 -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 1Crjes-0001rW-RQ for rpsec@ietf.org; Thu, 20 Jan 2005 16:16:04 -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 j0KKwxDH009082 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Thu, 20 Jan 2005 15:59:00 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 20 Jan 2005 15:58:53 -0500 Subject: Re: [RPSEC] proposed message to the IESG From: Blaine Christian To: Jeffrey Haas Message-ID: In-Reply-To: <20050120201845.GB22790@nexthop.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Hey Jeff, Fair enough... I will address through the specific points that Steve raised as problems for the IESG. Perhaps we can take the points one at a time. As I see it there appear to be two points of contention. 1. Draft not in the charter: The premise for this argument appears to be that by including requirements to cope with current operational practices the draft falls under the wrong working group. I read the charter and it does not state that operational requirements are verboten. The draft seems to fall under the charter. 2. BGP spec not followed: I believe the crux of this discussion is that by adding additional requirements to the way BGP currently works (to take into account operational practice) we are improperly specifying the requirements. However, ensuring that we preserve most of the current, established, practice seems like a valid requirement to me. Is the discussion revolving around the "extra" BGP attributes? If so, it is my perception that all transitive attributes MUST be protected via the security mechanism. My assumption, and I should be corrected if I am wrong, was that MD5/IPSec type mechanisms would be sufficient for attributes that are usually non-transitive (communities/localpref etc...). Actually, since I am also the guy pushing for one key so I don't see why the mechanism can't directly protect both types of attributes. What is wrong with that argument? Did I get your arguments right? Russ/Steve? BTW, I do not think we should care, too much, if the requirements document states that the current implementation of BGP RFC needs work to bring it into operational reality (or vice versa). If I take the BGP spec and compare it to the SIP spec it is quite an amazing site. The SIP spec has an incredible amount of detail while BGP is really quite loose. It has been a source of constant amazement to me that implementations actually work with each other. The fact that folks have implemented in ways that are not strictly within the RFC boundaries is no surprise. Regards, Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 20 17:19: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 RAA18152 for ; Thu, 20 Jan 2005 17:19:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrkuQ-00069e-4E for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 17:36:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkMa-0005BV-8A; Thu, 20 Jan 2005 17:01:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrjoC-0004HP-LS for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 16:25: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 QAA07660 for ; Thu, 20 Jan 2005 16:25:38 -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 1Crk3v-0002bG-TW for rpsec@ietf.org; Thu, 20 Jan 2005 16:41:57 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3A8502D48BE; Thu, 20 Jan 2005 16:25:08 -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 08630-02-24; Thu, 20 Jan 2005 16:25:06 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 24DDA2D48A7; Thu, 20 Jan 2005 16:25:06 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0KLP6H23164; Thu, 20 Jan 2005 16:25:06 -0500 (EST) Date: Thu, 20 Jan 2005 16:25:05 -0500 From: Jeffrey Haas To: Blaine Christian Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050120212505.GE22790@nexthop.com> References: <20050120201845.GB22790@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: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: rpsec@ietf.org, Stephen Kent X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Blaine, On Thu, Jan 20, 2005 at 03:58:53PM -0500, Blaine Christian wrote: > 1. Draft not in the charter: The premise for this argument appears to be > that by including requirements to cope with current operational practices > the draft falls under the wrong working group. I read the charter and it > does not state that operational requirements are verboten. The draft seems > to fall under the charter. I do not pretend to speak for Yakov or Sue (who is on this list) or the IDR working group. IMO, defining the security requirements for BGP is within the rpsec charter. Defining recommended protocol or operational changes to BGP is also within charter. Defining the actual protocol level changes to BGP is at best a cross-functional work item. IMO, most of the work would be done in IDR and it would be rpsec's responsibility to say "this doesn't do what we wanted". > 2. BGP spec not followed: I'll defer this to the other parties and try to stick to specifics since that fits the ADHD way I'm following this group at the moment. > If so, it is > my perception that all transitive attributes MUST be protected via the > security mechanism. Must they? What is to be protected? What does "protect" mean? I think these two last questions form the core of our arguments. However, it is difficult to articulate each of these without delving into solutions. > My assumption, and I should be corrected if I am wrong, > was that MD5/IPSec type mechanisms would be sufficient for attributes that > are usually non-transitive (communities/localpref etc...). Communities are transitive. :-) > Blaine -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 20 17:23: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 RAA18781 for ; Thu, 20 Jan 2005 17:23:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crkxt-0006K5-1Y for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 17:39:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkaF-00025d-4o; Thu, 20 Jan 2005 17:15:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkDj-0001IR-Ty for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 16:52: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 QAA13733 for ; Thu, 20 Jan 2005 16:52:01 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrkTT-0004jU-RU for rpsec@ietf.org; Thu, 20 Jan 2005 17:08:21 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0KLmZGu005056 for ; Thu, 20 Jan 2005 16:48:35 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAARHaG3j; Thu, 20 Jan 05 16:48:33 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0KLoH93005887; Thu, 20 Jan 2005 16:50:17 -0500 (EST) Date: Thu, 20 Jan 2005 16:50:17 -0500 (EST) From: Sandy Murphy Message-Id: <200501202150.j0KLoH93005887@tislabs.com> To: riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b >Russ White.... believes the specifications requirement should be based on >an analysis of what is provable Russ, I've really tried to hold back responding to your frequent mentions of "proof", "provable", "impossible to prove", etc. Now, to me and some people like me, this leads to the following sorts of considerations: "Well, first we'll have to agree on a logical system and I sure hope we can avoid natural logic because I've found the law of excluded middle too helpful to give it up and then we'll have to agree on some axioms and particularly a rule of inference and I don't see that we'll need anything more than good old modus ponens ...." Which is all a grandiose and hopefully diverting way to say that proofs are something you construct in a formal way in a formal system that you've jointly agreed to. I think you mean "convincing" when you say "proof" and you and Steve aren't agreeing to the same ground rules to convince each other. To some people, proofs of security features go something like this: (a) the spec says things should happen like this (b) it is possible to make things not happen like this (c) QED OK, so I'm generalizing a lot. But the core point is that security relies on assumptions holding. Sometimes those are innate (the IP address in the source field is the address of where this comes from) and sometimes it derives from the spec (the spec says that the message I received is generated when the source received my message, therefore I can assume that the source received my message). --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 20 17:35: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 RAA20579 for ; Thu, 20 Jan 2005 17:35:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crl9a-0006wd-Pt for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 17:51:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkaW-0002I9-S1; Thu, 20 Jan 2005 17:15:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkGK-00021K-2E for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 16:54: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 QAA14134 for ; Thu, 20 Jan 2005 16:54:41 -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 1CrkW3-0004ox-TL for rpsec@ietf.org; Thu, 20 Jan 2005 17:11:01 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j0KLsMtw001274; Thu, 20 Jan 2005 16:54:22 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAADyaahc; Thu Jan 20 16:54:12 2005 Date: Thu, 20 Jan 2005 16:54:06 -0500 From: Tony Tauber To: Stephen Kent Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============0509671715==" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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: 5d7a7e767f20255fce80fa0b77fb2433 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --===============0509671715== Content-Type: TEXT/Plain; charset=US-ASCII On Thu, 20 Jan 2005, Stephen Kent wrote: > Folks, > > Here is the text I plan to send to the IESG, based on previous list > discussions. Please let me know if anyone would like changes or > additions to the text, so it can be sent to the IESG soon. > > Thanks, > > Steve > -------- > If the IESG agrees that a BGP requirements document developed in the > Routing area should be based on the BGP spec produced by the same > area, then it may be necessary to revisit the current version of the > BGP spec to address the topics that Russ has identified as not > consistent with BGP implementation and practice. Alternatively, the > IESG might decide that the BGP security requirements document should > be based primarily on operational considerations, in which case I > suggest that the WG is more appropriately homed in the Operations > (vs. Routing) area, and the focus might be a BCP-style document. Hi Steve, Perhaps I could help boil down what I see some of the basic questions being. Your sentence begining with "Alternatively..." combined with Blaine's plea of "hey, I'm just an operator" (paraphrase mine) in this thread crystalized something for me. Operators want to secure inter-domain routing, not necessarily BGP. Their requirements are essentially pragmatic, though some commercial concerns (eg. strong unilateral control, possible obsfucation of routing/interconnection policies) sneak in. Is framing the problem as "securing BGP" appropriate? We've been striving (at least I keep advising) to focus on requirements, not solutions. Perhaps seeing BGP or some variant or add on to it as necessarily the solution is slightly constraining. That being said, it's likely that the solution will somehow involve BGP and, since that's an IETF protocol, changes to it ought to happen in the IETF. OTOH, if people figure some way to operationally work around it, that happens outside the IETF. My understanding/experience is that this organic process is what happened to cause the earlier BGP-4 spec to become out of steop with deployed reality; hence the effort to revise the spec in reverse. My guess (and I'm no longer an ISP operator) is that we could see something similar happen here should the IETF get too bogged down in figuring out which Area work gets done rather than getting the work done. Now, I don't want to come across as wedded to the idea that the RPSEC WG or even the IETF has to be the ones to solve this problem; if it gets done some other way, hopefully the users will benefit (eg. good technology w/good interoperability). All this being said, I think you've raised a great over-arching point in the discussions we've had heretofore which I'll paraprhase thus: --- Beware that the permissiveness of various deployment options can compromise the resulting security. It necessarily increases complexity, for instance, and thus becomes more difficult to understand, manage, and enforce. --- This notion might run counter to a "give the people what they want" approach to deriving requirements from Operators practical concerns. I respect your experience and expertise in the security field and only wish we had a greater range of voices from those who have such experience. Our problem has been that we're stuck in something of a culture gap and things are devolving into a winner-take-all atmosphere that's becoming toxic. I don't know that the we need too take it the IESG or if they could solve the problem (getting a useful improvement to routing security). If they could somehow, I'd welcome it, but this problem is truly difficult. OK, sorry for the rambling mail. Tony --===============0509671715== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0509671715== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0509671715==-- From rpsec-bounces@ietf.org Thu Jan 20 17:37:17 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 RAA20876 for ; Thu, 20 Jan 2005 17:37:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrlBJ-00072f-3d for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 17:53:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crkh3-0005W1-Om; Thu, 20 Jan 2005 17:22:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkNY-0006Ox-7h for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 17:02: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 RAA16393 for ; Thu, 20 Jan 2005 17:02:09 -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 1CrkdF-0005Xm-Qc for rpsec@ietf.org; Thu, 20 Jan 2005 17:18:29 -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 j0KM1UDH009792 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Thu, 20 Jan 2005 17:01:31 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 20 Jan 2005 17:01:23 -0500 Subject: Re: [RPSEC] proposed message to the IESG From: Blaine Christian To: Jeffrey Haas Message-ID: In-Reply-To: <20050120212505.GE22790@nexthop.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit > Defining the actual protocol level changes to BGP is at best > a cross-functional work item. IMO, most of the work would be done in IDR > and it would be rpsec's responsibility to say "this doesn't do what > we wanted". > Sounds correct to me... >> 2. BGP spec not followed: > > I'll defer this to the other parties and try to stick to specifics since > that fits the ADHD way I'm following this group at the moment. > Haha, you are not the only one... I have no idea why I submit myself to the sort of abuse this type of work entails. >> If so, it is >> my perception that all transitive attributes MUST be protected via the >> security mechanism. > > Must they? That is what the requirement says at this point... > What is to be protected? I believe that all the attributes can be protected with one of the two mechanisms (either a lock down of the BGP session via some signing mechanism or the use of a trust mechanism to ascertain the validity of the information). I still have this gnawing gut feeling that the two should be one and the same (one key per AS). Session security should be all about ensuring the relationship between two BGP peers and prefix/AS security should be all about ensuring the validity of received routes. > What does "protect" mean? Always a good question. Protect against operator idiocy (never). Protect against malicious advertisements or theft of prefix space, hopefully. > > I think these two last questions form the core of our arguments. However, > it is difficult to articulate each of these without delving into solutions. > >> My assumption, and I should be corrected if I am wrong, >> was that MD5/IPSec type mechanisms would be sufficient for attributes that >> are usually non-transitive (communities/localpref etc...). > > Communities are transitive. :-) getting ready to hit Jeff with a mackeral. That is why I said usually... . Most of the big Internet operators drop all communities except for the ones specifically meant for their networks. If the communities are dropped across the Internet operators as a general rule then the attributes are significantly less transitive than things like AS path and NLRI. It could also be said that the ability to advertise less specific blocks pretty much makes the AS Path and NLRI non-transitive as well. However, typically, the aggregator is the owner so the anchor is usually in a place that still makes sense. Regards, Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 20 17:49: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 RAA21870 for ; Thu, 20 Jan 2005 17:49:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrlNC-0007RO-0E for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 18:05:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crl0Z-0003mn-3C; Thu, 20 Jan 2005 17:42:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrkiZ-0006IA-7V for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 17:23: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 RAA18822 for ; Thu, 20 Jan 2005 17:23:52 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrkyJ-0006L5-9J for rpsec@ietf.org; Thu, 20 Jan 2005 17:40:12 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0KMKRiP007146 for ; Thu, 20 Jan 2005 17:20:27 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAASoai9n; Thu, 20 Jan 05 17:20:24 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0KMM3Nt006544; Thu, 20 Jan 2005 17:22:03 -0500 (EST) Date: Thu, 20 Jan 2005 17:22:03 -0500 (EST) From: Sandy Murphy Message-Id: <200501202222.j0KMM3Nt006544@tislabs.com> To: blaine@blaines.net, jhaas@nexthop.com Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 >2. BGP spec not followed: I believe the crux of this discussion is that by >adding additional requirements to the way BGP currently works (to take into >account operational practice) we are improperly specifying the requirements. It's really tough to analyze stuff that's not written down anywhere, even as written in some implementations, and isn't followed the same everywhere. I've been in too many idr and rpsec working groups listening to people contradict each other at the mike to believe that operational practice is anywhere near homogeneous ("no one does this" "hey, wait my whole operation depends on that"). Case in point: recent discussion about deprecating flap dampening or not. Anyone want to take on the task of writing up the current operational practice? Then there's the fact that operational practice changes to cope with operational environment. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 20 17:55:58 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 RAA22433 for ; Thu, 20 Jan 2005 17:55:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrlTO-0007dI-4i for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 18:12:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crl5G-0005Pi-Cy; Thu, 20 Jan 2005 17:47:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crkwu-0002mc-06 for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 17: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 RAA21001 for ; Thu, 20 Jan 2005 17:38:41 -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 1CrlCe-00073q-QC for rpsec@ietf.org; Thu, 20 Jan 2005 17:55:01 -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 j0KMc5DH010232 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Thu, 20 Jan 2005 17:38:06 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 20 Jan 2005 17:37:58 -0500 Subject: Re: [RPSEC] proposed message to the IESG From: Blaine Christian To: Sandy Murphy , Message-ID: In-Reply-To: <200501202222.j0KMM3Nt006544@tislabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit > It's really tough to analyze stuff that's not written down anywhere, > even as written in some implementations, and isn't followed the > same everywhere. You have that right. Just a few years ago implementing vendor X next to vendor Y was quite entertaining. BGP is a bit loose. Of course it is also quite well used and considering it's scope of deployment it is a pretty impressive feat. > > I've been in too many idr and rpsec working groups listening to > people contradict each other at the mike to believe that operational > practice is anywhere near homogeneous ("no one does this" "hey, wait > my whole operation depends on that"). Case in point: recent > discussion about deprecating flap dampening or not. > I could not agree more. BGP has a LOT of wiggle room in it. This must make security oriented folks nuts. I am only into security operationally. However, I have quite a bit of background in the "hey your implementation of BGP broke me" realm. Heck, a lot of times it was our specific manner of implementing BGP that broke people (MED route oscillation due to confederations comes to mind). While we will probably not be able to come up with a complete requirement that solves everything I do firmly believe we can improve the current state of affairs while letting the older implementations age out gracefully. > Anyone want to take on the task of writing up the current operational > practice? I am not biting on that one. I already did one of those on traffic engineering . Funny enough, I actually had an operator approach me after one presentation stating that they want the ability to insert an AS that belongs to another operator into their advertisement in order to block reachability for that AS! > > Then there's the fact that operational practice changes to cope with > operational environment. > That is a very good point. I have talked about this in the past. If a sufficient number of big vendors agree on an implementation they can probably make it happen (unless it is completely nuts). This has happened more times than I can count. The operators will find ways to work around things. However, operators also vote with their money and those who accede to the needs of the operators in the most effective way will win the market and the protocol wars. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 20 18:35:44 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 SAA27525 for ; Thu, 20 Jan 2005 18:35:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crm5t-0000Lf-2T for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 18:52:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crlk5-0006BT-1k; Thu, 20 Jan 2005 18:29:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrljC-000616-ID for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 18:28:38 -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 SAA26677 for ; Thu, 20 Jan 2005 18:28:35 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crlyw-00007E-Ux for rpsec@ietf.org; Thu, 20 Jan 2005 18:44:55 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Jan 2005 18:35:48 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-135.cisco.com [10.82.240.135]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0KNS0oB005774; Thu, 20 Jan 2005 18:28:00 -0500 (EST) Date: Thu, 20 Jan 2005 18:27:20 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: <200501202150.j0KLoH93005887@tislabs.com> Message-ID: References: <200501202150.j0KLoH93005887@tislabs.com> 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: b4a0a5f5992e2a4954405484e7717d8c 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: 92df29fa99cf13e554b84c8374345c17 > I think you mean "convincing" when you say "proof" and you and Steve > aren't agreeing to the same ground rules to convince each other. > > To some people, proofs of security features go something like this: > (a) the spec says things should happen like this > (b) it is possible to make things not happen like this > (c) QED The problem is in this: How do you describe what the specification specifies? -- Is there a concept of an "end to end" thing called an "update," and you're trying to prove "authorization" to readvertise this "update?" -- Are you trying to prove certain things about the information advertised to you by a peer (using an update, with many other pieces of information in it), are "true," in some sense? What are the questions we need to ask about this information? IMHO, just because the BGP specification says "the update is then processed using method x...." doesn't mean an "update" exists as an atomic thing within BGP. > OK, so I'm generalizing a lot. But the core point is that security > relies on assumptions holding. Sometimes those are innate (the IP > address in the source field is the address of where this comes from) and > sometimes it derives from the spec (the spec says that the message I > received is generated when the source received my message, therefore I > can assume that the source received my message). Yes, exactly. IMHO, we should ask what we can prove about a specific piece of information, and require certain things be found true. For instance, saying: "I want to prove this update was received from x, at time y, and hasn't been altered," doesn't answer any real questions. _Why_ do you want to prove those things? What is it you hope to prove by showing this update came from x at time y? If the answer is anything other than: "proving the packet was transported along a certain path at a certain time," then you're not at the requirements stage--you're still at the solutions stage, simply trying to push a solution off as a requirement. When the data is opaque, and the packet is "pushed into a tunnel" on one end, and "pulled out of the tunnel" at the other end, you have end-to-end security. If you're looking for end-to-end security, it might be sufficient to prove every node along the way touched the packet in a certain way. It's a completely different game when everyone along the way can pull the information out, repackage it, and possibly alter it. There's no concept of "end-to-end" in the BGP protocol in this way. Let me also point out that I assert an "update" isn't what I'm interested at all in BGP. I'm interested in a prefix and it's attributes. One of those attributes happens to be the as path, and you can make assertions about that as path. There's no such thing as "the update" in the same sort of context as "the packet" in an IP flow. :-) 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 Thu Jan 20 18:54: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 SAA28848 for ; Thu, 20 Jan 2005 18:54:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrmNr-0000nH-6I for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 19:10:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crm39-0000eT-FV; Thu, 20 Jan 2005 18:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crlyg-0008Js-K1 for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 18:44:38 -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 SAA28359 for ; Thu, 20 Jan 2005 18:44:35 -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 1CrmER-0000Zg-1S for rpsec@ietf.org; Thu, 20 Jan 2005 19:00:56 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A6DD72D4854 for ; Thu, 20 Jan 2005 18:44:01 -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 17480-02-3 for ; Thu, 20 Jan 2005 18:43:57 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C7CE82D4C1A for ; Thu, 20 Jan 2005 18:43:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] proposed message to the IESG Date: Thu, 20 Jan 2005 18:43:49 -0500 Message-ID: Thread-Topic: [RPSEC] proposed message to the IESG Thread-Index: AcT/SM85SowezAlyTuWfmkj13ysyoQAABzyg From: "Susan Hares" To: "Russ White" , "Sandy Murphy" X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Russ: Please confirm that when you mean prefix and attributes associated with that prefix that you do not care about:=20 1) grouping of the prefixes with attributes within a packet, or 2) the order of the prefixes across packets Because I would care if : Announce, withdraw, Announce turned into Announce, Announce, Withdraw Or Announce, Withdraw, Announce turned into Announce, Withdraw, Announce, Withdraw.=20 So this can happen with attacks along the way. I would care. I would care to find out how it was packaged to track how this change occurred.=20 If I could prove these changes were inserted by the White foundation for bad packets -- I would really worry. (You'd have finally gotten me back for all those tons of questions on OSPF). :-)... So, tell me what I misunderstood in your message. I gotta believe I missed something here. Sue -----Original Message----- From: Russ White [mailto:ruwhite@cisco.com]=20 Sent: Thursday, January 20, 2005 6:27 PM To: Sandy Murphy Cc: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG > I think you mean "convincing" when you say "proof" and you and Steve=20 > aren't agreeing to the same ground rules to convince each other. > > To some people, proofs of security features go something like this: > (a) the spec says things should happen like this > (b) it is possible to make things not happen like this > (c) QED The problem is in this: How do you describe what the specification=20 specifies? -- Is there a concept of an "end to end" thing called an "update," and=20 you're trying to prove "authorization" to readvertise this "update?" -- Are you trying to prove certain things about the information advertised=20 to you by a peer (using an update, with many other pieces of information in=20 it), are "true," in some sense? What are the questions we need to ask about=20 this information? IMHO, just because the BGP specification says "the update is then processed=20 using method x...." doesn't mean an "update" exists as an atomic thing=20 within BGP. > OK, so I'm generalizing a lot. But the core point is that security=20 > relies on assumptions holding. Sometimes those are innate (the IP=20 > address in the source field is the address of where this comes from) and=20 > sometimes it derives from the spec (the spec says that the message I=20 > received is generated when the source received my message, therefore I > can assume that the source received my message). Yes, exactly. IMHO, we should ask what we can prove about a specific piece=20 of information, and require certain things be found true. For instance,=20 saying: "I want to prove this update was received from x, at time y, and hasn't been altered," doesn't answer any real questions. _Why_ do you want=20 to prove those things? What is it you hope to prove by showing this update=20 came from x at time y? If the answer is anything other than: "proving the packet was transported=20 along a certain path at a certain time," then you're not at the=20 requirements stage--you're still at the solutions stage, simply trying to=20 push a solution off as a requirement. When the data is opaque, and the packet is "pushed into a tunnel" on one end, and "pulled out of the tunnel" at the other end, you have end-to-end=20 security. If you're looking for end-to-end security, it might be sufficient=20 to prove every node along the way touched the packet in a certain way. It's a completely different game when everyone along the way can pull the=20 information out, repackage it, and possibly alter it. There's no concept of=20 "end-to-end" in the BGP protocol in this way. Let me also point out that I assert an "update" isn't what I'm interested=20 at all in BGP. I'm interested in a prefix and it's attributes. One of those=20 attributes happens to be the as path, and you can make assertions about=20 that as path. There's no such thing as "the update" in the same sort of=20 context as "the packet" in an IP flow. :-) 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 Thu Jan 20 18:55: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 SAA28924 for ; Thu, 20 Jan 2005 18:55:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrmOx-0000oy-IK for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 19:11:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crm39-0000eY-TU; Thu, 20 Jan 2005 18:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crlzk-0008UH-BP for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 18:45: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 SAA28411 for ; Thu, 20 Jan 2005 18:45:41 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrmFU-0000bO-AP for rpsec@ietf.org; Thu, 20 Jan 2005 19:02:02 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 Jan 2005 18:52:56 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-135.cisco.com [10.82.240.135]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0KNj5W1008460; Thu, 20 Jan 2005 18:45:06 -0500 (EST) Date: Thu, 20 Jan 2005 18:44:25 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: <200501202222.j0KMM3Nt006544@tislabs.com> Message-ID: References: <200501202222.j0KMM3Nt006544@tislabs.com> 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: 21c69d3cfc2dd19218717dbe1d974352 Cc: rpsec@ietf.org, jhaas@nexthop.com, kent@bbn.com 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: 50a516d93fd399dc60588708fd9a3002 IMHO, any security system not flexible enough to change with operational changes isn't really that good of a security system. :-) >> 2. BGP spec not followed: I believe the crux of this discussion is that >> by adding additional requirements to the way BGP currently works (to >> take into account operational practice) we are improperly specifying the >> requirements. > > It's really tough to analyze stuff that's not written down anywhere, even > as written in some implementations, and isn't followed the same > everywhere. There are some general things we can surmize that I don't think _need_ to be written down. These assumptions should, probably, be in the draft, and they probably aren't there today, but they aren't much that anyone would contest. -- Address allocation is generally done by some controlling authority, but is then distributed to sub-authorities. For political reasons, we can't always expect the chain of authorization to be "friendly." In other words, you can't always expect the allocator and the allocatee (??) to be on any more than formal contractural terms, and that it will often cost money to get more services. -- Overlapping address spaces exist. Filtering of routing information is commone practice. Any others? > I've been in too many idr and rpsec working groups listening to people > contradict each other at the mike to believe that operational practice is > anywhere near homogeneous ("no one does this" "hey, wait my whole > operation depends on that"). Case in point: recent discussion about > deprecating flap dampening or not. Goodness, I hope no-one deprecates dampening! :-) 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 Thu Jan 20 19:11: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 TAA00379 for ; Thu, 20 Jan 2005 19:11:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crme2-0001BX-Du for rpsec-web-archive@ietf.org; Thu, 20 Jan 2005 19:27:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrmIE-00034e-VV; Thu, 20 Jan 2005 19:04:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrmDS-0002LH-Fs for rpsec@megatron.ietf.org; Thu, 20 Jan 2005 18:59: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 SAA29252 for ; Thu, 20 Jan 2005 18:59:51 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrmTD-0000uP-IW for rpsec@ietf.org; Thu, 20 Jan 2005 19:16:12 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 20 Jan 2005 19:07:08 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-135.cisco.com [10.82.240.135]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0KNxHoB011268; Thu, 20 Jan 2005 18:59:18 -0500 (EST) Date: Thu, 20 Jan 2005 18:58:39 -0500 (Eastern Standard Time) From: Russ White To: Susan Hares Subject: RE: [RPSEC] proposed message to the IESG 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: 82c9bddb247d9ba4471160a9a865a5f3 Cc: rpsec@ietf.org, Sandy Murphy 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: 02ec665d00de228c50c93ed6b5e4fc1a > Please confirm that when you mean prefix and attributes associated with > that prefix that you do not care about: > > 1) grouping of the prefixes with attributes within a packet, or > 2) the order of the prefixes across packets The grouping of the prefixes with the attributes. How these are placed inside packets is of no concern to anyone that I can think of. > Because I would care if : > > Announce, withdraw, Announce turned into > Announce, Announce, Withdraw > > Or > Announce, Withdraw, Announce turned into > Announce, Withdraw, Announce, Withdraw. It's actually quite interesting you would use withdraws as an illustration. Let's say I have this: 10.1.1.0/24----A----B---C---D | | +--------+ Now, let's assume C is using the path through B to reach 10.1.1.0/24, but also has the path through A. When A->B fails, what happens? -- B sends a withdraw for 10.1.1.0/24 to C. -- C examines its local table, and finds the althernate path via A. -- C sends an update to D stating the AS Path has changed from {A,B,C} to {A}. Notice what's missing? D never got B's withdraw. D implies that C is withdrawing the first route, because it sent the second, and BGP can only send one path to an eBGP peer. Again, there's no such thing as "the update" or "the withdraw" in BGP. What I care about is that the final state of the database on a BGP speaker matches reality. > So, tell me what I misunderstood in your message. I gotta believe I > missed something here. No, I just think you're having a hard time with the non end-to-end nature of this system. BGP is explicitely designed to transfer information. The actual format in which the information is transferred is intentionally loose, to allow modifications to the protocol, and to allow accrued efficiencies in implementations and throughout the system. :-) 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 Fri Jan 21 02:35: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 CAA14216 for ; Fri, 21 Jan 2005 02:35:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrtaL-0002aa-84 for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 02:52:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrtG4-0004fr-Up; Fri, 21 Jan 2005 02:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrtBj-0003Ir-Hl for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 02:26: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 CAA12689 for ; Fri, 21 Jan 2005 02:26:33 -0500 (EST) Received: from [193.230.140.1] (helo=ns.bancpost.ro) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrtRY-0002JR-Ci for rpsec@ietf.org; Fri, 21 Jan 2005 02:42:56 -0500 Received: from BUCIT01EXC01.BPTRO.INTR ([193.230.140.29]) by ns.bancpost.ro with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Jan 2005 09:39:59 +0200 Received: from BUCIT01EXC00.BPTRO.INTR ([10.96.32.66]) by BUCIT01EXC01.BPTRO.INTR with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Jan 2005 09:24:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [RPSEC] proposed message to the IESG Date: Fri, 21 Jan 2005 09:26:39 +0200 Message-ID: <8AAF0B029459BC4185E7326E3290F6634AB00B@BUCIT01EXC00.BPTRO.INTR> Thread-Topic: [RPSEC] proposed message to the IESG Thread-Index: AcT/TZxhNd+1Zb++QbuN2KGlW927eAAOvx3Q From: "Manaila, Florin" To: "Russ White" X-OriginalArrivalTime: 21 Jan 2005 07:24:35.0252 (UTC) FILETIME=[4215EF40:01C4FF8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org 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: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Hi all, I have to agree with Russ, when is saying that "BGP is explicitely designed to transfer information". So, in this way we have to work to secure the "transport layer" not the information witch BGP is transfer. Regarding, the authenticity of the information passed through the BGP, YES we should care also by this, but I think that this is a different side of the "BGP security". I believe that if we will try to combine this 2 parts we will have many delays before to take some conclusions. Best regards, Florin=20 -----Original Message----- From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] On Behalf Of Russ White Sent: Friday, January 21, 2005 1:59 AM To: Susan Hares Cc: rpsec@ietf.org; Sandy Murphy Subject: RE: [RPSEC] proposed message to the IESG > Please confirm that when you mean prefix and attributes associated=20 > with that prefix that you do not care about: > > 1) grouping of the prefixes with attributes within a packet, or > 2) the order of the prefixes across packets The grouping of the prefixes with the attributes. How these are placed inside packets is of no concern to anyone that I can think of. > Because I would care if : > > Announce, withdraw, Announce turned into Announce, Announce, Withdraw > > Or > Announce, Withdraw, Announce turned into Announce, Withdraw, Announce, > Withdraw. It's actually quite interesting you would use withdraws as an illustration.=20 Let's say I have this: 10.1.1.0/24----A----B---C---D | | +--------+ Now, let's assume C is using the path through B to reach 10.1.1.0/24, but also has the path through A. When A->B fails, what happens? -- B sends a withdraw for 10.1.1.0/24 to C. -- C examines its local table, and finds the althernate path via A. -- C sends an update to D stating the AS Path has changed from {A,B,C} to {A}. Notice what's missing? D never got B's withdraw. D implies that C is withdrawing the first route, because it sent the second, and BGP can only send one path to an eBGP peer. Again, there's no such thing as "the update"=20 or "the withdraw" in BGP. What I care about is that the final state of the database on a BGP speaker matches reality. > So, tell me what I misunderstood in your message. I gotta believe I=20 > missed something here. No, I just think you're having a hard time with the non end-to-end nature of this system. BGP is explicitely designed to transfer information. The actual format in which the information is transferred is intentionally loose, to allow modifications to the protocol, and to allow accrued efficiencies in implementations and throughout the system. :-) 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 Fri Jan 21 10:25: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 KAA19288 for ; Fri, 21 Jan 2005 10:25:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs0uf-0006is-Ei for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 10:41:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0WP-0004xU-AC; Fri, 21 Jan 2005 10:16:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0P1-0001Qj-Jz for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 10:08: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 KAA17213 for ; Fri, 21 Jan 2005 10:08:45 -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 1Cs0eu-00067M-16 for rpsec@ietf.org; Fri, 21 Jan 2005 10:25:13 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id BEB6D2D4A17; Fri, 21 Jan 2005 10:08:09 -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 86332-04-82; Fri, 21 Jan 2005 10:08:08 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7D6B52D49D4; Fri, 21 Jan 2005 10:08:08 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0LF88625966; Fri, 21 Jan 2005 10:08:08 -0500 (EST) Date: Fri, 21 Jan 2005 10:08:08 -0500 From: Jeffrey Haas To: Tony Tauber Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050121150808.GA25920@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: 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 Tony, On Thu, Jan 20, 2005 at 04:54:06PM -0500, Tony Tauber wrote: > Operators want to secure inter-domain routing, not necessarily BGP. We may have a procedural issue here. I agree that securing inter-domain routing is a good goal. That goal says more than securing BGP, particularly in the sense that we care about securing operational practices beyond just the security of the BGP-4 protocol. However, what we have for inter-domain routing is BGP-4. We should be very careful to not try to be overly broad in our goals. One consequence of being overly broad is to say "we don't care about BGP" and to consider a completely new protocol. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 10:36: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 KAA20334 for ; Fri, 21 Jan 2005 10:36:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs15T-0006zy-K0 for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 10:52:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0kV-0002RU-Cu; Fri, 21 Jan 2005 10:30:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0ZA-0006FS-UU for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 10:19: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 KAA18664 for ; Fri, 21 Jan 2005 10:19:14 -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 1Cs0p4-0006Xo-Gw for rpsec@ietf.org; Fri, 21 Jan 2005 10:35:42 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 513492D4BCC; Fri, 21 Jan 2005 10:18:45 -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 87979-01-9; Fri, 21 Jan 2005 10:18:44 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 267792D4B40; Fri, 21 Jan 2005 10:18:44 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0LFIhX26002; Fri, 21 Jan 2005 10:18:44 -0500 (EST) Date: Fri, 21 Jan 2005 10:18:43 -0500 From: Jeffrey Haas To: Blaine Christian Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050121151843.GB25920@nexthop.com> References: <20050120212505.GE22790@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: 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 Blaine, On Thu, Jan 20, 2005 at 05:01:23PM -0500, Blaine Christian wrote: > > What is to be protected? > > I believe that all the attributes can be protected with one of the two > mechanisms (either a lock down of the BGP session via some signing mechanism > or the use of a trust mechanism to ascertain the validity of the > information). I still have this gnawing gut feeling that the two should be > one and the same (one key per AS). Session security should be all about > ensuring the relationship between two BGP peers and prefix/AS security > should be all about ensuring the validity of received routes. To pick this example, were I to want to make implementation choices for protecting a session, I'd probably use some private key cryptographic mechanism. For transitive attributes, I'd probably want something public key. Those are details we shouldn't get bogged down on. Far more important is identifying the components of information that we're trying to secure and what we mean by securing them and what securing them will actually accomplish. This will suggest solutions and also our cost benefit tradeoffs. > > Communities are transitive. :-) > > getting ready to hit Jeff with a mackeral. That is why I said > usually... . I was intentionally (ahem) baiting you. Part of the point here is that while many of us are aware that communities are operationally sanitized, sometimes to the excess of "drop everything at the border that's not mine", this represents practice. This doesn't represent what the BGP protocol is capable of. By a slightly better example, extended communities are also transitive. However, data inside of them are intentionally non-transitive when the extended community mechanism is understood by the BGP speaker. Security implication: Whose behavior do you enforce? Transitive or non-transitive - path attribute transitivity or path attribute semantic transitivity? One of the challenges of securing things at the protocol level vs. the operational level is that if we take the most restrictive path, we potentially take protocol-valid things people do and remove them as options. In essence our question is, "Do we wish to change existing protocol semantics?" Arguments can be made either direction. > Blaine -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 10:38: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 KAA20495 for ; Fri, 21 Jan 2005 10:38:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs185-00074N-Dn for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 10:55:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0nq-00036F-9W; Fri, 21 Jan 2005 10:34:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0cN-0007bm-68 for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 10:22: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 KAA19042 for ; Fri, 21 Jan 2005 10:22:33 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs0sD-0006eh-RI for rpsec@ietf.org; Fri, 21 Jan 2005 10:39:01 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LFItam000663 for ; Fri, 21 Jan 2005 10:18:55 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAA7aqrb; Fri, 21 Jan 05 10:18:51 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LFKb0d007399; Fri, 21 Jan 2005 10:20:37 -0500 (EST) Date: Fri, 21 Jan 2005 10:20:37 -0500 (EST) From: Sandy Murphy Message-Id: <200501211520.j0LFKb0d007399@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 >>Case in point: recent discussion about >> deprecating flap dampening or not. > >Goodness, I hope no-one deprecates dampening! > See energetic thread early November on idr mailing list "Future of route flap dampening spec", including early comments "Is there something we want to do with the route flap dampening spec? Move to DS, deprecate, spin in place, ...?" "Move to historic and publish "flap damping considered harmful" RFC" The conversation eventually died down, with no announced consensus that I could see. And I've seen several presentations, like at NANOG, that covered the problems you can get into with flap dampening. No opinion myself, you understand, just pointing out the lack of operational homogeneity. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 10:41: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 KAA20625 for ; Fri, 21 Jan 2005 10:41:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1AO-00077h-LM for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 10:57:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0oo-0003Jx-Up; Fri, 21 Jan 2005 10:35:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0fK-0000Fk-JA for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 10:25: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 KAA19355 for ; Fri, 21 Jan 2005 10:25:36 -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 1Cs0vE-0006ix-TC for rpsec@ietf.org; Fri, 21 Jan 2005 10:42:05 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A48CD2D4935; Fri, 21 Jan 2005 10:25: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 88240-01-23; Fri, 21 Jan 2005 10:25:05 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 85F652D4830; Fri, 21 Jan 2005 10:25:05 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0LFP1L26032; Fri, 21 Jan 2005 10:25:01 -0500 (EST) Date: Fri, 21 Jan 2005 10:25:01 -0500 From: Jeffrey Haas To: "Manaila, Florin" Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050121152501.GC25920@nexthop.com> References: <8AAF0B029459BC4185E7326E3290F6634AB00B@BUCIT01EXC00.BPTRO.INTR> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8AAF0B029459BC4185E7326E3290F6634AB00B@BUCIT01EXC00.BPTRO.INTR> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Florin, On Fri, Jan 21, 2005 at 09:26:39AM +0200, Manaila, Florin wrote: > So, in this way we have to work to secure the "transport layer" not the > information witch BGP is transfer. In what way do you think that neither TCP+MD5 nor IP Sec covers this particular issue? -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 10:52: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 KAA21344 for ; Fri, 21 Jan 2005 10:52:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1Ks-0007RG-7O for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 11:08:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0z2-0005by-Ua; Fri, 21 Jan 2005 10:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs0w4-0004tj-CD for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 10:42: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 KAA20708 for ; Fri, 21 Jan 2005 10:42:54 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1Bx-0007A5-Po for rpsec@ietf.org; Fri, 21 Jan 2005 10:59:23 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LFdS4o002533 for ; Fri, 21 Jan 2005 10:39:28 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZbay8e; Fri, 21 Jan 05 10:39:25 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LFfBJg007970; Fri, 21 Jan 2005 10:41:11 -0500 (EST) Date: Fri, 21 Jan 2005 10:41:11 -0500 (EST) From: Sandy Murphy Message-Id: <200501211541.j0LFfBJg007970@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 >-- Overlapping address spaces exist. I don't know what you mean by this. I get the mental image of the same address being used by two hosts, but surely that's not what's meant, so I'm guessing you mean that authorization for the same address space can overlap - that is, two organizations can be allocated the same address space. BTW, if that's what you meant, then I'd say this is not a security problem, as long as there's a hierarchy involved in the overlap. It would be a problem if A was allocated some addressees and then allocated a subset to B and the same subset to C. I presume (you can correct me) that this is not viewed kindly, even in the twisty world of ISP business arrangements :-). Security authorizations aren't like resource allocations. If you delegate to someone you don't give up the right yourself. It doesn't work like memory allocations, where if you give part of your memory allocation to a subprocess you give up the right to use it yourself. It works like read permissions - if you give someone the right to read a file you can read, you don't lose the ability to read it yourself. So sub-address block allocations (if that's what you meant) don't cause a problem in checking authorization to advertise the block you're allocated. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 11:25:41 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 LAA24136 for ; Fri, 21 Jan 2005 11:25:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1rN-000066-Le for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 11:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1T4-0004HO-9d; Fri, 21 Jan 2005 11:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1Ma-0002We-C4 for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 11:10: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 LAA23147 for ; Fri, 21 Jan 2005 11:10:18 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1cU-00085P-Kt for rpsec@ietf.org; Fri, 21 Jan 2005 11:26:47 -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 j0LG9Njf008436; Fri, 21 Jan 2005 11:09:24 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 21 Jan 2005 10:54:08 -0500 To: Blaine Christian From: Stephen Kent Subject: Re: [RPSEC] proposed message to the IESG X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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="===============1912012793==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 --===============1912012793== Content-Type: multipart/alternative; boundary="============_-1105798743==_ma============" --============_-1105798743==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 11:10 AM -0500 1/20/05, Blaine Christian wrote: >Hello Steve, > >I am concerned about your assertion that the draft does not follow the BGP >spec. I have avoided stepping into the fray with you and Russ going at it. >But can you clarify, for me, exactly what parts of the BGP spec are being >ignored or changed in this draft? I have been working with BGP for many >years and I could not find a spot where the document did not match reality >or the needs of the operators. > >This document is intended to present a set of requirements from the operator >community to the folks creating the standards (which is why it is tracking >towards informational). > >Regards, > >Blaine Blaine, I did no say that the current draft of the security requirements document does not follow the BGP spec. I will send a separate message addressing that issue, later. What said is that we are at an impasse re what to use as a basis for the requirements. I say this based on the extended discussions on the list with Russ, in which he said, repeatedly, that using the BGP spec as the primary basis for the requirements document is inappropriate. Russ began making these comments in late December, when I responded to his comments on the current draft. (In fact, I never managed to get around to commenting on the draft itself, because of all the time spent arguing wit Russ over his and my suggested changes!) I proposed text in a message on 12/28/04 that I thought was appropriate for the draft, and I explained why, i.e., because it was traceable to the BGP spec. That triggered an intense discussion on the list (between Russ and me) that lasted for over a week. If we agree that the BGP spec is the starting point for security requirements, then we have an objective basis for deciding whether proposed text is appropriate or not. That is why I have pursued this issue. On 1/5 I sent a message that contained a lot of excerpts from the BGP spec in support of the text that I had provided, citing specific parts of the spec as a suitable basis for the security requirements. In response, on 1/6/05 Russ sent a message that ended with the comment: You can point out all sorts of phrases and comments in the draft, but you have to temper these statements with the actual operation of BGP in the real world, with real address ownership concepts, real aggregation, and real route origination policies. This sounds like a statement that Russ does not feel that the BGP spec provides a suitable basis for developing the security requirements. I another message on 1/6/05 Russ also said: And at some point, the WG has to decide which of these two models is valid. I believe that I've made a strong case to consider the operational use as a valid model, because of gaps in the alternative model. Russ was commenting on the following text in my message: >We both have prejudices in approaching this problem. One can fairly >say that I used the BGP spec as the basis for developing the >security requirements model that we then addressed with S-BGP. >Likewise, you adopted an operations-oriented view of security when >you developed soBGP. That does not make either approach >intrinsically valid or invalid. I think this is a pretty clear statement by Russ that he believes that an operational model, rather than the BGP spec, is the right basis for the requirements. In another message later that day, Russ reiterated this notion saying: Regardless of your attempts at striking at me personally, Steve, I don't see how you can get around building a set of requirements based on what exists, rather than the BGP specification, which is only part of the way things really work. The phrase "rather than the BGP specification" again seems to indicate a fairly strong bias against using the BGP spec as the primary basis for the security requirements. With regard to your question of whether BGP as deployed matches the spec, I note the following comment in a message from Iljitsch on 1/6/05. We were discussing what forms of aggregation are permitted by the BGP spec and he said: Now all of this non-RFC-compliant aggregation works without any problems because of the longest match first rule. This is a pretty direct statement calling into question congruence between the BGP spec and operational practice. Finally, you close with "This document is intended to present a set of requirements from the operator community to the folks creating the standards ..." I have to admit that I do not recall hearing that characterization of the goal for this document. The WG charter does not convey the notion that this document is to represent the operator view of security requirements for BGP. Your description of the context for developing the document is consistent with the concerns I expressed, i.e., an operational vs. protocol spec based perspective. I'd like to hear from both WG chairs with regard to whether the document is supposed to have this orientation, i.e., that it is supposed to be an operationally-oriented view of security requirements for BGP. If the context is what you suggest, I think my question to the IESG seems very much relevant. The WG charter makes no mention of an operational bias in developing routing security requirements. Steve --============_-1105798743==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] proposed message to the IESG
At 11:10 AM -0500 1/20/05, Blaine Christian wrote:
Hello Steve,

I am concerned about your assertion that the draft does not follow the BGP
spec.  I have avoided stepping into the fray with you and Russ going at it.
But can you clarify, for me, exactly what parts of the BGP spec are being
ignored or changed in this draft?  I have been working with BGP for many
years and I could not find a spot where the document did not match reality
or the needs of the operators.

This document is intended to present a set of requirements from the operator
community to the folks creating the standards (which is why it is tracking
towards informational).

Regards,
Blaine

Blaine,

I did no say that the current draft of the security requirements document does not follow the BGP spec. I will send a separate message addressing that issue, later.

What  said is that we are at an impasse re what to use as a basis for the requirements. I say this based on the extended discussions on the list with Russ, in which he said, repeatedly, that using the BGP spec as the primary basis for the requirements document is inappropriate.

Russ began making these comments in late December, when I responded to his comments on the current draft. (In fact, I never managed to get around to commenting on the draft itself, because of all the time spent arguing wit Russ over his and my suggested changes!) I proposed text in a message on 12/28/04 that I thought was appropriate for the draft, and I explained why, i.e., because it was traceable to the BGP spec. That triggered an intense discussion on the list (between Russ and me) that lasted for over a week.

If we agree that the BGP spec is the starting point for security requirements, then we have an objective basis for deciding whether proposed text is appropriate or not. That is why I have pursued this issue.

On 1/5 I sent a message that contained a lot of excerpts from the BGP spec in support of the text that I had provided, citing specific parts of the spec as a suitable basis for the security requirements.  In response, on 1/6/05 Russ sent a message that ended with the comment:

You can point out all sorts of phrases and comments in the draft, but you have to temper these statements with the actual operation of BGP in the real world, with real address ownership concepts, real aggregation, and real route origination policies.

This sounds like a statement that Russ does not feel that the BGP spec provides a suitable basis for developing the security requirements.

I another message on 1/6/05 Russ also said:

And at some point, the WG has to decide which of these two models is valid. I believe that I've made a strong case to consider the operational use as a valid model, because of gaps in the alternative model.

Russ was commenting on the following text in my message:

We both have prejudices in approaching this problem.  One can fairly say that I used the BGP spec as the basis for developing the security requirements model that we then addressed with S-BGP. Likewise, you adopted an operations-oriented view of security when you developed soBGP. That does not make either approach intrinsically valid or invalid.

I think this is a pretty clear statement by Russ that he believes that an operational model, rather than the BGP spec, is the right basis for the requirements.

In another message later that day, Russ reiterated this notion saying:

Regardless of your attempts at striking at me personally, Steve, I don't see how you can get around building a set of requirements based on what exists, rather than the BGP specification, which is only part of the way things really work.

The phrase "rather than the BGP specification" again seems to indicate a fairly strong bias against using the BGP spec as the primary basis for the security requirements.


With regard to your question of whether BGP as deployed matches the spec, I note the following comment in a message from Iljitsch on 1/6/05. We were discussing what forms of aggregation are permitted by the BGP spec and he said:

Now all of this non-RFC-compliant aggregation works without any problems because of the longest match first rule.

This is a pretty direct statement calling into question congruence between the BGP spec and operational practice.

Finally, you close with "This document is intended to present a set of requirements from the operator community to the folks creating the standards ..."  I have to admit that I do not recall hearing that characterization of the goal for this document. The WG charter does not convey the notion that this document is to represent the operator view of security requirements for BGP. Your description of the context for developing the document is consistent with the concerns I expressed, i.e., an operational vs. protocol spec based perspective.

I'd like to hear from both WG chairs with regard to whether the document is supposed to have this orientation, i.e., that it is supposed to be an operationally-oriented view of security requirements for BGP. If the context is what you suggest, I think my question to the IESG seems very much relevant. The WG charter makes no mention of an operational bias in developing routing security requirements.

Steve
--============_-1105798743==_ma============-- --===============1912012793== 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 --===============1912012793==-- From rpsec-bounces@ietf.org Fri Jan 21 11:26: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 LAA24178 for ; Fri, 21 Jan 2005 11:26:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1rm-00006j-BV for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 11:42:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1T5-0004I6-26; Fri, 21 Jan 2005 11:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1NH-0002k6-Ld for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 11:11: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 LAA23207 for ; Fri, 21 Jan 2005 11:11:01 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1dB-000863-V5 for rpsec@ietf.org; Fri, 21 Jan 2005 11:27:30 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0LG9Njh008436; Fri, 21 Jan 2005 11:09:25 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 21 Jan 2005 11:09:05 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] proposed message to the IESG X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae 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="===============0478708680==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 --===============0478708680== Content-Type: multipart/alternative; boundary="============_-1105798741==_ma============" --============_-1105798741==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:00 PM -0500 1/20/05, Russ White wrote: >>In contrast, Russ White, a co-chair of the WG and a contributor to >>this RPSEC document, has asserted that operational experience >>should be the primary driver for the requirements document. Russ >>has stated that the BGP spec cited above does not accurately >>reflect BGP implementation and deployment patterns, and thus is not >>a suitable basis for the security requirements document that the WG >>is slated to develop. > >Rephrase this to: > >Russ White.... believes the specifications requirement should be >based on an analysis of what is provable within an internetwork >using BGP as its routing protocol, rather than the proving the >processes within the BGP specification have been followed, >specifically. In one of your messages on 1/6 you said: And at some point, the WG has to decide which of these two models is valid. I believe that I've made a strong case to consider the operational use as a valid model, because of gaps in the alternative model. This was in response to my comment: >We both have prejudices in approaching this problem. One can fairly >say that I used the BGP spec as the basis for developing the >security requirements model that we then addressed with S-BGP. >Likewise, you adopted an operations-oriented view of security when >you developed soBGP. That does not make either approach >intrinsically valid or invalid. So, based on your comment above, my wording of the fundamental issue seems accurate. >I don't claim the BGP spec is wrong, just that the important >questions aren't about process, but how the information in the >system matches reality. You and I have argued over whether the path in an UPDATE is representative of the path via which the UPDATE was transmitted. You said no, yet the spec says yes, as I pointed out. This seems like a clear example where you believe that the way BGP works does not match the spec. Also, a message from Iljitsch on 1/6/05 includes the comment: Now all of this non-RFC-compliant aggregation works without any problems because of the longest match first rule. We have discussed whether aggregation is performed as specified in the spec, e.g., with regard to use of the ATOMIC AGGREGATE attribute. I asked colleague to analyze UPDATEs from RV, for all of 2004, and I reported the results in a message earlier this week. It shows that about 6% or all UPDATEs contain this attribute. Yet have received messages from folks who say that this attribute is almost certainly being used in a non-conformant fashion today. I can revise the text to say that you and others have questioned whether the BGP spec matches the way BGP is used in practice. >>Russ has stated that many of these do not reflect BGP >>implementation and deployment, hence his insistence on a different >>basis for requirements development. I have objected because Russ >>has not been able to cite IETF-approved documents that describe the >>basis he supports. > >See above. It's not a matter of citing other specifications. Many of >the things which need to be secured are outside IETF specifications >to begin with. For instance, the authorization to advertise a >specific block of addresses is completely outside the BGP >specification, since the BGP specification doesn't cover such things >as how to get an address block, etc. And yet, I think we all agree >that this is a critical requirement. so, the simple form of your response is that there are no IETF standards for what you feel are critical aspects of what needs to be considered re BGP security. Sounds like what I said. > >-- > >>It seems inappropriate for the IETF to adopt a BGP security >>requirements document that employs rationale that conflicts with >>the BGP spec, especially when both are developed in the same area. > >Could you please cite a specific instance where the requirements >document actually contradicts the BGP specification? The question is not whether the security requirements contradict the BGP spec, but whether the rationale for most of the requirements derives from the BGP spec. A security requirement can be stated that neither conforms to the spec nor contradicts it, but that does not make it an appropriate requirement. Unless we agree on the basis for the requirements, we can't objectively decide which ones are reasonable and which are not. That is the argument we are having, and the one that needs to be resolved before we can make progress. Steve --============_-1105798741==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] proposed message to the IESG
At 2:00 PM -0500 1/20/05, Russ White wrote:
In contrast, Russ White, a co-chair of the WG and a contributor to this RPSEC document, has asserted that operational experience should be the primary driver for the requirements document. Russ has stated that the BGP spec cited above does not accurately reflect BGP implementation and deployment patterns, and thus is not a suitable basis for the security requirements document that the WG is slated to develop.

Rephrase this to:
Russ White.... believes the specifications requirement should be based on an analysis of what is provable within an internetwork using BGP as its routing protocol, rather than the proving the processes within the BGP specification have been followed, specifically.

In one of your messages on 1/6 you said:

And at some point, the WG has to decide which of these two models is valid. I believe that I've made a strong case to consider the operational use as a valid model, because of gaps in the alternative model.

This was in response to my comment:

We both have prejudices in approaching this problem.  One can fairly say that I used the BGP spec as the basis for developing the security requirements model that we then addressed with S-BGP. Likewise, you adopted an operations-oriented view of security when you developed soBGP. That does not make either approach intrinsically valid or invalid.

So, based on your comment above, my wording of the fundamental issue seems accurate.


I don't claim the BGP spec is wrong, just that the important questions aren't about process, but how the information in the system matches reality.


You and I have argued over whether the path in an UPDATE is representative of the path via which the UPDATE was transmitted. You said no, yet the spec says yes, as I pointed out. This seems like a clear example where you believe that the way BGP works does not match the spec.

Also, a message from Iljitsch on 1/6/05 includes the comment:

Now all of this non-RFC-compliant aggregation works without any problems because of the longest match first rule.

We have discussed whether aggregation is performed as specified in the spec, e.g., with regard to use of the ATOMIC AGGREGATE attribute. I asked colleague to analyze UPDATEs from RV, for all of 2004, and I reported the results in a message earlier this week. It shows that about 6% or all UPDATEs contain this attribute.  Yet have received messages from folks who say that this attribute is almost certainly being used in a non-conformant fashion today.

I can revise the text to say that you and others have questioned whether the BGP spec matches the way BGP is used in practice.

Russ has stated that many of these do not reflect BGP implementation and deployment, hence his insistence on a different basis for requirements development. I have objected because Russ has not been able to cite IETF-approved documents that describe the basis he supports.

See above. It's not a matter of citing other specifications. Many of the things which need to be secured are outside IETF specifications to begin with. For instance, the authorization to advertise a specific block of addresses is completely outside the BGP specification, since the BGP specification doesn't cover such things as how to get an address block, etc. And yet, I think we all agree that this is a critical requirement.

so, the simple form of your response is that there are no IETF standards for what you feel are critical aspects of what needs to be considered re BGP security. Sounds like what I said.


--
It seems inappropriate for the IETF to adopt a BGP security requirements document that employs rationale that conflicts with the BGP spec, especially when both are developed in the same area.

Could you please cite a specific instance where the requirements document actually contradicts the BGP specification?

The question is not whether the security requirements contradict the BGP spec, but whether the rationale for most of the requirements derives from the BGP spec. A security requirement can be stated that neither conforms to the spec nor contradicts it, but that does not make it an appropriate requirement. Unless we agree on the basis for the requirements, we can't objectively decide which ones are reasonable and which are not. That is the argument we are having, and the one that needs to be resolved before we can make progress.

Steve
--============_-1105798741==_ma============-- --===============0478708680== 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 --===============0478708680==-- From rpsec-bounces@ietf.org Fri Jan 21 11: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 LAA25752 for ; Fri, 21 Jan 2005 11:43:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs28m-0000h9-8U for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:00:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1lL-0000dS-GS; Fri, 21 Jan 2005 11:35:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1UF-0004U1-4P for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 11:18: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 LAA23685 for ; Fri, 21 Jan 2005 11:18:12 -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 1Cs1k8-0008Jk-OO for rpsec@ietf.org; Fri, 21 Jan 2005 11:34:42 -0500 Received: from [10.254.254.11] ([10.254.254.11]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j0LGHSDH021807 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 21 Jan 2005 11:17:37 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 21 Jan 2005 11:13:54 -0500 Subject: Re: [RPSEC] proposed message to the IESG From: Blaine Christian To: Sandy Murphy , Message-ID: In-Reply-To: <200501211541.j0LFfBJg007970@tislabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit I can give you one! Anycast for DNS... Anycast is very cool... But everyone uses the same prefix. On 1/21/05 10:41 AM, "Sandy Murphy" wrote: >> -- Overlapping address spaces exist. > > I don't know what you mean by this. I get the mental image of the > same address being used by two hosts, but surely that's not what's > meant, so I'm guessing you mean that authorization for the same > address space can overlap - that is, two organizations can be > allocated the same address space. > > BTW, if that's what you meant, then I'd say this is not a security > problem, as long as there's a hierarchy involved in the overlap. > It would be a problem if A was allocated some addressees and then > allocated a subset to B and the same subset to C. I presume (you > can correct me) that this is not viewed kindly, even in the > twisty world of ISP business arrangements :-). > > Security authorizations aren't like resource allocations. If you > delegate to someone you don't give up the right yourself. It > doesn't work like memory allocations, where if you give part of > your memory allocation to a subprocess you give up the right to > use it yourself. It works like read permissions - if you give > someone the right to read a file you can read, you don't lose > the ability to read it yourself. > > So sub-address block allocations (if that's what you meant) > don't cause a problem in checking authorization to advertise > the block you're allocated. > > --Sandy > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 11:47:44 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 LAA26082 for ; Fri, 21 Jan 2005 11:47:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2Cj-0000pL-3g for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:04:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1ly-0000ox-66; Fri, 21 Jan 2005 11:36:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1f8-0007DU-BP for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 11:29: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 LAA24608 for ; Fri, 21 Jan 2005 11:29:28 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs1v2-0000EE-5u for rpsec@ietf.org; Fri, 21 Jan 2005 11:45:57 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LGQ1pv007807 for ; Fri, 21 Jan 2005 11:26:01 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAIaaqpp; Fri, 21 Jan 05 11:25:58 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LGRie9009664; Fri, 21 Jan 2005 11:27:44 -0500 (EST) Date: Fri, 21 Jan 2005 11:27:44 -0500 (EST) From: Sandy Murphy Message-Id: <200501211627.j0LGRie9009664@tislabs.com> To: rpsec@ietf.org Subject: RE: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 >Now, let's assume C is using the path through B to reach 10.1.1.0/24, but >also has the path through A. When A->B fails, what happens? >... >-- C sends an update to D stating the AS Path has changed from {A,B,C} to >{A}. Maybe this is a typo and you meant to say that C sends {A,C}. Or maybe you're hitting on my favorite case of "yes, always, no, not always" debate about BGP speakers always putting their own AS on the AS_PATH as they compose an update. >Notice what's missing? D never got B's withdraw. D implies that C is >withdrawing the first route, because it sent the second Bewilderment. So? The spec specifically says that a replacement route is one of the ways to indicate that "a previously advertised route is no longer available for use." As the decision process is specifically *NOT* mandated, D can imply nothing about why C is now choosing a different route. C might just have had a falling out with B. I don't know why you are bringing this up. Are you under the impression that someone said that a withdrawal had to be propogated? It's certainly true that if B sends an withdrawal to C, you'd like to have C cease to advertise a route through B. But that's more an internal correctness problem in C. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 11:51: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 LAA26428 for ; Fri, 21 Jan 2005 11:51:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2Fv-0000x2-1K for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:07:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1xR-0004Ju-0u; Fri, 21 Jan 2005 11:48:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1n0-0000xc-Dy for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 11:37:38 -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 LAA25470 for ; Fri, 21 Jan 2005 11:37:36 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs22v-0000X5-D7 for rpsec@ietf.org; Fri, 21 Jan 2005 11:54:05 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2005 11:45:00 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-290.cisco.com [10.82.225.34]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0LGb4oB004560; Fri, 21 Jan 2005 11:37:05 -0500 (EST) Date: Fri, 21 Jan 2005 11:36:23 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: <200501211541.j0LFfBJg007970@tislabs.com> Message-ID: References: <200501211541.j0LFfBJg007970@tislabs.com> 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: 9ed51c9d1356100bce94f1ae4ec616a9 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: 769a46790fb42fbb0b0cc700c82f7081 >> -- Overlapping address spaces exist. > > I don't know what you mean by this. I get the mental image of the same > address being used by two hosts, but surely that's not what's meant, so > I'm guessing you mean that authorization for the same address space can > overlap - that is, two organizations can be allocated the same address > space. In a sense, yes, and in a sense, no. -- A is allocated 10.1.0.0/16. -- A suballocates 10.1.1.0/24 to B. IMHO, we care about routes, not updates, and routes contain prefixes. One of the questions we can ask about those prefixes is: Is the originator authorized to advertise the address space in the route? In this case, A can advertise 10.1.0.0/16, and the answer is yes, even though it actually contains 10.1.1.0/24, for which the answer is technically no. So, in a sense, this address space, 10.1.1.0/24, is legally "owned" by two entities within the system. Other than redoing the entire allocation scheme, or disallowing aggregation (forcing A not to advertise 10.1.0.0/16 when it suballocates space out of it), I don't see how you get around this problem. It's certainly easier to just say: "We'll just worry about the path the update takes, and not worry about this problem. We'll assume that if you're authorized to readvertise the update, you're authorized to transit for this address space, and we'll also assume you're authorized to allow me to readvertise this address space." IMHO, this sort of transitive trust can't exist within a routing system. We need to focus on the questions we can ask, and base the requirements on them, rather than the process used to handle updates according to the BGP specification. :-) 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 Fri Jan 21 11:53: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 LAA26736 for ; Fri, 21 Jan 2005 11:53:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2IM-00011T-Kl for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:10:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1yf-0004Yh-VZ; Fri, 21 Jan 2005 11:49:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1uf-000313-5I for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 11:45: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 LAA25922 for ; Fri, 21 Jan 2005 11:45:30 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2Aa-0000jl-5p for rpsec@ietf.org; Fri, 21 Jan 2005 12:02:00 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Jan 2005 11:45:03 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-290.cisco.com [10.82.225.34]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0LGivoB006638; Fri, 21 Jan 2005 11:44:57 -0500 (EST) Date: Fri, 21 Jan 2005 11:44:18 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] proposed message to the IESG 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: c1c65599517f9ac32519d043c37c5336 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: 4d87d2aa806f79fed918a62e834505ca > What said is that we are at an impasse re what to use as a basis for the > requirements. I say this based on the extended discussions on the list > with Russ, in which he said, repeatedly, that using the BGP spec as the > primary basis for the requirements document is inappropriate. Let me clarify this a bit. When I say I don't believe the BGP specification is a good place to start, what I mean, specifically, is that the processes described in the BGP specification are not what we should be trying to secure. Attempting to secure the processes used to transmit and receive updates is the incorrect basis for a requirements draft. We should be asking questions about the data, and how it matches the real world, based on multiple sources, and not just the BGP specification. Attempting to secure the process of sending, receiving, and processing an update, as in saying: "A speaker should be able to verify that an update has actually passed through the AS' listed in the as path," is meaningless in the context of BGP, for various reasons. Stating: "A BGP speaker should be able to verify the path described in the as path of a received route," is meaningful. I don't care where the update came from, in terms of accuracy of data. I might care in terms of non-repudiation, but the questions should be separated--accuracy of data vs non-repudiation. I think the primary point of the argument is that I don't want to secure the processes used in BGP, I want to secure the data carried in BGP. In that context, we must take into consideration such things as authorization to advertise a set of addresses (which everyone agrees is a critical component of any security architecture, and yet is plainly not covered anyplace in the BGP specifications), deployability, and other factors. I would argue that since the final recommendation will impact the work of the IDR working group directly, the most appropriate place for the requirements to be defined is in the routing area. We specifically started the RPsec WG as an area where routing, operations, and security folks could mix and talk, so we consciously intended the result of having multiple inputs into the requirements documents. :-) 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 Fri Jan 21 11:56: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 LAA27186 for ; Fri, 21 Jan 2005 11:56:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2LU-00018b-TR for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:13:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1ym-0004bu-Cb; Fri, 21 Jan 2005 11:49:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1xG-0004Hm-UO for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 11: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 LAA26145 for ; Fri, 21 Jan 2005 11:48:12 -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 1Cs2DA-0000pI-Un for rpsec@ietf.org; Fri, 21 Jan 2005 12:04:42 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B16732D50AB; Fri, 21 Jan 2005 11:47:42 -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 94100-01-9; Fri, 21 Jan 2005 11:47:39 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 25B1B2D50A7; Fri, 21 Jan 2005 11:47:38 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0LGlcG26290; Fri, 21 Jan 2005 11:47:38 -0500 (EST) Date: Fri, 21 Jan 2005 11:47:38 -0500 From: Jeffrey Haas To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050121164737.GD25920@nexthop.com> References: <200501211520.j0LFKb0d007399@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501211520.j0LFKb0d007399@tislabs.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 On Fri, Jan 21, 2005 at 10:20:37AM -0500, Sandy Murphy wrote: > See energetic thread early November on idr mailing list "Future > of route flap dampening spec", including early comments > "Is there something we want to do with the route flap dampening spec? > Move to DS, deprecate, spin in place, ...?" > "Move to historic and publish "flap damping considered harmful" RFC" > > The conversation eventually died down, with no announced consensus > that I could see. Damping is not implemented quite according to the specification. The question is whether to change implementations to match the specification or update the specification. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 12:01: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 MAA27656 for ; Fri, 21 Jan 2005 12:01:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2Q8-0001Ia-Ap for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:18:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs26A-0006E2-UA; Fri, 21 Jan 2005 11:57:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs1zv-0004y8-QX for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 11:51: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 LAA26422 for ; Fri, 21 Jan 2005 11:50:57 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2Fq-0000w8-QH for rpsec@ietf.org; Fri, 21 Jan 2005 12:07:27 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Jan 2005 09:58:27 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0LGoNl2018116; Fri, 21 Jan 2005 08:50:23 -0800 (PST) Received: from boraw2k05 ([10.32.241.194]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVU04927; Fri, 21 Jan 2005 08:50:25 -0800 (PST) Message-Id: <200501211650.AVU04927@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'Jeffrey Haas'" , "'Tony Tauber'" Subject: RE: [RPSEC] proposed message to the IESG Date: Fri, 21 Jan 2005 08:50:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050121150808.GA25920@nexthop.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-index: AcT/zXnLtMc+ytBMSzit8SiPTIfK2wACyHCA X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Jeff Whether it is certifiably "secure" or not, a lot of operators already use out of band information to secure inter-domain routing. Routing registries, Cymru are two examples of information databases that __are__ offline that are used. We can argue until we turn blue in the face about which one is better, but I think people would like to start with something that is easily deployable and buys them __some__ security. The fact that at least one of the solutions has been around for at least 7 years and has not seen large scale deployment (if any), I think tells volumes about what the operator community want. Although IETF is not an operator forum, I think it is in the spirit of the IETF (of years past possibly) to listen to what people want. Security is not a 1 bit decision as you and I discussed many times before, it is a real number scale between 0 and 1. And there is no reason why we can not start at (say) 0.65 and work our way up. Regards, Bor > -----Original Message----- > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] > On Behalf Of Jeffrey Haas > Sent: Friday, January 21, 2005 7:08 AM > To: Tony Tauber > Cc: rpsec@ietf.org > Subject: Re: [RPSEC] proposed message to the IESG > > Tony, > > On Thu, Jan 20, 2005 at 04:54:06PM -0500, Tony Tauber wrote: > > Operators want to secure inter-domain routing, not necessarily BGP. > > We may have a procedural issue here. > > I agree that securing inter-domain routing is a good goal. > That goal says more than securing BGP, particularly in the > sense that we care about securing operational practices > beyond just the security of the > BGP-4 protocol. > > However, what we have for inter-domain routing is BGP-4. > > We should be very careful to not try to be overly broad in our goals. > One consequence of being overly broad is to say "we don't > care about BGP" > and to consider a completely new protocol. > > > -- > Jeff Haas > NextHop Technologies > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 12:19: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 MAA28620 for ; Fri, 21 Jan 2005 12:19:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2hl-0001iW-5d for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:36:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs28s-0006il-Tv; Fri, 21 Jan 2005 12:00:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs24g-0005r3-MT for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 11:55: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 LAA27083 for ; Fri, 21 Jan 2005 11:55:51 -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 1Cs2Kb-000164-Bz for rpsec@ietf.org; Fri, 21 Jan 2005 12:12:21 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 549F62D4AA4; Fri, 21 Jan 2005 11:55:23 -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 94183-01-53; Fri, 21 Jan 2005 11:55:22 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 152E32D4A27; Fri, 21 Jan 2005 11:55:22 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0LGtM826336; Fri, 21 Jan 2005 11:55:22 -0500 (EST) Date: Fri, 21 Jan 2005 11:55:22 -0500 From: Jeffrey Haas To: Bora Akyol Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050121165521.GE25920@nexthop.com> References: <20050121150808.GA25920@nexthop.com> <200501211650.AVU04927@mira-sjc5-e.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501211650.AVU04927@mira-sjc5-e.cisco.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: 2409bba43e9c8d580670fda8b695204a Bora, On Fri, Jan 21, 2005 at 08:50:25AM -0800, Bora Akyol wrote: > Whether it is certifiably "secure" or not, a lot of operators > already use out of band information to secure > inter-domain routing. > > Routing registries, Cymru are two examples of > information databases that __are__ offline that are used. Please keep in mind that I was one of the final operators of RSng. I've worked on the IRRd code and helped administer the RADB. So, you're preaching to the choir. :-) I'm only saying "don't throw the baby out with the bath water" or in this case, "let's not get into a situation where the answer is throwing out BGP". Nothing more. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 12:20: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 MAA28667 for ; Fri, 21 Jan 2005 12:20:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2iG-0001jd-3v for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:36:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs28t-0006iw-B8; Fri, 21 Jan 2005 12: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 1Cs25X-0005yx-Jj for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 11:56: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 LAA27163 for ; Fri, 21 Jan 2005 11:56:45 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2LP-00017s-D3 for rpsec@ietf.org; Fri, 21 Jan 2005 12:13:14 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LGrGH7010768 for ; Fri, 21 Jan 2005 11:53:16 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAACkaybv; Fri, 21 Jan 05 11:53:13 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LGsx8w010625; Fri, 21 Jan 2005 11:54:59 -0500 (EST) Date: Fri, 21 Jan 2005 11:54:59 -0500 (EST) From: Sandy Murphy Message-Id: <200501211654.j0LGsx8w010625@tislabs.com> To: rpsec@ietf.org Subject: RE: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d >I have to agree with Russ, when is saying that "BGP is explicitely >designed to transfer information". Actually, this pretty much says nothing. Can anyone think of a protocol that is NOT "explicitely (sic) designed to transfer information". (Sorry, Russ.) >So, in this way we have to work to secure the "transport layer" not the >information witch BGP is transfer. Agreed. And as that's presently part of the spec (in the IESG queue) we're pretty safe saying this. >Regarding, the authenticity of the information passed through the BGP, >YES we should care also by this, but I think that this is a different >side of the "BGP security". Yes, there are two sources of problems - the outsiders, who can be excluded by protecting the transport, and the legitimate peers. Protecting against the legitimate peers in a distributed computation like a routing protocol is much more difficult. And that's what we're arguing about. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 12:22:10 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 MAA28862 for ; Fri, 21 Jan 2005 12:22:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2k4-0001ns-It for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:38:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2HO-0008Bc-WB; Fri, 21 Jan 2005 12:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs26v-0006PR-E7 for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 11:58:13 -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 LAA27504 for ; Fri, 21 Jan 2005 11:58:10 -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 1Cs2Mq-0001Ck-2b for rpsec@ietf.org; Fri, 21 Jan 2005 12:14:40 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id EC3FD2D50A3; Fri, 21 Jan 2005 11:57:41 -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 93960-02-83; Fri, 21 Jan 2005 11:57:38 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4F5E92D4B77; Fri, 21 Jan 2005 11:57:31 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0LGvVt26351; Fri, 21 Jan 2005 11:57:31 -0500 (EST) Date: Fri, 21 Jan 2005 11:57:31 -0500 From: Jeffrey Haas To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050121165731.GF25920@nexthop.com> References: <200501211541.j0LFfBJg007970@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501211541.j0LFfBJg007970@tislabs.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Sandy, On Fri, Jan 21, 2005 at 10:41:11AM -0500, Sandy Murphy wrote: > >-- Overlapping address spaces exist. > > I don't know what you mean by this. I get the mental image of the > same address being used by two hosts, but surely that's not what's > meant, so I'm guessing you mean that authorization for the same > address space can overlap - that is, two organizations can be > allocated the same address space. In this case, it's CIDR as usual. I can own a larger block, say a /8, delegate a smaller block from that, say a /24, and still advertise my /8. When a BGP speaker announces a shorter prefix and not a longer prefix that it has, this is a form of aggregation. In the case where the AS_PATH is different, this is a form of ATOMIC_AGGREGATE. However, the BGP specification never covered the case for marking a route with ATOMIC_AGGREGATE in the adj-rib-out - it only did this on selecting the route into loc-rib. The name I use for the above case is an "implicit aggregate". This is because you are not creating a new shorter prefix where none previously existed. This is to distinguish it from the other case where a new route is created - I call this case an "explicit" or "proxy" aggregate. In this case, a new, shorter prefix route is created. This will usually involve either ATOMIC_AGGREGATE being set on the path attributes because the AS_PATH has been truncated or an AS_SET has been generated. The security implications of delegated address space where an implicit aggregate may be present are one of our items of concern. The fact that some provider may be using this delegated space implies two things operationally from a forwarding perspective: Consider the owner of the /8 to be ISP-A and the delegated /24 to be ISP-B. 1. If ISP-A and ISP-B are connected in some fashion, either directly or indirectly, ISP-A may be willing to forward traffic to ISP-B and will need ISP-B's /24 in order to do this. 2. If ISP-A and ISP-B are not connected in some fashion and ISP-A is unwilling to forward traffic for the covered /24, there may be occasions where ISP-B's traffic is blackholed. The implication is no matter how secure the /8 and the /24 routes are, if ISP-A and ISP-B must have some relationship for traffic for the covered /24 as ISP-A may, simply due to CIDR, receive that traffic. Ergo, if you're concerned about this situation, the only way to be truly sure about the forwarding is to get your own address space. Even then, if someone proxy aggregates and your route is filtered, they may still intercept your traffic simply using routing protocols (excluding a man-in-the-middle attack on the forwarding plane). -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 12:25:20 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 MAA29252 for ; Fri, 21 Jan 2005 12:25:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2n7-0001vn-TW for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:41:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2Si-0004It-NA; Fri, 21 Jan 2005 12:20:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2BU-00071h-Gx for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 12:02: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 MAA27689 for ; Fri, 21 Jan 2005 12:02:53 -0500 (EST) Received: from blaines.net ([65.79.159.21] helo=tunguy.blaines.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2RP-0001JE-1d for rpsec@ietf.org; Fri, 21 Jan 2005 12:19:23 -0500 Received: from [10.254.254.11] ([10.254.254.11]) (authenticated bits=0) by tunguy.blaines.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id j0LH29DH022354 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 21 Jan 2005 12:02:14 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 21 Jan 2005 12:02:03 -0500 Subject: Re: [RPSEC] proposed message to the IESG From: Blaine Christian To: Stephen Kent Message-ID: In-Reply-To: Mime-version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd 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="===============1387632171==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1387632171== Content-type: multipart/alternative; boundary="B_3189153734_7830764" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3189153734_7830764 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hey Steve, I suppose when you have an operator as editor you will get a bit of operator slant . One perspective might be that, in most venues, the potential customers of a service usually drive the requirements. We do have protocol developers on this thread and writing for the draft itself. My perception is that the value I add to the process is giving people a perspective on what operators would find deployable. I will try to go back through and find your text recommendations. I was hoping to apply the consensual view to the document. When vigorous debate ensued I decided to wait and see if we could come to terms. I know it is asking a lot... But if we could approach this in small chunks maybe we can address specific concerns point by point. My thought is that we should encompass the needs of the BGP spec in a way that addresses the manner in which things were actually deployed (if that makes any sense). Regards, Blaine On 1/21/05 10:54 AM, "Stephen Kent" wrote: > At 11:10 AM -0500 1/20/05, Blaine Christian wrote: >> Hello Steve, >> >> I am concerned about your assertion that the draft does not follow the BGP >> spec. I have avoided stepping into the fray with you and Russ going at it. >> But can you clarify, for me, exactly what parts of the BGP spec are being >> ignored or changed in this draft? I have been working with BGP for many >> years and I could not find a spot where the document did not match reality >> or the needs of the operators. >> >> This document is intended to present a set of requirements from the operator >> community to the folks creating the standards (which is why it is tracking >> towards informational). >> >> Regards, >> Blaine > > Blaine, > > I did no say that the current draft of the security requirements document does > not follow the BGP spec. I will send a separate message addressing that issue, > later. > > What said is that we are at an impasse re what to use as a basis for the > requirements. I say this based on the extended discussions on the list with > Russ, in which he said, repeatedly, that using the BGP spec as the primary > basis for the requirements document is inappropriate. > > Russ began making these comments in late December, when I responded to his > comments on the current draft. (In fact, I never managed to get around to > commenting on the draft itself, because of all the time spent arguing wit Russ > over his and my suggested changes!) I proposed text in a message on 12/28/04 > that I thought was appropriate for the draft, and I explained why, i.e., > because it was traceable to the BGP spec. That triggered an intense discussion > on the list (between Russ and me) that lasted for over a week. > > If we agree that the BGP spec is the starting point for security requirements, > then we have an objective basis for deciding whether proposed text is > appropriate or not. That is why I have pursued this issue. > > On 1/5 I sent a message that contained a lot of excerpts from the BGP spec in > support of the text that I had provided, citing specific parts of the spec as > a suitable basis for the security requirements. In response, on 1/6/05 Russ > sent a message that ended with the comment: > > You can point out all sorts of phrases and comments in the draft, but you have > to temper these statements with the actual operation of BGP in the real world, > with real address ownership concepts, real aggregation, and real route > origination policies. > > This sounds like a statement that Russ does not feel that the BGP spec > provides a suitable basis for developing the security requirements. > > I another message on 1/6/05 Russ also said: > > And at some point, the WG has to decide which of these two models is valid. I > believe that I've made a strong case to consider the operational use as a > valid model, because of gaps in the alternative model. > > Russ was commenting on the following text in my message: > >> We both have prejudices in approaching this problem. One can fairly say that >> I used the BGP spec as the basis for developing the security requirements >> model that we then addressed with S-BGP. Likewise, you adopted an >> operations-oriented view of security when you developed soBGP. That does not >> make either approach intrinsically valid or invalid. > > I think this is a pretty clear statement by Russ that he believes that an > operational model, rather than the BGP spec, is the right basis for the > requirements. > > In another message later that day, Russ reiterated this notion saying: > > Regardless of your attempts at striking at me personally, Steve, I don't see > how you can get around building a set of requirements based on what exists, > rather than the BGP specification, which is only part of the way things really > work. > > The phrase "rather than the BGP specification" again seems to indicate a > fairly strong bias against using the BGP spec as the primary basis for the > security requirements. > > > With regard to your question of whether BGP as deployed matches the spec, I > note the following comment in a message from Iljitsch on 1/6/05. We were > discussing what forms of aggregation are permitted by the BGP spec and he > said: > > Now all of this non-RFC-compliant aggregation works without any problems > because of the longest match first rule. > > This is a pretty direct statement calling into question congruence between the > BGP spec and operational practice. > > Finally, you close with "This document is intended to present a set of > requirements from the operator community to the folks creating the standards > ..." I have to admit that I do not recall hearing that characterization of > the goal for this document. The WG charter does not convey the notion that > this document is to represent the operator view of security requirements for > BGP. Your description of the context for developing the document is consistent > with the concerns I expressed, i.e., an operational vs. protocol spec based > perspective. > > I'd like to hear from both WG chairs with regard to whether the document is > supposed to have this orientation, i.e., that it is supposed to be an > operationally-oriented view of security requirements for BGP. If the context > is what you suggest, I think my question to the IESG seems very much relevant. > The WG charter makes no mention of an operational bias in developing routing > security requirements. > > Steve > --B_3189153734_7830764 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [RPSEC] proposed message to the IESG Hey S= teve,

I suppose when you have an operator as editor you will get a bit of operato= r slant <grin>.   One perspective might be that, in most ven= ues,  the potential customers of a service usually drive the requiremen= ts.  We do have protocol developers on this thread and writing for the = draft itself.  My perception is that the value I add to the process is = giving people a perspective on what operators would find deployable.

I will try to go back through and find your text recommendations.  I w= as hoping to apply the consensual view to the document.  When vigorous = debate ensued I decided to wait and see if we could come to terms.

I know it is asking a lot...  But if we could approach this in small c= hunks maybe we can address specific concerns point by point.  My though= t is that we should encompass the needs of the BGP spec in a way that addres= ses the manner in which things were actually deployed (if that makes any sen= se).

Regards,

Blaine


On 1/21/05 10:54 AM, "Stephen Kent" <kent@bbn.com> wrote:
At 11:10 AM -0500 1/20/05, Blaine Christian wrote:
Hello Steve,

I am concerned about your assertion that the draft does not follow the BGP<= BR> spec.  I have avoided stepping into the fray with you and Russ going a= t it.
But can you clarify, for me, exactly what parts of the BGP spec are being ignored or changed in this draft?  I have been working with BGP for ma= ny
years and I could not find a spot where the document did not match reality<= BR> or the needs of the operators.

This document is intended to present a set of requirements from the operato= r
community to the folks creating the standards (which is why it is tracking<= BR> towards informational).

Regards,
Blaine

Blaine,

I did no say that the current draft of the security requirements document d= oes not follow the BGP spec. I will send a separate message addressing that = issue, later.

What  said is that we are at an impasse re what to use as a basis for = the requirements. I say this based on the extended discussions on the list w= ith Russ, in which he said, repeatedly, that using the BGP spec as the prima= ry basis for the requirements document is inappropriate.

Russ began making these comments in late December, when I responded to his = comments on the current draft. (In fact, I never managed to get around to co= mmenting on the draft itself, because of all the time spent arguing wit Russ= over his and my suggested changes!) I proposed text in a message on 12/28/0= 4 that I thought was appropriate for the draft, and I explained why, i.e., b= ecause it was traceable to the BGP spec. That triggered an intense discussio= n on the list (between Russ and me) that lasted for over a week.

If we agree that the BGP spec is the starting point for security requiremen= ts, then we have an objective basis for deciding whether proposed text is ap= propriate or not. That is why I have pursued this issue.

On 1/5 I sent a message that contained a lot of excerpts from the BGP spec = in support of the text that I had provided, citing specific parts of the spe= c as a suitable basis for the security requirements. In response, on 1/6/05 = Russ sent a message that ended with the comment:

You can point out all sorts of phrases and comments in the draft, but yo= u have to temper these statements with the actual operation of BGP in the re= al world, with real address ownership concepts, real aggregation, and real r= oute origination policies.

This sounds like a statement that Russ does not feel that the BGP spec prov= ides a suitable basis for developing the security requirements.

I another message on 1/6/05 Russ also said:

And at some point, the WG has to decide which of these two models is val= id. I believe that I've made a strong case to consider the operational use a= s a valid model, because of gaps in the alternative model.

Russ was commenting on the following text in my message:

We both have prejudices in approaching this problem. &n= bsp;One can fairly say that I used the BGP spec as the basis for developing = the security requirements model that we then addressed with S-BGP. Likewise,= you adopted an operations-oriented view of security when you developed soBG= P. That does not make either approach intrinsically valid or invalid.

I think this is a pretty clear statement by Russ that he believes that an o= perational model, rather than the BGP spec, is the right basis for the requi= rements.

In another message later that day, Russ reiterated this notion saying:

Regardless of your attempts at striking at me personally, Steve, I don't= see how you can get around building a set of requirements based on what exi= sts, rather than the BGP specification, which is only part of the way things= really work.

The phrase "rather than the BGP specification" again seems to ind= icate a fairly strong bias against using the BGP spec as the primary basis f= or the security requirements.


With regard to your question of whether BGP as deployed matches the spec, I= note the following comment in a message from Iljitsch on 1/6/05. We were di= scussing what forms of aggregation are permitted by the BGP spec and he said= :

Now all of this non-RFC-compliant aggregation works without any problems= because of the longest match first rule.

This is a pretty direct statement calling into question congruence betw= een the BGP spec and operational practice.

Finally, you close with "This document is intended to present a set of= requirements from the operator community to the folks creating the standard= s ..."  I have to admit that I do not recall hearing that characte= rization of the goal for this document. The WG charter does not convey the n= otion that this document is to represent the operator view of security requi= rements for BGP. Your description of the context for developing the document= is consistent with the concerns I expressed, i.e., an operational vs. proto= col spec based perspective.

I'd like to hear from both WG chairs with regard to whether the document is= supposed to have this orientation, i.e., that it is supposed to be an opera= tionally-oriented view of security requirements for BGP. If the context is w= hat you suggest, I think my question to the IESG seems very much relevant. T= he WG charter makes no mention of an operational bias in developing routing = security requirements.

Steve


 --B_3189153734_7830764-- --===============1387632171== 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 --===============1387632171==-- From rpsec-bounces@ietf.org Fri Jan 21 12:28: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 MAA29419 for ; Fri, 21 Jan 2005 12:28:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2pq-000203-3P for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:44:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2T4-0004YZ-Om; Fri, 21 Jan 2005 12:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2EG-0007Nd-Um for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 12:05:49 -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 MAA27804 for ; Fri, 21 Jan 2005 12:05:46 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2UA-0001N5-5a for rpsec@ietf.org; Fri, 21 Jan 2005 12:22:16 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LH2J22011749 for ; Fri, 21 Jan 2005 12:02:19 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAFai8w; Fri, 21 Jan 05 12:02:15 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LH3v53010953; Fri, 21 Jan 2005 12:03:57 -0500 (EST) Date: Fri, 21 Jan 2005 12:03:57 -0500 (EST) From: Sandy Murphy Message-Id: <200501211703.j0LH3v53010953@tislabs.com> To: blaine@blaines.net, rpsec@ietf.org, sandy@tislabs.com Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >I can give you one! Anycast for DNS... Anycast is very cool... But >everyone uses the same prefix. OK, that's a legitimate case. So we'd have to design the security requirement so that it would cover this case. As an example of working on security requirements, would you say that it would be OK if an AS received updates from two peers, both claiming to be originating an address that was so duplicately sub-allocated? Or is this handled by having one AS authorized as the originator and something like multi-homed in two different places? (NOTE: these sorts of questions are what you would have to discuss in coming up with the security requirements - I'm not suggesting that we'd solve the problem here and now. Presently we're just discussing the process of arguing, not the argument.) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 12:32: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 MAA29664 for ; Fri, 21 Jan 2005 12:32:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2tp-00026f-02 for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:48:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2VK-0005oz-KZ; Fri, 21 Jan 2005 12: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 1Cs2LY-00012N-6y for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 12:13: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 MAA28214 for ; Fri, 21 Jan 2005 12:13:17 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2bS-0001Ye-Du for rpsec@ietf.org; Fri, 21 Jan 2005 12:29:47 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LH9pQQ012254 for ; Fri, 21 Jan 2005 12:09:51 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAaxai7x; Fri, 21 Jan 05 12:09:49 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LHBZ7C011117; Fri, 21 Jan 2005 12:11:35 -0500 (EST) Date: Fri, 21 Jan 2005 12:11:35 -0500 (EST) From: Sandy Murphy Message-Id: <200501211711.j0LHBZ7C011117@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 >-- A is allocated 10.1.0.0/16. >-- A suballocates 10.1.1.0/24 to B. >... >Is the originator >authorized to advertise the address space in the route? In this case, A can >advertise 10.1.0.0/16, and the answer is yes, even though it actually >contains 10.1.1.0/24, for which the answer is technically no. REALLY???????!!!!!!!!!! I've never seen a suggestion that either in spec or in operational practice, that allocating an address to someone removes your ability to announce those addresses yourself. Does this really truly happen in practice? If so, this is a big change to what I understood allocation to imply. And it would be a much bigger problem to try to secure such an interpretation of allocation. You'd not only have to securely distribute the information of what you've been allocated but also the information of what you've NOT suballocated. That's not easy! Are you really really sure that this is (a) current practice and (b) desirable? Realize that you are advocating taking on a very hard problem here. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 12:34: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 MAA29861 for ; Fri, 21 Jan 2005 12:34:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2wG-0002CH-9n for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 12:51:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2Vf-0005to-RW; Fri, 21 Jan 2005 12: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 1Cs2Ql-0003IV-P6 for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 12:18:43 -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 MAA28567 for ; Fri, 21 Jan 2005 12:18:41 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2gh-0001h1-3V for rpsec@ietf.org; Fri, 21 Jan 2005 12:35:11 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LHFG5U012760 for ; Fri, 21 Jan 2005 12:15:16 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAQEaO6y; Fri, 21 Jan 05 12:15:13 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LHGr5r011286; Fri, 21 Jan 2005 12:16:53 -0500 (EST) Date: Fri, 21 Jan 2005 12:16:53 -0500 (EST) From: Sandy Murphy Message-Id: <200501211716.j0LHGr5r011286@tislabs.com> To: kent@bbn.com, riw@cisco.com Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >Stating: "A BGP speaker should >be able to verify the path described in the as path of a received route," >is meaningful. I disagree strongly that the statement is "meaningful" unless and until you have decided on the *meaning* of "verify the path". That's a point that is unclear in the current requirements draft and has been noted as unclear and admitted to be unclear. And I think that's part of the disagreement between you and Steve. You not only disagree about the meaning, you can't agree how to decide what the meaning could be. So you have no way of "proving" (:-)) to each other which meaning is correct. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 12:39:39 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 MAA00324 for ; Fri, 21 Jan 2005 12:39:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs30y-0002M0-JX for rpsec-web-archive@ietf.org; Fri, 21 Jan 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 1Cs2gY-00008W-JM; Fri, 21 Jan 2005 12:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2Vn-00062A-0k for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 12:23: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 MAA29117 for ; Fri, 21 Jan 2005 12:23:52 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2li-0001si-9y for rpsec@ietf.org; Fri, 21 Jan 2005 12:40:22 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LHKSUk013085 for ; Fri, 21 Jan 2005 12:20:28 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAoTayJz; Fri, 21 Jan 05 12:20:25 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LHMCrC011421; Fri, 21 Jan 2005 12:22:12 -0500 (EST) Date: Fri, 21 Jan 2005 12:22:12 -0500 (EST) From: Sandy Murphy Message-Id: <200501211722.j0LHMCrC011421@tislabs.com> To: rpsec@ietf.org Subject: RE: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 >The fact that at least one of the solutions has been around >for at least 7 years and has not seen large scale deployment (if any), >I think tells volumes about what the operator community want. By that measure, TCP MD5 was around for years, implemented by a major vendor or two, and was still not seeing widespread deployment - from which we would conclude that it was clear what the operator community wanted. Which isn't to say it shouldn't be a security requirement. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 12:48:21 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 MAA00909 for ; Fri, 21 Jan 2005 12:48:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs39P-0002ZT-Gt for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 13:04:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2nS-0001aA-Hc; Fri, 21 Jan 2005 12:42:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2hU-0000TK-KQ for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 12:36: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 MAA00016 for ; Fri, 21 Jan 2005 12:35:58 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs2xQ-0002F2-2L for rpsec@ietf.org; Fri, 21 Jan 2005 12:52:28 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LHWX5b014106 for ; Fri, 21 Jan 2005 12:32:33 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAoRa4HB; Fri, 21 Jan 05 12:32:30 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LHYH4e011723; Fri, 21 Jan 2005 12:34:17 -0500 (EST) Date: Fri, 21 Jan 2005 12:34:17 -0500 (EST) From: Sandy Murphy Message-Id: <200501211734.j0LHYH4e011723@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 >> >-- Overlapping address spaces exist. >> >> I don't know what you mean by this. >... >In this case, it's CIDR as usual. I can own a larger block, say a /8, >delegate a smaller block from that, say a /24, and still advertise >my /8. So what you are saying (and what I was trying to get Russ to say) is that what is overlapping is the authority over the address space - two ISP's have been allocated an address space. >The name I use for the above case is an "implicit aggregate". >... >I call this case an "explicit" or >"proxy" aggregate. I've heard different opinions on how common the proxy aggregation case is. One example of the security requirement process would be to decide if this was a semantics we wanted to retain and secure and if so how. (Implicit aggregation - you just have to show your allocation from someone else, where that might be IANA. Proxy aggregation - you have to show .... that you received two updates that add up to the aggregated prefix??? At any rate, it's nay so easy.) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 12:51: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 MAA01233 for ; Fri, 21 Jan 2005 12:51:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs3Ci-0002gq-Df for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 13:08:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2uO-00030x-4F; Fri, 21 Jan 2005 12:49:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2pM-0001rk-MW for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 12:44: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 MAA00693 for ; Fri, 21 Jan 2005 12:44:04 -0500 (EST) From: sthaug@nethelp.no Received: from bizet.nethelp.no ([195.1.209.33]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cs35F-0002T2-OA for rpsec@ietf.org; Fri, 21 Jan 2005 13:00:35 -0500 Received: (qmail 15207 invoked by uid 1001); 21 Jan 2005 17:43:55 -0000 To: kent@bbn.com Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: Your message of "Fri, 21 Jan 2005 10:54:08 -0500" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 21 Jan 2005 18:43:55 +0100 Message-ID: <15205.1106329435@bizet.nethelp.no> X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 > Finally, you close with "This document is intended to present a set > of requirements from the operator community to the folks creating the > standards ..." I have to admit that I do not recall hearing that > characterization of the goal for this document. The WG charter does > not convey the notion that this document is to represent the operator > view of security requirements for BGP. I don't see a need for the document to represent *only* the operator view of security requirements for BGP. However, if the operator view is not represented at all, there is a high probability that anything based on this document would be ignored by many operators. Working for an operator myself, I clearly feel that if there is a conflict between the BGP spec and the way BGP is actually used by a significant number of operators, the operational practices need to be taken into consideration - and the conflict should be explicitly spelled out. Steinar Haug, Nethelp consulting, sthaug@nethelp.no _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 12:56: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 MAA01487 for ; Fri, 21 Jan 2005 12:56:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs3Gs-0002oO-6z for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 13:12:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2uf-00036u-BO; Fri, 21 Jan 2005 12:49:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2qg-00024d-OE for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 12:45:32 -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 MAA00766 for ; Fri, 21 Jan 2005 12:45:27 -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 1Cs36a-0002Ur-TL for rpsec@ietf.org; Fri, 21 Jan 2005 13:01:58 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 31D382D4E22; Fri, 21 Jan 2005 12:44:54 -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 98290-01-68; Fri, 21 Jan 2005 12:44:53 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E78C32D4DDE; Fri, 21 Jan 2005 12:44:52 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0LHiq726528; Fri, 21 Jan 2005 12:44:52 -0500 (EST) Date: Fri, 21 Jan 2005 12:44:52 -0500 From: Jeffrey Haas To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050121174452.GI25920@nexthop.com> References: <200501211722.j0LHMCrC011421@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501211722.j0LHMCrC011421@tislabs.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Fri, Jan 21, 2005 at 12:22:12PM -0500, Sandy Murphy wrote: > By that measure, TCP MD5 was around for years, implemented by a > major vendor or two, and was still not seeing widespread deployment > - from which we would conclude that it was clear what the > operator community wanted. While similarly a proposal to add IKE support for TCP+MD5 so that rekeying operations were easier never got off the ground in IDR. Operators can be fickle. They will often ask for rope and then act surprised when they hang themselves (and occasionally the whole Internet) with it. I'm a big fan of rope, but also making sure that you keep your gallows to yourself. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 13:02: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 NAA02138 for ; Fri, 21 Jan 2005 13:02:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs3NS-0002zl-Fg for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 13:19:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs32G-0004zN-94; Fri, 21 Jan 2005 12:57:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs2xi-0003gY-1S for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 12:52:46 -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 MAA01286 for ; Fri, 21 Jan 2005 12:52:43 -0500 (EST) From: sthaug@nethelp.no Received: from bizet.nethelp.no ([195.1.209.33]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cs3Dd-0002iK-EH for rpsec@ietf.org; Fri, 21 Jan 2005 13:09:13 -0500 Received: (qmail 16875 invoked by uid 1001); 21 Jan 2005 17:52:44 -0000 To: sandy@tislabs.com Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: Your message of "Fri, 21 Jan 2005 12:11:35 -0500 (EST)" References: <200501211711.j0LHBZ7C011117@tislabs.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 21 Jan 2005 18:52:44 +0100 Message-ID: <16873.1106329964@bizet.nethelp.no> X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 > >-- A is allocated 10.1.0.0/16. > >-- A suballocates 10.1.1.0/24 to B. > >... > >Is the originator > >authorized to advertise the address space in the route? In this case, A can > >advertise 10.1.0.0/16, and the answer is yes, even though it actually > >contains 10.1.1.0/24, for which the answer is technically no. > > > REALLY???????!!!!!!!!!! > > I've never seen a suggestion that either in spec or in operational > practice, that allocating an address to someone removes your > ability to announce those addresses yourself. It depends on what the announcement is meant to convey. If A suballocates 10.1.1.0/24 to B, A can no longer use 10.1.1.0/24 for its own purposes (obviously). If announcement is meant to convey the right to use a particular bit of the address space, A should no longer announce 10.1.0.0/16. I think it is certainly fair game to discuss whether A is *authorized* to announce 10.1.0.0/16 in this case. And yet, it is done every day, and it works (due to longest prefix matching). Steinar Haug, Nethelp consulting, sthaug@nethelp.no _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 14:09: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 OAA06886 for ; Fri, 21 Jan 2005 14:09:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4Pk-0004rX-18 for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 14:25:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs48Z-0001o9-SG; Fri, 21 Jan 2005 14:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3yc-00084b-Gh for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 13:57:46 -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 NAA05898 for ; Fri, 21 Jan 2005 13:57:45 -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 1Cs4EX-0004TJ-Ej for rpsec@ietf.org; Fri, 21 Jan 2005 14:14:14 -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 j0LIvDDH023733 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 21 Jan 2005 13:57:14 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 21 Jan 2005 13:57:07 -0500 Subject: Re: [RPSEC] proposed message to the IESG From: Blaine Christian To: Sandy Murphy , Message-ID: In-Reply-To: <200501211703.j0LH3v53010953@tislabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On 1/21/05 12:03 PM, "Sandy Murphy" wrote: >> I can give you one! Anycast for DNS... Anycast is very cool... But >> everyone uses the same prefix. > > OK, that's a legitimate case. > > So we'd have to design the security requirement so that it would > cover this case. > > As an example of working on security requirements, would you say > that it would be OK if an AS received updates from two peers, both > claiming to be originating an address that was so duplicately > sub-allocated? Or is this handled by having one AS authorized > as the originator and something like multi-homed in two different > places? (NOTE: these sorts of questions are what you would have > to discuss in coming up with the security requirements - I'm not > suggesting that we'd solve the problem here and now. Presently > we're just discussing the process of arguing, not the argument.) I won't try and make the solution. But I can tell you that we did add it to the requirements draft. Another example is that operators need the ability to advertise, from different AS's, the exact same prefix. A prime example would be a network owner that does not do BGP but is multihomed. > > --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 14:11:39 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 OAA06971 for ; Fri, 21 Jan 2005 14:11:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4S0-0004tn-Rf for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 14:28:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs48a-0001os-Gy; Fri, 21 Jan 2005 14:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs3zK-0008Cb-1c for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 13:58: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 NAA05962 for ; Fri, 21 Jan 2005 13:58:28 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4FF-0004Ur-18 for rpsec@ietf.org; Fri, 21 Jan 2005 14:14:58 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 21 Jan 2005 10:59:31 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-290.cisco.com [10.82.225.34]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0LIvpRP009455; Fri, 21 Jan 2005 10:57:52 -0800 (PST) Date: Fri, 21 Jan 2005 13:57:10 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: <200501211716.j0LHGr5r011286@tislabs.com> Message-ID: References: <200501211716.j0LHGr5r011286@tislabs.com> 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: d8ae4fd88fcaf47c1a71c804d04f413d Cc: rpsec@ietf.org, kent@bbn.com 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: bdc523f9a54890b8a30dd6fd53d5d024 >> Stating: "A BGP speaker should be able to verify the path described in >> the as path of a received route," is meaningful. > > I disagree strongly that the statement is "meaningful" unless and until > you have decided on the *meaning* of "verify the path". That's actually correct. What I mean by "meaningful" is that the path actually exists, that there is a way from my peer, who has advertised that path, to the destination stated in the route. What others apparently want it to mean is that the update has passed through the route described in the update. Suppose you state: "A speaker should be able to prove the update has passed through the AS' listed in the as path," as a requirement. Now, my question is going to be: "Why? What do you want to prove by verifying this in this way?" Your answer is going to be: "Because proving this proves the path actually exists, and can prove non-repudiation, and...." Well, then, you shouldn't have an objection to asking those questions, discussing them, and listing the outcome as the requirements themselves. That I can ask this question, and the answer is going to be a set of things you are trying to verify/prove, shows me the stated requirement is actually a solution, not a true requirement. I think the actual main sticking point is that many people think requiring "verify/prove the update has passed through path x" actually proves transitive authorization, but then we fall into the entire trap of "transitive authorization for what??" The update (updates aren't transitive), the prefix (it's been proven you can't do transitive authorization for prefixes), or.... what, exactly? Rather than stating this question separately, and discussing it, we're at a point where some folks would like to just include a solution as the requirement, claiming it's the "right thing to do, because it matches the 'sense of the BGP specifications,'" and leave it at that, burying the entire discussion. I think, if you go back far enough in the thread, I've said this before. I specifically stated that every currently proposed system can meet the requirements as they are written today (S-BGP, IRV, SPV, soBGP, and several others, including off-line databases built IRR databases, etc). Systems may, if they want to, claim _more_ security than the requirements document state (remember, this is informational, and meant to guide, not a standard), and, at that point, the community would be able to set that question out on its own, discuss the assumptions, tradeoffs, and feasibility of answering it. In other words, admit, honestly, that we can't reach a concensus on this one question, and write the document in such a way that the question is left to the protocol designers, implementors, and deployers, to decide. I believe that suggestion was rejected, outright, by Steve. Instead, he states that we are "missing essential security we could claim." My argument is that we can't claim that security, the type of security you're talking about doesn't, and can't, exist in routing systems today. IMHO, the best way to move forward is exactly what I said above. State the requirements we can agree on, state we can't reach concensus on this one point, and move forward. The requirements are reasonable, as written, and clear in what they mean. We need more justifications, introductions, etc, etc, but the doc itself asks the correct questions, and in the correct way (well, the wording may not be formal enough for some people). This business about the requirements "not being based on the BGP specification" is a red herring, IMHO, meant to push requirements into the draft without actually discussing those requirements, or without actually considering the tradeoffs, etc, as they really exist. :-) 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 Fri Jan 21 14:17: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 OAA07363 for ; Fri, 21 Jan 2005 14:17:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4Y6-00052X-1k for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 14:34:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs49K-0002Pb-Eg; Fri, 21 Jan 2005 14:08:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs485-0001e4-2L for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 14:07: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 OAA06755 for ; Fri, 21 Jan 2005 14:07:31 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4O0-0004p5-D7 for rpsec@ietf.org; Fri, 21 Jan 2005 14:24:01 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LJ4515024407 for ; Fri, 21 Jan 2005 14:04:05 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAWvayQV; Fri, 21 Jan 05 14:04:02 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LJ5mEL014846; Fri, 21 Jan 2005 14:05:48 -0500 (EST) Date: Fri, 21 Jan 2005 14:05:48 -0500 (EST) From: Sandy Murphy Message-Id: <200501211905.j0LJ5mEL014846@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >Another example is that operators need the ability >to advertise, from different AS's, the exact same prefix. A prime example >would be a network owner that does not do BGP but is multihomed. Well, I would say that *when* we are discussing the security requirements, we would have to look at this operational case, decide if it needed to be retained and secured, and what it might take to represent this case and secure this case. (Like: separate the ideas of being allocated an address from the idea of being authorized to advertise the origination of an address - just so this case could be represented and secured.) Not that I'm saying that we should argue that specific point right now. Just that's how I see us incorporating operational issues into our discussion of the security requirements for BGP. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 14:20:12 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 OAA07547 for ; Fri, 21 Jan 2005 14:20:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4aH-00056N-C7 for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 14:36:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4Iu-0004NB-Sv; Fri, 21 Jan 2005 14:18:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4DF-00038X-KH for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 14:12:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07025 for ; Fri, 21 Jan 2005 14:12:52 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4TA-0004uX-UE for rpsec@ietf.org; Fri, 21 Jan 2005 14:29:22 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 21 Jan 2005 14:12:20 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-290.cisco.com [10.82.225.34]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0LJCIW1002242; Fri, 21 Jan 2005 14:12:18 -0500 (EST) Date: Fri, 21 Jan 2005 14:11:37 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: RE: [RPSEC] proposed message to the IESG In-Reply-To: <200501211627.j0LGRie9009664@tislabs.com> Message-ID: References: <200501211627.j0LGRie9009664@tislabs.com> 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: 798b2e660f1819ae38035ac1d8d5e3ab 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: 2409bba43e9c8d580670fda8b695204a > Bewilderment. So? The spec specifically says that a replacement route > is one of the ways to indicate that "a previously advertised route is no > longer available for use." As the decision process is specifically *NOT* > mandated, D can imply nothing about why C is now choosing a different > route. C might just have had a falling out with B. > > I don't know why you are bringing this up. Are you under the impression > that someone said that a withdrawal had to be propogated? It's certainly > true that if B sends an withdrawal to C, you'd like to have C cease to > advertise a route through B. But that's more an internal correctness > problem in C. Susan brought up the ordering of withdraws and updates as being important. :-) 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 Fri Jan 21 14:24: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 OAA07953 for ; Fri, 21 Jan 2005 14:24:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4es-0005EQ-KS for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 14:41:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4J4-0004ST-Du; Fri, 21 Jan 2005 14:18:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4GH-0003jS-JI for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 14:16: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 OAA07213 for ; Fri, 21 Jan 2005 14:16:00 -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 1Cs4WD-0004zm-Lj for rpsec@ietf.org; Fri, 21 Jan 2005 14:32:30 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j0LJFiKN001549; Fri, 21 Jan 2005 19:15:44 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j0LJFiOC001546; Fri, 21 Jan 2005 19:15:44 GMT Date: Fri, 21 Jan 2005 19:15:44 +0000 From: bmanning@vacation.karoshi.com To: Blaine Christian Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050121191544.GA1423@vacation.karoshi.com.> References: <200501211703.j0LH3v53010953@tislabs.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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org 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: 1ac7cc0a4cd376402b85bc1961a86ac2 > I won't try and make the solution. But I can tell you that we did add it to > the requirements draft. Another example is that operators need the ability > to advertise, from different AS's, the exact same prefix. A prime example > would be a network owner that does not do BGP but is multihomed. amen to this.. as an operator, we do have cases where there is -NOT- a unique orign AS for a given prefix. --bill _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 14:45: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 OAA10396 for ; Fri, 21 Jan 2005 14:45:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4yp-00062K-IW for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 15:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4d3-0001MR-8r; Fri, 21 Jan 2005 14:39:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4Oj-0005ln-AS for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 14:24: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 OAA07925 for ; Fri, 21 Jan 2005 14:24:43 -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 1Cs4ee-0005Ck-Kd for rpsec@ietf.org; Fri, 21 Jan 2005 14:41:13 -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 j0LJLXDH024101 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 21 Jan 2005 14:21:33 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 21 Jan 2005 14:21:27 -0500 Subject: Re: [RPSEC] proposed message to the IESG From: Blaine Christian To: Russ White , Sandy Murphy 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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit > I think, if you go back far enough in the thread, I've said this before. I > specifically stated that every currently proposed system can meet the > requirements as they are written today (S-BGP, IRV, SPV, soBGP, and several > others, including off-line databases built IRR databases, etc). Systems > may, if they want to, claim _more_ security than the requirements document > state (remember, this is informational, and meant to guide, not a > standard), and, at that point, the community would be able to set that > question out on its own, discuss the assumptions, tradeoffs, and > feasibility of answering it. Only one point I want to make in the above statement. If the requirements document allows every proposed standard then it is not yet complete. It "should" be written such that it helps to identify the most feasible solution. The trick, IMHO, is to get specific enough in the requirements that either one of the existing solutions fits or a better solution gets designed. If the solutions are close enough together that they all solve the document then we should just toss a coin . _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 14:47: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 OAA10566 for ; Fri, 21 Jan 2005 14:47:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs50g-00065L-Qp for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 15:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4d5-0001My-3Q; Fri, 21 Jan 2005 14:39:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4Qu-0006DG-C9 for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 14:27: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 OAA08075 for ; Fri, 21 Jan 2005 14:26:59 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs4gp-0005FU-L4 for rpsec@ietf.org; Fri, 21 Jan 2005 14:43:28 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2005 14:34:21 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-290.cisco.com [10.82.225.34]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0LJQPW1006180; Fri, 21 Jan 2005 14:26:25 -0500 (EST) Date: Fri, 21 Jan 2005 14:25:44 -0500 (Eastern Standard Time) From: Russ White To: Blaine Christian Subject: Re: [RPSEC] proposed message to the IESG 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, kent@bbn.com, Sandy Murphy 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 >> I think, if you go back far enough in the thread, I've said this before. I >> specifically stated that every currently proposed system can meet the >> requirements as they are written today (S-BGP, IRV, SPV, soBGP, and several >> others, including off-line databases built IRR databases, etc). Systems >> may, if they want to, claim _more_ security than the requirements document >> state (remember, this is informational, and meant to guide, not a >> standard), and, at that point, the community would be able to set that >> question out on its own, discuss the assumptions, tradeoffs, and >> feasibility of answering it. > > Only one point I want to make in the above statement. If the requirements > document allows every proposed standard then it is not yet complete. It > "should" be written such that it helps to identify the most feasible > solution. The trick, IMHO, is to get specific enough in the requirements > that either one of the existing solutions fits or a better solution gets > designed. If the solutions are close enough together that they all solve > the document then we should just toss a coin . IMHO, I don't agree.... I think all of the proposed solutions meet all of the MUSTs listed in the current requirements, and all miss at least one SHOULD. I've spent some time thinking about this, so I'm not just guessing.... :-) That seems about right, to me. Each of the proposals put forward, thus far, have been put forward by people with serious interest in the topic, and have each taken a long time to develop, so this situation doesn't surprise me at all. :-) 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 Fri Jan 21 15:02: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 PAA12479 for ; Fri, 21 Jan 2005 15:02:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs5Fd-0006mO-RD for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 15:19:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4mT-0003k6-Ka; Fri, 21 Jan 2005 14:49:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4de-0001cU-LJ for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 14:40: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 OAA09972 for ; Fri, 21 Jan 2005 14:40: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 1Cs4tb-0005sG-7B for rpsec@ietf.org; Fri, 21 Jan 2005 14:56:39 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2005 14:47:33 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-290.cisco.com [10.82.225.34]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0LJdboB025493; Fri, 21 Jan 2005 14:39:37 -0500 (EST) Date: Fri, 21 Jan 2005 14:38:56 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: <200501211711.j0LHBZ7C011117@tislabs.com> Message-ID: References: <200501211711.j0LHBZ7C011117@tislabs.com> 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: 0a7aa2e6e558383d84476dc338324fab 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: 244a2fd369eaf00ce6820a760a3de2e8 >> -- A is allocated 10.1.0.0/16. >> -- A suballocates 10.1.1.0/24 to B. >> ... >> Is the originator authorized to advertise the address space in the >> route? In this case, A can advertise 10.1.0.0/16, and the answer is yes, >> even though it actually contains 10.1.1.0/24, for which the answer is >> technically no. > > REALLY???????!!!!!!!!!! > > I've never seen a suggestion that either in spec or in operational > practice, that allocating an address to someone removes your ability to > announce those addresses yourself. My point exactly. What's the correct solution here? Security wise, we have an ownership ambiguity. Operationally, we can't do business without doing it this way. It just won't scale. > Does this really truly happen in practice? "Some 59,000 advertisements, or 55% of the total number of routing table entries, are being used to punch policy holes in existing aggregate announcements." draft-iab-bgparch-02.txt I think that pretty well sums the answer up, though the numbers are from some number of years ago, when a full table was about 120,000 routes. I'd actually expect the percentage is about the same, though, in today's table, and probably higher when you see a really large provider's table, in the range of 250,000 routes or more. > Realize that you are advocating taking on a very hard problem here. IMHO, it's not a solvable problem. In other words, it's logically impossible to solve, without requiring operationally untenable solutions. Two of the examples given in the path considerations draft are built around this problem, explicitely. And this is the reason I say things get a lot harder when you start realizing updates aren't transitive, routing information is, and you need to ask questions about the routing information, rather than the path of the update. In short, if the way the data's arranged precludes certain types of security from being tenable, there's no sense is stating you can provide those types of security in a security requirements document. And that's the nub of the problem with claiming the ability to transitively authorize advertisement of prefixes (routes), rather than updates.... But, I don't want to go there, just point out that there are logical reasons why I don't think we can reach a concensus on the third question from my other email. In any case, I'd rather not bury it by saying: "we'll secure the processes in the BGP draft, and assume the rest will just work." :-) 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 Fri Jan 21 15:05:00 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 PAA12684 for ; Fri, 21 Jan 2005 15:05:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs5Hd-0006rV-Dg for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 15:21:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4z1-0008DX-Ev; Fri, 21 Jan 2005 15:02:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs4kx-0003Mu-0F for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 14: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 OAA10595 for ; Fri, 21 Jan 2005 14:47:41 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs50t-00064v-Ks for rpsec@ietf.org; Fri, 21 Jan 2005 15:04:11 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2005 14:55:06 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-290.cisco.com [10.82.225.34]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0LJl9W1011673; Fri, 21 Jan 2005 14:47:10 -0500 (EST) Date: Fri, 21 Jan 2005 14:46:28 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: <200501211905.j0LJ5mEL014846@tislabs.com> Message-ID: References: <200501211905.j0LJ5mEL014846@tislabs.com> 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: 93238566e09e6e262849b4f805833007 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: 9466e0365fc95844abaf7c3f15a05c7d >> Another example is that operators need the ability to advertise, from >> different AS's, the exact same prefix. A prime example would be a >> network owner that does not do BGP but is multihomed. > > Well, I would say that *when* we are discussing the security > requirements, we would have to look at this operational case, decide if > it needed to be retained and secured, and what it might take to represent > this case and secure this case. (Like: separate the ideas of being > allocated an address from the idea of being authorized to advertise the > origination of an address - just so this case could be represented and > secured.) I think this is actually already covered in the current draft, either as a SHOULD or a MUST. At least, I seem to recall it being in there. Of course, it's not a part of the BGP spec.... :-) 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 Fri Jan 21 16:25:17 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 QAA22451 for ; Fri, 21 Jan 2005 16:25:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs6XM-0001ft-4G for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 16:41:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs5qK-0008VB-9C; Fri, 21 Jan 2005 15:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs5p7-0007jg-GO for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 15:56: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 PAA18467 for ; Fri, 21 Jan 2005 15:56:03 -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 1Cs653-00005e-Ij for rpsec@ietf.org; Fri, 21 Jan 2005 16:12:34 -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 j0LKtDDH025186 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 21 Jan 2005 15:55:14 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 21 Jan 2005 15:55:07 -0500 Subject: Re: [RPSEC] proposed message to the IESG 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: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, kent@bbn.com, Sandy Murphy X-BeenThere: rpsec@ietf.org 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: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit On 1/21/05 2:25 PM, "Russ White" wrote: > >>> I think, if you go back far enough in the thread, I've said this before. I >>> specifically stated that every currently proposed system can meet the >>> requirements as they are written today (S-BGP, IRV, SPV, soBGP, and several >>> others, including off-line databases built IRR databases, etc). Systems >>> may, if they want to, claim _more_ security than the requirements document >>> state (remember, this is informational, and meant to guide, not a >>> standard), and, at that point, the community would be able to set that >>> question out on its own, discuss the assumptions, tradeoffs, and >>> feasibility of answering it. >> >> Only one point I want to make in the above statement. If the requirements >> document allows every proposed standard then it is not yet complete. It >> "should" be written such that it helps to identify the most feasible >> solution. The trick, IMHO, is to get specific enough in the requirements >> that either one of the existing solutions fits or a better solution gets >> designed. If the solutions are close enough together that they all solve >> the document then we should just toss a coin . > > IMHO, I don't agree.... I think all of the proposed solutions meet all of > the MUSTs listed in the current requirements, and all miss at least one > SHOULD. I've spent some time thinking about this, so I'm not just > guessing.... :-) > I just want to parse the sentence a bit... It sounds like you are saying the draft will not be used to aid in the selection process of the security mechanism. I thought that is what we were shooting for? I DO agree that it is possible the draft covers all of the existing solutions. > That seems about right, to me. Each of the proposals put forward, thus far, > have been put forward by people with serious interest in the topic, and > have each taken a long time to develop, so this situation doesn't surprise > me at all. My understanding of the proposals as described matches yours. I know everyone devoted significant effort in development to get us this far. Perhaps, when we get to the protocol specification phase, the best thing to do is evaluate the proposed mechanisms against the requirements draft and see if some form of an almagam is possible? _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 16:51: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 QAA26171 for ; Fri, 21 Jan 2005 16:51:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs6wp-00031h-5h for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 17:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs6I0-0000uf-Fs; Fri, 21 Jan 2005 16:25:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs5xa-0003MB-GC for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 16:04:50 -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 QAA19039 for ; Fri, 21 Jan 2005 16:04:48 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs6DW-0000Ku-Le for rpsec@ietf.org; Fri, 21 Jan 2005 16:21:20 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2005 16:12:13 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-290.cisco.com [10.82.225.34]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0LL49oB016816; Fri, 21 Jan 2005 16:04:15 -0500 (EST) Date: Fri, 21 Jan 2005 16:03:28 -0500 (Eastern Standard Time) From: Russ White To: Blaine Christian Subject: Re: [RPSEC] proposed message to the IESG 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rpsec@ietf.org, kent@bbn.com, Sandy Murphy 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: 769a46790fb42fbb0b0cc700c82f7081 >> IMHO, I don't agree.... I think all of the proposed solutions meet all >> of the MUSTs listed in the current requirements, and all miss at least >> one SHOULD. I've spent some time thinking about this, so I'm not just >> guessing.... :-) > > I just want to parse the sentence a bit... It sounds like you are saying > the draft will not be used to aid in the selection process of the > security mechanism. I thought that is what we were shooting for? I DO > agree that it is possible the draft covers all of the existing solutions. No, there are two differentiators: -- Which shoulds are matched, and which aren't? What are the tradeoffs in this space? -- Is there "extra" security claimed by any of the solutions? How do you evaluate those claims, and what are their tradeoffs, if they are provable? Finally, I think the draft serves another _very_ important purpose, to open the door for other people to think about the problems, and dream up new solutions to the problems. It's always harder to dream up new solutions in a space without something to work with. I think all of these are very good reasons to go forth and require (!). > My understanding of the proposals as described matches yours. I know > everyone devoted significant effort in development to get us this far. > Perhaps, when we get to the protocol specification phase, the best thing > to do is evaluate the proposed mechanisms against the requirements draft > and see if some form of an almagam is possible? I don't see that happening, really.... I don't know that we'll ever have a technical design team to design a solution, but I think that question is up in the air. I'm not certain it's pertinent, though, at this point, we need more community feedback to decide. :-) 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 Fri Jan 21 17: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 RAA28711 for ; Fri, 21 Jan 2005 17:24:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7SD-00042Q-P3 for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 17:40:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7Az-0001Zl-RV; Fri, 21 Jan 2005 17:22:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs73z-0000C1-8k for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 17:15: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 RAA28312 for ; Fri, 21 Jan 2005 17:15:29 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7Jw-0003pE-4f for rpsec@ietf.org; Fri, 21 Jan 2005 17:32: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 j0LMEnjl029755; Fri, 21 Jan 2005 17:14:55 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 21 Jan 2005 17:14:05 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] proposed message to the IESG 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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 At 11:44 AM -0500 1/21/05, Russ White wrote: >>What said is that we are at an impasse re what to use as a basis >>for the requirements. I say this based on the extended discussions >>on the list with Russ, in which he said, repeatedly, that using the >>BGP spec as the primary basis for the requirements document is >>inappropriate. > >Let me clarify this a bit. When I say I don't believe the BGP >specification is a good place to start, what I mean, specifically, >is that the processes described in the BGP specification are not >what we should be trying to secure. What you keep saying is that you don't want to use the BGP specs as a basis for determining security requirements because you prefer to not focus on securing the process but rather the outcome of the process. The problem with this approach is that the specs do not provide a description of the outcome. So, the WG gets into arguments about what the outcome should be, with no objective basis for deciding what is or is not correct. That's why I believe that we need to base the security requirements on the algorithmic aspects of the spec. yes, we all agree that there are some aspects of the requirements that will be outside the scope of the BGP spec, but we have not yet managed to get a clean description of which parts fit where, because you reject the notion of the protocol spec as the primary basis for the security requirements. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 17:26: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 RAA28849 for ; Fri, 21 Jan 2005 17:26:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7UC-00045i-9A for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 17:42:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7B0-0001Zu-5a; Fri, 21 Jan 2005 17:22:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs73z-0000CS-Jp for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 17:15: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 RAA28313 for ; Fri, 21 Jan 2005 17:15:29 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7Jw-0003pA-4b for rpsec@ietf.org; Fri, 21 Jan 2005 17:32: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 j0LMEnjh029755; Fri, 21 Jan 2005 17:14:51 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200501211541.j0LFfBJg007970@tislabs.com> Date: Fri, 21 Jan 2005 17:06:30 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] proposed message to the IESG 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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org 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 At 11:36 AM -0500 1/21/05, Russ White wrote: >>>-- Overlapping address spaces exist. >> >>I don't know what you mean by this. I get the mental image of the >>same address being used by two hosts, but surely that's not what's >>meant, so I'm guessing you mean that authorization for the same >>address space can overlap - that is, two organizations can be >>allocated the same address space. > >In a sense, yes, and in a sense, no. > >-- A is allocated 10.1.0.0/16. >-- A suballocates 10.1.1.0/24 to B. > >IMHO, we care about routes, not updates, and routes contain >prefixes. One of the questions we can ask about those prefixes is: >Is the originator authorized to advertise the address space in the >route? In this case, A can advertise 10.1.0.0/16, and the answer is >yes, even though it actually contains 10.1.1.0/24, for which the >answer is technically no. > >So, in a sense, this address space, 10.1.1.0/24, is legally "owned" >by two entities within the system. Other than redoing the entire >allocation scheme, or disallowing aggregation (forcing A not to >advertise 10.1.0.0/16 when it suballocates space out of it), I don't >see how you get around this problem. > >It's certainly easier to just say: "We'll just worry about the path >the update takes, and not worry about this problem. We'll assume >that if you're authorized to readvertise the update, you're >authorized to transit for this address space, and we'll also assume >you're authorized to allow me to readvertise this address space." > >IMHO, this sort of transitive trust can't exist within a routing >system. We need to focus on the questions we can ask, and base the >requirements on them, rather than the process used to handle updates >according to the BGP specification. > >:-) > >Russ > Russ, You persist in using terms that you ascribe to the models proposed by others (e.g., Sany or me), but we either don't use those terms, or don't use the the way you define them. Sandy pointed out this problem earlier when you kept using the term "prove" and I'll note it again here for the phrase "transitive trust." Don't do this; it confuses matters and in no way helps support your arguments. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 17:28:27 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 RAA28948 for ; Fri, 21 Jan 2005 17:28:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7WV-00048a-SZ for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 17:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7B5-0001cO-5k; Fri, 21 Jan 2005 17:22:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs74D-0000Fp-9w for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 17: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 RAA28322 for ; Fri, 21 Jan 2005 17:15:43 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7K9-0003q2-4J for rpsec@ietf.org; Fri, 21 Jan 2005 17:32:15 -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 j0LMEnjj029755; Fri, 21 Jan 2005 17:14:53 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 21 Jan 2005 16:53:51 -0500 To: Blaine Christian From: Stephen Kent Subject: Re: [RPSEC] proposed message to the IESG 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 12:02 PM -0500 1/21/05, Blaine Christian wrote: >Hey Steve, > >I suppose when you have an operator as editor you will get a bit of >operator slant . One perspective might be that, in most >venues, the potential customers of a service usually drive the >requirements. We do have protocol developers on this thread and >writing for the draft itself. My perception is that the value I add >to the process is giving people a perspective on what operators >would find deployable. We all bring our own perspectives to the table. The WG co-chairs chose you to be the lead editor and thus one could say that they implicitly endorsed the idea of bringing an operations slant to the document. However, the WG charter does not state that, and the home for the WG is not the operations area. That, in part, is why I suggested two weeks ago to bring this issue to the IESG. >I will try to go back through and find your text recommendations. I >was hoping to apply the consensual view to the document. When >vigorous debate ensued I decided to wait and see if we could come to >terms. I'll get back to you with specific suggestions relative to the original text (vs. the comments I made relative to the suggestions Russ, made). >I know it is asking a lot... But if we could approach this in small >chunks maybe we can address specific concerns point by point. My >thought is that we should encompass the needs of the BGP spec in a >way that addresses the manner in which things were actually deployed >(if that makes any sense). Working on this a chunk at a time makes sense to me too. My problem with the "the way things are actually deployed" aspect of this is that it puts all of us non-operations folks at a disadvantage in the discussion. The BGP spec is readily available to all of us, and it represents an IETF approved document. How BGP is deployed and how ISPs make use of it is not documented in the same fashion, seems subject to more interpretation, and thus represents a more contentious basis for our discussions. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 17:30: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 RAA29101 for ; Fri, 21 Jan 2005 17:30:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7Yp-0004CU-Fn for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 17:47:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7B7-0001eG-Om; Fri, 21 Jan 2005 17:22:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs74b-0000GX-G4 for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 17:16: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 RAA28328 for ; Fri, 21 Jan 2005 17:16:07 -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 1Cs7KX-0003qS-9K for rpsec@ietf.org; Fri, 21 Jan 2005 17:32:39 -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 j0LMFTDH026075 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 21 Jan 2005 17:15:29 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 21 Jan 2005 17:15:22 -0500 Subject: Re: [RPSEC] proposed message to the IESG 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: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, kent@bbn.com, Sandy Murphy X-BeenThere: rpsec@ietf.org 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: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit > -- Which shoulds are matched, and which aren't? What are the tradeoffs in > this space? > Very good point. I think this leads us towards doing some work further refining, somehow, the relative priorities of the shoulds. > -- Is there "extra" security claimed by any of the solutions? How do you > evaluate those claims, and what are their tradeoffs, if they are provable? > Is that something that should be documented? I doubt discussion will resolve those questions (as we have historic proof that it does not seem to work). This could be something where we can develop a weighting system and select the aspects that are perceived as important and rate them. After we agree on the items to be weighted we can assign a numeric rating to each proposed solution (on the specific aspect under review). Once each aspect has a rating we let the scoring system decide. I was heavily involved with this process for an employer before. It seems to work well with large groups of decision makers. Items that are "MUST" would be in a class all their own (where a failure to meet a MUST is criteria for immediate abandonment until revision). > Finally, I think the draft serves another _very_ important purpose, to open > the door for other people to think about the problems, and dream up new > solutions to the problems. It's always harder to dream up new solutions in > a space without something to work with. > > I think all of these are very good reasons to go forth and require (!). > I agree with that. Without getting the needs documented designing (or deciding) on something is pretty futile. >> My understanding of the proposals as described matches yours. I know >> everyone devoted significant effort in development to get us this far. >> Perhaps, when we get to the protocol specification phase, the best thing >> to do is evaluate the proposed mechanisms against the requirements draft >> and see if some form of an almagam is possible? > > I don't see that happening, really.... I don't know that we'll ever have a > technical design team to design a solution, but I think that question is up > in the air. I'm not certain it's pertinent, though, at this point, we need > more community feedback to decide. Well, I suspect that we will get the almagam even if it happens without being overtly stated. I recall several hallway conversations where folks identified bits that they could incorporate within their specifications (from other specifications). On a completely different topic that is in no way directed towards anyone in particular... I would love it if we could all try to forget about the proposed systems and focus on the requirements first. If we can get the proposed systems out of our heads we can focus on how to optimize the requirements such that we can achieve optimal deployment of a new system. If we can get the requirements optimized such that deployment is broad we can improve overall security of the inter-domain routing system. While we may not be able to perfectly secure the system and please all the developers on this thread, we can, perhaps, make things safer and pave the way for future improvements to the security of distributed prefixes. BTW, I am just as guilty about thinking about the solutions (as evidenced by the paragraph before the one above). _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 17:35: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 RAA29403 for ; Fri, 21 Jan 2005 17:35:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7dU-0004K7-DJ for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 17:52:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7MG-0004xm-TT; Fri, 21 Jan 2005 17:34:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7Fq-0003Ar-U1 for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 17:27: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 RAA28913 for ; Fri, 21 Jan 2005 17:27:44 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7Vm-00047d-1C for rpsec@ietf.org; Fri, 21 Jan 2005 17:44:17 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LMOHkZ012187 for ; Fri, 21 Jan 2005 17:24:17 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAngaaZx; Fri, 21 Jan 05 17:24:14 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LMQ0lf024149; Fri, 21 Jan 2005 17:26:00 -0500 (EST) Date: Fri, 21 Jan 2005 17:26:00 -0500 (EST) From: Sandy Murphy Message-Id: <200501212226.j0LMQ0lf024149@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a > amen to this.. as an operator, we do have cases where > there is -NOT- a unique orign AS for a given prefix. I say again - there's a difference in the address being allocated to two different organizations and the address being advertised by two different organizations. --Sandy > amen to this.. as an operator, we do have cases where > there is -NOT- a unique orign AS for a given prefix. I say again - there's a difference in the address being allocated to two different organizations and the address being advertised by two different organizations. And, again, that an example of the distinctions we'd have to make as we tried to define the security requirements. Rather than say "oh, you can't represent this, so it is not secureable", you would say "this is done now, it is important to continue to do, so how would you represent it so it could be secured". --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 17:37: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 RAA29527 for ; Fri, 21 Jan 2005 17:37:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7f5-0004MA-UW for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 17:53:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7MJ-00050A-P7; Fri, 21 Jan 2005 17: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 1Cs7J9-0003gZ-Qn for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 17:31: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 RAA29119 for ; Fri, 21 Jan 2005 17:31:09 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7Z6-0004CI-TN for rpsec@ietf.org; Fri, 21 Jan 2005 17:47:42 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 21 Jan 2005 17:30:40 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-290.cisco.com [10.82.225.34]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0LMUbW1023156; Fri, 21 Jan 2005 17:30:37 -0500 (EST) Date: Fri, 21 Jan 2005 17:29:56 -0500 (Eastern Standard Time) From: Russ White To: Stephen Kent Subject: Re: [RPSEC] proposed message to the IESG 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: 9ed51c9d1356100bce94f1ae4ec616a9 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: 769a46790fb42fbb0b0cc700c82f7081 See my email to Sandy. I think I've explained myself enough times on list, and I don't see how this email contributes to the conversation. I've not seen a single refutation of any reason I've given for my position, other than a continuing statement: "We should base the requirements on the algorithms in the BGP specification" repeated over and over again. :-) Russ On Fri, 21 Jan 2005, Stephen Kent wrote: > At 11:44 AM -0500 1/21/05, Russ White wrote: >>> What said is that we are at an impasse re what to use as a basis for the >>> requirements. I say this based on the extended discussions on the list >>> with Russ, in which he said, repeatedly, that using the BGP spec as the >>> primary basis for the requirements document is inappropriate. >> >> Let me clarify this a bit. When I say I don't believe the BGP specification >> is a good place to start, what I mean, specifically, is that the processes >> described in the BGP specification are not what we should be trying to >> secure. > > What you keep saying is that you don't want to use the BGP specs as a basis > for determining security requirements because you prefer to not focus on > securing the process but rather the outcome of the process. The problem with > this approach is that the specs do not provide a description of the outcome. > So, the WG gets into arguments about what the outcome should be, with no > objective basis for deciding what is or is not correct. That's why I believe > that we need to base the security requirements on the algorithmic aspects of > the spec. > > yes, we all agree that there are some aspects of the requirements that will > be outside the scope of the BGP spec, but we have not yet managed to get a > clean description of which parts fit where, because you reject the notion of > the protocol spec as the primary basis for the security requirements. > > Steve > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 17:51:17 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 RAA00294 for ; Fri, 21 Jan 2005 17:51:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7sZ-0004i6-OQ for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 18:07:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7We-0008AY-Du; Fri, 21 Jan 2005 17:45:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7UK-0007K8-8B for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 17:42: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 RAA29780 for ; Fri, 21 Jan 2005 17:42:41 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7kH-0004TJ-34 for rpsec@ietf.org; Fri, 21 Jan 2005 17:59:14 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2005 17:50:07 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-290.cisco.com [10.82.225.34]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0LMg8oB010184; Fri, 21 Jan 2005 17:42:08 -0500 (EST) Date: Fri, 21 Jan 2005 17:41:26 -0500 (Eastern Standard Time) From: Russ White To: Blaine Christian Subject: Re: [RPSEC] proposed message to the IESG 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: bdc523f9a54890b8a30dd6fd53d5d024 Cc: rpsec@ietf.org, kent@bbn.com, Sandy Murphy 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: 3002fc2e661cd7f114cb6bae92fe88f1 >> -- Which shoulds are matched, and which aren't? What are the tradeoffs in >> this space? > > Very good point. I think this leads us towards doing some work further > refining, somehow, the relative priorities of the shoulds. > >> -- Is there "extra" security claimed by any of the solutions? How do you >> evaluate those claims, and what are their tradeoffs, if they are provable? > > Is that something that should be documented? I doubt discussion will > resolve those questions (as we have historic proof that it does not seem > to work). This could be something where we can develop a weighting > system and select the aspects that are perceived as important and rate > them. After we agree on the items to be weighted we can assign a numeric > rating to each proposed solution (on the specific aspect under review). > Once each aspect has a rating we let the scoring system decide. I was > heavily involved with this process for an employer before. It seems to > work well with large groups of decision makers. No, I don't think so.... I would leave this out, or we'll rat hole on each item, and never actually have a draft. Part of the point here is that we can push things we never reach concensus into this category, and actually get a draft out the door at some point, IMHO. :-) > Items that are "MUST" would be in a class all their own (where a failure > to meet a MUST is criteria for immediate abandonment until revision). Yes, and I think the draft, as it sits, accurately represents the correct set of shoulds and musts. I would rather see serious discussion on that topic than the rathole about what we should base the draft on, myself. > On a completely different topic that is in no way directed towards anyone > in particular... I would love it if we could all try to forget about the > proposed systems and focus on the requirements first. If we can get the > proposed systems out of our heads we can focus on how to optimize the > requirements such that we can achieve optimal deployment of a new system. > If we can get the requirements optimized such that deployment is broad we > can improve overall security of the inter-domain routing system. While > we may not be able to perfectly secure the system and please all the > developers on this thread, we can, perhaps, make things safer and pave > the way for future improvements to the security of distributed prefixes. Sure, but we have to get past this question: Should we toss the draft as it sits today, and rewrite it based strictly on the processes/algorithms described in the BGP specifications? Specifically, as it concerns the contents of an "update" (not a transitive object in BGP), should we: -- Describe how the update should be secured (any proposed solution must be able to verify the path taken by the update is the same as the as path in the update). --OR-- -- Describe what things must and/should be asserted as true or false based on the routing data contained within an update (any proposed system must verify the as path is correct, with correct meaning x, y, and z, and the appropriate should and must in each case). That seems to be the critical question at this moment. IMHO: -- The current draft does the second. -- The second is the correct way to approach the problem. -- The first is a solution, not a requirement, for the reasons I've listed elsewhere. :-) 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 Fri Jan 21 17:54: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 RAA00481 for ; Fri, 21 Jan 2005 17:54:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7vU-0004nQ-9b for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 18:10:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7dq-0000w4-3G; Fri, 21 Jan 2005 17:52:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7Y1-0008HA-UM for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 17:46: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 RAA00016 for ; Fri, 21 Jan 2005 17:46:31 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7nz-0004Zs-Sh for rpsec@ietf.org; Fri, 21 Jan 2005 18:03:04 -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 j0LMk1jf001036; Fri, 21 Jan 2005 17:46:01 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200501211716.j0LHGr5r011286@tislabs.com> Date: Fri, 21 Jan 2005 17:45:46 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] proposed message to the IESG 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org 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: 856eb5f76e7a34990d1d457d8e8e5b7f Russ, >This business about the requirements "not being based on the BGP >specification" is a red herring, IMHO, meant to push requirements >into the draft without actually discussing those requirements, or >without actually considering the tradeoffs, etc, as they really >exist. This is obnoxious and calls into question whether you can serve (impartially) as WG co-chair. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 17:56: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 RAA00620 for ; Fri, 21 Jan 2005 17:56:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7xb-0004rH-1i for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 18:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7dq-0000wl-IX; Fri, 21 Jan 2005 17:52:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs7Y6-0008HC-JP for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 17:46:38 -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 RAA00019 for ; Fri, 21 Jan 2005 17:46:35 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs7o4-0004a1-DS for rpsec@ietf.org; Fri, 21 Jan 2005 18:03:08 -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 j0LMk1jh001036; Fri, 21 Jan 2005 17:46:03 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200501211711.j0LHBZ7C011117@tislabs.com> Date: Fri, 21 Jan 2005 17:45:17 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] proposed message to the IESG 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: b280b4db656c3ca28dd62e5e0b03daa8 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org 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 At 2:38 PM -0500 1/21/05, Russ White wrote: >>>-- A is allocated 10.1.0.0/16. >>>-- A suballocates 10.1.1.0/24 to B. >>>... > >>>Is the originator authorized to advertise the address space in the >>>route? In this case, A can advertise 10.1.0.0/16, and the answer >>>is yes, even though it actually contains 10.1.1.0/24, for which >>>the answer is technically no. >> >>REALLY???????!!!!!!!!!! >> >>I've never seen a suggestion that either in spec or in operational >>practice, that allocating an address to someone removes your >>ability to announce those addresses yourself. > >My point exactly. What's the correct solution here? Security wise, >we have an ownership ambiguity. Operationally, we can't do business >without doing it this way. It just won't scale. > >>Does this really truly happen in practice? > >"Some 59,000 advertisements, or 55% of the total number of routing >table entries, are being used to punch policy holes in existing >aggregate announcements." draft-iab-bgparch-02.txt > >I think that pretty well sums the answer up, though the numbers are >from some number of years ago, when a full table was about 120,000 >routes. I'd actually expect the percentage is about the same, >though, in today's table, and probably higher when you see a really >large provider's table, in the range of 250,000 routes or more. > >>Realize that you are advocating taking on a very hard problem here. > >IMHO, it's not a solvable problem. In other words, it's logically >impossible to solve, without requiring operationally untenable >solutions. Two of the examples given in the path considerations >draft are built around this problem, explicitely. > >And this is the reason I say things get a lot harder when you start >realizing updates aren't transitive, routing information is, and you >need to ask questions about the routing information, rather than the >path of the update. In short, if the way the data's arranged >precludes certain types of security from being tenable, there's no >sense is stating you can provide those types of security in a >security requirements document. And that's the nub of the problem >with claiming the ability to transitively authorize advertisement of >prefixes (routes), rather than updates.... But, I don't want to go >there, just point out that there are logical reasons why I don't >think we can reach a concensus on the third question from my other >email. > >In any case, I'd rather not bury it by saying: "we'll secure the >processes in the BGP draft, and assume the rest will just work." Russ, I've sent several messages that explain how one should deal with advertisements for short and longer prefixes that overlap, and I cited text from the BGP spec to substantiate my argument. (Do you have a serious mail delivery problem :-)?) this is not an insolvable problem, except to the extent that your assert arbitrary constraints about how to address it. And solving it does not require reliance on BGP practice vs. the BGP spec. it just requires a careful reading of the spec. For example, in my message of 1/6/05 (5:15 PM) in response to this same sort of example that you presented I said: >You would not want to stop ISP A from advertising the /16. It is >authorized to do so by its initial allocation of this prefix from an >RIR or IANA. I'm not sure where you have derived the notion that the >ISP is not authorized to advertise the /16 because of its allocation >of the /24 to a subscriber. This is certainly NOT an S-BGP concept. >The words you are using suggest to me that you have a vague notion >of what I mean when I speak about authorization, but that notion is >inaccurate. I think several of my previous messages have included >text that make clear that this sort of allocation by an ISP is NOT a >problem. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 18:25: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 SAA03328 for ; Fri, 21 Jan 2005 18:25:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8QC-0005WH-8s for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 18:42:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs83x-0007B6-DJ; Fri, 21 Jan 2005 18:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs82m-0006LZ-Ho for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 18:18: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 SAA02730 for ; Fri, 21 Jan 2005 18:18:18 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8Il-0005M4-2l for rpsec@ietf.org; Fri, 21 Jan 2005 18:34:51 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LNErcG016292 for ; Fri, 21 Jan 2005 18:14:53 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4CaGZF; Fri, 21 Jan 05 18:14:51 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LNGXut025350; Fri, 21 Jan 2005 18:16:33 -0500 (EST) Date: Fri, 21 Jan 2005 18:16:33 -0500 (EST) From: Sandy Murphy Message-Id: <200501212316.j0LNGXut025350@tislabs.com> To: riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 >>> -- A is allocated 10.1.0.0/16. >>> -- A suballocates 10.1.1.0/24 to B. >>> ... > >>> Is the originator authorized to advertise the address space in the >>> route? In this case, A can advertise 10.1.0.0/16, and the answer is yes, >>> even though it actually contains 10.1.1.0/24, for which the answer is >>> technically no. >> >> REALLY???????!!!!!!!!!! >... >> I've never seen a suggestion that either in spec or in operational >> practice, that allocating an address to someone removes your ability to >> announce those addresses yourself. > >My point exactly. So you are agreeing that you've never seen this either in a spec or in an operational practice? Then what makes you think it is true? (Not a completely facetious question - I'd like to find out.) I'm pretty sure I must not be understanding correctly here. Russ, you seem to be saying that if a tier-1 AS allocates a subblock of its allocated address space, that it is technically NOT ALLOWED to continue to advertise that address space. Is that a correct statement of what you are saying? I hope Blaine would chime in on that one. Do you want to be continue that requirement and to represent that in the security requirements? >"Some 59,000 advertisements, or 55% of the total number of routing table >entries, are being used to punch policy holes in existing aggregate >announcements." draft-iab-bgparch-02.txt But all the bgparch (now RFC3221) says is that people advertise more specific prefixes for various reasons, policies being one of them. I don't read into that a statement that the aggregate announcement is (technically) not allowed to be advertised. I'm looking for a suggestion that an AS is *N*O*T**A*L*L*O*W*E*D to continue to advertise a part of its own address space that it had suballocated. Or indeed that the sub-allocat-ee would want them to cease to advertise the allocated sub-space. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 18:42: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 SAA04500 for ; Fri, 21 Jan 2005 18:42:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8gD-0005uX-J7 for rpsec-web-archive@ietf.org; Fri, 21 Jan 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 1Cs8P0-0004pn-PX; Fri, 21 Jan 2005 18:41:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8Nm-0004DQ-8u for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 18:40: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 SAA04262 for ; Fri, 21 Jan 2005 18:39:59 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8dj-0005pk-W8 for rpsec@ietf.org; Fri, 21 Jan 2005 18:56:33 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LNaYc6017679 for ; Fri, 21 Jan 2005 18:36:34 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5faOHI; Fri, 21 Jan 05 18:36:32 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LNcIB1025766; Fri, 21 Jan 2005 18:38:18 -0500 (EST) Date: Fri, 21 Jan 2005 18:38:18 -0500 (EST) From: Sandy Murphy Message-Id: <200501212338.j0LNcIB1025766@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 >> I disagree strongly that the statement is "meaningful" unless and until >> you have decided on the *meaning* of "verify the path". > >That's actually correct. You are agreeing with me that we need to define "verify the path"? >What I mean by "meaningful" is that the path >actually exists, that there is a way from my peer, who has advertised that >path, to the destination stated in the route. (a) If you agree that we need to define "verify the path", why are you defining "meaningful"? (b) Your definition sounds to me like a definition of "verify the path", not a definition of "meaningful", anyway. (c) I know you'll hate me for bringing up definitions again, but -- by "exist", you mean "two AS's adjacent in the AS_PATH have a peering relationship?" --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 18:46: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 SAA04856 for ; Fri, 21 Jan 2005 18:46:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8kT-00063D-CP for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 19:03:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8S4-0005lK-S9; Fri, 21 Jan 2005 18:44:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8PZ-0004rt-Js for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 18:41:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04476 for ; Fri, 21 Jan 2005 18:41:50 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8fX-0005st-AS for rpsec@ietf.org; Fri, 21 Jan 2005 18:58:24 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Jan 2005 18:41:22 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-290.cisco.com [10.82.225.34]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0LNfGoB020343; Fri, 21 Jan 2005 18:41:17 -0500 (EST) Date: Fri, 21 Jan 2005 18:40:37 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: <200501212316.j0LNGXut025350@tislabs.com> Message-ID: References: <200501212316.j0LNGXut025350@tislabs.com> 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: f60d0f7806b0c40781eee6b9cd0b2135 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: fb6060cb60c0cea16e3f7219e40a0a81 >>>> -- A is allocated 10.1.0.0/16. >>>> -- A suballocates 10.1.1.0/24 to B. >>>> ... >> >>>> Is the originator authorized to advertise the address space in the >>>> route? In this case, A can advertise 10.1.0.0/16, and the answer is yes, >>>> even though it actually contains 10.1.1.0/24, for which the answer is >>>> technically no. >>> >>> REALLY???????!!!!!!!!!! >> ... >>> I've never seen a suggestion that either in spec or in operational >>> practice, that allocating an address to someone removes your ability to >>> announce those addresses yourself. >> >> My point exactly. > So you are agreeing that you've never seen this either in a spec or in an > operational practice? You missed the rest of my sentence? "What's the correct solution here? Security wise, we have an ownership ambiguity. Operationally, we can't do business without doing it this way. It just won't scale." This doesn't imply I know of a policy, or that I believe there to be a policy, but rather I'm pointing out an ambiguous situation. > I'm pretty sure I must not be understanding correctly here. > > Russ, you seem to be saying that if a tier-1 AS allocates a subblock of > its allocated address space, that it is technically NOT ALLOWED to > continue to advertise that address space. Is that a correct statement of > what you are saying? > I'm looking for a suggestion that an AS is *N*O*T**A*L*L*O*W*E*D to > continue to advertise a part of its own address space that it had > suballocated. Or indeed that the sub-allocat-ee would want them to cease > to advertise the allocated sub-space. Okay, so say A owns 10.1.0.0/16. A suballocates 10.1.1.0/24 to B, so B now owns 10.1.1.0/24. -- Would you say 10.1.1.0/24 is a part of 10.1.0.0/16, so that by advertising 10.1.0.0/16, you are, in fact, also advertising reachability to 10.1.1.0/24? -- Would you say that A advertising 10.1.0.0/16 is, in fact, advertising B's address space? -- If your answer to these two questions is yes, what is your conclusion? >From a pure security perspective, would you say A should be able to continue advertising 10.1.0.0./16? I'm not stating this is a current policy anyplace, etc, I'm simply asking what you think. I don't know of any policy or specification stating A should stop advertising 10.1.0.0/16. In fact, I've asserted A actually continues advertising 10.1.0.0/16 in the real world. I'm confused that you're confused about what I'm saying.... :-) :-) 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 Fri Jan 21 18:48: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 SAA04982 for ; Fri, 21 Jan 2005 18:48:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8mQ-00065Z-Dl for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 19:05:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8UC-00067m-6M; Fri, 21 Jan 2005 18:46:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8Rf-0005ck-Nl for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 18:44: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 SAA04669 for ; Fri, 21 Jan 2005 18:44:01 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8he-0005xq-Fq for rpsec@ietf.org; Fri, 21 Jan 2005 19:00:34 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LNebgj018037 for ; Fri, 21 Jan 2005 18:40:37 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAMsaGoJ; Fri, 21 Jan 05 18:40:34 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LNgLYV025873; Fri, 21 Jan 2005 18:42:21 -0500 (EST) Date: Fri, 21 Jan 2005 18:42:21 -0500 (EST) From: Sandy Murphy Message-Id: <200501212342.j0LNgLYV025873@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 >Suppose you state: "A speaker >should be able to prove the update has passed through the AS' listed in the >as path," as a requirement. Now, my question is going to be: "Why? What do >you want to prove by verifying this in this way? Your answer is going to >be: "Because proving this proves the path actually exists, and can prove >non-repudiation, and...." Well, no, that's not what my answer would be. My answer would be: Answer 1: that's what the spec says happens If you were teaching a class in BGP and people had been studying the spec, and you put the following question on the test: AS A receives an update from B containing a route with the AS_PATH set to {B,C,D}. Which of the following does your implementation assume in deciding what to do with this update? (Choose the most complete answer.) (a) AS A is connected to AS B (b) B peers with C. C peers with D. D is connected to the NLRI. We don't know how B came by this AS_PATH. (c) B received an update from C containing (C,D) and C received an update from D containing {D}, and D is connected to the NLRI (d) traffic to the NLRI sent to B will be passed to C and then to D. I would say that the correct answer was (c). And, yes, I know that the correct answer is not (d). -------------------- Answer 2: that's a fairly succinct statement that covers (all, most) of the cases of things we want to prevent. Case 1: The spec says that the AS_PATH is used to detect loops. Therefore, noone should be able to delete AS's from the AS_PATH. And I don't think this is OK even if the resulting AS_PATH has valid adjacencies. Do you think it would be OK? (Question, not challenge.) Case 2: The operational common practice is that a shorter AS_PATH is the better AS_PATH. So no one should be able to change the length of the AS_PATH. (This is not a spec requirement, but it is so widely implemented, it comes close. And, incidentally, IMHO, derived from the expectation that the AS_PATH represents the AS's through which this information has traveled.) If someone changed the length of the AS_PATH, but the resulting AS_PATH had valid adjacencies, do you think it would be OK? (Question, not challenge.) Case 3: Suppose when an AS is composing the AS_PATH of an update, it completely scrambles the order of the AS's from their sequence in the AS_PATH of the Loc_RIB_In entry it choose. The resulting order accidentally matches valid adjacencies, but bears no relationship to the order of AS's by which the information got there. Is that OK? Honestly, I have no opinion whether that is OK or not. It's not going to hurt the length checking and its not going to hurt loop checking - but as soon as someone decides to make a policy on the basis of AS order in the AS_PATH, you'd have a problem. Case 4: Suppose an AS chooses a route which would have an AS_PATH of length X, and it puts an AS_PATH in the update it sends which has length X but has no other bearing to the AS_PATH of the route it has chosen. It uses this same length X AS_PATH for all updates it sends for which the route it chose would have an AS_PATH of length X. So the length is correct, and the AS_PATH adjacencies all check. Is that OK? I would say not, because it removes the ability to check for loops. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 19:09: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 TAA07861 for ; Fri, 21 Jan 2005 19:09:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs96l-0006gl-2U for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 19:26:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8ek-0000K2-7J; Fri, 21 Jan 2005 18:57:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8ap-0007YP-7A for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 18:53: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 SAA05321 for ; Fri, 21 Jan 2005 18:53:28 -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 1Cs8qn-0006AM-OX for rpsec@ietf.org; Fri, 21 Jan 2005 19:10: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 j0LNqwDH027259 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Fri, 21 Jan 2005 18:52:59 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 21 Jan 2005 18:52:52 -0500 Subject: Re: [RPSEC] proposed message to the IESG From: Blaine Christian To: Sandy Murphy , Russ White Message-ID: In-Reply-To: <200501212316.j0LNGXut025350@tislabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit > > I'm pretty sure I must not be understanding correctly here. > > Russ, you seem to be saying that if a tier-1 AS allocates a subblock of its > allocated address space, that it is technically NOT ALLOWED to continue > to advertise that address space. Is that a correct statement of what > you are saying? > > I hope Blaine would chime in on that one. Okay... I can give you common practice from my perspective. Common practice is that an ISP will delegate a more specific prefix to a customer. All the ISP usually cares about is advertising the less specific prefix. It is normally a bad idea for the owner of a less specific chunk of prefixes who has allocated a more specific prefix to a customer to advertise that more specific prefix on their own (unless they are propagating a BGP advert). This is left to the customer to decide. So, it is technically "allowed" but it would be considered inappropriate unless there are unusual circumstances. Please realize that the above paragraph relates specifically to BGP. However, even with static allocations I would be hard pressed to find common examples of an ISP bothering (or desiring etc.) to advertise a specifically allocated sub-block. A, somewhat notable, diversion from this would be the use of BGP and deaggregation to effect loadsharing between two different AS'. I have done this in the past but I have had to do a lot of crazy things with BGP to get the job done. The one "loaner" chunk of information that I HAVE seen as pretty much forbidden by many is the use of a "loaner" AS outside of the owners control. Even this is not illegal in the protocol, obviously, but it does create all sorts of complications which contra-indicate its use (path loops getting interesting here). > > Do you want to be continue that requirement and to represent that > in the security requirements? > >> "Some 59,000 advertisements, or 55% of the total number of routing table >> entries, are being used to punch policy holes in existing aggregate >> announcements." draft-iab-bgparch-02.txt > > But all the bgparch (now RFC3221) says is that people advertise > more specific prefixes for various reasons, policies being one > of them. > > I don't read into that a statement that the aggregate announcement > is (technically) not allowed to be advertised. > > I'm looking for a suggestion that an AS is *N*O*T**A*L*L*O*W*E*D > to continue to advertise a part of its own address space that it had > suballocated. Or indeed that the sub-allocat-ee would want them > to cease to advertise the allocated sub-space. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 19:17:48 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 TAA08712 for ; Fri, 21 Jan 2005 19:17:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9EM-000709-Ei for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 19:34:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8s6-0004ZK-9o; Fri, 21 Jan 2005 19:11:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8fH-0000Qf-BQ for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 18:58: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 SAA06901 for ; Fri, 21 Jan 2005 18:58:04 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8vF-0006NA-7s for rpsec@ietf.org; Fri, 21 Jan 2005 19:14:38 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0LNsdnh019644 for ; Fri, 21 Jan 2005 18:54:39 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAE6aqxM; Fri, 21 Jan 05 18:54:37 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0LNuNGf026270; Fri, 21 Jan 2005 18:56:23 -0500 (EST) Date: Fri, 21 Jan 2005 18:56:23 -0500 (EST) From: Sandy Murphy Message-Id: <200501212356.j0LNuNGf026270@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 >Okay, so say A owns 10.1.0.0/16. A suballocates 10.1.1.0/24 to B, so B now >owns 10.1.1.0/24. > >-- Would you say 10.1.1.0/24 is a part of 10.1.0.0/16, so that by >advertising 10.1.0.0/16, you are, in fact, also advertising reachability to >10.1.1.0/24? > >-- Would you say that A advertising 10.1.0.0/16 is, in fact, advertising >B's address space? > >-- If your answer to these two questions is yes, what is your conclusion? My answer would be yes to both questions - A is allowed to continue to advertise reachability to addresses it has sub-allocated to B. And I don't see a problem with that. Surely that's OK? A will still be able to reach B, surely? Blackholes aside. So parts of the world that do see B's announcement will send traffic by that route and if there are parts of the world that see A's announcement but not B's (could happen, right?) will send the traffic through A. (Leaving aside the case of the non-BGP-speaker who is allocated addresses.) I'm ok with the definition of authorized-to-advertise as "has been allocated", which does not say "has been allocated and has not suballocated". --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 19:18: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 TAA08760 for ; Fri, 21 Jan 2005 19:18:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9Ex-00070z-MD for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 19:34:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8s9-0004Zv-0e; Fri, 21 Jan 2005 19:11:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs8go-0000ZZ-Cg for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 18:59:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07046 for ; Fri, 21 Jan 2005 18:59:39 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs8wm-0006On-61 for rpsec@ietf.org; Fri, 21 Jan 2005 19:16:13 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 21 Jan 2005 16:00:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0LNx7RO024712; Fri, 21 Jan 2005 15:59:08 -0800 (PST) Received: from boraw2k05 ([10.32.241.194]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVU48162; Fri, 21 Jan 2005 15:59:06 -0800 (PST) Message-Id: <200501212359.AVU48162@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'Sandy Murphy'" , Subject: RE: [RPSEC] proposed message to the IESG Date: Fri, 21 Jan 2005 15:59:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200501212226.j0LMQ0lf024149@tislabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-index: AcUACaTUR42DhKPQQTic+AuleAx4CAAC3SWQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit > -----Original Message----- > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] > On Behalf Of Sandy Murphy > Sent: Friday, January 21, 2005 2:26 PM > To: rpsec@ietf.org > Cc: sandy@tislabs.com > Subject: Re: [RPSEC] proposed message to the IESG > > > amen to this.. as an operator, we do have cases where > > there is -NOT- a unique orign AS for a given prefix. > > I say again - there's a difference in the address being > allocated to two different organizations and the address > being advertised by two different organizations. > Sandy This DOES happen, in fact there was a UCLA paper on this topic a while back. Bora _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 19:35: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 TAA09855 for ; Fri, 21 Jan 2005 19:35:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9V2-0007Sj-8P for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 19:51:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs9CL-0003Oh-Gl; Fri, 21 Jan 2005 19:32:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs97G-0001pz-H6 for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 19:27: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 TAA09487 for ; Fri, 21 Jan 2005 19:26:59 -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 1Cs9NE-0007I9-En for rpsec@ietf.org; Fri, 21 Jan 2005 19:43:33 -0500 Received: from [172.17.19.3] (helo=[172.17.19.3]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1Cs978-0003f2-TD; Sat, 22 Jan 2005 01:26:55 +0100 Message-ID: <41F19DC9.4080600@schlund.net> Date: Sat, 22 Jan 2005 01:26:49 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG References: <200501212356.j0LNuNGf026270@tislabs.com> In-Reply-To: <200501212356.j0LNuNGf026270@tislabs.com> 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 X-BeenThere: rpsec@ietf.org 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="===============1743695193==" 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) --===============1743695193== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig037114563EF143FDEE2BFAEC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig037114563EF143FDEE2BFAEC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sandy Murphy wrote: >(Leaving aside the case of the non-BGP-speaker who is allocated >addresses.) I'm ok with the definition of authorized-to-advertise >as "has been allocated", which does not say "has been allocated and >has not suballocated". > > I agree with you that this is the current state, but is it granted to always be like this? What if for whatever reason an RIR changes its policy... ? This would have to be somehow taken into account when verifying the origin authorization of a route. tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig037114563EF143FDEE2BFAEC 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.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB8Z3JehvPYvDU0roRAsRjAKCvheiRwrcvuQXNOKwyK0AlnF46awCghOew 7DVNrI4BPS85eIonoUTq3GE= =Ontj -----END PGP SIGNATURE----- --------------enig037114563EF143FDEE2BFAEC-- --===============1743695193== 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 --===============1743695193==-- From rpsec-bounces@ietf.org Fri Jan 21 20:07: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 UAA12250 for ; Fri, 21 Jan 2005 20:07:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsA0o-0008Dw-Qc for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 20:24:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs9jN-0003Bx-Hd; Fri, 21 Jan 2005 20:06:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cs9cb-0001lW-Un for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 19:59: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 TAA11631 for ; Fri, 21 Jan 2005 19:59:22 -0500 (EST) Received: from server2.tcw.telecomplete.net ([213.160.116.2] helo=mx-0.telecomplete.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cs9sa-00082C-1e for rpsec@ietf.org; Fri, 21 Jan 2005 20:15:57 -0500 Received: from server2.tcw.telecomplete.net ([127.0.0.1]) by mx-0.telecomplete.net with esmtp (Exim 4.22) id 1Cs9cP-0004yA-Eu; Sat, 22 Jan 2005 00:59:13 +0000 Date: Sat, 22 Jan 2005 00:59:13 +0000 (GMT) From: "Stephen J. Wilcox" X-X-Sender: steve@server2.tcw.telecomplete.net To: Blaine Christian Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: rpsec@ietf.org, Russ White , Sandy Murphy X-BeenThere: rpsec@ietf.org 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: 32b73d73e8047ed17386f9799119ce43 Hi Blaine, I'm dropping in suggestions late here without reading the whole thread in detail and the thread seems to have forked a bit too! ISPs appear to commonly allocate IPs whilst remaining to announce the less specific (i think thats what Sandy was saying). There are also lots of ISPs announcing more specifics as well as the less specific all from their own ASN. I've not encountered any ISPs who suballoc a block then announce that specific block from their own ASN altho if a block is being moved from one ASN to another, or even if the allocating ISP bought the customer and is going thro a migration process then I can see reasons why these situations might exist for a temporary period... Steve On Fri, 21 Jan 2005, Blaine Christian wrote: > > > > I'm pretty sure I must not be understanding correctly here. > > > > Russ, you seem to be saying that if a tier-1 AS allocates a subblock of its > > allocated address space, that it is technically NOT ALLOWED to continue > > to advertise that address space. Is that a correct statement of what > > you are saying? > > > > I hope Blaine would chime in on that one. > > Okay... I can give you common practice from my perspective. Common practice > is that an ISP will delegate a more specific prefix to a customer. All the > ISP usually cares about is advertising the less specific prefix. It is > normally a bad idea for the owner of a less specific chunk of prefixes who > has allocated a more specific prefix to a customer to advertise that more > specific prefix on their own (unless they are propagating a BGP advert). > This is left to the customer to decide. So, it is technically "allowed" but > it would be considered inappropriate unless there are unusual circumstances. > Please realize that the above paragraph relates specifically to BGP. > However, even with static allocations I would be hard pressed to find common > examples of an ISP bothering (or desiring etc.) to advertise a specifically > allocated sub-block. A, somewhat notable, diversion from this would be the > use of BGP and deaggregation to effect loadsharing between two different > AS'. I have done this in the past but I have had to do a lot of crazy > things with BGP to get the job done. > > The one "loaner" chunk of information that I HAVE seen as pretty much > forbidden by many is the use of a "loaner" AS outside of the owners control. > Even this is not illegal in the protocol, obviously, but it does create all > sorts of complications which contra-indicate its use (path loops getting > interesting here). > > > > > > > > Do you want to be continue that requirement and to represent that > > in the security requirements? > > > >> "Some 59,000 advertisements, or 55% of the total number of routing table > >> entries, are being used to punch policy holes in existing aggregate > >> announcements." draft-iab-bgparch-02.txt > > > > But all the bgparch (now RFC3221) says is that people advertise > > more specific prefixes for various reasons, policies being one > > of them. > > > > I don't read into that a statement that the aggregate announcement > > is (technically) not allowed to be advertised. > > > > I'm looking for a suggestion that an AS is *N*O*T**A*L*L*O*W*E*D > > to continue to advertise a part of its own address space that it had > > suballocated. Or indeed that the sub-allocat-ee would want them > > to cease to advertise the allocated sub-space. > > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Jan 21 22:34: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 WAA18531 for ; Fri, 21 Jan 2005 22:34:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsCJ6-0002b9-3m for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 22:51:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsC0O-0003fM-El; Fri, 21 Jan 2005 22:32:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsBwr-000341-Nx for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 22:28:29 -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 WAA18188 for ; Fri, 21 Jan 2005 22:28:27 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsCCs-0002Tz-38 for rpsec@ietf.org; Fri, 21 Jan 2005 22:45:02 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 21 Jan 2005 22:27:58 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-541.cisco.com [10.82.242.29]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0M3RtW1010030; Fri, 21 Jan 2005 22:27:56 -0500 (EST) Date: Fri, 21 Jan 2005 22:27:14 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: <200501212342.j0LNgLYV025873@tislabs.com> Message-ID: References: <200501212342.j0LNgLYV025873@tislabs.com> 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: b045c2b078f76b9f842d469de8a32de3 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: f0b5a4216bfa030ed8a6f68d1833f8ae >> Suppose you state: "A speaker should be able to prove the update has >> passed through the AS' listed in the as path," as a requirement. Now, my >> question is going to be: "Why? What do you want to prove by verifying >> this in this way? Your answer is going to be: "Because proving this >> proves the path actually exists, and can prove non-repudiation, and...." > > Well, no, that's not what my answer would be. > > My answer would be: > > Answer 1: that's what the spec says happens > > If you were teaching a class in BGP and people had been studying the > spec, and you put the following question on the test: > > AS A receives an update from B containing a route with the AS_PATH set to > {B,C,D}. Which of the following does your implementation assume in > deciding what to do with this update? (Choose the most complete > answer.) > > (a) AS A is connected to AS B > (b) B peers with C. C peers with D. D is connected to the NLRI. We don't > know how B came by this AS_PATH. > (c) B received an update from C containing (C,D) and C received an update > from D containing {D}, and D is connected to the NLRI > (d) traffic to the NLRI sent to B will be passed to C and then to D. > I would say that the correct answer was (c). And, yes, I know that the > correct answer is not (d). Let me ask this: If you were teaching a class on IPsec to a bunch of routing geeks, would you use "colliqual" terms, like "IPsec tunnel" to explain how it works, or would you delve into the real terms, and operation, immediately? Does the IPsec draft use the term "tunnel?" Is it really a "tunnel?" There are no instances you can think of where you'd use terms that model the reality, but don't reflect the actual way things work? Before I answer your question directly, and while you're thinking about the question above, let point out that routing protocol specifications actually provide a model of behaviour; they are "loose." For instance, if you were to read the BGP specification, how would you describe the BGP peering FSM, specifically in the case of a connection collision? You would state: "When the second TCP connection is received, a new BGP process starts. The collision is resolved using x means, and one of the two processes on each BGP speaker is terminated." You'd be right, based on the current spec (not the draft), but that's not the way BGP is implemented. In fact, I don't know of any implementation that actually runs a different process for each speaker. I'm certain cisco, Juniper, Procket, and Redback don't (didn't in some cases). It's easier to describe in terms of multiple processes, so that's what the BGP spec does. Another example is the concept of the loc-rib-in and loc-rib-out. The BGP specification relies on these concepts heavily. In reality, there's no implementation that has a loc-rib-in or a loc-rib-out. They don't exist. They're useful for explaining the model, but they they are never used in an implementations. At least I don't know of that have a loc-rib-in and a loc-rib-out. Another example, in another protocol. The OSPF and IS-IS specifications both specify the use of the Dijkstra algorithm to find the shortest paths through the network. In reality, and SPF algorithm will do, as long as it has the same results as Dijkstra. In other words, an implementation of either of these protocols could use any SPF algorithm, and still be compliant with the specifications. Take a look at Alex's alternative ABR implementations draft, as another instance. You'll find a number of places where implementations optimize the specification, not in a way that contradicts the specifications, per se. In the routing world, we consider this sort of thing "normal operation." There are two classes of things that we look at when considering compliance with a specification. The first is "on the wire." The second is "implementation specific." The "area" the concept of "implementation specific" covers in the security world is, I believe, rather narrow, things like what sort of data structure to use, etc. In the routing world, the concept of "implementation specific" is much wider. The specifications tend to be models, rather than "strict specifications." If everyone implemented what was actually described in the BGP specification, down to the last period, BGP wouldn't be very efficient, and the internet wouldn't work. A protocol implemenation is "specification compliant" if it interoperates with another implementation that is "specification compliant." Look at the RP implementation reports, they don't say: "Cisco has implemented BGP based on the specification, to examine the loc-rib-in, use the command x, etc." They say: "Cisco interoperates with vendor x, y, and z, in these areas." What's on the wire counts. The rest is implementation specific. Now, back to your question, and a short answer, with that as background. My answer would be: it depends. Who am I talking to? -- If I'm talking to a new BGP coder, trying to explain how the code works in relation to the specification, I would say none of the above. I would say we take the route (nlri/attribute) pair out of the update, and check the AS Path for any instances of my local AS number. If there are no instances of my local AS number in the AS Path, I will process the route. If there are, then I discard it. That's it.... I don't care what the AS Path says, as long as it doesn't include my route. Even in the best path decision, I only care about the length of the AS Path, I've no care in the world about the AS' listed in the AS Path at all. -- If I'm talking to a routing protocol engineer, who understands graph theory, and is just picking up BGP, I would say "B has sent me update containing a route stating it has a path to the NLRI via {B,C,D}. The AS Path is used to detect loops." I probably wouldn't discuss updates in any context other than the way routes are transported between BGP speakers (peers). -- If I were talking to a new networking class, trying to explain BGP for the first time, I would draw an as graph on the board, and show how the AS Path proves the path is loop free. I would probably use the terms you used in (c), until I got to policy explanations, then I would note instances where the AS Path isn't going to match the path the route takes through the network. > Answer 2: that's a fairly succinct statement that covers (all, most) > of the cases of things we want to prevent. > > Case 1: The spec says that the AS_PATH is used to detect loops. > Therefore, noone should be able to delete AS's from the AS_PATH. > > And I don't think this is OK even if the resulting AS_PATH has valid > adjacencies. Do you think it would be OK? (Question, not challenge.) Yes, I do believe there are valid, operational reasons why an AS would remove AS' from the AS Path. For instance, there's a command to remove all the private AS' from an AS Path in cisco routers. It's common enough practice to remove the private AS' from an AS Path that we've actually built a specific command for it. Further, this is specifically what re-origination (rather than aggregation, to use the "correct" term), does, as well. It removes elements from the AS Path. So, in your question above, there could be another AS behind D that actually contains the destination, that I can't see. It's a common occurance. We take great pains to explain this when we teach BGP, most of the time. And, finally, confederations, by definition, remove AS information from the AS Path. > Case 2: The operational common practice is that a shorter AS_PATH is > the better AS_PATH. So no one should be able to change the length of > the AS_PATH. (This is not a spec requirement, but it is so widely > implemented, it comes close. And, incidentally, IMHO, derived from > the expectation that the AS_PATH represents the AS's through which > this information has traveled.) Actually, this isn't true. In a large number of cases, the as path length is not the major determinate of the "better" path. More specifically, any route you learn from a customer is probably going to be decided on local preference. Any route you learn from a peer is probably going to be decided by igp metric, and then possibly as path. A large number of the routes you learn are going to fall all the way to the last point in the decision tree, the router id, or in cisco's case, the older route (ask Blaine about this, it's an area he has heartburn with!). :-) > If someone changed the length of the AS_PATH, but the resulting AS_PATH > had valid adjacencies, do you think it would be OK? (Question, not > challenge.) Yes, I do. It's common operational process to insert multiples of the same as in an as path. In fact, I've just discovered a case where the origin and as path length are intentionally changed to implement a specific policy. I'd never heard of this before, but.... I'll point something out here.... The variety of things people do with BGP would astound you. The cases are almost unbelievable. Just cruise through the knobs available in the major vendor's implementations, and try to figure out what they're there for. Yet I've seen every one of those things used, in real life. Conditional advertisement, conditional injection, AS Path stripping, local AS spoofing, AS migration and merge, re-origination, aggregation, .... There are several hundred pages of BGP configuration guides, command references, and feature guides on cisco.com. > Case 3: Suppose when an AS is composing the AS_PATH of an update, it > completely scrambles the order of the AS's from their sequence in the > AS_PATH of the Loc_RIB_In entry it choose. The resulting order > accidentally matches valid adjacencies, but bears no relationship to > the order of AS's by which the information got there. Is that OK? > Honestly, I have no opinion whether that is OK or not. It's not going > to hurt the length checking and its not going to hurt loop checking - > but as soon as someone decides to make a policy on the basis of > AS order in the AS_PATH, you'd have a problem. I wouldn't use the as path to build policy, for the most part. I might make policy based on the origin, and the next hop, but everything in the middle is up for grabs. Let me put it this way--if you already acknowledge the traffic forwarded along this route may not follow the AS Path listed in the packet, then what sort of policy would you enforce based on the AS Path? Let me put it another way: Is there any sense in which the policy will not be based on the desirability of forwarding traffic via the advertised route? If you already know the AS Path isn't gaurenteed to bear any relation to the path of the packet, in real life, then isn't is illogical to base your packet forwarding policy on an AS Path that may not represent the actual path of the packet? IMHO, if you trust the as path in this situation, you get what you deserve. :-) > Case 4: Suppose an AS chooses a route which would have an AS_PATH of > length X, and it puts an AS_PATH in the update it sends which has length > X but has no other bearing to the AS_PATH of the route it has chosen. It > uses this same length X AS_PATH for all updates it sends for which the > route it chose would have an AS_PATH of length X. So the length is > correct, and the AS_PATH adjacencies all check. Is that OK? I would say > not, because it removes the ability to check for loops. This is closely related to the case you've listed above. A---B---C---D | | +-----------+ What you're asking is what if A advertises 10.1.1.0/24 to B, but B advertises that route with a path of {D,A} to C, rather than just {A}, correct? I know, you've said if the as path is the same. Now, D wont' get this route, right, because the as path has been messed with. I would point out two things: -- D will receive the route through A directly, in most situations, right? Well, A may have a policy set so D doesn't receive this route through A directly, but ignoring that possibility, the impact of this attack is nil. -- If B wants to disrupt communications between A and D, why doesn't it just filter the route, or the traffic? If I'm on the path, you can't stop me from disrupting your traffic in a number of other ways, so defending against this attack is, essentially, a null proposition. I can't think of any way to make this attack work when you're not already on the path (?). I hope that helps.... :-) 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 Fri Jan 21 22:44:36 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 WAA18835 for ; Fri, 21 Jan 2005 22:44:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsCSU-0002la-MO for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 23:01:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsCBT-0005vc-3l; Fri, 21 Jan 2005 22:43:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsC7K-0004vS-Ih for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 22:39: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 WAA18686 for ; Fri, 21 Jan 2005 22:39:16 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsCNK-0002fE-DM for rpsec@ietf.org; Fri, 21 Jan 2005 22:55:51 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 Jan 2005 22:46:44 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-541.cisco.com [10.82.242.29]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0M3cioB021858; Fri, 21 Jan 2005 22:38:44 -0500 (EST) Date: Fri, 21 Jan 2005 22:38:03 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: <200501212356.j0LNuNGf026270@tislabs.com> Message-ID: References: <200501212356.j0LNuNGf026270@tislabs.com> 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 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: 4d87d2aa806f79fed918a62e834505ca >> -- Would you say 10.1.1.0/24 is a part of 10.1.0.0/16, so that by >> advertising 10.1.0.0/16, you are, in fact, also advertising reachability to >> 10.1.1.0/24? >> >> -- Would you say that A advertising 10.1.0.0/16 is, in fact, advertising >> B's address space? >> >> -- If your answer to these two questions is yes, what is your conclusion? > > My answer would be yes to both questions - A is allowed to continue to > advertise reachability to addresses it has sub-allocated to B. And I > don't see a problem with that. Surely that's OK? A will still be able > to reach B, surely? Blackholes aside. So parts of the world that do see > B's announcement will send traffic by that route and if there are parts > of the world that see A's announcement but not B's (could happen, right?) > will send the traffic through A. What if A's policy were such that some parts of the world weren't supposed to see its address space at all? How would A enforce this policy? I'm surprised you don't find this rather loose definition of ownership problematic at all. It's a lot like me selling a room in my house, and the new owner and I both listing it on our tax returns, isn't it? Would it bother you if a credit card company gave you a number from a block, then used that block to charge something, with the result that your bill increased? If it wouldn't bother you, can I have your credit card number???.... :-) > (Leaving aside the case of the non-BGP-speaker who is allocated > addresses.) I'm ok with the definition of authorized-to-advertise as > "has been allocated", which does not say "has been allocated and has not > suballocated". This actually happens, to--or at least it used to.... Suppose you have a customer who wants to dual home, but doesn't want to run BGP? You could give your customer a block, say a /24, and tell them to have their other provider run a static, and originate the route as well. I don't think this happens often any longer, but when I was working the TAC, I encountered this on a regular basis. :-) 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 Fri Jan 21 23:37: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 XAA20970 for ; Fri, 21 Jan 2005 23:37:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsDHx-0003i0-4H for rpsec-web-archive@ietf.org; Fri, 21 Jan 2005 23:54:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsD0n-0000hj-DJ; Fri, 21 Jan 2005 23:36:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsCwU-0008DV-Lx for rpsec@megatron.ietf.org; Fri, 21 Jan 2005 23:32: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 XAA20670 for ; Fri, 21 Jan 2005 23:32:07 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsDCU-0003as-Vo for rpsec@ietf.org; Fri, 21 Jan 2005 23:48:43 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 21 Jan 2005 23:31:39 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-541.cisco.com [10.82.242.29]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0M4VaW1017671; Fri, 21 Jan 2005 23:31:36 -0500 (EST) Date: Fri, 21 Jan 2005 23:30:55 -0500 (Eastern Standard Time) From: Russ White To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG In-Reply-To: <200501212338.j0LNcIB1025766@tislabs.com> Message-ID: References: <200501212338.j0LNcIB1025766@tislabs.com> 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: 36c793b20164cfe75332aa66ddb21196 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: 1676547e4f33b5e63227e9c02bd359e3 >>> I disagree strongly that the statement is "meaningful" unless and until >>> you have decided on the *meaning* of "verify the path". >> >> That's actually correct. > > You are agreeing with me that we need to define "verify the path"? Yes, but I think I've said that before. In fact, I believe I insisted we insert text explaining what, exactly, about the AS Path must and should be verified. >> What I mean by "meaningful" is that the path >> actually exists, that there is a way from my peer, who has advertised that >> path, to the destination stated in the route. > > (a) If you agree that we need to define "verify the path", why are you > defining "meaningful"? > (b) Your definition sounds to me like a definition of "verify the path", > not a definition of "meaningful", anyway. I don't understand these two?? > (c) I know you'll hate me for bringing up definitions again, but -- by > "exist", you mean "two AS's adjacent in the AS_PATH have a peering > relationship?" I mean every pairwise set of AS' listed in the AS Path have a peering relationship. I do _not_ mean the "update" (really route) has passed through each of those pairwise peerings. Going back to my other email: -- Suppose you state: "A speaker should be able to prove the update has passed through the AS' listed in the as path," as a requirement. Now, my question is going to be: "Why? What do you want to prove by verifying this in this way?" Your answer is going to be: "Because proving this proves the path actually exists, and can prove non-repudiation, and...." -- I believe you stated your answer would be: "Because the specification says that's what's supposed to happen." Thus, you are stating the questions I've asked above are invalid questions. Asking why is always met with: "It's what the spec says," and no other anwers or questions, based on operational and implementation experience, are allowed. Given this, I go back to my original statement. We won't reach concensus on this point. I believe asking "why" is valid, based on my experience with BGP in the real world. I also believe asking "why" is valid, even within the pure security space. You would never, as a security expert, place four locks on a door, without considering the other methods of entry into the space, simply because: "the specification states you must enter through the door." Essentially, what I'm saying is that you're trying to secure the wrong thing. You're trying to secure the routing update, the process. I'm trying to secure routing. >From another tack: If someone asks you why the security requirements include a section on deployability, what would your answer be? According to these rules, that entire section needs to go, correct? Or can you justify it from the BGP specification? Further, why aren't you insisting the other attributes be treated in the same way? For instance, why shouldn't a BGP speaker be required to prove the next hop listed in a received update is actually the next hop it should send the traffic to? Why aren't we requiring speakers to prove the point at which transitive communities are added to a route, and the authorization of an AS to add those transitive communities? Or the MED, for instance, why aren't we requiring BGP speakers to verify that attribute? Is it because operational experience shows us that those questions aren't the right sorts of questions to ask about those attributes? My contention is very simple: Operational and implementation experience shows that the right question to ask about the AS Path is not: "has the update traversed this set of AS'?" I believe the correct questions, based on both the BGP specification and operational experience with BGP as a protocol, have already been defined in the draft. -- If the only answer allowed to the question above is: "It's what the specification states," I don't see how we can come to concensus without either: -- Building the requirements loose enough to support both interpretations, letting the designers make their best case, and the community decide through whatever process it uses (the market, a technical design team, or other methods) which is correct, securing the process, or securing routing, based on the tradeoffs and other issues involved. -- Simply disbanding the entire draft. -- One or more people dropping completely out of the conversation, and simply no longer contributing in any way shape or form. I believe the best path to take is the first path, since it is a way forward as a community. It seems I may be alone in that belief, since I've offered this option on several occasions, and no-one has supported the concept in any previous instance. IMHO, the third option is quickly approaching, which is a shame. I hate to see the community lose technical expertise, and perspective, but it's what most often happens if only a minority will accept the middle road. :-) 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 Sat Jan 22 08:29: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 IAA02882 for ; Sat, 22 Jan 2005 08:29:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsLaC-0005mQ-Kt for rpsec-web-archive@ietf.org; Sat, 22 Jan 2005 08:45:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsLIK-0004FH-To; Sat, 22 Jan 2005 08:27:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsLG4-0003hk-Kg for rpsec@megatron.ietf.org; Sat, 22 Jan 2005 08:24: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 IAA02727 for ; Sat, 22 Jan 2005 08:24:55 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsLWA-0005hP-EI for rpsec@ietf.org; Sat, 22 Jan 2005 08:41:34 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 22 Jan 2005 05:24:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (sjc-vpn7-260.cisco.com [10.21.145.4]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j0MDOI1N015165; Sat, 22 Jan 2005 05:24:18 -0800 (PST) Date: Sat, 22 Jan 2005 08:23:36 -0500 (Eastern Standard Time) From: Russ White To: sandy@tislabs.com 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: 7da5a831c477fb6ef97f379a05fb683c Cc: rpsec@ietf.org Subject: [RPSEC] Back to Basics--The AS Path 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: 932cba6e0228cc603da43d861a7e09d8 Sandy: My last message last night actually drove me back into the BGP specification, to discover what the specification really says. Note that throughout this email, I've used your preferred wording, using the term "update" as if updates were transitive objects being sent through a BGP network, and I've attempted to be as precise as possible in all definitions and wordings. Now, if we are going to claim something close to this as a requirement: "On receiving an update, any proposed solution MUST verify the update has passed through the pairwise peerings represented by the AS Path attribute contained in the update." With this as our basis: "Because the specification says so." Then I think we should really go look at the specification, and see what it actually says, no? I used the most current version of the specification, currently in line for draft-standard state, which I found here: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-26.txt On searching the document for all occurances of the words: "as_path," or: "as path," I found only a few instances. The one I _believe_ is relevant is here, on page 25: b) When a given BGP speaker advertises the route to an external peer, then the advertising speaker updates the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol mes- sage). If the act of prepending will cause an overflow in the AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. When I examine this text, I find two interesting things: -- First, there is no mention of any conditions under which information may be removed from the AS Path, or the AS Path is reordered. I believe, based on reading of the specification (without outside reference to operational or implementation experience), this means the AS Path may be reordered, or information may be removed from the AS Path. Let me at least say neither of these are strictly prohibited. -- Second, when describing the operation of a BGP speaker, the draft doesn't say the speaker MUST prepend its own AS number as the last element of the sequence, it says it "will." In my experience, when a draft means "MUST," it uses "MUST," rather than "will." This implies the writers of this specification (if you refer to page 7, you'll find I'm listed as a contributor) believed there were valid situations when a BGP speaker would not follow the operational procedure described here. Would you say this is all correct? I believe, then, that you cannot get the proposed requirement listed above from the BGP specification itself. At least I can't find any justification for it. If you believe the specification should say "MUST" at this point, I would say that's an argument for the IDR WG, not for RPsec. :-) -- Now, let's expand this further, and say we'd like to state this: "On receiving an update, any proposed solution MUST verify the update has passed through the pairwise peerings represnted by the AS Path attribute contained in the update." And base it on this reasoning: "The sense of the BGP specification is that the protocol will not operate correctly is this rule is not followed." This is a slightly less strong justification, but let's deal with it, anyway, just for argument's sake. I would point out numerous instances have been cited where operational requirements, in running, live networks, have caused operators to: -- Add additional information to an AS Path, causing it to _not_ represent the list of peerwise AS peerings the update has passed through. A common example of this is AS Path prepend. -- Remove information from the AS Path, causing it to _not_ represent the list of peerwise AS peerings the update has passed through. A common example of this is stripping private AS numbers out of the AS Path at an autonomous system boundary. -- Advertise a set of reachable addresses which contains address space reachable through a different AS Path than that listed in the update. A common instance of this is the re-origination of routing information at an autonomous system border. With these thoughts in mind, we must choose between one of three alternatives: -- These examples are a figment of my imagination. If you want to choose this option, you'll need to consult my psychologist. -- Operators shouldn't be doing these things, and therefore the justification above stands. In fact, the security requirements document should be defined so such modifications are not allowed, and the BGP specification should be modified in accordance with this. -- The requirement, as listed, in some way, doesn't truly define what "valid" means as applied to an AS Path, based on operational and implementation experience. I would suggest the third option as the logical choice. Now, if we can't base the definition of "valid" in reference to the AS Path on the BGP specification, because the required MUST isn't there, and we operational experience shows we can't base it on what we think the "sense of the BGP draft is or should be," then how can we define "valid" in reference to an AS Path? I would suggest the definition contained in the current BGP security requirements draft, as published, are a good start. The wording may be formalized, etc., but the sense of the definition in that draft is based on the sense of the BGP specification combined with operational and implementation experience, IMHO. I hope it helps to clarify things by starting from the beginning, and summarize the overall picture. :-) 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 Sat Jan 22 08:42: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 IAA03785 for ; Sat, 22 Jan 2005 08:42:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsLn4-00062l-7N for rpsec-web-archive@ietf.org; Sat, 22 Jan 2005 08:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsLTq-0005oh-Vv; Sat, 22 Jan 2005 08:39:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsLT4-0005gR-GH for rpsec@megatron.ietf.org; Sat, 22 Jan 2005 08:38: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 IAA03419 for ; Sat, 22 Jan 2005 08:38:20 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsLjA-0005wB-1G for rpsec@ietf.org; Sat, 22 Jan 2005 08:55:00 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 22 Jan 2005 08:45:53 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-391.cisco.com [10.82.225.135]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0MDbmW1013720; Sat, 22 Jan 2005 08:37:48 -0500 (EST) Date: Sat, 22 Jan 2005 08:37:07 -0500 (Eastern Standard Time) From: Russ White To: sandy@tislabs.com 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: 2ed806e2f53ff1a061ad4f97e00345ac Cc: rpsec@ietf.org Subject: [RPSEC] Back to the Basics: The AS Path 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: c54bc2f42d02429833c0ca4b8725abd7 Sandy: My last message last night actually drove me back into the BGP specification, to discover what the specification really says. Note that throughout this email, I've used your preferred wording, using the term "update" as if updates were transitive objects being sent through a BGP network, and I've attempted to be as precise as possible in all definitions and wordings. Now, if we are going to claim something close to this as a requirement: "On receiving an update, any proposed solution MUST verify the update has passed through the pairwise peerings represented by the AS Path attribute contained in the update." With this as our basis: "Because the specification says so." Then I think we should really go look at the specification, and see what it actually says, no? I used the most current version of the specification, currently in line for draft-standard state, which I found here: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-26.txt On searching the document for all occurances of the words: "as_path," or: "as path," I found only a few instances. The one I _believe_ is relevant is here, on page 25: b) When a given BGP speaker advertises the route to an external peer, then the advertising speaker updates the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system prepends its own AS number as the last element of the sequence (put it in the leftmost position with respect to the position of octets in the protocol mes- sage). If the act of prepending will cause an overflow in the AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment. When I examine this text, I find two interesting things: -- First, there is no mention of any conditions under which information may be removed from the AS Path, or the AS Path is reordered. I believe, based on reading of the specification (without outside reference to operational or implementation experience), this means the AS Path may be reordered, or information may be removed from the AS Path. Let me at least say neither of these are strictly prohibited. -- Second, when describing the operation of a BGP speaker, the draft doesn't say the speaker MUST prepend its own AS number as the last element of the sequence, it simply says: "the local system prepends its own AS number as the last element of the sequence." In my experience, when draft authors intend to make a restrictive requirement, they use the phrase MUST in the requirement. In this case, it appears the wording is explanitory, rather than a requirement (?). -- Third, that the MUST is missing implies the authors, reviewers, and contributors to this specification (if you refer to page 7, you'll find I'm listed as a contributor) believed there were valid situations when a BGP speaker would not follow the operational procedure described here. Would you say this is all correct? I believe, then, that you cannot get the proposed requirement listed above from the BGP specification itself. At least I can't find any justification for it. If you believe the specification should say "MUST" at this point, I would say that's an argument for the IDR WG, not for RPsec. :-) -- Now, let's expand this further, and say we'd like to state this: "On receiving an update, any proposed solution MUST verify the update has passed through the pairwise peerings represnted by the AS Path attribute contained in the update." And base it on this reasoning: "The sense of the BGP specification is that the protocol will not operate correctly is this rule is not followed, or that's what the BGP specification authors meant to say, or that's what the BGP specification should say, and it was just missed." This is a slightly less strong justification, but let's deal with it, anyway, just for argument's sake (because I happen to know that someone on this list is going to use one of the above justifications in their reply). I would point out numerous instances have been cited where operational requirements, in running, live networks, have caused operators to: -- Add additional information to an AS Path, causing it to _not_ represent the list of peerwise AS peerings the update has passed through. A common example of this is AS Path prepend. -- Remove information from the AS Path, causing it to _not_ represent the list of peerwise AS peerings the update has passed through. A common example of this is stripping private AS numbers out of the AS Path at an autonomous system boundary. -- Advertise a set of reachable addresses which contains address space reachable through a different AS Path than that listed in the update. A common instance of this is the re-origination of routing information at an autonomous system border. With these thoughts in mind, we must choose between one of three alternatives: -- These examples are a figment of my imagination. If you want to choose this option, you'll need to consult my psychologist. I'm afraid I can't help you any further. :-) -- Operators shouldn't be doing these things, and therefore the justification above stands. In fact, the security requirements document should be defined so such modifications are not allowed, and the BGP specification should be modified in accordance with this. I would contend this is operationally unteneble. -- The requirement, as listed, in some way, doesn't truly define what "valid" means as applied to an AS Path, based on operational and implementation experience. I would suggest the third option as the logical choice. Now, if we can't base the definition of "valid" in reference to the AS Path on the BGP specification, because the required MUST isn't there, and operational experience shows we can't base it on what we think the "sense of the BGP draft is or should be," then how can we define "valid" in reference to an AS Path? I would suggest the definition contained in the current BGP security requirements draft, as published, is a good start. The wording may be formalized, etc., but the sense of the definition in that draft is based on the sense of the BGP specification combined with operational and implementation experience, IMHO. I hope it helps to clarify things by starting from the beginning, and summarize the overall picture. :-) 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 Sat Jan 22 12:24:12 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 MAA16745 for ; Sat, 22 Jan 2005 12:24:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsPFl-0002E6-Rn for rpsec-web-archive@ietf.org; Sat, 22 Jan 2005 12:40:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsOtk-0003tG-8f; Sat, 22 Jan 2005 12:18:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsOjr-0008Cm-5W for rpsec@megatron.ietf.org; Sat, 22 Jan 2005 12:07: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 MAA15592 for ; Sat, 22 Jan 2005 12:07:52 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsOzy-0001nm-21 for rpsec@ietf.org; Sat, 22 Jan 2005 12:24:35 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 22 Jan 2005 12:15:27 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn2-607.cisco.com [10.82.242.95]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0MH7KoB004902 for ; Sat, 22 Jan 2005 12:07:21 -0500 (EST) Date: Sat, 22 Jan 2005 12:06:40 -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: 4b800b1eab964a31702fa68f1ff0e955 Subject: [RPSEC] A Call for A Reasonable Compromise on Securing the AS Path 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: d8ae4fd88fcaf47c1a71c804d04f413d Y'all: I've seggested, in the text of several emails, that there are a number of ways forward on the BGP security requirements draft. IMHO, we aren't going to reach concensus on the issue of "what security means in the cotext of the AS Path." Well, maybe the next couple days will tell us, but I'm assuming no such concensus will be possible. I believe the two rational ways forward, as a WG are: -- Build the requirements "loose," so they will fit either definition of "securing the AS Path." -- Simply include two different options in this area, and any other area where there's enough contention and no apparent concensus. I'm thinking of the first case being something like: -- Any proposed security mechanism MUST be able to verify: -- x -- y -- z Any proposed security mechinism SHOULD be able to verify: -- x -- y -- z Proposed security mechanisms MAY assert more security than is outlined here. Any such claims SHOULD be justified and defended in the context of the security proposal draft(s). -- The other option seems to be something like this: Any proposed security mechanism MUST support one of two mechanisms to verify/validate the AS Path: -- Method A -- Method B -- Either of these is fine with me, but I believe we've been mired in the argument over the AS Path, specifically, far too long than is healthy, and we should try to find a way forward. As we encounter other areas where there is a strong argument preventing concensus, we should possibly consider this sort of option again, and simply try to reach a concensus that we can't reach concensus, and should find more than one "subconcensus" to place in the document. I believe this sort of step is unusual, but I also believe there is too much at stake, in terms of future work, to leave this argument open, and simply not progress the draft. If the AD's have any comment on this possibility as a procedure, or if Tony would like to chime in, I would appreciate it. :-) 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 Sun Jan 23 09:05:00 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 JAA15004 for ; Sun, 23 Jan 2005 09:05:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Csich-0003DT-Sa for rpsec-web-archive@ietf.org; Sun, 23 Jan 2005 09:21:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsiKx-00083Z-SQ; Sun, 23 Jan 2005 09:03:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsiJM-0007rD-KI for rpsec@megatron.ietf.org; Sun, 23 Jan 2005 09:01:52 -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 JAA14793 for ; Sun, 23 Jan 2005 09:01:51 -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 1CsiZf-00038R-DH for rpsec@ietf.org; Sun, 23 Jan 2005 09:18:43 -0500 Received: from [172.17.19.3] (helo=[172.17.19.3]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CsiJE-0008Cc-FG; Sun, 23 Jan 2005 15:01:45 +0100 Message-ID: <41F3AE42.80605@schlund.net> Date: Sun, 23 Jan 2005 15:01:38 +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] Back to the Basics: The AS Path 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: 156eddb66af16eef49a76ae923b15b92 Cc: rpsec@ietf.org, sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1129587791==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1129587791== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig16C79B98A61BD3940547B207" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig16C79B98A61BD3940547B207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Russ, Russ White wrote: > My last message last night actually drove me back into the BGP > specification, to discover what the specification really says. Note that > throughout this email, I've used your preferred wording, using the term > "update" as if updates were transitive objects being sent through a BGP > network, and I've attempted to be as precise as possible in all > definitions > and wordings. for me, the word "update" is an inprecise reference fo "UPDATE message" which is clearly a message beween to BGP neighbors, and not somthing transitive. The BGP draft also states that "Routes are stored in the Routing Information Bases (RIBs): namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out, as described in Section 3.2.". So no updates are stored, but routes (= content of an update) are put into different RIBs. > When I examine this text, I find two interesting things: > > -- First, there is no mention of any conditions under which > information may > be removed from the AS Path, or the AS Path is reordered. I believe, > based > on reading of the specification (without outside reference to operational > or implementation experience), this means the AS Path may be > reordered, or > information may be removed from the AS Path. Let me at least say > neither of > these are strictly prohibited. I agree that MUSTs must be followed, but not that missing "MUST NOTs" mean its allowed. I'm sure no document is complete in this sense. I fear there is an inherent conflict between MUST NOTs and extensibility... > -- Second, when describing the operation of a BGP speaker, the draft > doesn't say the speaker MUST prepend its own AS number as the last > element > of the sequence, it simply says: "the local system prepends its own AS > number as the last element of the sequence." In my experience, when > draft authors intend to make a restrictive requirement, they use the > phrase MUST in the requirement. In this case, it appears the wording > is explanitory, rather than a requirement (?). > > -- Third, that the MUST is missing implies the authors, reviewers, and > contributors to this specification (if you refer to page 7, you'll > find I'm listed as a contributor) believed there were valid situations > when a BGP speaker would not follow the operational procedure > described here. yes, there are: route servers at IXPs. They collect and redistribute routes of connected ISPs via EBGP sessions but try to stay as invisible as possible. This also includes not to put its AS into the path because it would make the path less favorable compared to directly exchanged routes. But I guess route-servers generally are special, so they definitely are a pain for security architectures... > Now, let's expand this further, and say we'd like to state this: > > "On receiving an update, any proposed solution MUST verify the update has > passed through the pairwise peerings represnted by the AS Path attribute > contained in the update." > > And base it on this reasoning: > > "The sense of the BGP specification is that the protocol will not > operate correctly is this rule is not followed, or that's what the BGP > specification authors meant to say, or that's what the BGP > specification should say, and it was just missed." the AS-PATH attribute is important functionally to avoid loops and is somewhat important as a metric. From a security point of view, the as-path is much more important in my eyes. When you want to check, wether the route of the route is authorized, the as-path would be a logic basis for this. If the as-path does not mirror the route of the route, on what basis would you otherwise want to check this? > -- Add additional information to an AS Path, causing it to _not_ > represent > the list of peerwise AS peerings the update has passed through. A common > example of this is AS Path prepend. agreed, this is a valuable usage e.g. when merging ASes > -- Remove information from the AS Path, causing it to _not_ represent the > list of peerwise AS peerings the update has passed through. A common > example of this is stripping private AS numbers out of the AS Path at an > autonomous system boundary. not quite aggreed: even if the BGP spec would be hurted by this behavior, it's an internal operation and not visible for the rest of the internet. This could impact security but does not necessarily... > -- Advertise a set of reachable addresses which contains address space > reachable through a different AS Path than that listed in the update. A > common instance of this is the re-origination of routing information > at an > autonomous system border. I didn't get this :-/ If the routing path differs from the forwarding path, this can lead to loops on the forwarding plane. For this reason this is very dangerous and should never be constructed intentionally. I know there are con- stellations with route reflectors and more specifics where this can occur without anybody doing "something wrong", but this should not be a basis to consider this behavior as accepted. > With these thoughts in mind, we must choose between one of three > alternatives: > > -- These examples are a figment of my imagination. If you want to choose > this option, you'll need to consult my psychologist. I'm afraid I > can't help you any further. :-) > > -- Operators shouldn't be doing these things, and therefore the > justification above stands. In fact, the security requirements document > should be defined so such modifications are not allowed, and the BGP > specification should be modified in accordance with this. I would > contend this is operationally unteneble. > > -- The requirement, as listed, in some way, doesn't truly define what > "valid" means as applied to an AS Path, based on operational and > implementation experience. > > I would suggest the third option as the logical choice. I aggree that operators practise and software features differ from the exact wording of the BGP spec and at least use grey space for some of the example you describe. For that reason I also think that the BGP spec as single basis is not sufficient. tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig16C79B98A61BD3940547B207 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.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB865DehvPYvDU0roRAm4aAKC17A+hSP3DxR8hVtAjBY5ylOMzSwCgs7LG xhBztmGgGRDjk8jC3avvsJs= =eTSE -----END PGP SIGNATURE----- --------------enig16C79B98A61BD3940547B207-- --===============1129587791== 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 --===============1129587791==-- From rpsec-bounces@ietf.org Sun Jan 23 12:56: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 MAA27880 for ; Sun, 23 Jan 2005 12:56:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsmEy-0007Ie-2K for rpsec-web-archive@ietf.org; Sun, 23 Jan 2005 13:13:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cslx8-00062V-VD; Sun, 23 Jan 2005 12:55:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CslwC-0005wY-Jy for rpsec@megatron.ietf.org; Sun, 23 Jan 2005 12:54: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 MAA27847 for ; Sun, 23 Jan 2005 12:54:09 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsmCX-0007Gd-Mb for rpsec@ietf.org; Sun, 23 Jan 2005 13:11:06 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 23 Jan 2005 12:53:42 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-659.cisco.com [10.82.226.147]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0NHrcoB012146; Sun, 23 Jan 2005 12:53:39 -0500 (EST) Date: Sun, 23 Jan 2005 12:52:57 -0500 (Eastern Standard Time) From: Russ White To: Stefan Mink Subject: Re: [RPSEC] Back to the Basics: The AS Path In-Reply-To: <41F3AE42.80605@schlund.net> Message-ID: References: <41F3AE42.80605@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: 42e3ed3f10a1d8bef690f09da16f507a Cc: rpsec@ietf.org, sandy@tislabs.com 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: d2b46e3b2dfbff2088e0b72a54104985 > for me, the word "update" is an inprecise reference fo "UPDATE message" > which is clearly a message beween to BGP neighbors, and not somthing > transitive. The BGP draft also states that "Routes are stored in the > Routing Information Bases (RIBs): namely, the Adj-RIBs-In, the Loc-RIB, > and the Adj-RIBs-Out, as described in Section 3.2.". So no updates are > stored, but routes (= content of an update) are put into different RIBs. Correct. I would actually much rather discuss this in terms of routes, rather than updates, but the entire current language is built around updates, rather than routes..... Of course, actual implementations don't have an adj-rib-in, loc-rib, and adj-rib-out (I always confuse all of these names, and call them the wrong thing), so these are models of behaviour, not requirements. >> Now, let's expand this further, and say we'd like to state this: >> >> "On receiving an update, any proposed solution MUST verify the update has >> passed through the pairwise peerings represnted by the AS Path attribute >> contained in the update." >> >> And base it on this reasoning: >> >> "The sense of the BGP specification is that the protocol will not operate >> correctly is this rule is not followed, or that's what the BGP >> specification authors meant to say, or that's what the BGP specification >> should say, and it was just missed." > the AS-PATH attribute is important functionally to avoid loops and is > somewhat important as a metric. From a security point of view, the > as-path is much more important in my eyes. When you want to check, wether > the route of the route is authorized, the as-path would be a logic basis > for this. If the as-path does not mirror the route of the route, on what > basis would you otherwise want to check this? I'm not certain what you mean by authorizing: "the route of a route." I suppose there are a number of ways I could take this. Suppose I have: A---B---C Are you saying you want to show that A is authorizing B to send routing information to C? But, if the AS Path doesn't always actually reflect the path the routing information has taken (as you acknowledge in at least one case), .... >> -- Add additional information to an AS Path, causing it to _not_ represent >> the list of peerwise AS peerings the update has passed through. A common >> example of this is AS Path prepend. > > agreed, this is a valuable usage e.g. when merging ASes ....how can you prove this using the AS Path? I'm not certain how to get to "authorization to advertise routing information" from "prove the route has followed the path listed in the AS Path?", since the AS Path doesn't actually represent the path the routing information took through the network, in all cases? Beyond this, why do we want to prove this "authorization chain?" Is it to prove the sender is authorizing packets to flow along the reverse path than the one the routing information took? Since you can't ever prove traffic flows along the reverse path the routing information takes, this doesn't seem to be helpful, either. draft-white-pathconsiderations-04 shows some examples of this occuring. Finally, you could say you're actually trying to authorize the advertisement of reachability information, since the route is actually made up of a prefix and attributes, which is what we would call reachability information. "Is my peer authorized to advertise reachability to 10.1.1.1 to me?" is the sort of question we're talking about here. And, here again, draft-white-pathconsiderations-04 shows how this doesn't work in the real world, the first example is the simplest. So, I suppose I'm confused by the concept of "authorization" in the context of the AS Path as carried in BGP routes. What does it mean, exactly? What are we attempting to authorize? >> -- Remove information from the AS Path, causing it to _not_ represent the >> list of peerwise AS peerings the update has passed through. A common >> example of this is stripping private AS numbers out of the AS Path at an >> autonomous system boundary. > > not quite aggreed: even if the BGP spec would be hurted by this behavior, > it's an internal operation and not visible for the rest of the internet. This > could impact security but does not necessarily... The path of the routing information is actually {65100,1,2,3}, but you're reporting the path of the routing information as {1,2,3}. It's not a matter of the operation being "internal," it's a matter of the path of the routing information not matching the reported path of the routing information. Another example is confederations, where AS' are inserted into, and then removed from, the AS Path. Again, the confed AS appears to be a single AS to the remainder of the internetwork, but there are path elements that are added and removed, showing the AS Path is not a sacrosant version of the actual path of the routing information. >> -- Advertise a set of reachable addresses which contains address space >> reachable through a different AS Path than that listed in the update. A >> common instance of this is the re-origination of routing information at an >> autonomous system border. > > I didn't get this :-/ > If the routing path differs from the forwarding path, this can lead to > loops on the forwarding plane. For this reason this is very dangerous > and should never be constructed intentionally. I know there are con- > stellations with route reflectors and more specifics where this can > occur without anybody doing "something wrong", but this should not > be a basis to consider this behavior as accepted. draft-white-pathconsiderations-04, first example. I would consider each entity's actions within the internetwork perfectly acceptable and normal behaviour. > I aggree that operators practise and software features differ from the > exact wording of the BGP spec and at least use grey space for some of the > example you describe. For that reason I also think that the BGP spec as > single basis is not sufficient. Agreed. There are two camps here: -- The requirements document should state any proposed solution must verify/prove/etc. the path the routing information actually took is the same as the AS Path attribute of the route. -- The requirements document should state and proposed solution must verify the AS Path attribute of any received route exists (represents a valid set of peerings within the internetwork), since this is all we can actually prove or validate. We can't prove authorization using any of the various definitions we've tried to use, so we shouldn't require any proposed solution to prove authorization. I think the second is the most logical choice, but I'm willing to allow both to be included in the draft as alternatives, in either of the two ways I've proposed on list. Either word the requirements to cover both options, or have two separate requirements. :-) 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 Sun Jan 23 16:41: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 QAA12310 for ; Sun, 23 Jan 2005 16:41:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cspkh-0003Rp-1c for rpsec-web-archive@ietf.org; Sun, 23 Jan 2005 16:58:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CspSK-0003ZV-Ls; Sun, 23 Jan 2005 16:39:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CspRV-0003SP-AX for rpsec@megatron.ietf.org; Sun, 23 Jan 2005 16:38: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 QAA12144 for ; Sun, 23 Jan 2005 16:38:42 -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 1Csphr-0003NC-7V for rpsec@ietf.org; Sun, 23 Jan 2005 16:55:40 -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 j0NLc8DH023989 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Sun, 23 Jan 2005 16:38:11 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 23 Jan 2005 16:38:01 -0500 Subject: Re: [RPSEC] Back to the Basics: The AS Path From: Blaine Christian To: Russ White , Stefan Mink 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit > Agreed. > > There are two camps here: > > -- The requirements document should state any proposed solution must > verify/prove/etc. the path the routing information actually took is the > same as the AS Path attribute of the route. Hey Russ, can we work this backwards a bit and see it if still makes sense? Perhaps we can list the cases where the path can not be proven and still allow for path verification? So, path can not be proven for... 1. Reoriginations: This is information reduction/expansion for the sake of performance and it could be argued that it is a tacit agreement between the provider of reoriginated information and the reoriginatee. If it is an agreement between originator and originatee then security would most likely also be an agreement betwixt the two. Heck, if I do BGP with a customer and advertise default this is essentially the same thing. 2. Confederations: These happen "internal" to an AS so I suppose this could just be captured and dealt with separately. 3. Private AS stripping: Most folks do not allow this type of stuff to propagate beyond the initial two networks involved so again it should fall, mostly, in the realm of a private agreement. 4. Route propagators (really just packet forwarders for all intents and purposes). A packet forwarder is a packet forwarder. As long as whatever security information is necessary is passed along as well I don't think this is really germane to the discussion. Can anyone think of other special cases such as the above? Would everything else be "verifiable"? Just above every one of the above path manipulations is based on either a private agreement or an internal optimization for a network. You know that, no matter what happens with the specification, the ability to track signatures across an entire AS path is quite attractive as a means of identifying miscreants or potential issues. Even if noting and ignoring the special cases does not work. Another thought... We did build into the requirements draft language that allows for non-secure things. Wouldn't unverifiable stuff just end up in the "not secured" realm anyway? Regards, Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jan 23 20:57: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 UAA00324 for ; Sun, 23 Jan 2005 20:57:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cstkk-0000yS-FB for rpsec-web-archive@ietf.org; Sun, 23 Jan 2005 21:14:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CstSV-0004Am-R3; Sun, 23 Jan 2005 20:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CstRP-0003z7-Hh for rpsec@megatron.ietf.org; Sun, 23 Jan 2005 20:54: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 UAA00126 for ; Sun, 23 Jan 2005 20:54:53 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cstho-0000u7-Kq for rpsec@ietf.org; Sun, 23 Jan 2005 21:11:53 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 23 Jan 2005 21:02:42 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from russpc.Whitehouse.intra (rtp-vpn1-665.cisco.com [10.82.226.153]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0O1sKoB025716; Sun, 23 Jan 2005 20:54:21 -0500 (EST) Date: Sun, 23 Jan 2005 20:53:40 -0500 (Eastern Standard Time) From: Russ White To: Blaine Christian Subject: Re: [RPSEC] Back to the Basics: The AS Path 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: 202a3ece0492a8c7e7c8672d5214398f Cc: Stefan Mink , sandy@tislabs.com, 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: 2bf730a014b318fd3efd65b39b48818c >> -- The requirements document should state any proposed solution must >> verify/prove/etc. the path the routing information actually took is the >> same as the AS Path attribute of the route. > Hey Russ, can we work this backwards a bit and see it if still makes > sense? Perhaps we can list the cases where the path can not be proven and > still allow for path verification? Hmmm.... What do you mean by "path verification?" Do you mean proving the routing information has actually passed through the AS' listed in the AS Path? I'll assume so.... Let me start out by stating this: The claim is that this wording: "The receiver of a specific prefix/attribute MUST be able to verify the routing information has passed through every AS peering pair in the AS Path." Should replace the current wording in the BGP requirements draft, because it is supported by this: "According to the BGP specification (or according to what the BGP specification SHOULD read), each AS handling the AS Path MUST insert their AS in the AS Path. Further, no information may be removed from the AS Path." I believe you've already conceded, below, that this simply isn't the case. I'll work with that assumption, since the tenor of the rest of your email seems to assume that, but it would, actually, be nice to get a statement on whether you believe using the sense of the BGP specification, or the BGP specification itself, justifies changing the current wording.... :-) Based on my reading of your email, I'll assume you're now trying to justify changing the wording on the draft to something close to the one listed above based on a desire for non-repudiation--that's it's important to know who, exactly, forwarded a specific piece of routing information, so you can hold the originator and forwarders of that routing information liable (legally or socially) for originating or forwarding false routing information. I'll deal with this more at the end of this email. > 1. Reoriginations: This is information reduction/expansion for the sake > of performance and it could be argued that it is a tacit agreement > between the provider of reoriginated information and the reoriginatee. > If it is an agreement between originator and originatee then security > would most likely also be an agreement betwixt the two. Heck, if I do > BGP with a customer and advertise default this is essentially the same > thing. This doesn't negate my argument that informaiton is removed from the AS Path, and therefore the AS Path attribute of the route doesn't actually match the path of the routing information through the network. However, you're claiming that since this only occurs in the context of a customer and their provider, it just doesn't matter that information is removed from the AS Path. Okay, I understand your argument, I believe. The problem is you don't know if the customer has actually authorized, from the information in the reoriginated route, the advertisement of this routing information. So, you can't prove authorization, in this case, only non-repudiation. You can try to prove the customer's provider actually advertised the route, you can't prove the customer authorized the provider to do so. In fact, the provider could be maliciously advertising the customer's address space, even though a previously valid agreement allowing them to do so has now been voided because of some "falling out" between the two. > 2. Confederations: These happen "internal" to an AS so I suppose this > could just be captured and dealt with separately. Again, the point of the argument is that information is, in fact, removed from the AS Path, not that it's "internal" to an AS or not, simply that it happens. It would be different if the Confed AS' were inserted in a completely separate attribute that could be removed separately, rather than modifying the AS Path, but in reality, they aren't. They are inserted into a confederation set within the AS Path itself, and the confed set is stripped out of the AS Path at the other side of the confed. > 3. Private AS stripping: Most folks do not allow this type of stuff to > propagate beyond the initial two networks involved so again it should > fall, mostly, in the realm of a private agreement. Again, however, just because it happens in the private context doesn't show that information isn't being removed from the AS Path, correct? Again, you're arguing, as above, that it doesn't matter, because it's a private context. A BGP speaker receiving this route would only be able to assume it has the entire AS Path, and that the originator is authorized to originate it. However, unknown to the receiver, there is actually another AS in the AS Path, and there's no way for the receiver to know of the original AS actually authorized the advertisement of the routing information by the apparent originator from the routing information itself. Seems like a lot of assumptions, to me. Again, we're in the same position as reorigination, where we can try to prove non-repudiation, but not authorization. > 4. Route propagators (really just packet forwarders for all intents and > purposes). A packet forwarder is a packet forwarder. As long as > whatever security information is necessary is passed along as well I > don't think this is really germane to the discussion. ?? I don't really understand this one. > Can anyone think of other special cases such as the above? Would > everything else be "verifiable"? Just above every one of the above path > manipulations is based on either a private agreement or an internal > optimization for a network. Just about.... But, you're dealing with a separate problem here. You're morphing the issue from: -- "Does the BGP specification support changing the requirements currently listed in the requirements draft to some other wording?" -- TO -- -- "Does the requirement for non-repudiation support changing the requirements currently listed in the requirements draft to some other wording?" I believe non-repudiation is already covered in the current text of the draft, and I don't have an argument with it being there. So, I'm not certain why the wording would need to change to include non-redudiation. But let's run with the argument that non-repudiation _could_, possibly justify changing the current wording, and see where it takes us. What do we know about non-repudation, as a concept? We know that other RFCs state, quite clearly, that non-repudiation isn't possible. So, you're making something acknoweldged as not possible a MUST. IMHO, that's not a good idea. In fact, I'll just about bet the wording on non-redudiation is removed from the draft or, at the least, altered radically, before it's actually pupblished, based on the reasoning I've seen from the security folks in the past. :-) Now, let's run a different direction, and see where it takes us. Let's assume we _do_ make this wording change, and then we have to build a justification for the wording in the draft. What would the justification be? Since we can't justify the requirement with: "Because the BGP specification says so, or it should say so, and it doesn't," then we have to find some other justification, correct? That justification would be the requirements, as they are currently stated in the draft. Interesting.... If you have to justify the requirement with the current requirements, why change to some other requirement at all? I suppose I'm just confused on this point.... If I justify a requirement with something previously listed as requirements, it sounds like I'm moving into the solution space, instead of the requirements space. > You know that, no matter what happens with the specification, the ability > to track signatures across an entire AS path is quite attractive as a > means of identifying miscreants or potential issues. Even if noting and > ignoring the special cases does not work. This is a solution, not a requirement, so I won't go there.... The special cases, combined with the problems inherent with non-repudiation, kill off non-repudiation as a justifaction for the change in wording, IMHO. > Another thought... We did build into the requirements draft language that > allows for non-secure things. Wouldn't unverifiable stuff just end up in > the "not secured" realm anyway? You don't know if they are or aren't. If you remove information from the AS Path, you can't tell what that information was, so you can't say: "Oh, this is just less secure, because information has been removed from the AS Path." Second, you can't deny that in many of these situations, the removal of information is such that the originator should still expect their routes to be treated in a secure way. :-) 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 Sun Jan 23 22:57: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 WAA09730 for ; Sun, 23 Jan 2005 22:57:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CsvcI-00049H-2D for rpsec-web-archive@ietf.org; Sun, 23 Jan 2005 23:14:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsvKe-0006Dg-Bn; Sun, 23 Jan 2005 22:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsvKB-00069m-TN for rpsec@megatron.ietf.org; Sun, 23 Jan 2005 22:55: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 WAA09642 for ; Sun, 23 Jan 2005 22:55:33 -0500 (EST) Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Csvac-00045D-JO for rpsec@ietf.org; Sun, 23 Jan 2005 23:12:34 -0500 Received: from comcast.net (h00045affd586.ne.client2.attbi.com[65.96.173.139]) by comcast.net (rwcrmhc11) with SMTP id <2005012403550301300k5gr5e>; Mon, 24 Jan 2005 03:55:03 +0000 Received: by comcast.net (sSMTP sendmail emulation); Sun, 23 Jan 2005 22:55:01 -0500 Date: Sun, 23 Jan 2005 22:55:00 -0500 From: Tony Tauber To: rpsec@ietf.org Subject: Re: [RPSEC] A Call for A Reasonable Compromise on Securing the AS Path 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: 52e1467c2184c31006318542db5614d5 X-BeenThere: rpsec@ietf.org 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: e1e48a527f609d1be2bc8d8a70eb76cb On Sat, 22 Jan 2005, Russ White wrote: > Y'all: > > I've seggested, in the text of several emails, that there are a > number of ways forward on the BGP security requirements draft. IMHO, > we aren't going to reach concensus on the issue of "what security > means in the cotext of the AS Path." Well, maybe the next couple > days will tell us, but I'm assuming no such concensus will be > possible. > If the AD's have any comment on this possibility as a procedure, or > if Tony would like to chime in, I would appreciate it. Yes, we need to figure out how to move forward. I know there has been a lot of back and forth already but more than one person has indicated that the current threads have become indigestible. So, to try and encourage more diversity of opinion here, I'd like to ask everyone who's motivated to (really) succinctly indicate what is wrong with the current draft. Please stick to textual citations and/or specific suggested replacement. (If you'd like, submit an entire replacement, of course.) Please also refrain from imputation about what another would have us do or believe (eg. "some would say...") or what someone else's motivation might be. Please also refrain from hyper-verbose output and strained metaphors. We've gotten way past the point of productivity lately. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jan 23 23:33:27 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 XAA14578 for ; Sun, 23 Jan 2005 23:33:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CswBI-0005NN-IA for rpsec-web-archive@ietf.org; Sun, 23 Jan 2005 23:50:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Csvti-00024b-Qa; Sun, 23 Jan 2005 23:32:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CsvrD-0001gz-BH for rpsec@megatron.ietf.org; Sun, 23 Jan 2005 23:29:43 -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 XAA13986 for ; Sun, 23 Jan 2005 23:29:40 -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 1Csw7d-0005FI-HK for rpsec@ietf.org; Sun, 23 Jan 2005 23:46:42 -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 j0O4TA9T003854 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Sun, 23 Jan 2005 23:29:10 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 23 Jan 2005 23:29:03 -0500 Subject: Re: [RPSEC] Back to the Basics: The AS Path From: Blaine Christian To: Russ White , 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: bc102ac530ba955ef81f1f75b8bebe44 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: 10dcc25e55b9b5f7d6ded516404bdc4c Content-Transfer-Encoding: 7bit Responses inline... I just want to give this one more shot... The last few paragraphs have the most meat. I should preface with stating that I almost always take the devils advocate position in an argument. I am finding value in the discussion and about three emails back from Russ I caught some of the best discussion points yet. On 1/23/05 8:53 PM, "Russ White" wrote: > >>> -- The requirements document should state any proposed solution must >>> verify/prove/etc. the path the routing information actually took is the >>> same as the AS Path attribute of the route. > >> Hey Russ, can we work this backwards a bit and see it if still makes >> sense? Perhaps we can list the cases where the path can not be proven and >> still allow for path verification? > > Hmmm.... What do you mean by "path verification?" Do you mean proving the > routing information has actually passed through the AS' listed in the AS > Path? I'll assume so.... > I am certain that I would like to be able to "affirm" that the update traversed the stated path. I suppose this also means "prove". I am not so certain that I can see all the permutations where this would not be the case. I really did want to work this backward and see if we can come up with a limited subset of things that fall outside of verifiable. I am also not so certain that this needs to be done real time or that a potential option would not be to just declare paths that are verifiable to be "secured" and paths that are not verifiable to be "not secured". > Let me start out by stating this: The claim is that this wording: > > "The receiver of a specific prefix/attribute MUST be able to verify the > routing information has passed through every AS peering pair in the AS > Path." This is impossible as currently worded due to the exceptions we already identified. > > Should replace the current wording in the BGP requirements draft, because > it is supported by this: > > "According to the BGP specification (or according to what the BGP > specification SHOULD read), each AS handling the AS Path MUST insert their > AS in the AS Path. Further, no information may be removed from the AS > Path." As worded, not a likely addition to the text. > > I believe you've already conceded, below, that this simply isn't the case. > I'll work with that assumption, since the tenor of the rest of your email > seems to assume that, but it would, actually, be nice to get a statement on > whether you believe using the sense of the BGP specification, or the BGP > specification itself, justifies changing the current wording.... :-) Well, I am quite comfortable in stating as follows: The deployment of any new "replacement" system relies heavily on the state of the existing system. As such, the BGP specification takes second place to the great unwashed mass of actual implementation. If you want to deploy something to replace/upgrade an existing system you need to take into serious account the existing implementations, features, and the needs of the users. > > Based on my reading of your email, I'll assume you're now trying to justify > changing the wording on the draft to something close to the one listed > above based on a desire for non-repudiation--that's it's important to know > who, exactly, forwarded a specific piece of routing information, so you can > hold the originator and forwarders of that routing information liable > (legally or socially) for originating or forwarding false routing > information. I'll deal with this more at the end of this email. You know it! Not sure the wording of the draft needs changes but the desire to be able to identify issues does exist. > >> 1. Reoriginations: This is information reduction/expansion for the sake >> of performance and it could be argued that it is a tacit agreement >> between the provider of reoriginated information and the reoriginatee. >> If it is an agreement between originator and originatee then security >> would most likely also be an agreement betwixt the two. Heck, if I do >> BGP with a customer and advertise default this is essentially the same >> thing. > > This doesn't negate my argument that informaiton is removed from the AS > Path, and therefore the AS Path attribute of the route doesn't actually > match the path of the routing information through the network. However, > you're claiming that since this only occurs in the context of a customer > and their provider, it just doesn't matter that information is removed from > the AS Path. > > Okay, I understand your argument, I believe. The problem is you don't know > if the customer has actually authorized, from the information in the > reoriginated route, the advertisement of this routing information. So, you > can't prove authorization, in this case, only non-repudiation. You can try > to prove the customer's provider actually advertised the route, you can't > prove the customer authorized the provider to do so. > > In fact, the provider could be maliciously advertising the customer's > address space, even though a previously valid agreement allowing them to do > so has now been voided because of some "falling out" between the two. Ahh, my apologies, we had our sides reversed. I was more focused on the typical case which was the reduction of route information on the behalf of aging equipment, sheer desire for improved switch over speed, or load sharing. In most cases, that I am aware of, the reoriginator is usually the owner of the block being reoriginated. The "owner" of the block advertises it and does whatever the heck they want with it (assuming they use at least 80% of it ). > >> 2. Confederations: These happen "internal" to an AS so I suppose this >> could just be captured and dealt with separately. > > Again, the point of the argument is that information is, in fact, removed > from the AS Path, not that it's "internal" to an AS or not, simply that it > happens. It would be different if the Confed AS' were inserted in a > completely separate attribute that could be removed separately, rather than > modifying the AS Path, but in reality, they aren't. They are inserted into > a confederation set within the AS Path itself, and the confed set is > stripped out of the AS Path at the other side of the confed. No argument here... I was shooting for a list of things that are "less than" verifiable. > >> 3. Private AS stripping: Most folks do not allow this type of stuff to >> propagate beyond the initial two networks involved so again it should >> fall, mostly, in the realm of a private agreement. > > Again, however, just because it happens in the private context doesn't show > that information isn't being removed from the AS Path, correct? Again, > you're arguing, as above, that it doesn't matter, because it's a private > context. Yes, I am saying that in a private context people can/should do whatever they want within their networks. > > A BGP speaker receiving this route would only be able to assume it has the > entire AS Path, and that the originator is authorized to originate it. > However, unknown to the receiver, there is actually another AS in the AS > Path, and there's no way for the receiver to know of the original AS > actually authorized the advertisement of the routing information by the > apparent originator from the routing information itself. Yes, but a private AS is an internal device used to do internal things. If it was stripped out it should be okay and the system would have to deal with it. > > Seems like a lot of assumptions, to me. Again, we're in the same position > as reorigination, where we can try to prove non-repudiation, but not > authorization. I am not sure about authorization. This starts us traipsing our way back to a central authority models that give me the willies. How about, three people that I trust said they trust a fourth person. Since they trust that person I trust that person (just not as much as the first three ). And since some types of customers are really picky throw in a strict hierarchy ability (already in the draft folks). > >> 4. Route propagators (really just packet forwarders for all intents and >> purposes). A packet forwarder is a packet forwarder. As long as >> whatever security information is necessary is passed along as well I >> don't think this is really germane to the discussion. > > ?? I don't really understand this one. Hmmm, route policy servers? Packet scrubbers? Wacky stuff that does BGP magic in an attempt to optimize cost/latency etc..? I admit, it was a catchall. > >> Can anyone think of other special cases such as the above? Would >> everything else be "verifiable"? Just above every one of the above path >> manipulations is based on either a private agreement or an internal >> optimization for a network. > > Just about.... But, you're dealing with a separate problem here. You're > morphing the issue from: My apologies for any morphing. But you started it with Sandy . I can't help it if it was a great discussion. > > -- "Does the BGP specification support changing the requirements currently > listed in the requirements draft to some other wording?" > My two cents is that the implementation and non-flag day deployment issues should come first in any discussion. There are several significant BGP implementations out there. We need to be able to keep this thing up while it is evolving into a more secure system. > -- TO -- > > -- "Does the requirement for non-repudiation support changing the > requirements currently listed in the requirements draft to some other > wording?" > > I believe non-repudiation is already covered in the current text of the > draft, and I don't have an argument with it being there. So, I'm not > certain why the wording would need to change to include non-redudiation. > But let's run with the argument that non-repudiation _could_, possibly > justify changing the current wording, and see where it takes us. > > What do we know about non-repudation, as a concept? We know that other RFCs > state, quite clearly, that non-repudiation isn't possible. So, you're > making something acknoweldged as not possible a MUST. IMHO, that's not a > good idea. In fact, I'll just about bet the wording on non-redudiation is > removed from the draft or, at the least, altered radically, before it's > actually pupblished, based on the reasoning I've seen from the security > folks in the past. :-) Not sure non-repudiation needs change... But if security folks are going to give us a hard time, even though we worded it pretty loosely, then so be it, we will adapt. If folks will be overly strict in interpretation then we can work on the language. Suggestions are always welcome! > > Now, let's run a different direction, and see where it takes us. Let's > assume we _do_ make this wording change, and then we have to build a > justification for the wording in the draft. What would the justification > be? Since we can't justify the requirement with: "Because the BGP > specification says so, or it should say so, and it doesn't," then we have > to find some other justification, correct? > > That justification would be the requirements, as they are currently stated > in the draft. Interesting.... If you have to justify the requirement with > the current requirements, why change to some other requirement at all? I > suppose I'm just confused on this point.... If I justify a requirement with > something previously listed as requirements, it sounds like I'm moving into > the solution space, instead of the requirements space. You know, I was about to start this response with the words "chicken and egg" but stopped myself. Lets take a step back and talk about a network and an AS. I am thinking that we are bit bound up in thinking that one network equals one AS. This is patently not the case and I think we all know it. One network I worked on had about 10 in active use. I could really care less about whether the AS path was verified for inbound prefix announcements. What I DO care about is identifying how the prefix announcement arrived at my doorstep. For the very first external network I connect to it is easy. But take a step further in and the problem becomes very complex. Unfortunately, the only tool we have to tell us how the update arrived at our door step is the AS path. Most of the time that AS path is pretty reliable. We get a chain of providers that, in an operational role, we can go and contact individually to identify exactly where a forwarding problem, or routing issue, might exist. However, there are occasional cases where announcements/withdraws reach our network that were, in no way, acceptable announcements/withdraws. Sometimes these announcements happen so quick we do not catch them (these are the ones that really bother me). Enforce first AS helps maintain a chain of responsibility and may actually help to resolve the evidence problem. Unfortunately, if it does not get widely implemented it is useless. The same thing could be said about security in general though. A twist on this might be that if we knew that the entire path had enforce first AS enabled, and session security enabled between each set of peers, we could assign a different level of trust to that path vs. a path received without enforce AS enabled (a gauge to full implementation at least would help). To take a slightly different tack, and one I have been pushing. It is all well and good to have a wonderfully complex and highly secured system but if we can't tell when/if something is being abused in that system it is worthless. Also, the pain I experience from actors that are more than one AS hop away is usually the most exquisite. If we can't improve the system at a distance of more than one hop then I would hesitate to push forward. Now, reviewing all that blather that I put forth in the above, all I see is that we still have a system where folks can potentially abuse things. However, what we can possibly get is a mechanism to identify and deny abusers. We need the last part of the key to make this part work. What we need is the ever ephermal idea of "authorization". If we are using one of our nifty new protocols to propagate "ownership" of prefix space the reuse of that tool to secure peering sessions seems tantalizingly close. This leads us back to the idea that the path is "plausible". If a announcement/withdraw has passed the hurdle of enforced first AS, has traversed secured inter-as connections, exists, and comes from a "trusted" party then it would certainly be plausible. It actually seems highly probable. Does this make sense? What we would not have, in the above, would be end to end security of the actual advertisement. I am not sure how end to end security of an advertisement is possible when each AS makes it's own magic with advertisements. Even if I end to end secured the advertisement it is still defeatable internal to any of the networks. > >> You know that, no matter what happens with the specification, the ability >> to track signatures across an entire AS path is quite attractive as a >> means of identifying miscreants or potential issues. Even if noting and >> ignoring the special cases does not work. > > This is a solution, not a requirement, so I won't go there.... > Okay... Remove the word signatures. The ability to be "more sure" that the update traversed a set of networks (note I pulled the term AS path out) is attractive. > The special cases, combined with the problems inherent with > non-repudiation, kill off non-repudiation as a justifaction for the change > in wording, IMHO. > >> Another thought... We did build into the requirements draft language that >> allows for non-secure things. Wouldn't unverifiable stuff just end up in >> the "not secured" realm anyway? > > You don't know if they are or aren't. If you remove information from the AS > Path, you can't tell what that information was, so you can't say: "Oh, this > is just less secure, because information has been removed from the AS > Path." Second, you can't deny that in many of these situations, the removal > of information is such that the originator should still expect their routes > to be treated in a secure way. > That is true... I suppose my thinking is that people already secure their internal network bits and getting anal about someone ELSES network is pretty futile. Either they are going to take care of it or not. If we can identify that they are a source of hacking they will either adapt or wither. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 08:21: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 IAA07008 for ; Mon, 24 Jan 2005 08:21:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct4Qb-0002ln-S9 for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 08:38:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct486-0004ys-3W; Mon, 24 Jan 2005 08:19:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct3wV-0002pM-Jz for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 08:07:43 -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 IAA05676 for ; Mon, 24 Jan 2005 08:07:41 -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 1Ct4D0-0002Hk-Nf for rpsec@ietf.org; Mon, 24 Jan 2005 08:24:47 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1Ct3wS-00077e-UF; Mon, 24 Jan 2005 14:07:41 +0100 Message-ID: <41F4F32B.903@schlund.net> Date: Mon, 24 Jan 2005 14:07:55 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russ White Subject: Re: [RPSEC] Back to the Basics: The AS Path References: <41F3AE42.80605@schlund.net> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: rpsec@ietf.org, sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1521761357==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1521761357== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6800BA00C8C4ADDC06766376" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6800BA00C8C4ADDC06766376 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Russ, Russ White wrote: > Of course, actual implementations don't have an adj-rib-in, loc-rib, and > adj-rib-out (I always confuse all of these names, and call them the > wrong thing), so these are models of behaviour, not requirements. sure, but requirements should rather be based on these models of behavior than on how it is usually implemented. Otherwise it would make unusual and may be better ways of implementation impossible. > I'm not certain what you mean by authorizing: "the route of a route." I > suppose there are a number of ways I could take this. Suppose I have: > > A---B---C > > Are you saying you want to show that A is authorizing B to send routing > information to C? But, if the AS Path doesn't always actually reflect > the path the routing information has taken (as you acknowledge in at > least one case), .... the fact that there are currently situations, where the as-path does not reflect the actual forwarding path, is at least partially based on the fact, that it wasn't a critical requirement. As you wrote many things are being done today because it didn't hurt anybody so far. If now it starts hurting, maybe we should more think about how to avoid these situations. For me, origin authorisation is just the beginning. The authorization, to pass on routes (and by this permit traffic to flow in the opposite direction) is relevant to network stability (what happends if a big traffic flow due to a wrong announcment starts to use a network path that doesn't have the capacity to carry it) and can have an impact on the economic result, i.e. who is earning money with which traffic. I don't want my customers to announce my prefixes to another transit of them and my wish would be, that a future security architecture would be able to actually make it verifiable, wether a received route was sent by the other side in an authorized way. You can not keep "an attacker" from announcing routes he isn't authorized to announce to another BGP neighbor. On the other hand as an honest BGP neighbor you should be able to check, if an advertisement is not authorized. How do you verify, wether an announcement is authorized? Not by checking the RIR database but by checking contracts between BGP neighbors. And thats exactly the point where current policies are not precise enough. The only contain what's beeing announced to whom but not what he is allowed to do with it. Now if you want to check that authorization chain, on which data do you base it? There's just the as-path, that in many/most cases reflects the ASes it traversed, but in many cases it does not. My point is that in the latter case, authorization is just not verifiable without adding another bgp attribute that truely reflects the path the update took. Concerning the difference between routing path and forwarding path, you still have the problem, that you can avoid loops on routing plane but you can not on forwarding plane. For me a routing protocol with this behavior is a real danger. You didn't reply to this so far. >> agreed, this is a valuable usage e.g. when merging ASes > > > ....how can you prove this using the AS Path? I'm not certain how to get > to "authorization to advertise routing information" from "prove the > route has followed the path listed in the AS Path?", since the AS Path > doesn't actually represent the path the routing information took through > the network, in all cases? I don't see any problems here. If two ASes merge, authorizations don't change for that reason. If there is still a physical separation of the networks or not is not relevant for the rest of the internet. > Beyond this, why do we want to prove this "authorization chain?" Is it > to prove the sender is authorizing packets to flow along the reverse > path than the one the routing information took? Since you can't ever > prove traffic flows along the reverse path the routing information > takes, this doesn't seem to be helpful, either. > draft-white-pathconsiderations-04 shows some examples of this occuring. just because something is broken, it doesn't mean we shouldn't try to fix ist :) > Finally, you could say you're actually trying to authorize the > advertisement of reachability information, since the route is actually > made up of a prefix and attributes, which is what we would call > reachability information. "Is my peer authorized to advertise > reachability to 10.1.1.1 to me?" is the sort of question we're talking > about here. And, here again, draft-white-pathconsiderations-04 shows how > this doesn't work in the real world, the first example is the simplest. that means to me, that a verification of authorization is not achievable :( > So, I suppose I'm confused by the concept of "authorization" in the > context of the AS Path as carried in BGP routes. What does it mean, > exactly? What are we attempting to authorize? the current state is: if you have a route, you can do what you want with it and the only thing you can do is withdraw a route from a BGP peer if he's announcing it in a way it's not authorized from your point of view (e.g. a customer announces one of your prefixes to a peer or transit provider, the only thing you can do is withdraw the route). I hate it but it seems to be a similar problem the media industry is facing with music/video... > The path of the routing information is actually {65100,1,2,3}, but > you're reporting the path of the routing information as {1,2,3}. It's > not a matter of the operation being "internal," it's a matter of the > path of the routing information not matching the reported path of the > routing information. I consider AS65100 as not being autonomous, but as being part of AS1. > Another example is confederations, where AS' are inserted into, and then > removed from, the AS Path. Again, the confed AS appears to be a single > AS to the remainder of the internetwork, but there are path elements > that are added and removed, showing the AS Path is not a sacrosant > version of the actual path of the routing information. same point here. The sub-ASes of the confederations are not autonomous. They can only interoperate with other ASes by using the official ASN. >> I didn't get this :-/ >> If the routing path differs from the forwarding path, this can lead to >> loops on the forwarding plane. For this reason this is very dangerous >> and should never be constructed intentionally. I know there are con- >> stellations with route reflectors and more specifics where this can >> occur without anybody doing "something wrong", but this should not >> be a basis to consider this behavior as accepted. > > > draft-white-pathconsiderations-04, first example. I would consider each > entity's actions within the internetwork perfectly acceptable and normal > behaviour. sorry, for me it's not acceptable and is far from normal. Just one example to show how fragile such constructs are: Assume AS D somehow looses the route to E, then B is blackholing all traffic to E. > There are two camps here: > > -- The requirements document should state any proposed solution must > verify/prove/etc. the path the routing information actually took is the > same as the AS Path attribute of the route. that's me. But I also see that this is hard to achieve at the moment, but it could be achieved, if people would understand, that its dangerous if routing plane and forwarding plane do differnt things. I'd be glad if somebody would tell me that I got it all wrong and there's no problem but so far nobody did. You could be the first one, who illustrates me not only that this is common practise, but also that there are no disadvantages and dangers whatsoever with this practise... tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig6800BA00C8C4ADDC06766376 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 iD8DBQFB9PMuehvPYvDU0roRAoR5AKC9Fj31YKtxV3u0spZDX7W9N4AwUgCgsvJV 178G3QPh8JquCc0bzHZj/so= =9/o9 -----END PGP SIGNATURE----- --------------enig6800BA00C8C4ADDC06766376-- --===============1521761357== 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 --===============1521761357==-- From rpsec-bounces@ietf.org Mon Jan 24 11:09:00 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 LAA25282 for ; Mon, 24 Jan 2005 11:09:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct72R-0001FA-S2 for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 11:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct6gc-0004bi-Hy; Mon, 24 Jan 2005 11:03:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct6co-00043u-1R for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 10:59: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 KAA24431 for ; Mon, 24 Jan 2005 10:59: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 1Ct6tH-0000qJ-BL for rpsec@ietf.org; Mon, 24 Jan 2005 11:16:38 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 96B302D4C3C; Mon, 24 Jan 2005 10:55: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 09271-01-7; Mon, 24 Jan 2005 10:55:36 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A2B022D4C05; Mon, 24 Jan 2005 10:55:36 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0OFtag06134; Mon, 24 Jan 2005 10:55:36 -0500 (EST) Date: Mon, 24 Jan 2005 10:55:36 -0500 From: Jeffrey Haas To: Blaine Christian Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050124155536.GC5850@nexthop.com> References: <200501212316.j0LNGXut025350@tislabs.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: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: e1e48a527f609d1be2bc8d8a70eb76cb On Fri, Jan 21, 2005 at 06:52:52PM -0500, Blaine Christian wrote: > Okay... I can give you common practice from my perspective. Common practice > is that an ISP will delegate a more specific prefix to a customer. All the > ISP usually cares about is advertising the less specific prefix. It is > normally a bad idea for the owner of a less specific chunk of prefixes who > has allocated a more specific prefix to a customer to advertise that more > specific prefix on their own (unless they are propagating a BGP advert). To be clear here, you're specifically saying: ISP-A(ggregate) will not be originating the more specific prefix into the BGP network themselves? If so, I think we're all in agreement. >From a possible security infrastructure standpoint (pointing towards the current RIR, IRR entities), it would be very unusual for someone to allocate address space from a block and assign it for advertisement to not only the delegated party, but also the owning party. It would be weird... ... but I can't see a reason to preclude it. > The one "loaner" chunk of information that I HAVE seen as pretty much > forbidden by many is the use of a "loaner" AS outside of the owners control. > Even this is not illegal in the protocol, obviously, but it does create all > sorts of complications which contra-indicate its use (path loops getting > interesting here). At minimum, I think this would be bad key hygiene and you typically would not want to do this. The question is, do we want to make allowances for this in our requirements? -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 12:03: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 MAA01670 for ; Mon, 24 Jan 2005 12:03:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7th-0003UO-P5 for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 12:21:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7ZJ-0001b5-DD; Mon, 24 Jan 2005 12:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7NW-00074l-KU for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 11:47:50 -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 LAA28700 for ; Mon, 24 Jan 2005 11:47:47 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7e3-0002kC-Rh for rpsec@ietf.org; Mon, 24 Jan 2005 12:04: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 j0OGl9jf021060; Mon, 24 Jan 2005 11:47:10 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 24 Jan 2005 11:38:50 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Back to Basics--The AS Path X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.6 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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="===============0730145583==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba --===============0730145583== Content-Type: multipart/alternative; boundary="============_-1105537267==_ma============" --============_-1105537267==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I'll just pick one example of a significant error in this message, because finding and correcting all of them is too much work. >On searching the document for all occurances of the words: >"as_path," or: "as path," I found only a few instances. The one I >_believe_ is relevant is here, on page 25: > > b) When a given BGP speaker advertises the route to an external > peer, then the advertising speaker updates the AS_PATH attribute > as follows: > > 1) if the first path segment of the AS_PATH is of type > AS_SEQUENCE, the local system prepends its own AS number as the > last element of the sequence (put it in the leftmost position > with respect to the position of octets in the protocol mes- > sage). If the act of prepending will cause an overflow in the > AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a > new segment of type AS_SEQUENCE and prepend its own AS number > to this new segment. > >When I examine this text, I find two interesting things: > >-- First, there is no mention of any conditions under which >information may be removed from the AS Path, or the AS Path is >reordered. I believe, based on reading of the specification (without >outside reference to operational or implementation experience), this >means the AS Path may be reordered, or information may be removed >from the AS Path. Let me at least say neither of these are strictly >prohibited. Perhaps you forgot the following quote from the BGP spec that appeared in my message a few weeks ago: The path segment type is a 1-octet long field with the following values defined: Value Segment Type 1 AS_SET: unordered set of ASs a route in the UPDATE message has traversed 2 AS_SEQUENCE: ordered set of ASs a route in the UPDATE message has traversed This makes a pretty clear statement about the ordering of the AS numbers in an AS_SEQUENCE, and what they represent. Steve --============_-1105537267==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] Back to Basics--The AS Path
I'll just pick one example of a significant error in this message, because finding and correcting all of them is too much work.


On searching the document for all occurances of the words: "as_path," or: "as path," I found only a few instances. The one I _believe_ is relevant is here, on page 25:

        b) When a given BGP speaker advertises the route to an external
        peer, then the advertising speaker updates the AS_PATH attribute
        as follows:

           1) if the first path segment of the AS_PATH is of type
           AS_SEQUENCE, the local system prepends its own AS number as the
           last element of the sequence (put it in the leftmost position
           with respect to the position of octets in the protocol mes-
           sage). If the act of prepending will cause an overflow in the
           AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
           new segment of type AS_SEQUENCE and prepend its own AS number
           to this new segment.

When I examine this text, I find two interesting things:
-- First, there is no mention of any conditions under which information may be removed from the AS Path, or the AS Path is reordered. I believe, based on reading of the specification (without outside reference to operational or implementation experience), this means the AS Path may be reordered, or information may be removed from the AS Path. Let me at least say neither of these are strictly prohibited.

Perhaps you forgot the following quote from the BGP spec that appeared in my message a few weeks ago:

The path segment type is a 1-octet long field with the following values defined:


     Value      Segment Type


       1         AS_SET: unordered set of ASs a route in the
                    UPDATE message has traversed
       2         AS_SEQUENCE: ordered set of ASs a route in
                    the UPDATE message has traversed
This makes a pretty clear statement about the ordering of the AS numbers in an AS_SEQUENCE, and what they represent.

Steve
--============_-1105537267==_ma============-- --===============0730145583== 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 --===============0730145583==-- From rpsec-bounces@ietf.org Mon Jan 24 12:08: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 MAA02275 for ; Mon, 24 Jan 2005 12:08:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7ya-0003ig-Mw for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 12:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7ZJ-0001bA-TK; Mon, 24 Jan 2005 12:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7NZ-00074n-BL for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 11:47:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28703 for ; Mon, 24 Jan 2005 11:47:49 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7e6-0002k9-D6 for rpsec@ietf.org; Mon, 24 Jan 2005 12:04:58 -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 j0OGl9jh021060; Mon, 24 Jan 2005 11:47:11 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 24 Jan 2005 11:44:55 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.6 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0749470099==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============0749470099== Content-Type: multipart/alternative; boundary="============_-1105537265==_ma============" --============_-1105537265==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" OK, this additional error was so egregious I could not pass it up: > >-- Add additional information to an AS Path, causing it to _not_ represent >the list of peerwise AS peerings the update has passed through. A common >example of this is AS Path prepend. > Again, you seem to be ignoring the following quote from my analysis of BGP message, discussion section 5.1.2 of the document: ... The end of this subsection explicitly allows for adding multiple instances of the ASes own number; this is not seen by the spec as conflicting the notion of the UPDATE having traversed the path it contains, e.g., indicating a loop. The text I was referring to was this: Whenever the modification of the AS_PATH attribute calls for including or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration. This shows that the example you cite is explicitly allowed in the spec. Steve --============_-1105537265==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] Back to the Basics: The AS Path
OK, this additional error was so egregious  I could not pass it up:



-- Add additional information to an AS Path, causing it to _not_ represent
the list of peerwise AS peerings the update has passed through. A common
example of this is AS Path prepend.

Again, you seem to be ignoring the following quote from my analysis of BGP message, discussion section 5.1.2 of the document:

... The end of this subsection explicitly allows for adding multiple instances of the ASes own number; this is not seen by the spec as conflicting the notion of the UPDATE having traversed the path it contains, e.g., indicating a loop.

The text I was referring to was this:

Whenever the modification of the AS_PATH attribute calls for including or prepending the AS number of the local system, the local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute. This is controlled via local configuration.

This shows that the example you cite is explicitly allowed in the spec.

Steve
--============_-1105537265==_ma============-- --===============0749470099== 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 --===============0749470099==-- From rpsec-bounces@ietf.org Mon Jan 24 12:20: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 MAA03067 for ; Mon, 24 Jan 2005 12:20:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct89f-00048z-UI for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 12:37:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7b5-0001u1-O3; Mon, 24 Jan 2005 12:01:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7Sp-0008Ft-7l for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 11:53: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 LAA29147 for ; Mon, 24 Jan 2005 11:53:16 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7jL-0002yK-Ei for rpsec@ietf.org; Mon, 24 Jan 2005 12:10:25 -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 j0OGqijf021352; Mon, 24 Jan 2005 11:52:45 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <41F3AE42.80605@schlund.net> References: <41F3AE42.80605@schlund.net> Date: Mon, 24 Jan 2005 11:52:21 -0500 To: Stefan Mink From: Stephen Kent Subject: Re: [RPSEC] Back to the Basics: The AS Path 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 3:01 PM +0100 1/23/05, Stefan Mink wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="------------enig16C79B98A61BD3940547B207" > >Hi Russ, > >Russ White wrote: > >>My last message last night actually drove me back into the BGP >>specification, to discover what the specification really says. Note that >>throughout this email, I've used your preferred wording, using the term >>"update" as if updates were transitive objects being sent through a BGP >>network, and I've attempted to be as precise as possible in all definitions >>and wordings. > > >for me, the word "update" is an inprecise reference fo "UPDATE >message" which is >clearly a message beween to BGP neighbors, and not somthing transitive. The >BGP draft also states that >"Routes are stored in the Routing Information Bases (RIBs): namely, >the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out, as described in >Section 3.2.". So no updates are stored, but routes (= content of an update) >are put into different RIBs. yes, the UPDATE message per se is not passed through ASes. For example, a set of withdrawn routes in an UPDATE message is purely a local transmission of that data. Selected AS path attribute data is transitive, and it makes up the bulk of the UPDATE message. A route is a set of NLRI and associated path data, and that is what is stored in these nominal databases, as per the spec. The BGP spec indicates which path attributes are transitive and which are not, and thus which ones need to be passed on (transitively) to neighbors, if the speaker decides to propagate the route. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 12:21: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 MAA03199 for ; Mon, 24 Jan 2005 12:21:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8Ax-0004BN-MT for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 12:38:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7j7-0003OZ-Vs; Mon, 24 Jan 2005 12:10:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7ZK-0001bR-Az for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 12:00: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 LAA29890 for ; Mon, 24 Jan 2005 11:59:59 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct7pq-0003GT-W5 for rpsec@ietf.org; Mon, 24 Jan 2005 12:17:08 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OGuWox014625 for ; Mon, 24 Jan 2005 11:56:32 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAmzaWJC; Mon, 24 Jan 05 11:56:30 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OGwI54017678; Mon, 24 Jan 2005 11:58:18 -0500 (EST) Date: Mon, 24 Jan 2005 11:58:18 -0500 (EST) From: Sandy Murphy Message-Id: <200501241658.j0OGwI54017678@tislabs.com> To: rpsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: sandy@tislabs.com Subject: [RPSEC] a new question about valid advertisements (originations) X-BeenThere: rpsec@ietf.org 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 We settled the question last week about being allocated a /8, suballocating a /16 and continuing to announce the /8. Everyone believes that this is desirable and wants to have the security properties state that this is valid and the security mechanisms continue to permit it. Done. But what about if the organization that is allocated the /8 and suballocated the /16 announces the /16 also? Such things happen when providers are attempting to do load balancing and the like, right? So I've been thinking that if you were allocated a /8 you would be allowed to advertise any more specific prefix as well. But is the case where you are advertising a more specific prefix that you've suballocated to another party against the accepted behavior? I can see the possibility that this would be considered a security problem, as announcing the /16 you'd suballocated would effect the way traffic flowed in the Internet, as some places would see and accept one /16 and others would see and accept the other. So help me out here - is the announcement of a more specific prefix of a block you've been allocated and which you've suballocated to someone else - permitted? a problem? something to prevent with the security mechanisms? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 12:27: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 MAA03593 for ; Mon, 24 Jan 2005 12:27:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8G2-0004Oq-6n for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 12:44:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7u9-00009k-P3; Mon, 24 Jan 2005 12:21:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7gT-0002uf-Rc for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 12:07:25 -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 MAA02121 for ; Mon, 24 Jan 2005 12:07:22 -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 1Ct7wy-0003bf-EV for rpsec@ietf.org; Mon, 24 Jan 2005 12:24:31 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id BDE742D483C for ; Mon, 24 Jan 2005 12:06:50 -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 14815-02-27 for ; Mon, 24 Jan 2005 12:06:46 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id F1AD52D4B91 for ; Mon, 24 Jan 2005 12:06:32 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0OH6Wv06344 for rpsec@ietf.org; Mon, 24 Jan 2005 12:06:32 -0500 (EST) Date: Mon, 24 Jan 2005 12:06:32 -0500 From: Jeffrey Haas To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124170632.GD5850@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: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 X-BeenThere: rpsec@ietf.org 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: f2728948111f2edaaf8980b5b9de55af On Sat, Jan 22, 2005 at 08:37:07AM -0500, Russ White wrote: > b) When a given BGP speaker advertises the route to an external > peer, then the advertising speaker updates the AS_PATH attribute > as follows: > > 1) if the first path segment of the AS_PATH is of type > AS_SEQUENCE, the local system prepends its own AS number as the > last element of the sequence (put it in the leftmost position > with respect to the position of octets in the protocol mes- > sage). If the act of prepending will cause an overflow in the > AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a > new segment of type AS_SEQUENCE and prepend its own AS number > to this new segment. > > When I examine this text, I find two interesting things: > > -- First, there is no mention of any conditions under which information may > be removed from the AS Path, or the AS Path is reordered. I believe, based > on reading of the specification (without outside reference to operational > or implementation experience), this means the AS Path may be reordered, or > information may be removed from the AS Path. Let me at least say neither of > these are strictly prohibited. When adding to an AS_SEQUENCE, the operation is a prepend. When you overflow an AS_SEQUENCE path segment, you prepend a new AS_SEQUENCE. Thus, a compliant implementation will only _prepend_ AS numbers. An AS_PATH may be changed by the specification under the following circumstances: Aggregation using AS_SETS will cause the generation of AS_SETS. These sets are unordered but are suggested to be sorted. An AS_SET will count as a length of 1 towards AS_PATH length in the decision process. Aggregation using the "brief" form will cause the truncation of the AS_PATH. When the path is truncated, ATOMIC_AGGREGATE must be attached. Confederations modify the AS_PATH by adding the confederation versions of AS_SETS and AS_SEQUENCES. These are removed upon advertisement to a confederation external peer. They follow the same rules. In operational practice: o When utilizing private AS numbers, trailing private AS numbers may be stripped. I am unaware of implementations that will strip non private AS numbers. o Some implementations will allow an operator to insert an arbitrary set of AS numbers into the AS_PATH, however it will also prepend it's own AS number upon advertising the route to an external peer. My own conclusions are: o Re-ordering does not happen inside of sequences. AS_PATHs may be truncated during aggregation (by the specification) or by removing private AS numbers (outside of the specification). Removing private AS numbers may introduce loops if done improperly. However, the scope of these loops are usually localized to the private ASes which are usually stub ASes. o Even when additional ASes are introduced into the AS_PATH (outside of the specification), loops are not introduced. They effectively prune path availability. This is the only common operational practice that I'm aware of that potentially breaks pair-wise AS adjacency verification. The operational requirements of this feature in a "secure" BGP infrastructure are somewhat dubious but beg the question of "authorization to advertise". Note that implementations have knobs that allow one to accept advertisements that are a local-loop. > -- Second, when describing the operation of a BGP speaker, the draft > doesn't say the speaker MUST prepend its own AS number as the last element > of the sequence, it simply says: "the local system prepends its own AS > number as the last element of the sequence." In my experience, when draft > authors intend to make a restrictive requirement, they use the phrase MUST > in the requirement. In this case, it appears the wording is explanitory, > rather than a requirement (?). This is reinforced by the following: : If the UPDATE message is received from an external peer, the local : system MAY check whether the leftmost (with respect to the position : of octets in the protocol message) AS in the AS_PATH attribute is : equal to the autonomous system number of the peer that sent the mes- : sage. If the check determines that this is not the case, the Error : Subcode MUST be set to Malformed AS_PATH. > -- Third, that the MUST is missing implies the authors, reviewers, and > contributors to this specification (if you refer to page 7, you'll find I'm > listed as a contributor) believed there were valid situations when a BGP > speaker would not follow the operational procedure described here. The only operational scenario that I'm aware of that allows for the adjacent AS check to be disabled (which defaults to on in most of the implementations that I'm aware of) is proxy BGP routing (a route server). > Would you say this is all correct? I believe, then, that you cannot get the > proposed requirement listed above from the BGP specification itself. At > least I can't find any justification for it. If you believe the > specification should say "MUST" at this point, I would say that's an > argument for the IDR WG, not for RPsec. :-) I believe we (or at least I) made the suggestion that the requirements allow for route servers. So, with the exception of the two operationally common exceptions I listed above, the spec is generally followed. All of these situations can be reasonably accomodated by a suggested infrastructure. To make suggestions: o Private AS removal is similar to our truncation arguments when we're talking about aggregation. So long as the AS at the rightmost side is the one that the security infrastrucutre says is allowed to originate the AS in the public Internet, truncation is fine and would not violate globally visible security. o Route servers could be accomodated a few different ways: + Actually put the server's AS in the path, follow normal practice. + Treat this as a special zone of trust (much like internal BGP) and don't verify adjacent AS (but use transport layer security), make sure that the recipient of the proxied route executes the normal security practices. o Arbitrarily inserting ASes to deny "authorization" to receive a route is a harder case. This almost suggests a new AS_PATH type specifically to accomodate this in the security infrastructure. > "On receiving an update, any proposed solution MUST verify the update has > passed through the pairwise peerings represnted by the AS Path attribute > contained in the update." > > And base it on this reasoning: > > "The sense of the BGP specification is that the protocol will not operate > correctly is this rule is not followed, or that's what the BGP > specification authors meant to say, or that's what the BGP specification > should say, and it was just missed." Here's where I'll make the other side of the argument: The specification says to prepend. I've given the known cases where we may change things beyond prepending. Operationally, people rely on the adjancencies for policy. This is outside the protocol specification. Loop detection is a condition of phase two of the route selection process: : If the AS_PATH attribute of a BGP route contains an AS loop, the BGP : route should be excluded from the Phase 2 decision function. AS loop : detection is done by scanning the full AS path (as specified in the : AS_PATH attribute), and checking that the autonomous system number of : the local system does not appear in the AS path. Operations of a BGP : speaker that is configured to accept routes with its own autonomous : system number in the AS path are outside the scope of this document Ergo, the only requirement for loop free operation of the protocol is that the AS be present in the path. In general, you should receive your routes with your peer's AS at the start of the AS_PATH. The protocol will work properly if the path is re-ordered. However, if implementations start reordering the path for no good reason, operators will be very, very upset. [Russ gives a similar list above] > -- Advertise a set of reachable addresses which contains address space > reachable through a different AS Path than that listed in the update. A > common instance of this is the re-origination of routing information at an > autonomous system border. Re-origination may potentially lead to loops. However, I don't think this violates the security infrastructure so long as the route is allowed to be originated (by the security infrastructure) by multiple parties. > With these thoughts in mind, we must choose between one of three > alternatives: > > -- These examples are a figment of my imagination. If you want to choose > this option, you'll need to consult my psychologist. I'm afraid I can't > help you any further. :-) > > -- Operators shouldn't be doing these things, and therefore the > justification above stands. In fact, the security requirements document > should be defined so such modifications are not allowed, and the BGP > specification should be modified in accordance with this. I would contend > this is operationally unteneble. > > -- The requirement, as listed, in some way, doesn't truly define what > "valid" means as applied to an AS Path, based on operational and > implementation experience. Four: The security infrastructure should just deal with these things as they're not insurmountable. Only the arbitrary addition of ASes is problematic. Compliant implementations will follow the prepend rule. Truncating the path must be dealt with for aggregation. > Now, if we can't base the definition of "valid" in reference to the AS Path > on the BGP specification, because the required MUST isn't there, and > operational experience shows we can't base it on what we think the "sense > of the BGP draft is or should be," then how can we define "valid" in > reference to an AS Path? I think I've presented arguments to the contrary, above. Final notes: At no step of the above process is "authorization" included. BGP, in general, does not express the ability to propogate or not propagate a reachability. The operational practice of injecting someone's AS number in a route to prevent them from receiving a route could be considered a form of "denial of authorization", but that's largely out of scope of the protocol. In any case, I'm not trying to prove authorization using any of the above information. I'm not sure "non-repudiation" is the security property we actually want out of verifying pairwise adjacencies. I don't want to say "you're claiming to not have sent me this". Instead I want to say "each of these parties have touched this route and propagated it". I don't think they're exactly the same thing. I also seem to remember a comment either on rpsec or bgpsecreq asserting the same thing, but I can't find the relevant message. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 12:32: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 MAA04122 for ; Mon, 24 Jan 2005 12:32:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8LF-0004eb-OP for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 12:49:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7us-0000gG-7r; Mon, 24 Jan 2005 12:22:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7mC-0004ar-J0 for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 12:13: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 MAA02588 for ; Mon, 24 Jan 2005 12:13:17 -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 1Ct82j-0003q4-U1 for rpsec@ietf.org; Mon, 24 Jan 2005 12:30:26 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 87D9C2D4965; Mon, 24 Jan 2005 12:12:48 -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 14815-02-65; Mon, 24 Jan 2005 12:12:45 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D37FE2D4868; Mon, 24 Jan 2005 12:12:42 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0OHCgo06379; Mon, 24 Jan 2005 12:12:42 -0500 (EST) Date: Mon, 24 Jan 2005 12:12:42 -0500 From: Jeffrey Haas To: Sandy Murphy Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050124171241.GE5850@nexthop.com> References: <200501211734.j0LHYH4e011723@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501211734.j0LHYH4e011723@tislabs.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Fri, Jan 21, 2005 at 12:34:17PM -0500, Sandy Murphy wrote: > I've heard different opinions on how common the proxy aggregation > case is. One example of the security requirement process would be to > decide if this was a semantics we wanted to retain and secure > and if so how. (Implicit aggregation - you just have to show > your allocation from someone else, where that might be IANA. Proxy > aggregation - you have to show .... that you received two updates > that add up to the aggregated prefix??? At any rate, it's nay > so easy.) I believe the suggestion I made on bgpsecreq is that one can't readily describe a proxy aggregate as being a secure route. Therefore, this is a good target for transitive local trust (perhaps the wrong terminology). By way of example, if I advertise a proxy aggregate, I can verify from the originating party that they've claimed to originated the route, and that they don't claim to "own" the route. I may then choose based on my trust metric via the people who have propagated the route whether or not I'll accept that route. I know that I can't trace the route to IANA delegation. Tracing the originating party is problematic. The process of generating an aggregate will change the AS_PATH. The AS portion of the AGGREGATOR could be used for the authorization operation, but AGGREGATOR may be overwritten upon the next aggregation operation. Dealing with this case in the security infrastructure cleanly may require BGP protocol changes, although mild ones. > --Sandy -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 12:34: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 MAA04311 for ; Mon, 24 Jan 2005 12:34:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8N6-0004kT-An for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 12:51:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7uv-0000iK-8w; Mon, 24 Jan 2005 12:22:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct7nR-0005CQ-R8 for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 12:14:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02669 for ; Mon, 24 Jan 2005 12:14:34 -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 1Ct83y-0003uX-B6 for rpsec@ietf.org; Mon, 24 Jan 2005 12:31:43 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CF73B2D4AE9; Mon, 24 Jan 2005 12:14:04 -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 15056-01-55; Mon, 24 Jan 2005 12:14:03 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 74A902D4AD7; Mon, 24 Jan 2005 12:14:03 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0OHE3I06386; Mon, 24 Jan 2005 12:14:03 -0500 (EST) Date: Mon, 24 Jan 2005 12:14:03 -0500 From: Jeffrey Haas To: Stephen Kent Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124171403.GF5850@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: 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 Steve, On Mon, Jan 24, 2005 at 11:44:55AM -0500, Stephen Kent wrote: > OK, this additional error was so egregious I could not pass it up: To be fair to Russ: > >-- Add additional information to an AS Path, causing it to _not_ represent > >the list of peerwise AS peerings the update has passed through. A common > >example of this is AS Path prepend. > > Again, you seem to be ignoring the following quote from my analysis > of BGP message, discussion section 5.1.2 of the document: Russ, I believe, was speaking of the Cisco "as path prepend" operation in their CLI. This option is what is used to insert an arbitrary number of ASes beyond that of the local AS number. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 12:55: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 MAA06230 for ; Mon, 24 Jan 2005 12:55:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8he-0005bJ-DJ for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 13:12:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8Ir-0005as-P7; Mon, 24 Jan 2005 12:47:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8Ac-0003wu-VI for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 12:38: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 MAA04738 for ; Mon, 24 Jan 2005 12:38:31 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8R9-0004uu-Lf for rpsec@ietf.org; Mon, 24 Jan 2005 12:55:41 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OHZ3lc019663 for ; Mon, 24 Jan 2005 12:35:03 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAmQa4yM; Mon, 24 Jan 05 12:35:01 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OHanqb019295; Mon, 24 Jan 2005 12:36:49 -0500 (EST) Date: Mon, 24 Jan 2005 12:36:49 -0500 (EST) From: Sandy Murphy Message-Id: <200501241736.j0OHanqb019295@tislabs.com> To: rpsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sandy@tislabs.com Subject: [RPSEC] Re: Back to Basics--The AS Path X-BeenThere: rpsec@ietf.org 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 >I've used your preferred wording, using the term >"update" as if updates were transitive objects being sent through a BGP >network, I'd like to go on record right now to say that I do not believe that updates are transitive objects. I hope that I've never said that updates were transitive, since "transitive" is a term that applies to relations, not objects. If I ever said updates were transitive, I apologize for being so inprecise in terminology. And inaccurate, even if you were trying to stretch the definition of transitive to include objects or operations on objects, since we all know that any update is created anew by each AS on the basis of received and configured info. So. Update are not transitive. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 12:56: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 MAA06285 for ; Mon, 24 Jan 2005 12:56:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8i8-0005bj-9F for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 13:13:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8J3-0005cP-LX; Mon, 24 Jan 2005 12:47:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8B5-00041V-03 for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 12:39: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 MAA04766 for ; Mon, 24 Jan 2005 12:38:59 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8Rb-0004vc-Oz for rpsec@ietf.org; Mon, 24 Jan 2005 12:56:09 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OHZXb0019755 for ; Mon, 24 Jan 2005 12:35:33 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAi4aiKM; Mon, 24 Jan 05 12:35:30 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OHbJ8q019355; Mon, 24 Jan 2005 12:37:19 -0500 (EST) Date: Mon, 24 Jan 2005 12:37:19 -0500 (EST) From: Sandy Murphy Message-Id: <200501241737.j0OHbJ8q019355@tislabs.com> To: rpsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sandy@tislabs.com Subject: [RPSEC] Re: Back to Basics--The AS Path X-BeenThere: rpsec@ietf.org 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: 93238566e09e6e262849b4f805833007 >-- First, there is no mention of any conditions under which information may >be removed from the AS Path, or the AS Path is reordered. I believe, based >on reading of the specification (without outside reference to operational >or implementation experience), this means the AS Path may be reordered, or >information may be removed from the AS Path. Let me at least say neither of >these are strictly prohibited. An interesting interpretation of the spec. (Tongue in cheek.) I do not believe that you can read a spec to say that any operation not "strictly prohibited" is allowed. The specs say what operations should be performed, they could not hope to cover all possible operations that are not to be performed. So I reject this line of reasoning. But I'm also going to post this section of your email to the idr list to see if other implementers interpret specs in this way and this specific part of this spec in this specific way. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 12:56: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 MAA06311 for ; Mon, 24 Jan 2005 12:56:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8iL-0005cH-37 for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 13: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 1Ct8JA-0005eG-Bo; Mon, 24 Jan 2005 12:47:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8CF-00047E-7y for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 12:40: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 MAA04871 for ; Mon, 24 Jan 2005 12:40:12 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct8Sm-0004xe-1Y for rpsec@ietf.org; Mon, 24 Jan 2005 12:57:21 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OHajlm019832 for ; Mon, 24 Jan 2005 12:36:45 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAxLaOUM; Mon, 24 Jan 05 12:36:43 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OHcVwu019383; Mon, 24 Jan 2005 12:38:31 -0500 (EST) Date: Mon, 24 Jan 2005 12:38:31 -0500 (EST) From: Sandy Murphy Message-Id: <200501241738.j0OHcVwu019383@tislabs.com> To: rpsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sandy@tislabs.com Subject: [RPSEC] Re: Back to Basics--The AS Path X-BeenThere: rpsec@ietf.org 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: 9466e0365fc95844abaf7c3f15a05c7d >-- Second, when describing the operation of a BGP speaker, the draft >doesn't say the speaker MUST prepend its own AS number as the last element >of the sequence, it says it "will." In my experience, when a draft means >"MUST," it uses "MUST," rather than "will." This implies the writers of >this specification (if you refer to page 7, you'll find I'm listed as a >contributor) believed there were valid situations when a BGP speaker would >not follow the operational procedure described here. Good catch, Russ!!! I've been in a number of idr meetings where exactly this point was discussed. The idr security vulnerabilities draft I wrote initally mentioned the vulnerabilities that result if the AS_PATH did not start with the peer's AS. I was told that the new version of the spec said that it was necessary for the peer to add it's own AS. So I softened the language to say only that if implementations did not check for the peer's AS as the first AS, bogus AS_PATHs could still be produced. I'm passing this one to the idr list to find out if the MUST was removed because of special conditions or whether this was an oversight. It's an important oversight, I would say, that should be corrected if possible. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 13:32: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 NAA09573 for ; Mon, 24 Jan 2005 13:32:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9HL-00078P-BB for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 13:49:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8y2-0007DV-NJ; Mon, 24 Jan 2005 13:29:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct8u8-000641-KC for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 13:25:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08926 for ; Mon, 24 Jan 2005 13:25:33 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9Ag-0006qH-0w for rpsec@ietf.org; Mon, 24 Jan 2005 13:42:43 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OIM6iD025715 for ; Mon, 24 Jan 2005 13:22:06 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7_aqmY; Mon, 24 Jan 05 13:22:00 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OINijP021165; Mon, 24 Jan 2005 13:23:44 -0500 (EST) Date: Mon, 24 Jan 2005 13:23:44 -0500 (EST) From: Sandy Murphy Message-Id: <200501241823.j0OINijP021165@tislabs.com> To: jhaas@nexthop.com, kent@bbn.com Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >Russ, I believe, was speaking of the Cisco "as path prepend" operation >in their CLI. This option is what is used to insert an arbitrary >number of ASes beyond that of the local AS number. Ouch. People actually operationally add arbitrary AS's to the AS_PATH? I'm stuck right now on the idea of how I might protect the AS_PATH if this were a desired feature. I don't know how either a "check the pairwise adjacencies" check or a "check for transit through the mentioned AS's" check could deal with this. Any chance this could be considered a current operational behavior that would be deprecated as faciilitating abusive practices? It can be difficult to allow only benign manipulations if those same manipulations can be malicious as well. Unless you can find a way for the code to tell the benign cases from the malicious ones. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 13:57: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 NAA11776 for ; Mon, 24 Jan 2005 13:57:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9fA-00087o-LP for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 14: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 1Ct9Cd-0001tZ-Gt; Mon, 24 Jan 2005 13:44:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct98h-00013u-4j for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 13:40: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 NAA10270 for ; Mon, 24 Jan 2005 13:40:37 -0500 (EST) From: sthaug@nethelp.no Received: from bizet.nethelp.no ([195.1.209.33]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ct9PE-0007TK-GP for rpsec@ietf.org; Mon, 24 Jan 2005 13:57:45 -0500 Received: (qmail 63588 invoked by uid 1001); 24 Jan 2005 18:40:25 -0000 To: sandy@tislabs.com Subject: Re: [RPSEC] Back to the Basics: The AS Path In-Reply-To: Your message of "Mon, 24 Jan 2005 13:23:44 -0500 (EST)" References: <200501241823.j0OINijP021165@tislabs.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 24 Jan 2005 19:40:25 +0100 Message-ID: <63586.1106592025@bizet.nethelp.no> X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 > >Russ, I believe, was speaking of the Cisco "as path prepend" operation > >in their CLI. This option is what is used to insert an arbitrary > >number of ASes beyond that of the local AS number. > > Ouch. People actually operationally add arbitrary AS's to the AS_PATH? The common usage is to prepend an arbitrary number of your *own* AS to the path. I wouldn't be surprised if some people depend on being able to prepend an arbitrary AS other than their own. > Any chance this could be considered a current operational behavior > that would be deprecated as faciilitating abusive practices? Being able to prepend your own AS is vital. Steinar Haug, Nethelp consulting, sthaug@nethelp.no _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 13:58: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 NAA11961 for ; Mon, 24 Jan 2005 13:58:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9gN-0008D6-JX for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 14:15:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9Co-0001vd-LC; Mon, 24 Jan 2005 13:44:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct99r-0001Dd-Eq for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 13:41: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 NAA10556 for ; Mon, 24 Jan 2005 13:41:49 -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 1Ct9QO-0007Vb-Ch for rpsec@ietf.org; Mon, 24 Jan 2005 13:58:57 -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 j0OIec9T021496 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 24 Jan 2005 13:40:42 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 24 Jan 2005 13:40:31 -0500 Subject: Re: [RPSEC] Back to the Basics: The AS Path From: Blaine Christian To: Sandy Murphy , , Message-ID: In-Reply-To: <200501241823.j0OINijP021165@tislabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit On 1/24/05 1:23 PM, "Sandy Murphy" wrote: >> Russ, I believe, was speaking of the Cisco "as path prepend" operation >> in their CLI. This option is what is used to insert an arbitrary >> number of ASes beyond that of the local AS number. > > Ouch. People actually operationally add arbitrary AS's to the AS_PATH? Normally, AS's are prepended by the AS sending the update (in other words they prepend their OWN AS not someone elses). > > I'm stuck right now on the idea of how I might protect the AS_PATH if > this were a desired feature. I don't know how either a "check the > pairwise adjacencies" check or a "check for transit through the > mentioned AS's" check could deal with this. Lump multiple, identical, AS numbers together and you should be able to still check pairwise. > > Any chance this could be considered a current operational behavior > that would be deprecated as faciilitating abusive practices? Not much of a chance. Very widely used. > > It can be difficult to allow only benign manipulations if those > same manipulations can be malicious as well. Unless you can find > a way for the code to tell the benign cases from the malicious ones. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:04: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 OAA12871 for ; Mon, 24 Jan 2005 14:04:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9lz-0008WI-Kf for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 14:21:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9Q0-0005QE-Ds; Mon, 24 Jan 2005 13:58:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9EM-0002I5-1F for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 13:46: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 NAA10945 for ; Mon, 24 Jan 2005 13:46: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 1Ct9Up-0007jo-1h for rpsec@ietf.org; Mon, 24 Jan 2005 14:03:36 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j0OIk5KN021554; Mon, 24 Jan 2005 18:46:05 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j0OIk55s021551; Mon, 24 Jan 2005 18:46:05 GMT Date: Mon, 24 Jan 2005 18:46:05 +0000 From: bmanning@vacation.karoshi.com To: Sandy Murphy Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124184605.GK20867@vacation.karoshi.com.> References: <200501241823.j0OINijP021165@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501241823.j0OINijP021165@tislabs.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rpsec@ietf.org, jhaas@nexthop.com, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Mon, Jan 24, 2005 at 01:23:44PM -0500, Sandy Murphy wrote: > >Russ, I believe, was speaking of the Cisco "as path prepend" operation > >in their CLI. This option is what is used to insert an arbitrary > >number of ASes beyond that of the local AS number. > > Ouch. People actually operationally add arbitrary AS's to the AS_PATH? every single day. AS padding is common practice > Any chance this could be considered a current operational behavior > that would be deprecated as faciilitating abusive practices? perhaps not. why would you consider this an abusive practice? > It can be difficult to allow only benign manipulations if those > same manipulations can be malicious as well. Unless you can find > a way for the code to tell the benign cases from the malicious ones. i am reminded that even normally benign actions, when taken to excess or w/o consideration of the environment where there operatate, may be malignant. biological analogs of recent memory include death by excessive salt and water intake. > > --Sandy > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:08:39 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 OAA13179 for ; Mon, 24 Jan 2005 14:08:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9qN-0000Fy-GL for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 14:25:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9Tq-0007Pf-Rk; Mon, 24 Jan 2005 14: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 1Ct9I3-0003Oo-QN for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 13:50: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 NAA11114 for ; Mon, 24 Jan 2005 13:50:17 -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 1Ct9Ya-0007qE-W9 for rpsec@ietf.org; Mon, 24 Jan 2005 14:07:26 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 6DD882D4EA4; Mon, 24 Jan 2005 13:49:41 -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 26174-01-79; Mon, 24 Jan 2005 13:49:38 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 2D99E2D4DCF; Mon, 24 Jan 2005 13:49:27 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0OInR206749; Mon, 24 Jan 2005 13:49:27 -0500 (EST) Date: Mon, 24 Jan 2005 13:49:26 -0500 From: Jeffrey Haas To: Blaine Christian Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124184926.GJ5850@nexthop.com> References: <200501241823.j0OINijP021165@tislabs.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: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Blaine, On Mon, Jan 24, 2005 at 01:40:31PM -0500, Blaine Christian wrote: > On 1/24/05 1:23 PM, "Sandy Murphy" wrote: > >> Russ, I believe, was speaking of the Cisco "as path prepend" operation > >> in their CLI. This option is what is used to insert an arbitrary > >> number of ASes beyond that of the local AS number. > > > > Ouch. People actually operationally add arbitrary AS's to the AS_PATH? > > Normally, AS's are prepended by the AS sending the update (in other words > they prepend their OWN AS not someone elses). Given this assumption (you only append your own ASes), a security mechanism can be devised to deal with this. (After all, in this case, the set of ASes is considered an equivalence class as far as the security goes.) More problematic is when this is done by adding in an AS_SET. AS_SETs are problematic for AS_PATH security in general. However, we're aware of people who do this to deny routes to other ASes. This means they put someone else's AS in there. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:12:10 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 OAA13535 for ; Mon, 24 Jan 2005 14:12:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9tk-0000Pe-MU for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 14:29:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9VF-0007wz-Fj; Mon, 24 Jan 2005 14:03:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9NU-0004iw-EO for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 13:55: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 NAA11712 for ; Mon, 24 Jan 2005 13:55:54 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9e1-00085I-2X for rpsec@ietf.org; Mon, 24 Jan 2005 14:13:03 -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 j0OIt5jh028057; Mon, 24 Jan 2005 13:55:12 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 24 Jan 2005 13:52:36 -0500 To: Blaine Christian From: Stephen Kent Subject: Re: [RPSEC] Back to the Basics: The AS Path 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, jhaas@nexthop.com, Sandy Murphy X-BeenThere: rpsec@ietf.org 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 1:40 PM -0500 1/24/05, Blaine Christian wrote: >On 1/24/05 1:23 PM, "Sandy Murphy" wrote: > >>> Russ, I believe, was speaking of the Cisco "as path prepend" operation >>> in their CLI. This option is what is used to insert an arbitrary >>> number of ASes beyond that of the local AS number. >> >> Ouch. People actually operationally add arbitrary AS's to the AS_PATH? > >Normally, AS's are prepended by the AS sending the update (in other words >they prepend their OWN AS not someone elses). OK, but that's what I cited as a specifically allowed behavior in the current BGP spec. So, is that what you assumed Russ meant, or is it "let's add arbitrary ASes?" > >> >> I'm stuck right now on the idea of how I might protect the AS_PATH if >> this were a desired feature. I don't know how either a "check the >> pairwise adjacencies" check or a "check for transit through the >> mentioned AS's" check could deal with this. > >Lump multiple, identical, AS numbers together and you should be able to >still check pairwise. the fact that it is just a repeated instance of the same AS makes this easy. > >> >> Any chance this could be considered a current operational behavior >> that would be deprecated as faciilitating abusive practices? > >Not much of a chance. Very widely used. I think Sandy was talking about the "arbitrary AS" case, not the case where an AS adds itself multiple times. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:13: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 OAA13642 for ; Mon, 24 Jan 2005 14:13:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9v4-0000UP-D2 for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 14:30:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9YT-0000BG-BU; Mon, 24 Jan 2005 14:07:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9QL-0005Ul-SR for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 13:58:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12009 for ; Mon, 24 Jan 2005 13:58:52 -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 1Ct9gt-0008Di-E4 for rpsec@ietf.org; Mon, 24 Jan 2005 14:16:00 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j0OIwpKN021606; Mon, 24 Jan 2005 18:58:51 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j0OIwpxY021603; Mon, 24 Jan 2005 18:58:51 GMT Date: Mon, 24 Jan 2005 18:58:51 +0000 From: bmanning@vacation.karoshi.com To: sthaug@nethelp.no Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124185851.GM20867@vacation.karoshi.com.> References: <200501241823.j0OINijP021165@tislabs.com> <63586.1106592025@bizet.nethelp.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63586.1106592025@bizet.nethelp.no> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rpsec@ietf.org, sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On Mon, Jan 24, 2005 at 07:40:25PM +0100, sthaug@nethelp.no wrote: > > >Russ, I believe, was speaking of the Cisco "as path prepend" operation > > >in their CLI. This option is what is used to insert an arbitrary > > >number of ASes beyond that of the local AS number. > > > > Ouch. People actually operationally add arbitrary AS's to the AS_PATH? > > The common usage is to prepend an arbitrary number of your *own* AS to > the path. I wouldn't be surprised if some people depend on being able > to prepend an arbitrary AS other than their own. and there are some folks who have several AS'es and they use these as well as private AS'es.. > > Any chance this could be considered a current operational behavior > > that would be deprecated as faciilitating abusive practices? > > Being able to prepend your own AS is vital. yes. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:15:17 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 OAA13759 for ; Mon, 24 Jan 2005 14:15:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9wm-0000WQ-NY for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 14:32:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9YW-0000CL-08; Mon, 24 Jan 2005 14:07:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9S4-0005w1-D3 for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:00: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 OAA12126 for ; Mon, 24 Jan 2005 14:00:38 -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 1Ct9ib-0008Fl-Co for rpsec@ietf.org; Mon, 24 Jan 2005 14:17: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 j0OIxw9T021725 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 24 Jan 2005 13:59:59 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 24 Jan 2005 13:59:51 -0500 Subject: Re: [RPSEC] Back to the Basics: The AS Path 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, jhaas@nexthop.com, Sandy Murphy X-BeenThere: rpsec@ietf.org 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 > > OK, but that's what I cited as a specifically allowed behavior in the > current BGP spec. So, is that what you assumed Russ meant, or is it > "let's add arbitrary ASes?" > >> >>> >>> I'm stuck right now on the idea of how I might protect the AS_PATH if >>> this were a desired feature. I don't know how either a "check the >>> pairwise adjacencies" check or a "check for transit through the >>> mentioned AS's" check could deal with this. >> >> Lump multiple, identical, AS numbers together and you should be able to >> still check pairwise. > > the fact that it is just a repeated instance of the same AS makes this easy. > I have heard exactly one "request" for random AS insertion from an operator. The request was based on a desire to ensure that "certain" AS's would reject an announcement (taking advantage of loop free BGP behavior). This will be a question I will posit for the operators. >> >>> >>> Any chance this could be considered a current operational behavior >>> that would be deprecated as faciilitating abusive practices? >> >> Not much of a chance. Very widely used. > > I think Sandy was talking about the "arbitrary AS" case, not the case > where an AS adds itself multiple times. > > Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:24:44 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 OAA14627 for ; Mon, 24 Jan 2005 14:24:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtA5w-0000sK-7w for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 14:41:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9mP-0002sz-V4; Mon, 24 Jan 2005 14:21:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9f6-0001f2-1l for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:14:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13702 for ; Mon, 24 Jan 2005 14:14:06 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ct9vd-0000Un-54 for rpsec@ietf.org; Mon, 24 Jan 2005 14:31:15 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OJAZZw002263 for ; Mon, 24 Jan 2005 14:10:35 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAApfaGAe; Mon, 24 Jan 05 14:10:33 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OJCLiL023053; Mon, 24 Jan 2005 14:12:21 -0500 (EST) Date: Mon, 24 Jan 2005 14:12:21 -0500 (EST) From: Sandy Murphy Message-Id: <200501241912.j0OJCLiL023053@tislabs.com> To: rpsec@ietf.org, sthaug@nethelp.no Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 >Being able to prepend your own AS is vital. Yes, understood. But prepending arbitrary AS's is a challenging security principle to support. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:28: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 OAA14896 for ; Mon, 24 Jan 2005 14:28:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtA9b-00012R-Gy for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 14:45:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9nu-0003GA-17; Mon, 24 Jan 2005 14:23:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9jT-0002LS-67 for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:18: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 OAA14097 for ; Mon, 24 Jan 2005 14:18:37 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtA00-0000ck-OU for rpsec@ietf.org; Mon, 24 Jan 2005 14:35:46 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OJF9Xs002774 for ; Mon, 24 Jan 2005 14:15:09 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAd4aaAf; Mon, 24 Jan 05 14:15:06 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OJGtad023213; Mon, 24 Jan 2005 14:16:55 -0500 (EST) Date: Mon, 24 Jan 2005 14:16:55 -0500 (EST) From: Sandy Murphy Message-Id: <200501241916.j0OJGtad023213@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 >> Ouch. People actually operationally add arbitrary AS's to the AS_PATH? > >Normally, AS's are prepended by the AS sending the update (in other words >they prepend their OWN AS not someone elses). Yes, well understood. It was the *arbitrary* AS prepending that I was asking about. Judging paths as valid that have the same AS several times in sequence is no problem. >Lump multiple, identical, AS numbers together and you should be able to >still check pairwise. Same way works if you are trying to judge by AS's transited. >> Any chance this could be considered a current operational behavior >> that would be deprecated as faciilitating abusive practices? > >Not much of a chance. Very widely used. Understand what I'm trying to say here. It is prepending *ARBITRARY* AS's that I don't quite see a way to secure right now. It's the *ARBITRARY* nature that is the problem, not the prepending. Please - don't go thinking (or saying) that I have spoken out agains prepending multiple copies of your own AS. I haven't. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:35: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 OAA15357 for ; Mon, 24 Jan 2005 14:35:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtAFt-0001Fe-05 for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 14:52:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9wC-0004fm-VQ; Mon, 24 Jan 2005 14:31:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9rD-0003s2-Tb for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:26: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 OAA14830 for ; Mon, 24 Jan 2005 14:26:37 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtA7m-0000xg-6l for rpsec@ietf.org; Mon, 24 Jan 2005 14:43:46 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OJNA6Z003960 for ; Mon, 24 Jan 2005 14:23:10 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAASmaiUh; Mon, 24 Jan 05 14:23:07 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OJOtv6023512; Mon, 24 Jan 2005 14:24:55 -0500 (EST) Date: Mon, 24 Jan 2005 14:24:55 -0500 (EST) From: Sandy Murphy Message-Id: <200501241924.j0OJOtv6023512@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a >> Ouch. People actually operationally add arbitrary AS's to the AS_PATH? > > every single day. AS padding is common practice *ARBITRARY* prepending? So AS 100 puts AS 333's AS in the AS_PATH it is advertising? Note: I am not now suggesting, nor have I ever suggested, that prepending your own AS multiple times is a problem. If one wants to allow *ARBITRARY* AS prepending, then one has a very difficult time telling a totally bogus AS_PATH from a legitimate, operational use AS_PATH. >> Any chance this could be considered a current operational behavior >> that would be deprecated as faciilitating abusive practices? > > perhaps not. why would you consider this an abusive practice? I didn't say it was an abusive practice. I said it facilitated abusive practices. By making the totoally fictional bogus AS_PATH indistinguishable (at least to me right now) from a AS_PATH deliberately created by a legitimate operator. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:36: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 OAA15485 for ; Mon, 24 Jan 2005 14:36:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtAHI-0001Hv-Ls for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 14:53:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9xu-00055g-Tw; Mon, 24 Jan 2005 14:33:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ct9sD-00041M-II for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:27:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14884 for ; Mon, 24 Jan 2005 14:27: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 1CtA8k-0000yc-TE for rpsec@ietf.org; Mon, 24 Jan 2005 14:44:48 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j0OJRVKN021750; Mon, 24 Jan 2005 19:27:31 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j0OJRVn4021747; Mon, 24 Jan 2005 19:27:31 GMT Date: Mon, 24 Jan 2005 19:27:30 +0000 From: bmanning@vacation.karoshi.com To: Sandy Murphy Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124192730.GA21736@vacation.karoshi.com.> References: <200501241912.j0OJCLiL023053@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501241912.j0OJCLiL023053@tislabs.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: rpsec@ietf.org, sthaug@nethelp.no X-BeenThere: rpsec@ietf.org 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: 7d33c50f3756db14428398e2bdedd581 On Mon, Jan 24, 2005 at 02:12:21PM -0500, Sandy Murphy wrote: > >Being able to prepend your own AS is vital. > > Yes, understood. But prepending arbitrary AS's is a challenging security > principle to support. where will you check to ensure an AS is properly assigned? whois? --bill > --Sandy > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:45: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 OAA16051 for ; Mon, 24 Jan 2005 14:45:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtAQ4-0001bq-VY for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 15:02:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtA6G-0006zW-A3; Mon, 24 Jan 2005 14:42:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtA53-0006Pc-PG for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:40: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 OAA15876 for ; Mon, 24 Jan 2005 14:40:55 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtALb-0001U4-O9 for rpsec@ietf.org; Mon, 24 Jan 2005 14:58:05 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OJbSfu005742 for ; Mon, 24 Jan 2005 14:37:28 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA41aGnl; Mon, 24 Jan 05 14:37:26 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OJdEV5024039; Mon, 24 Jan 2005 14:39:14 -0500 (EST) Date: Mon, 24 Jan 2005 14:39:14 -0500 (EST) From: Sandy Murphy Message-Id: <200501241939.j0OJdEV5024039@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 >However, we're aware of people who do this to deny routes to other ASes. >This means they put someone else's AS in there. I have heard of this, and Blaine just mentioned this. But I don't understand -- why choose this technique to deny routes to other AS's. It seems to me that a withdrawal or not issuing an update at all accomplishes the same purpose. So why is this chosen as the mechanism for denying routes to other AS's? If there's a unique advantage to doing it this way, that's one thing. But if this one case is the sticking point behind avoiding a definition that says you shouldn't insert *ARBITRARY* (note well: ARBITRARY, not your own) AS's, and if there are other ways to accomplish the same purpose, then I'd say one alternative would be to prohibit the behavior and let the operators use the other techniques for accomplishing their purpose. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:53:39 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 OAA16705 for ; Mon, 24 Jan 2005 14:53:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtAXv-0001xH-Rx for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 15:10:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAGF-00007C-Km; Mon, 24 Jan 2005 14:52:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtA8M-0007He-1M for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:44: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 OAA16007 for ; Mon, 24 Jan 2005 14:44:20 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtAOu-0001af-5g for rpsec@ietf.org; Mon, 24 Jan 2005 15:01:29 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OJeqkR006262 for ; Mon, 24 Jan 2005 14:40:52 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4iaqmm; Mon, 24 Jan 05 14:40:48 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OJga94024310; Mon, 24 Jan 2005 14:42:36 -0500 (EST) Date: Mon, 24 Jan 2005 14:42:36 -0500 (EST) From: Sandy Murphy Message-Id: <200501241942.j0OJga94024310@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sthaug@nethelp.no X-BeenThere: rpsec@ietf.org 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: 856eb5f76e7a34990d1d457d8e8e5b7f >> Yes, understood. But prepending arbitrary AS's is a challenging security >> principle to support. > > where will you check to ensure an AS is properly assigned? > whois? Assigned? What do you mean? We're currently just trying to decide what a valid path is. We haven't talked yet about how one would perform the verification, if that's what you mean. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 14:58: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 OAA17079 for ; Mon, 24 Jan 2005 14:58:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtAcz-00028F-3e for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 15:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAGM-00009G-0S; Mon, 24 Jan 2005 14:52:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtA9F-0007O8-1F for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:45: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 OAA16047 for ; Mon, 24 Jan 2005 14:45:15 -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 1CtAPk-0001bZ-V3 for rpsec@ietf.org; Mon, 24 Jan 2005 15:02:24 -0500 Received: from [172.17.19.3] (helo=[172.17.19.3]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CtA97-0004qm-SQ; Mon, 24 Jan 2005 20:45:10 +0100 Message-ID: <41F5503C.90308@schlund.net> Date: Mon, 24 Jan 2005 20:45:00 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [RPSEC] Back to the Basics: The AS Path References: <200501241823.j0OINijP021165@tislabs.com> In-Reply-To: <200501241823.j0OINijP021165@tislabs.com> 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: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: rpsec@ietf.org, jhaas@nexthop.com, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1205551098==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1205551098== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF334DB48E4015C84A60FC81" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF334DB48E4015C84A60FC81 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sandy Murphy wrote: >Ouch. People actually operationally add arbitrary AS's to the AS_PATH? > >I'm stuck right now on the idea of how I might protect the AS_PATH if >this were a desired feature. I don't know how either a "check the >pairwise adjacencies" check or a "check for transit through the >mentioned AS's" check could deal with this. > >Any chance this could be considered a current operational behavior >that would be deprecated as faciilitating abusive practices? > > in the past I once used the "as path prepend" feature to prepend certain routes from transit providers with their own AS to make them less likely to be elected as best route. I'm not sure this is really "abusive" practice although I did more than prepend my own AS number. I'm fully d'accord that this is not a brilliant practise but using a higher localPref ist sometimes not the right path and prepending your own AS just doesn't work here. The application here would not really break a security architecture since no arbitrary AS was inserted but only ASes involved in the sessions. But I'm not sure what other "creative" usages are still possible... tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigDF334DB48E4015C84A60FC81 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.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9VA/ehvPYvDU0roRAuKLAKCprthqwiODZX0EkICGXRoiNU0zggCgsRml Q1losCaOhCa995BpQaDN5tY= =Tvqy -----END PGP SIGNATURE----- --------------enigDF334DB48E4015C84A60FC81-- --===============1205551098== 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 --===============1205551098==-- From rpsec-bounces@ietf.org Mon Jan 24 15:01: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 PAA17381 for ; Mon, 24 Jan 2005 15:01:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtAfv-0002Fo-6X for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 15:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAGZ-0000Er-Ku; Mon, 24 Jan 2005 14:52:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAEF-0008GF-2k for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:50: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 OAA16525 for ; Mon, 24 Jan 2005 14:50:24 -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 1CtAUk-0001pb-LU for rpsec@ietf.org; Mon, 24 Jan 2005 15:07:34 -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 j0OJnl9T022360 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 24 Jan 2005 14:49:50 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 24 Jan 2005 14:49:40 -0500 Subject: Re: [RPSEC] Back to the Basics: The AS Path From: Blaine Christian To: Sandy Murphy , Message-ID: In-Reply-To: <200501241939.j0OJdEV5024039@tislabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit On 1/24/05 2:39 PM, "Sandy Murphy" wrote: >> However, we're aware of people who do this to deny routes to other ASes. >> This means they put someone else's AS in there. > > I have heard of this, and Blaine just mentioned this. But I don't > understand -- why choose this technique to deny routes to other AS's. > It seems to me that a withdrawal or not issuing an update at all > accomplishes the same purpose. > > So why is this chosen as the mechanism for denying routes to other AS's? The trick is that it works for one specific AS and not the Internet in general. If I insert provider Xs AS in the AS path they will reject the announcement. No one else will reject it. I don't know of another knob that can do this... > > If there's a unique advantage to doing it this way, that's one thing. > > But if this one case is the sticking point behind avoiding a definition > that says you shouldn't insert *ARBITRARY* (note well: ARBITRARY, not > your own) AS's, and if there are other ways to accomplish the same > purpose, then I'd say one alternative would be to prohibit the > behavior and let the operators use the other techniques for accomplishing > their purpose. > > --Sandy > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 15:02: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 PAA17429 for ; Mon, 24 Jan 2005 15:02:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtAgc-0002Gg-Aj for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 15:19:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAGa-0000F2-5e; Mon, 24 Jan 2005 14:52:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAEG-0008GK-KO for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:50:28 -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 OAA16528 for ; Mon, 24 Jan 2005 14:50:26 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtAUo-0001q4-Pc for rpsec@ietf.org; Mon, 24 Jan 2005 15:07:36 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OJkwXn006874 for ; Mon, 24 Jan 2005 14:46:58 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAoiaaBn; Mon, 24 Jan 05 14:46:56 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OJVjSu023762; Mon, 24 Jan 2005 14:31:45 -0500 (EST) Date: Mon, 24 Jan 2005 14:31:45 -0500 (EST) From: Sandy Murphy Message-Id: <200501241931.j0OJVjSu023762@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 >> The common usage is to prepend an arbitrary number of your *own* AS to >> the path. I wouldn't be surprised if some people depend on being able >> to prepend an arbitrary AS other than their own. > > and there are some folks who have several AS'es and > they use these as well as private AS'es.. I know that there are folks who own several AS's for various reasons. But could they not just make sure that they repeat the same one of those AS's when they do multiple prepending? Hope it's not just a "the config tools don't let us". As for private AS's, I thought the whole idea of the "private" part was that you didn't include them in updates to external peers? Isn't that commonly reported as bad practice? >> Being able to prepend your own AS is vital. > > yes. Not in question. No one has suggested that you wouldn't be able to do so. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 15:12:21 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 PAA18727 for ; Mon, 24 Jan 2005 15:12:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtAq1-0002bL-MS for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 15:29:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtATE-00055F-VA; Mon, 24 Jan 2005 15:05:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAGo-0000Na-Kq for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:53: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 OAA16672 for ; Mon, 24 Jan 2005 14:53:04 -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 1CtAXM-0001wP-BG for rpsec@ietf.org; Mon, 24 Jan 2005 15:10:14 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j0OJr3KN021872; Mon, 24 Jan 2005 19:53:03 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j0OJr27S021869; Mon, 24 Jan 2005 19:53:02 GMT Date: Mon, 24 Jan 2005 19:53:02 +0000 From: bmanning@vacation.karoshi.com To: Sandy Murphy Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124195302.GB21736@vacation.karoshi.com.> References: <200501241924.j0OJOtv6023512@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501241924.j0OJOtv6023512@tislabs.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) 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.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Mon, Jan 24, 2005 at 02:24:55PM -0500, Sandy Murphy wrote: > >> Ouch. People actually operationally add arbitrary AS's to the AS_PATH? > > > > every single day. AS padding is common practice > > *ARBITRARY* prepending? So AS 100 puts AS 333's AS in the AS_PATH it > is advertising? so if AS 4555 prepended AS 7085 and AS 2886, there would be a problem for you? (all these ASN are held by me) > Note: I am not now suggesting, nor have I ever suggested, that > prepending your own AS multiple times is a problem. right. > If one wants to allow *ARBITRARY* AS prepending, then one has a very > difficult time telling a totally bogus AS_PATH from a legitimate, > operational use AS_PATH. > > >> Any chance this could be considered a current operational behavior > >> that would be deprecated as faciilitating abusive practices? > > > > perhaps not. why would you consider this an abusive practice? > > I didn't say it was an abusive practice. I said it facilitated abusive > practices. By making the totoally fictional bogus AS_PATH indistinguishable > (at least to me right now) from a AS_PATH deliberately created by > a legitimate operator. ok... so when a process is deliberatly designed to be "opaque" to external view/review, it lends itself/facilites potentially abusive practices. can RPSEC deal w/ "opaque" bits in the validation path? > > --Sandy > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 15:13:36 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 PAA18867 for ; Mon, 24 Jan 2005 15:13:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtArF-0002fh-07 for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 15:30:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtATI-00058I-Q3; Mon, 24 Jan 2005 15:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAIj-0000f5-6z for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 14:55: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 OAA16771 for ; Mon, 24 Jan 2005 14:55:03 -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 1CtAZH-0001yI-Dr for rpsec@ietf.org; Mon, 24 Jan 2005 15:12:12 -0500 Received: from [172.17.19.3] (helo=[172.17.19.3]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CtAIf-0008Lh-Mh; Mon, 24 Jan 2005 20:55:02 +0100 Message-ID: <41F5528F.2010101@schlund.net> Date: Mon, 24 Jan 2005 20:54:55 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [RPSEC] Back to the Basics: The AS Path References: <200501241939.j0OJdEV5024039@tislabs.com> In-Reply-To: <200501241939.j0OJdEV5024039@tislabs.com> 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: 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: , Content-Type: multipart/mixed; boundary="===============0099257807==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0099257807== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE22A675DA7BA5FC8B3EC0271" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE22A675DA7BA5FC8B3EC0271 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sandy Murphy wrote: >>However, we're aware of people who do this to deny routes to other ASes. >>This means they put someone else's AS in there. >> >> > >I have heard of this, and Blaine just mentioned this. But I don't >understand -- why choose this technique to deny routes to other AS's. >It seems to me that a withdrawal or not issuing an update at all >accomplishes the same purpose. > >So why is this chosen as the mechanism for denying routes to other AS's? > >If there's a unique advantage to doing it this way, that's one thing. > >But if this one case is the sticking point behind avoiding a definition >that says you shouldn't insert *ARBITRARY* (note well: ARBITRARY, not >your own) AS's, and if there are other ways to accomplish the same >purpose, then I'd say one alternative would be to prohibit the >behavior and let the operators use the other techniques for accomplishing >their purpose. > > welcome back to the authorization problem :) There is currently no clean way to influence the distribution of a route once it left your router... tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigE22A675DA7BA5FC8B3EC0271 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.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9VKPehvPYvDU0roRAnq0AKC8jZz90ZayN9ii8SuafMRpvRuKOQCfSbA1 pkN2QZDImqPBCvMqsPRXvfA= =6nBN -----END PGP SIGNATURE----- --------------enigE22A675DA7BA5FC8B3EC0271-- --===============0099257807== 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 --===============0099257807==-- From rpsec-bounces@ietf.org Mon Jan 24 15:27: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 PAA20593 for ; Mon, 24 Jan 2005 15:27:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtB4G-00039N-8h for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 15:44:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAiz-0007su-VA; Mon, 24 Jan 2005 15:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAgZ-00065v-Ei for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 15:19:43 -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 PAA19592 for ; Mon, 24 Jan 2005 15:19: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 1CtAx8-0002uW-QG for rpsec@ietf.org; Mon, 24 Jan 2005 15:36:51 -0500 Received: from [172.17.19.3] (helo=[172.17.19.3]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CtAgW-0005bn-Ls; Mon, 24 Jan 2005 21:19:41 +0100 Message-ID: <41F55853.8050408@schlund.net> Date: Mon, 24 Jan 2005 21:19:31 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmanning@vacation.karoshi.com Subject: Re: [RPSEC] Back to the Basics: The AS Path References: <200501241924.j0OJOtv6023512@tislabs.com> <20050124195302.GB21736@vacation.karoshi.com.> In-Reply-To: <20050124195302.GB21736@vacation.karoshi.com.> 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: rpsec@ietf.org, Sandy Murphy X-BeenThere: rpsec@ietf.org 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="===============0961210719==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0961210719== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4F73E0FEA9067F5349823BD5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4F73E0FEA9067F5349823BD5 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit bmanning@vacation.karoshi.com wrote: > so if AS 4555 prepended AS 7085 and AS 2886, there would > >be a problem for you? (all these ASN are held by me) > is there are reason why you wanted to prepend the other two ASes besides wanting to avoid they use the route? If not prepending by 4555 would perfectly do as well, wouln't it? tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig4F73E0FEA9067F5349823BD5 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.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9VhVehvPYvDU0roRAr5ZAJ9BycVfnQxuaMRFQQJsKITtNusWywCdGSU3 9wkuzp5UCLIH8GMYk55DSwc= =tJB2 -----END PGP SIGNATURE----- --------------enig4F73E0FEA9067F5349823BD5-- --===============0961210719== 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 --===============0961210719==-- From rpsec-bounces@ietf.org Mon Jan 24 15:44: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 PAA21674 for ; Mon, 24 Jan 2005 15:44:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBLT-0003t0-40 for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 16:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtB2J-0008Vp-Lr; Mon, 24 Jan 2005 15:42:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAxO-0006DE-Le for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 15:37: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 PAA21123 for ; Mon, 24 Jan 2005 15:37:04 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBDx-0003Rv-4X for rpsec@ietf.org; Mon, 24 Jan 2005 15:54:14 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OKXZs4010894 for ; Mon, 24 Jan 2005 15:33:35 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAF5aWqv; Mon, 24 Jan 05 15:33:33 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OKZJxU026800; Mon, 24 Jan 2005 15:35:19 -0500 (EST) Date: Mon, 24 Jan 2005 15:35:19 -0500 (EST) From: Sandy Murphy Message-Id: <200501242035.j0OKZJxU026800@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 >The trick is that it works for one specific AS and not the Internet in >general. If I insert provider Xs AS in the AS path they will reject the >announcement. No one else will reject it. > >I don't know of another knob that can do this... Not send them an announcement at all? Really, I don't get this. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 15:48: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 PAA21860 for ; Mon, 24 Jan 2005 15:48:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBOh-00040A-3m for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 16:05:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtB2K-0008WO-83; Mon, 24 Jan 2005 15:42:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtAxq-0006U5-QY for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 15:37: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 PAA21155 for ; Mon, 24 Jan 2005 15:37:32 -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 1CtBEP-0003Rp-A5 for rpsec@ietf.org; Mon, 24 Jan 2005 15:54:42 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 4DF592D48A6; Mon, 24 Jan 2005 15:36:58 -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 36460-01-80; Mon, 24 Jan 2005 15:36:57 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 231732D4881; Mon, 24 Jan 2005 15:36:57 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0OKavI07187; Mon, 24 Jan 2005 15:36:57 -0500 (EST) Date: Mon, 24 Jan 2005 15:36:57 -0500 From: Jeffrey Haas To: Blaine Christian Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124203656.GL5850@nexthop.com> References: <200501241939.j0OJdEV5024039@tislabs.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: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da To make this a little more clear for Sandy: On Mon, Jan 24, 2005 at 02:49:40PM -0500, Blaine Christian wrote: > On 1/24/05 2:39 PM, "Sandy Murphy" wrote: > >> However, we're aware of people who do this to deny routes to other ASes. > >> This means they put someone else's AS in there. > > > > I have heard of this, and Blaine just mentioned this. But I don't > > understand -- why choose this technique to deny routes to other AS's. > > It seems to me that a withdrawal or not issuing an update at all > > accomplishes the same purpose. > > > > So why is this chosen as the mechanism for denying routes to other AS's? > > The trick is that it works for one specific AS and not the Internet in > general. If I insert provider Xs AS in the AS path they will reject the > announcement. No one else will reject it. > > I don't know of another knob that can do this... More importantly, you can't deny someone a route transitively without doing something like this. To whit: A ---- B ---- C ---- D ---- E AS A originates a route. B doesn't wish AS E to use this route. There is no way to "de-authorize" E. However, if I advertise my route to C thus, e.g.: 10/8 Despite the fact that the route should have as an AS_PATH, this doesn't "break" BGP (although it isn't strictly compliant behavior) and E will in fact discard the route when it advertised by D->E because of the loop condition. The reasons for doing this are many and varied. They complicate our life if we're trying to use the AS_PATH adjacencies for security purposes. Also, we could advertise it as: 10/8 [E] (where [] represents a set and <> represents a sequence) When sets are involved, how do we determine adjancencies? Compliant implementations may generate an arbitrary mix of sets and sequences upon normal aggregation. When not aggregating along the path, a set should never be present, so this _should_ limit us to sequences for most checks. The questions are thus: 1. Do we wish to accomodate this technique in our security infrastructure? 2. If so, how? This is probably solution-specific. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 16:18: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 QAA29323 for ; Mon, 24 Jan 2005 16:18:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBs0-0006X1-Gc for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 16:35:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtB2x-0000Nm-7P; Mon, 24 Jan 2005 15:42:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtB0B-0007d9-Nd for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 15:39: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 PAA21399 for ; Mon, 24 Jan 2005 15:39:56 -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 1CtBGj-0003Z1-Sq for rpsec@ietf.org; Mon, 24 Jan 2005 15:57:07 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 3D97F2D4C01; Mon, 24 Jan 2005 15:39:27 -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 37122-02-61; Mon, 24 Jan 2005 15:39:24 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A680B2D4B02; Mon, 24 Jan 2005 15:39:24 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0OKdOE07197; Mon, 24 Jan 2005 15:39:24 -0500 (EST) Date: Mon, 24 Jan 2005 15:39:24 -0500 From: Jeffrey Haas To: bmanning@vacation.karoshi.com Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124203924.GM5850@nexthop.com> References: <200501241924.j0OJOtv6023512@tislabs.com> <20050124195302.GB21736@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050124195302.GB21736@vacation.karoshi.com.> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com 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 Bill, On Mon, Jan 24, 2005 at 07:53:02PM +0000, bmanning@vacation.karoshi.com wrote: > so if AS 4555 prepended AS 7085 and AS 2886, there would > be a problem for you? (all these ASN are held by me) This would depend on the actual security mechanism being used. To suggest a mechanism that relies on signing set adjacencies, there is nothing fundamentally wrong with: <4555 7085 2666 X> being advertised by 4555 when it was learned from X, so long as the chain is signed <4555 <7085 <2666 X>>> Note that this is just meant to illustrate the problem is not insurmountable, not to make a specific recommendation of how we deal with this issue. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 16:29:20 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 QAA01370 for ; Mon, 24 Jan 2005 16:29:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtC2Y-0007Kk-Il for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 16:46:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBev-0007Dy-RT; Mon, 24 Jan 2005 16:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtB3U-0000l0-EY for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 15:43: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 PAA21608 for ; Mon, 24 Jan 2005 15:43:22 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBK4-0003j3-3e for rpsec@ietf.org; Mon, 24 Jan 2005 16:00:32 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OKdt70011575 for ; Mon, 24 Jan 2005 15:39:55 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAMQaqMw; Mon, 24 Jan 05 15:39:53 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OKffTY027209; Mon, 24 Jan 2005 15:41:41 -0500 (EST) Date: Mon, 24 Jan 2005 15:41:41 -0500 (EST) From: Sandy Murphy Message-Id: <200501242041.j0OKffTY027209@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Stefan Mink says: >I agree with you that this is the current state, but is it granted to >always be like this? What if for whatever reason an RIR changes >its policy... ? This would have to be somehow taken into account >when verifying the origin authorization of a route. One can only devise the security protections with respect to the current requirements for authorization. If the authorization definitions change, then the security protections have to change as well. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 16:30: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 QAA01479 for ; Mon, 24 Jan 2005 16:30:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtC3E-0007LO-Nd for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 16:47:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBew-0007E5-61; Mon, 24 Jan 2005 16:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtB48-00012n-Vd for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 15:44: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 PAA21624 for ; Mon, 24 Jan 2005 15:43:59 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBKe-0003ro-Ja for rpsec@ietf.org; Mon, 24 Jan 2005 16:01:09 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OKeWVL011670 for ; Mon, 24 Jan 2005 15:40:32 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAcQaaYw; Mon, 24 Jan 05 15:40:30 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OKgIL6027245; Mon, 24 Jan 2005 15:42:18 -0500 (EST) Date: Mon, 24 Jan 2005 15:42:18 -0500 (EST) From: Sandy Murphy Message-Id: <200501242042.j0OKgIL6027245@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 >I agree that MUSTs must be followed, but not that missing "MUST NOTs" >mean its allowed. I'm sure no document is complete in this sense. I agree wholeheartedly! --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 16:32: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 QAA01742 for ; Mon, 24 Jan 2005 16:32:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtC5V-0007VF-VM for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 16:49:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBfV-0007aq-20; Mon, 24 Jan 2005 16:22:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBAI-00048O-Lr for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 15:50: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 PAA22033 for ; Mon, 24 Jan 2005 15:50:24 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBQr-000463-3T for rpsec@ietf.org; Mon, 24 Jan 2005 16:07:34 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OKkuxc012396 for ; Mon, 24 Jan 2005 15:46:56 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAbCaqny; Mon, 24 Jan 05 15:46:54 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OKmg11027453; Mon, 24 Jan 2005 15:48:42 -0500 (EST) Date: Mon, 24 Jan 2005 15:48:42 -0500 (EST) From: Sandy Murphy Message-Id: <200501242048.j0OKmg11027453@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Jeff: >Thus, a compliant implementation will only _prepend_ AS numbers. That would be my interpretation, also. (with the exceptions noted by you later) >: If the UPDATE message is received from an external peer, the local >: system MAY check whether the leftmost (with respect to the position >: of octets in the protocol message) AS in the AS_PATH attribute is >: equal to the autonomous system number of the peer that sent the mes- >: sage. If the check determines that this is not the case, the Error >: Subcode MUST be set to Malformed AS_PATH. Thanks for pointing this out. So even if the spec does not say MUST prepend, it makes non-prepending a session ending error if caught? That would mean that an attempt to exploit non-prepending would have to depend on the recipient not checking. (Not that the bad guys are reluctant to take advantage of checks not being performed. ;-}) > Removing private AS numbers may introduce loops if done improperly. > However, the scope of these loops are usually localized to the > private ASes which are usually stub ASes. You say nothing about loops introduced by deleting AS's other than private AS's and other than at the end of the path. I said that I thought such deletion could lead to loops. Do you think so? >Ergo, the only requirement for loop free operation of the protocol >is that the AS be present in the path. In general, you should receive >your routes with your peer's AS at the start of the AS_PATH. The >protocol will work properly if the path is re-ordered. I think you imply here that you see a chance for loops if AS's are deleted from the path. I think I said that I didn't see an attack from reordering the prefixes, that at least it wouldn't pose a problem for the loop detection. But that I could see the potential for problems if policies in the future started relying on the adjacencies in the AS_PATH, which you may have meant when you said >Operationally, people rely on the adjancencies for policy. This is >outside the protocol specification. So, were you saying here that reordering might make it impossible for people to "rely on the adjancencies for policy"? >Four: The security infrastructure should just deal with these things >as they're not insurmountable. Only the arbitrary addition of ASes >is problematic. Compliant implementations will follow the prepend rule. >Truncating the path must be dealt with for aggregation. I agree completely! Especially the "problematic" nature of *ARBITRARY* addition of AS's. (note well: I've no objection to prepending your own AS). And aggregation points are another tough problem for the security definition. As you have said, this is not really difficult if the aggregation point is doing what you call "implicit aggregation" and owns the aggregated prefix. And, as you say, not so easy to do for proxy aggregation. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 16:33:48 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 QAA01973 for ; Mon, 24 Jan 2005 16:33:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtC6p-0007XN-2R for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 16:50:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBfh-0007yD-Do; Mon, 24 Jan 2005 16:22:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBGG-0006gd-LU for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 15:56:36 -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 PAA22695 for ; Mon, 24 Jan 2005 15:56:34 -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 1CtBWp-0004PE-4G for rpsec@ietf.org; Mon, 24 Jan 2005 16:13:44 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 194C32D4EE2; Mon, 24 Jan 2005 15:50:24 -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 38865-01-14; Mon, 24 Jan 2005 15:50:22 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B54872D4EC9; Mon, 24 Jan 2005 15:50:22 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0OKoM507240; Mon, 24 Jan 2005 15:50:22 -0500 (EST) Date: Mon, 24 Jan 2005 15:50:22 -0500 From: Jeffrey Haas To: Sandy Murphy Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124205022.GO5850@nexthop.com> References: <200501241931.j0OJVjSu023762@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501241931.j0OJVjSu023762@tislabs.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Mon, Jan 24, 2005 at 02:31:45PM -0500, Sandy Murphy wrote: > As for private AS's, I thought the whole idea of the "private" part > was that you didn't include them in updates to external peers? Isn't > that commonly reported as bad practice? Private ASes can be used for whatever purpose you want. However, they're not supposed to be visible in the public Internet. In order for private ASes to be visible, you have to put them in your eBGP sessions. If the network looks like: 2 --- 1 --- 65000 --- 65001 10/8 And destination D shows up at AS 2 as: 10/8 <1> Then we've met common practice. AS 1 will likely have: 10/8 <1 65000 65001> -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 16:38:20 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 QAA02854 for ; Mon, 24 Jan 2005 16:38:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCBF-0007rF-VO for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 16:55:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBgc-0000u8-KA; Mon, 24 Jan 2005 16:23:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBOA-0002ba-LW for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 16:04:46 -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 QAA25692 for ; Mon, 24 Jan 2005 16:04:43 -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 1CtBeh-00052y-8N for rpsec@ietf.org; Mon, 24 Jan 2005 16:21:53 -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 j0OL4A9T023453 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 24 Jan 2005 16:04:11 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 24 Jan 2005 16:04:03 -0500 Subject: Re: [RPSEC] Back to the Basics: The AS Path From: Blaine Christian To: Sandy Murphy , Message-ID: In-Reply-To: <200501242035.j0OKZJxU026800@tislabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit On 1/24/05 3:35 PM, "Sandy Murphy" wrote: >> The trick is that it works for one specific AS and not the Internet in >> general. If I insert provider Xs AS in the AS path they will reject the >> announcement. No one else will reject it. >> >> I don't know of another knob that can do this... > > Not send them an announcement at all? Really, I don't get this. > Ahhh, you see the problem is that you are not directly connected to that AS yet you do not want them to see your prefixes. You can not specifically block announcements through every OTHER network to that network. The only way to do it is to force the loop check. *_a___b___c___d | | |___e___f If you do not want "d" in the above graph to install a prefix the use of loop free routing as a kludge becomes necessary. Otherwise you would have to block b's outbound to c and to e. BTW, I am getting initial responses from the operator community where folks are saying that they prepend inbound advertisements with that, specific, peers AS. This case still seems to fit in with the compression of like AS numbers into "one" instance of an AS for the purposes of identity. Regards, Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 16:38:44 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 QAA02927 for ; Mon, 24 Jan 2005 16:38:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCBe-0007sB-1E for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 16:55:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBgj-00015t-FK; Mon, 24 Jan 2005 16:23:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBPO-0003gP-46 for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 16:06: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 QAA25977 for ; Mon, 24 Jan 2005 16:05:59 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtBfq-0005DL-Fr for rpsec@ietf.org; Mon, 24 Jan 2005 16:23:10 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OL2PFl014110 for ; Mon, 24 Jan 2005 16:02:25 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAADra4IB; Mon, 24 Jan 05 16:02:23 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OL46hV028013; Mon, 24 Jan 2005 16:04:06 -0500 (EST) Date: Mon, 24 Jan 2005 16:04:06 -0500 (EST) From: Sandy Murphy Message-Id: <200501242104.j0OL46hV028013@tislabs.com> To: blaine@blaines.net, riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: e1e48a527f609d1be2bc8d8a70eb76cb >> Russ, you seem to be saying that if a tier-1 AS allocates a subblock of its >> allocated address space, that it is technically NOT ALLOWED to continue >> to advertise that address space. Is that a correct statement of what >> you are saying? >... >It is >normally a bad idea for the owner of a less specific chunk of prefixes who >has allocated a more specific prefix to a customer to advertise that more >specific prefix on their own (unless they are propagating a BGP advert). I'm not exactly reading email in order here, so I just came to this response to my message last Friday. It seems to answer the question I posed this morning, at least as far as saying whether it is allowed. The answer being "It is normally a bad idea." So does that mean that the security protections should try to prohibit this? And is the "bad idea" specific to announcing the same more specific prefix? Have you seen operationally that people objected to less specifics being announced that contained their more specific prefix? Since the less specific prefix is not going to replace their own more specific in places that receive both, it would be less dangerous to the customer, right? >However, even with static allocations I would be hard pressed to find common >examples of an ISP bothering (or desiring etc.) to advertise a specifically >allocated sub-block. But we have to consider the malicious case where someone may do any manner of illogical things. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 16:39: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 QAA03009 for ; Mon, 24 Jan 2005 16:39:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCCH-0007u0-0d for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 16:56:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBhU-0002Pd-1t; Mon, 24 Jan 2005 16:24:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtBWj-0001Py-Fr for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 16:13:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28216 for ; Mon, 24 Jan 2005 16:13:35 -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 1CtBnH-000659-Fu for rpsec@ietf.org; Mon, 24 Jan 2005 16:30:45 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j0OLDPKN022192; Mon, 24 Jan 2005 21:13:25 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j0OLDPN4022189; Mon, 24 Jan 2005 21:13:25 GMT Date: Mon, 24 Jan 2005 21:13:25 +0000 From: bmanning@vacation.karoshi.com To: Sandy Murphy Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124211325.GB22137@vacation.karoshi.com.> References: <200501241942.j0OJga94024310@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501241942.j0OJga94024310@tislabs.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rpsec@ietf.org, sthaug@nethelp.no X-BeenThere: rpsec@ietf.org 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 Mon, Jan 24, 2005 at 02:42:36PM -0500, Sandy Murphy wrote: > >> Yes, understood. But prepending arbitrary AS's is a challenging security > >> principle to support. > > > > where will you check to ensure an AS is properly assigned? > > whois? > > Assigned? What do you mean? much of the thread has talked about "my" vs "arbitrary" ASNs. how are these attributes to be determined by anyone other than the prefix originator? > We're currently just trying to decide what a valid path is. We haven't > talked yet about how one would perform the verification, if that's > what you mean. and my question lies at the heart of "valid" path. by what means is a "valid" path determined? e.g. i originate prefix 192.168.53.0/24 from AS 4555... by what means does someone/someprogram deterministically decide that AS 4555 is "mine" and is allowed to properly originate a path to said prefix? if the answer is via the WHOIS protocol, then there are larger fish to fry than RPSEC... :) > > --Sandy > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 17:01:41 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 RAA07331 for ; Mon, 24 Jan 2005 17:01:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCXq-00016i-Qt for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 17:18:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCCx-0006hf-QG; Mon, 24 Jan 2005 16:57:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtC0V-0006ho-7I for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 16:44: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 QAA03726 for ; Mon, 24 Jan 2005 16:44:20 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCH4-0008DT-BI for rpsec@ietf.org; Mon, 24 Jan 2005 17:01:31 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OLerec017722 for ; Mon, 24 Jan 2005 16:40:53 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAx0aaNI; Mon, 24 Jan 05 16:40:51 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OLgWRw029015; Mon, 24 Jan 2005 16:42:32 -0500 (EST) Date: Mon, 24 Jan 2005 16:42:32 -0500 (EST) From: Sandy Murphy Message-Id: <200501242142.j0OLgWRw029015@tislabs.com> To: blaine@blaines.net, jhaas@nexthop.com Subject: Re: [RPSEC] Back to the Basics: The AS Path 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 >A ---- B ---- C ---- D ---- E > >AS A originates a route. B doesn't wish AS E to use this route. Ah, it is not to keep your peer from using the route, it is to keep someone several hops away from using the route. (There must be a reason why one would want to do this, but it's just another example of weird policies that people want to enforce.) >When sets are involved, how do we determine adjancencies? This is a difficult question for all solutions I know of. One can be really loose - as long as there is one subset of the set that can be assembled with the preceding and following sequences of AS's to form a valid path, the path is OK. One can be really strict - all paths composed of AS's in the set with the preceding and following sequences of AS's must be OK for the path to be OK. Neither is satisfactory, from a protection point of view. The fact that the AS's in multiple sequences are bundled in the AS_SET and lose the identify of the sequences they came from makes it really hard to judge. But I've been told be people who should know that AS_SET's are actually rarely used. That most places just re-originate. Still true? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 17:12: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 RAA08194 for ; Mon, 24 Jan 2005 17:12:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCiU-0001Vm-NQ for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 17:29:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCFK-0008St-WD; Mon, 24 Jan 2005 16:59:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCBS-0005mH-7Y for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 16:55:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05670 for ; Mon, 24 Jan 2005 16:55:39 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCRw-0000bj-Ok for rpsec@ietf.org; Mon, 24 Jan 2005 17:12:50 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OLq6KP018899 for ; Mon, 24 Jan 2005 16:52:06 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAskaq6K; Mon, 24 Jan 05 16:52:04 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OLrqba029382; Mon, 24 Jan 2005 16:53:52 -0500 (EST) Date: Mon, 24 Jan 2005 16:53:52 -0500 (EST) From: Sandy Murphy Message-Id: <200501242153.j0OLrqba029382@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c >Private ASes can be used for whatever purpose you want. However, they're >not supposed to be visible in the public Internet. > >In order for private ASes to be visible, you have to put them in your eBGP >sessions. Can I put these two statements together to conclude that private AS's aren't supposed to be in your eBGP sessions? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 17:18: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 RAA08802 for ; Mon, 24 Jan 2005 17:18:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCnr-0001lb-0o for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 17:35:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCUe-00016p-RX; Mon, 24 Jan 2005 17:15:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCLz-0004FF-Rl for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 17:06:36 -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 RAA07858 for ; Mon, 24 Jan 2005 17:06: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 1CtCca-0001Ha-1T for rpsec@ietf.org; Mon, 24 Jan 2005 17:23:44 -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 j0OM5t9T024318 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Mon, 24 Jan 2005 17:05:58 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 24 Jan 2005 17:05:48 -0500 Subject: Re: [RPSEC] Back to the Basics: The AS Path From: Blaine Christian To: Sandy Murphy , Message-ID: In-Reply-To: <200501242142.j0OLgWRw029015@tislabs.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit On 1/24/05 4:42 PM, "Sandy Murphy" wrote: >> A ---- B ---- C ---- D ---- E >> >> AS A originates a route. B doesn't wish AS E to use this route. > > Ah, it is not to keep your peer from using the route, it is to > keep someone several hops away from using the route. > > (There must be a reason why one would want to do this, but it's > just another example of weird policies that people want to > enforce.) Funny enough, considering the group of people who are discussing this. The cited need was that when someone is hacking at you from a specific AS you can deny your route to that AS. BTW, I have only had one person say this was something that they MIGHT want to use. I have received no reports of actual usage as of yet. I had one person say they have seen it before but very rarely. > >> When sets are involved, how do we determine adjancencies? > > This is a difficult question for all solutions I know of. > > One can be really loose - as long as there is one subset of the > set that can be assembled with the preceding and following sequences > of AS's to form a valid path, the path is OK. > > One can be really strict - all paths composed of AS's in the set > with the preceding and following sequences of AS's must be OK > for the path to be OK. > > Neither is satisfactory, from a protection point of view. The > fact that the AS's in multiple sequences are bundled in the AS_SET > and lose the identify of the sequences they came from makes it really > hard to judge. > > But I've been told be people who should know that AS_SET's are > actually rarely used. That most places just re-originate. > Still true? Last time I looked AS_SETs were rarely used. A few years ago I was bit by a combination of a certain vendor whose shall remain nameless and another vendor who shall remain nameless. Vendor A propagated an AS Set that exceeded the alloted variable size on Vendor B. Funny enough that caused just about every router on the network to panic. Believe it or not it was a day one bug. BTW, I am one of the many who, for a few years,was routinely slammed by large scale BGP badness. Most of the badness was due to code issues. This is why the attempt to modify the way BGP works is going to have to be dealt with VERY carefully. I believe AS_SET is still sparsely used. > > --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 17:26:27 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 RAA09447 for ; Mon, 24 Jan 2005 17:26:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCvr-00027f-3y for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 17:43:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCca-0003yh-0s; Mon, 24 Jan 2005 17:23:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCVO-0001dO-Vp for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 17:16: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 RAA08615 for ; Mon, 24 Jan 2005 17:16:15 -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 1CtCly-0001e5-5x for rpsec@ietf.org; Mon, 24 Jan 2005 17:33:27 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A40CA2D4BCC; Mon, 24 Jan 2005 17:15:42 -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 45559-02-68; Mon, 24 Jan 2005 17:15:40 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A1CC32D4BA6; Mon, 24 Jan 2005 17:15:40 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0OMFe207992; Mon, 24 Jan 2005 17:15:40 -0500 (EST) Date: Mon, 24 Jan 2005 17:15:40 -0500 From: Jeffrey Haas To: Sandy Murphy Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124221540.GU5850@nexthop.com> References: <200501242153.j0OLrqba029382@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501242153.j0OLrqba029382@tislabs.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com 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 On Mon, Jan 24, 2005 at 04:53:52PM -0500, Sandy Murphy wrote: > >Private ASes can be used for whatever purpose you want. However, they're > >not supposed to be visible in the public Internet. > > > >In order for private ASes to be visible, you have to put them in your eBGP > >sessions. > > Can I put these two statements together to conclude that private AS's > aren't supposed to be in your eBGP sessions? No. Amongst other reasons, BGP-4 can be used outside the context of "the Internet". So can IPv4, hence RFC 1918 address space. > --Sandy -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 17:28: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 RAA09606 for ; Mon, 24 Jan 2005 17:28:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCy4-0002Dw-Ep for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 17:45:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCdH-0004Co-4j; Mon, 24 Jan 2005 17:24:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCVn-0001lc-Pq for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 17:16:43 -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 RAA08675 for ; Mon, 24 Jan 2005 17:16:40 -0500 (EST) Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtCmN-0001jB-Vy for rpsec@ietf.org; Mon, 24 Jan 2005 17:33:52 -0500 Received: from [69.170.17.195] (HELO JLaptop.joelhalpern.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8834821 for rpsec@ietf.org; Mon, 24 Jan 2005 17:16:39 -0500 Message-Id: <6.1.2.0.0.20050124171556.02b7c318@localhost> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 24 Jan 2005 17:16:07 -0500 To: rpsec@ietf.org From: "Joel M. Halpern" Subject: Re: [RPSEC] Back to Basics--The AS Path Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: rpsec@ietf.org 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: e1e48a527f609d1be2bc8d8a70eb76cb I have been watching this debate, and trying to understand what is driving such strong disagreement. I thinking about it, I am reminded of a comment made by a colleague of my in a protocol discussion. "Of course that's lying. That's what routers do. We lie, cheat, and steal." His point was that in achieving the objectives of making things work, we (the router and operational communities) have always bent the spec, lied when necessary, and made it work. The basic rule is that if it is not completely prohibited by the spec, someone probably does it. And even if it is prohibited, it probably still happens. (Deployed routers have been known to be configured for example, to forward packets in ways that do not agree with their BGP advertisements, even though that flat violates the spec.) Unless we recognize and address this basic mismatch, it becomes impossible to agree on what it means to secure the routing system. This applies independent of which protocol we are talking about. (I have seen some interesting topological lies in OSPF. I have committed some of them myself.) Hence, arguing about what the spec does or does not say is never going to resolve this debate. The new BGP spec is as accurate as folks could make it. It still does not, and can not, capture all of the realities. Particularly since some of those realities violate the spec. I do not know that Russ' text is any better at allowing us to have a set of requirements we can understand and apply to the real world. I do understand that paying attention to the stated semantics of the spec is also very helpful in getting a useful security result. (After all, it is pretty hard to "secure" an undefined semantic.) This may not help the primary discussants come to agreement. But maybe this perspective will help someone else on this list come up with a useful way forward. Yours, Joel M. Halpern _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 17:35: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 RAA10152 for ; Mon, 24 Jan 2005 17:35:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtD4C-0002Te-7g for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 17:52:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCmM-0007Js-OP; Mon, 24 Jan 2005 17:33:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCel-0004nm-9P for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 17:25:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09363 for ; Mon, 24 Jan 2005 17:25:56 -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 1CtCvL-00025l-M5 for rpsec@ietf.org; Mon, 24 Jan 2005 17:43:08 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j0OMPtKN022502; Mon, 24 Jan 2005 22:25:55 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j0OMPte7022499; Mon, 24 Jan 2005 22:25:55 GMT Date: Mon, 24 Jan 2005 22:25:55 +0000 From: bmanning@vacation.karoshi.com To: Sandy Murphy Subject: Re: [RPSEC] Back to the Basics: The AS Path Message-ID: <20050124222555.GA22290@vacation.karoshi.com.> References: <200501242153.j0OLrqba029382@tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501242153.j0OLrqba029382@tislabs.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) 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.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Mon, Jan 24, 2005 at 04:53:52PM -0500, Sandy Murphy wrote: > >Private ASes can be used for whatever purpose you want. However, they're > >not supposed to be visible in the public Internet. > > > >In order for private ASes to be visible, you have to put them in your eBGP > >sessions. > > Can I put these two statements together to conclude that private AS's > aren't supposed to be in your eBGP sessions? perhaps... private ASNs are to be used btwn "consenting" networks so if nets A,B,D,F agree, then you may see an AS path btwn them that has private ASNs in play... > > --Sandy > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 17:41:17 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 RAA10825 for ; Mon, 24 Jan 2005 17:41:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtDAB-0002kX-Kh for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 17:58:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCnB-0007iL-G2; Mon, 24 Jan 2005 17:34:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtCkY-0006UC-4p for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 17:31: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 RAA09790 for ; Mon, 24 Jan 2005 17:31:55 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtD17-0002KV-Nz for rpsec@ietf.org; Mon, 24 Jan 2005 17:49:07 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0OMSSSA022484 for ; Mon, 24 Jan 2005 17:28:28 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5Mai6R; Mon, 24 Jan 05 17:28:25 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0OMU74q000996; Mon, 24 Jan 2005 17:30:07 -0500 (EST) Date: Mon, 24 Jan 2005 17:30:07 -0500 (EST) From: Sandy Murphy Message-Id: <200501242230.j0OMU74q000996@tislabs.com> To: blaine@blaines.net, jhaas@nexthop.com, sandy@tislabs.com Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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: 1ac7cc0a4cd376402b85bc1961a86ac2 >Funny enough, considering the group of people who are discussing this. The >cited need was that when someone is hacking at you from a specific AS you >can deny your route to that AS. I thought I had heard stories of assembling a path of providers who cooperated to discover the source and shut it down. For single sources only, of course. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 18:26: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 SAA16964 for ; Mon, 24 Jan 2005 18:26:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtDrY-0004xD-I3 for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 18:43:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDW4-0004Mn-3z; Mon, 24 Jan 2005 18:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDGQ-0002cW-5E for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 18:04: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 SAA13582 for ; Mon, 24 Jan 2005 18:04:51 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtDWz-0003wZ-R5 for rpsec@ietf.org; Mon, 24 Jan 2005 18:22:03 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0ON1NDc025503 for ; Mon, 24 Jan 2005 18:01:23 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAA29aWZX; Mon, 24 Jan 05 18:01:21 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0ON39w2001912; Mon, 24 Jan 2005 18:03:09 -0500 (EST) Date: Mon, 24 Jan 2005 18:03:09 -0500 (EST) From: Sandy Murphy Message-Id: <200501242303.j0ON39w2001912@tislabs.com> To: jmh@joelhalpern.com, rpsec@ietf.org Subject: Re: [RPSEC] Back to Basics--The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d >Hence, arguing about what the spec does or does not say is never going to >resolve this debate. The new BGP spec is as accurate as folks could make >it. It still does not, and can not, capture all of the >realities. The really tough questions become: what operational uses are so common, so useful, (AND so lacking in ways to exploit harmfully) that we want to maintain them. And how can we do that. >I do >understand that paying attention to the stated semantics of the spec is >also very helpful in getting a useful security result. Yes. But that won't cover the accepted (mis)uses, lies, etc. Particularly when those uses violate the semantics. >(After all, it is >pretty hard to "secure" an undefined semantic.) Yes, we agree. So getting the "undefined semantics" down will be important. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 18:49:58 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 SAA19408 for ; Mon, 24 Jan 2005 18:49:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtEEf-0005z9-UY for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 19:07:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDtn-0005Lx-Rr; Mon, 24 Jan 2005 18:45:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDo1-0003jO-DE for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 18:39:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18345 for ; Mon, 24 Jan 2005 18:39:34 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtE4b-0005WR-Lu for rpsec@ietf.org; Mon, 24 Jan 2005 18:56:46 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0ONa8kJ028600 for ; Mon, 24 Jan 2005 18:36:08 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAW4a423; Mon, 24 Jan 05 18:36:05 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0ONbsr6002936; Mon, 24 Jan 2005 18:37:54 -0500 (EST) Date: Mon, 24 Jan 2005 18:37:54 -0500 (EST) From: Sandy Murphy Message-Id: <200501242337.j0ONbsr6002936@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >Let me ask this: If you were teaching a class on IPsec to a bunch of >routing geeks, would you use "colliqual" terms, like "IPsec tunnel" to >explain how it works, or would you delve into the real terms, and >operation, immediately? Does the IPsec draft use the term "tunnel?" A bad example from your point of view. You betcha the IPsec draft uses the term tunnel. "tunnel", "tunnel mode", "AH tunnel", "ESP tunnel" - all through RFC 240[1,2,6,7,9]. >Before I answer your question directly, and while you're thinking about the >question above :-) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 18:51: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 SAA19518 for ; Mon, 24 Jan 2005 18:51:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtEFq-00061K-Pt for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 19:08:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDul-0005fR-1p; Mon, 24 Jan 2005 18:46:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtDrf-0004nA-2S for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 18: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 SAA18779 for ; Mon, 24 Jan 2005 18:43:19 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtE8G-0005hP-91 for rpsec@ietf.org; Mon, 24 Jan 2005 19:00:32 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CtDrc-0006OY-CP; Mon, 24 Jan 2005 23:43:21 +0000 Date: Mon, 24 Jan 2005 15:43:16 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1755916642.20050124154316@psg.com> To: Russ White Subject: Re: [RPSEC] A Call for A Reasonable Compromise on Securing the AS Path In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Russ, folks- I'm in the process of catching up on the discussion on the mailing list. You can expect to hear from me or Bill today or tomorrow. -- Alex http://www.psg.com/~zinin Saturday, January 22, 2005, 9:06:40 AM, Russ White wrote: > Y'all: > I've seggested, in the text of several emails, that there are a number of > ways forward on the BGP security requirements draft. IMHO, we aren't going > to reach concensus on the issue of "what security means in the cotext of > the AS Path." Well, maybe the next couple days will tell us, but I'm > assuming no such concensus will be possible. > I believe the two rational ways forward, as a WG are: > -- Build the requirements "loose," so they will fit either definition of > "securing the AS Path." > -- Simply include two different options in this area, and any other area > where there's enough contention and no apparent concensus. > I'm thinking of the first case being something like: > -- > Any proposed security mechanism MUST be able to verify: > -- x > -- y > -- z > Any proposed security mechinism SHOULD be able to verify: > -- x > -- y > -- z > Proposed security mechanisms MAY assert more security than is outlined > here. Any such claims SHOULD be justified and defended in the context of > the security proposal draft(s). > -- > The other option seems to be something like this: > Any proposed security mechanism MUST support one of two mechanisms to > verify/validate the AS Path: > -- Method A > -- Method B > -- > Either of these is fine with me, but I believe we've been mired in the > argument over the AS Path, specifically, far too long than is healthy, and > we should try to find a way forward. As we encounter other areas where > there is a strong argument preventing concensus, we should possibly > consider this sort of option again, and simply try to reach a concensus > that we can't reach concensus, and should find more than one "subconcensus" > to place in the document. > I believe this sort of step is unusual, but I also believe there is too > much at stake, in terms of future work, to leave this argument open, and > simply not progress the draft. > If the AD's have any comment on this possibility as a procedure, or if Tony > would like to chime in, I would appreciate it. > :-) > 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 Jan 24 19:19: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 TAA22452 for ; Mon, 24 Jan 2005 19:19:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtEgv-0007Iy-6v for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 19:36:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtEB1-0001rW-4O; Mon, 24 Jan 2005 19:03:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtE5f-00008K-V3 for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 18:57:52 -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 SAA19919 for ; Mon, 24 Jan 2005 18:57:48 -0500 (EST) Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtEMH-0006Ee-AX for rpsec@ietf.org; Mon, 24 Jan 2005 19:15:01 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0ONsNYj001234 for ; Mon, 24 Jan 2005 18:54:23 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAoAaiAc; Mon, 24 Jan 05 18:54:21 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0ONu96V003605; Mon, 24 Jan 2005 18:56:09 -0500 (EST) Date: Mon, 24 Jan 2005 18:56:09 -0500 (EST) From: Sandy Murphy Message-Id: <200501242356.j0ONu96V003605@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 >I'll point something out here.... The variety of things people do with BGP >would astound you. The cases are almost unbelievable. Just cruise through >the knobs available in the major vendor's implementations, and try to >figure out what they're there for. Yet I've seen every one of those things >used, in real life. Conditional advertisement, conditional injection, AS >Path stripping, local AS spoofing, AS migration and merge, re-origination, >aggregation, .... What we need to do is figure out what operational twists are used, which are so common or so needed that people would not do without, which behaviors could be exploited to cause harm, then judge which to accept as part of what must be secured and which can be prohibited by a security protection. Against this we put the behaviors that we know we really want to counter. We can use the lists of what we want to preserve and what we want to squash to help build the security requirements. >Let me put it another way: Is there any sense in which the policy will not >be based on the desirability of forwarding traffic via the advertised >route? As you've pointed out, there's no end to the "variety of things people do with BGP". It's tough to try to decide what the motivation behind some of those policies might be. I really don't know the answer to your question. For some cases I've seen, the motivation seems to be a desire to cause another provider trouble, whether there's an effect on traffic at all. >A---B---C---D >| | >+-----------+ > >What you're asking is what if A advertises 10.1.1.0/24 to B, but B >advertises that route with a path of {D,A} to C, rather than just {A}, >correct? Well, no, actually. I was talking about B getting in an update containing an AS_PATH of length two, no matter what the contents, and choosing that route but sending a route with a path of {{D,A,B} to C. In other words, replace the AS_PATH of length 2 with some other path of length 2. With valid adjacencies. Just exploring how exactly you mean "valid adjacencies" as a verification metric for AS_PATHs. I would think this would not protect against loops. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 19:28:00 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 TAA23395 for ; Mon, 24 Jan 2005 19:27:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtEpT-0007iw-BZ for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 19:45:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtEXa-0001mN-MP; Mon, 24 Jan 2005 19:26:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtEGj-0003aH-Q7 for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 19:09: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 TAA21164 for ; Mon, 24 Jan 2005 19:09:14 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtEXL-0006h4-6Q for rpsec@ietf.org; Mon, 24 Jan 2005 19:26:27 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0P05lW4002130 for ; Mon, 24 Jan 2005 19:05:47 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAetaqie; Mon, 24 Jan 05 19:05:41 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0P07SpL003857; Mon, 24 Jan 2005 19:07:28 -0500 (EST) Date: Mon, 24 Jan 2005 19:07:28 -0500 (EST) From: Sandy Murphy Message-Id: <200501250007.j0P07SpL003857@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d >I'm surprised you don't find this rather loose definition of ownership >problematic at all. It's a lot like me selling a room in my house, and the >new owner and I both listing it on our tax returns, isn't it? Would it >bother you if a credit card company gave you a number from a block, then >used that block to charge something, with the result that your bill >increased? If it wouldn't bother you, can I have your credit card But like I've said security authorizations don't always (frequently don't) get consumed by being delegated. It's not like resources which can only be used by a single entity at a time. Some things can be shared usage and I think you've argued emphatically that you want to be able to advertise less specifics even when the more specific has been suballocated - an example of dual use. Granting someone read access to my files doesn't make it necessary for me to loose read access. Granting someone signature authority on my credit card doesn't mean I loose signature authority. Honestly, Russ - weren't you arguing that operationally the requirement was that the less specific was allowed to be advertised even if the more specific subblock was allocated to someone else? Why are you complaining that I agree with you? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 24 19:31: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 TAA23620 for ; Mon, 24 Jan 2005 19:31:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtEsd-0007sy-67 for rpsec-web-archive@ietf.org; Mon, 24 Jan 2005 19:48:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtEaA-0003eq-V9; Mon, 24 Jan 2005 19: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 1CtEXb-0001ns-Vm for rpsec@megatron.ietf.org; Mon, 24 Jan 2005 19:26: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 TAA23278 for ; Mon, 24 Jan 2005 19:26:40 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtEoC-0007gB-Ky for rpsec@ietf.org; Mon, 24 Jan 2005 19:43:53 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0P0NFVw003764 for ; Mon, 24 Jan 2005 19:23:15 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAgca4vh; Mon, 24 Jan 05 19:23:12 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0P0OwHw004366; Mon, 24 Jan 2005 19:24:58 -0500 (EST) Date: Mon, 24 Jan 2005 19:24:58 -0500 (EST) From: Sandy Murphy Message-Id: <200501250024.j0P0OwHw004366@tislabs.com> To: riw@cisco.com, sandy@tislabs.com Subject: Re: [RPSEC] proposed message to the IESG 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 >Asking why is always met with: "It's >what the spec says," and no other anwers or questions, based on operational >and implementation experience, are allowed. I don't agree that we should ignore operational experience. But it is real tough to generate security protections unless you have a good description of what's being protected. As Joel said, it's tough to secure unwritten semantics. Even those operational uses that don't match what the spec says have to be considered if the security protections are going to be acceptable, deployable and all that. Which is not to say that if we can point to any particular current use of a behavior, then that behavior automatically must be included in the requirements and the security protections have to allow it. I asked a lot of messages ago if anyone wanted to write up the current operational practice. We have to have that, at least the ones that people want to preserve. --Sandy P.S. A short off the top of my head list: prepending your own AS confederations truncating private AS's from an AS_PATH using private AS's between consenting adult ISP's Injection of foreign AS into AS_PATH - I don't think this has reached consensus yet as useful enough to keep, but it's been brought up. Noone mentioned communities? I've seen a Black Hat presentation suggesting how these could be used to steal traffic, but not recent. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jan 25 11:24: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 LAA17688 for ; Tue, 25 Jan 2005 11:24:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtTlT-0007B5-Bl for rpsec-web-archive@ietf.org; Tue, 25 Jan 2005 11:42:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtTT6-0000Pf-P1; Tue, 25 Jan 2005 11:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtTMB-00079Q-8A for rpsec@megatron.ietf.org; Tue, 25 Jan 2005 11:15: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 LAA16625 for ; Tue, 25 Jan 2005 11:15:52 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtTcu-0006oE-2b for rpsec@ietf.org; Tue, 25 Jan 2005 11:33:13 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0PGCNhe018116 for ; Tue, 25 Jan 2005 11:12:24 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAACTaGuJ; Tue, 25 Jan 05 11:12:14 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0PGDwr4005857; Tue, 25 Jan 2005 11:13:58 -0500 (EST) Date: Tue, 25 Jan 2005 11:13:58 -0500 (EST) From: Sandy Murphy Message-Id: <200501251613.j0PGDwr4005857@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Back to the Basics: The AS Path X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 > e.g. i originate prefix 192.168.53.0/24 from AS 4555... > by what means does someone/someprogram deterministically > decide that AS 4555 is "mine" and is allowed to properly < originate a path to said prefix? > > if the answer is via the WHOIS protocol, then there are larger > fish to fry than RPSEC... :) I think you are saying that we'll need to build/adapt an infrastructure that will be able to represent allocations of prefixes to AS's, as well as authentication of the speaker. Yes, I think that everyone understands that this is a necessity and that it alone will be a tough thorny problem to solve, both from a practical standpoint (the existing databases are inaccurate, incomplete, etc.) and from an ideal standpoint (there are relationships that are not your typical relationship that will have to be representable). --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Jan 25 21:41: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 VAA10879 for ; Tue, 25 Jan 2005 21:41:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtdO7-0004t3-Ak for rpsec-web-archive@ietf.org; Tue, 25 Jan 2005 21:58:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctd5K-0004D6-UV; Tue, 25 Jan 2005 21:39:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctd0p-0003Gi-Ir for rpsec@megatron.ietf.org; Tue, 25 Jan 2005 21:34: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 VAA10570 for ; Tue, 25 Jan 2005 21:34:29 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtdHf-0004iz-58 for rpsec@ietf.org; Tue, 25 Jan 2005 21:51:55 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1Ctd0n-000MWA-Pr for rpsec@ietf.org; Wed, 26 Jan 2005 02:34:29 +0000 Date: Tue, 25 Jan 2005 18:34:26 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <706348933.20050125183426@psg.com> To: rpsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: [RPSEC] Situation with BGP security reqs draft X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Folks- Now that I've caught up on the discussion on the ML, I should say that with more people involved within the last 2-3 days, the discussion has gotten much healthier and more technical. Clear technical arguments, patience, and mutual desire to explain one's point of view is exactly what'd like to happen in this WG, considering the difference in background of people showing up here. Regarding the topic of securing the AS path. Given the improvement in the situation on the mailing list, it seems the WG would benefit from some more discussion on this topic, concentrating on the questions whether securing AS Path (note that I'm not defining "secure" here) is possible and useful. While there's no unanimous agreement on this topic, I've seen a few people say it would be interesting to be able to do so, even if there were exceptions to the general case. I believe more discussion is warranted. I would also like to comment on a few things I observed when following the discussion: 1. My recommendation would be to first converge on terminology. I sense a lot of frustration on both routing and security sides triggered by very loose use of both routing and security terms. I understand how this can be annoying to us, engineers, who prefer precise definitions. I'd start by agreeing on what you mean by BGP Route, BGP Update, address space authorization, prefix announcement authorization, etc. However, please don't simply say "this is not the term we use", try to explain and educate if necessary. Someone will also need to maintain the list of agreed on terms. 2. Regarding whether the discussion and the requirements document should be based on the BGP spec vs the operational aspects, and whether operational aspects belong here at all or should go to the OPS area. The fact is--we need both. It is impossible to secure a protocol without a specification that defines a reference model describing its behavior. On the other hand, blindly ignoring operational realities simply because they are not described in the spec is not the right thing to do. We need security requirements for a protocol defined by an IETF spec with the real-life operational considerations in mind. The fact that this WG is in the RTG area and not in O&M should not stop you from doing that. In situations where operational reality differs from the spec, try to use common sense. If some operational practice isn't explicitly spelled out, but falls within the BGP framework (e.g. route reorigination vs route aggregation within BGP), we simply have to deal with it and point out the security implications. If the reality contradicts the spec, then it is either that the implementation decided to be non-compliant and we shouldn't have to deal with it, or the spec needs to be fixed and we need to advise the IDR WG. 3. I noticed people argue that since one can't really guarantee that packet forwarding trajectory will follow the routing update trajectory, one shouldn't be interested in the routing update trajectory at all. My advice would be to limit these discussions to the properties of the protocol itself. E.g., I would consider interactions with static routes out of control of BGP, and hence out of scope for this discussion. I will follow up with Russ, Steve, and Tony more off the list. -- Alex http://www.psg.com/~zinin _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 01:02: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 BAA22907 for ; Wed, 26 Jan 2005 01:02:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtgXH-0001z5-9B for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 01:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtgBt-0007HC-Mq; Wed, 26 Jan 2005 00: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 1CtgB3-000740-7X for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 00: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 AAA22637 for ; Wed, 26 Jan 2005 00:57:14 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtgRu-0001qa-J2 for rpsec@ietf.org; Wed, 26 Jan 2005 01:14:42 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 26 Jan 2005 01:05:28 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0Q5uhoA025931; Wed, 26 Jan 2005 00:56:43 -0500 (EST) Received: from [10.42.2.136] (rtp-vpn3-300.cisco.com [10.82.217.46]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA02737; Wed, 26 Jan 2005 00:56:42 -0500 (EST) Date: Wed, 26 Jan 2005 00:56:51 -0500 (EST) From: Russ White X-X-Sender: ruwhite@russ-whites-computer.local To: Alex Zinin Subject: Re: [RPSEC] Situation with BGP security reqs draft In-Reply-To: <706348933.20050125183426@psg.com> Message-ID: References: <706348933.20050125183426@psg.com> 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 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: 02ec665d00de228c50c93ed6b5e4fc1a > 1. My recommendation would be to first converge on terminology. I sense a lot > of frustration on both routing and security sides triggered by very loose > use of both routing and security terms. I understand how this can be > annoying to us, engineers, who prefer precise definitions. I'd start by > agreeing on what you mean by BGP Route, BGP Update, address space authorization, > prefix announcement authorization, etc. However, please don't simply say > "this is not the term we use", try to explain and educate if necessary. > Someone will also need to maintain the list of agreed on terms. In order to start this portion of the discussion, I _think_ the two wordings currently proposed for the meaning of "secure the AS Path" are: -- 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. -- 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). -- 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. [-] OR [-] -- A BGP speaker MUST, on receiving a route from a peer, be able to verify the routing information has passed through every pair wise peering relationship listed in the AS Path attribute. -- 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. I'm assuming the wording about enforce first AS is included in both cases, as it is in the current draft. I've tried to use formal and equivalent language in both definitions. Would everyone agree these fairly represent the two views being discussed? If you don't agree, please suggest wording that corrects what you think is wrong about either definition. :-) 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 Jan 26 06:20: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 GAA12415 for ; Wed, 26 Jan 2005 06:20:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtlUZ-0001wW-8i for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 06:37:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtlAz-0006ZV-4Y; Wed, 26 Jan 2005 06:17:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtlAC-0006Ee-Mn for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 06:16: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 GAA12093 for ; Wed, 26 Jan 2005 06:16:39 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtlR3-0001pV-Mf for rpsec@ietf.org; Wed, 26 Jan 2005 06:34:11 -0500 Received: from pc6 (1Cust78.tnt4.lnd4.gbr.da.uu.net [62.188.133.78]) by galaxy.systems.pipex.net (Postfix) with SMTP id 3BE97E000191; Wed, 26 Jan 2005 11:16:05 +0000 (GMT) Message-ID: <000801c5038f$d3b9c120$0601a8c0@pc6> From: "Tom Petch" To: "Tony Tauber" , References: Subject: Re: [RPSEC] Transport level security was A Call for A Reasonable Compromise on Securing the AS Path Date: Wed, 26 Jan 2005 11:11:23 +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: 97adf591118a232206bdb5a27b217034 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit From: "Tony Tauber" To: Sent: Monday, January 24, 2005 4:55 AM Subject: Re: [RPSEC] A Call for A Reasonable Compromise on Securing the AS Path > So, to try and encourage more diversity of opinion here, > I'd like to ask everyone who's motivated to (really) succinctly > indicate what is wrong with the current draft. Please stick to > textual citations and/or specific suggested replacement. > (If you'd like, submit an entire replacement, of course.) > Abstract ... While securing the information transmitted between two BGP speakers is a relatively easy technical matter, ... I disagree. Currently BGP offers only MD5 which from my understanding of security is inadequate. And there is much work in TCPM which cites BGP as its driving force which has revealed to me many holes in TCP. Securing the transport may be easier than establishing trust for a lengthy AS_PATH but I see it as the fundamental first step and should come first in the requirements, not be relegated to the last chapter as if it were an afterthought. The requirements should specify the need for an MD5 replacement and should cite the TCPM work. (I suspect many experts in BGP and its operation will not know of the loopholes in TCP so any security solution should point those out and identify what if anything can be done). Tom Petch _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 07:49: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 HAA19528 for ; Wed, 26 Jan 2005 07:49:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtmsX-0004hu-TG for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 08:06:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtmUC-0004Qs-RO; Wed, 26 Jan 2005 07:41:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtmRa-0003dS-AV for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 07:38:46 -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 HAA18361 for ; Wed, 26 Jan 2005 07:38:45 -0500 (EST) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtmiU-00047U-SK for rpsec@ietf.org; Wed, 26 Jan 2005 07:56:15 -0500 Received: from pc6 (1Cust72.tnt9.lnd4.gbr.da.uu.net [62.188.138.72]) by galaxy.systems.pipex.net (Postfix) with SMTP id CA62CE0002A5; Wed, 26 Jan 2005 12:38:12 +0000 (GMT) Message-ID: <047e01c5039b$4bbfc380$0601a8c0@pc6> From: "Tom Petch" To: "Alex Zinin" , References: <706348933.20050125183426@psg.com> Subject: Re: [RPSEC] Route - was Situation with BGP security reqs draft Date: Wed, 26 Jan 2005 12:35: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: 1.2 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: 1.2 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Tom Petch ----- Original Message ----- From: "Alex Zinin" To: Sent: Wednesday, January 26, 2005 3:34 AM Subject: [RPSEC] Situation with BGP security reqs draft > Folks- > > Now that I've caught up on the discussion on the ML, I should say that with > more people involved within the last 2-3 days, the discussion has gotten much > healthier and more technical. Clear technical arguments, patience, and mutual > desire to explain one's point of view is exactly what'd like to happen in this > WG, considering the difference in background of people showing up here. > > Regarding the topic of securing the AS path. Given the improvement in the > situation on the mailing list, it seems the WG would benefit from some more > discussion on this topic, concentrating on the questions whether securing AS > Path (note that I'm not defining "secure" here) is possible and useful. While > there's no unanimous agreement on this topic, I've seen a few people say it > would be interesting to be able to do so, even if there were exceptions to the > general case. I believe more discussion is warranted. > > I would also like to comment on a few things I observed when following the > discussion: > > 1. My recommendation would be to first converge on terminology. I sense a lot > of frustration on both routing and security sides triggered by very loose > use of both routing and security terms. I understand how this can be > annoying to us, engineers, who prefer precise definitions. I'd start by > agreeing on what you mean by BGP Route, Route A unit of information that pairs a set of destinations with the attributes of a path to those destinations. The set of destina- tions are systems whose IP addresses are contained in one IP address prefix carried in the Network Layer Reachability Informa- tion (NLRI) field of an UPDATE message. The path is the informa- tion reported in the path attributes field of the same UPDATE mes- sage. This is taken from the latest revision of the BGP specification and so, while it may not be the natural definition for other aspects of routing and routing protocols, I think it is the only one to use in the context of BGP security. This definition has been the underlying source of many discussions on the IDR list ie people assume a route is something else. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 07:53:41 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 HAA19854 for ; Wed, 26 Jan 2005 07:53:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctmwx-0004pD-1a for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 08:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtmeC-0007l1-20; Wed, 26 Jan 2005 07:51:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtmYE-0005GL-Tm for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 07:45:38 -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 HAA19081 for ; Wed, 26 Jan 2005 07:45:37 -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 1Ctmp7-0004VW-LS for rpsec@ietf.org; Wed, 26 Jan 2005 08:03:08 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CtmY9-00043e-Sy; Wed, 26 Jan 2005 13:45:34 +0100 Message-ID: <41F790EB.1030700@schlund.net> Date: Wed, 26 Jan 2005 13:45:31 +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] Situation with BGP security reqs draft References: <706348933.20050125183426@psg.com> 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: 00e94c813bef7832af255170dca19e36 Cc: Alex Zinin , 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="===============1793204578==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1793204578== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6B029920EE3DA202122BE28D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6B029920EE3DA202122BE28D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Russ White wrote: >> 1. My recommendation would be to first converge on terminology. I sense a lot >> of frustration on both routing and security sides triggered by very loose >> use of both routing and security terms. I understand how this can be >> annoying to us, engineers, who prefer precise definitions. I'd start by >> agreeing on what you mean by BGP Route, BGP Update, address space authorization, >> prefix announcement authorization, etc. However, please don't simply say >> "this is not the term we use", try to explain and educate if necessary. >> Someone will also need to maintain the list of agreed on terms. > > > In order to start this portion of the discussion, I _think_ the two > wordings currently proposed for the meaning of "secure the AS Path" are: For me the distinction between the items were too fine for me to fully get them, so I try my own version: A "secure AS path" is a) "authentic": It MUST be verifyable who did which change to the attribute. This includes "complete": deletion of items can be detected and can be made visible. (may be this should be generalized to the entire route so no special treatment of the as-path attribute is necessary) b) "authorized": b1) It MUST be verifyable that the first AS in the path was authorized to enter it into the internet routing table ("origin authorization") b2) It MUST be verifyable that each AS on the path was authorized to use the route, i.e. the preceding AS intentively announced the route to exactly this AS. ("usage authorization") b3) It SHOULD be verifyable that each party on the path was authorized to readvertise the route to exactly the next AS. ("transit authorization") I'm not sure about the SHOULDs/MUSTs, this is just a first shot. The SHOULD in the last item is based upon my impression that there is no proper solution for that so far, e.g. there are no means currently to prevent a customer from readvertising your routes although is authorized to readvertise them to its customers. I hope this second view helps somewhat, if not: just forget it ;) tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enig6B029920EE3DA202122BE28D 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 iD8DBQFB95DuehvPYvDU0roRAlkjAKDVFkhz8feERuTk0v1IAvXHXb9j8wCfcls7 7DQsMgWDTwSNSYmyvUH3Wm0= =xu8K -----END PGP SIGNATURE----- --------------enig6B029920EE3DA202122BE28D-- --===============1793204578== 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 --===============1793204578==-- From rpsec-bounces@ietf.org Wed Jan 26 12:20: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 MAA17828 for ; Wed, 26 Jan 2005 12:20:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctr7I-0004hn-7Y for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 12:38:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtqbP-0003Uy-LD; Wed, 26 Jan 2005 12:05:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtqVT-000296-Q3 for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 11:59: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 LAA16071 for ; Wed, 26 Jan 2005 11:59:00 -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 1CtqmP-00046u-DG for rpsec@ietf.org; Wed, 26 Jan 2005 12:16:34 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id ACA092D4A60 for ; Wed, 26 Jan 2005 11:58:26 -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 16605-02-62 for ; Wed, 26 Jan 2005 11:58:24 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D43CD2D4839 for ; Wed, 26 Jan 2005 11:58:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] proposed message to the IESG Date: Wed, 26 Jan 2005 11:58:24 -0500 Message-ID: Thread-Topic: [RPSEC] proposed message to the IESG Thread-Index: AcT/Pj5bBxV1kGY8S/2SPFPbPkon3AEibR4w From: "Susan Hares" To: "Jeffrey Haas" , "Blaine Christian" X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable 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: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Blaine and Jeff:=20 Just so it is said.=20 BGP mechanisms or operational changes are in the IDR charter.=20 Cross-functional items start in one working group and move to the other. The originating working group is responsible for clearly defining the requirements for the mechanisms.=20 Sue Hares -----Original Message----- From: Jeffrey Haas=20 Sent: Thursday, January 20, 2005 4:25 PM To: Blaine Christian Cc: rpsec@ietf.org; Stephen Kent Subject: Re: [RPSEC] proposed message to the IESG Blaine, On Thu, Jan 20, 2005 at 03:58:53PM -0500, Blaine Christian wrote: > 1. Draft not in the charter: The premise for this argument appears to be > that by including requirements to cope with current operational practices > the draft falls under the wrong working group. I read the charter and it > does not state that operational requirements are verboten. The draft seems > to fall under the charter. I do not pretend to speak for Yakov or Sue (who is on this list) or the IDR working group. IMO, defining the security requirements for BGP is within the rpsec charter. Defining recommended protocol or operational changes to BGP is also within charter. =20 Defining the actual protocol level changes to BGP is at best a cross-functional work item. IMO, most of the work would be done in IDR and it would be rpsec's responsibility to say "this doesn't do what we wanted". > 2. BGP spec not followed:=20 I'll defer this to the other parties and try to stick to specifics since that fits the ADHD way I'm following this group at the moment. > If so, it is > my perception that all transitive attributes MUST be protected via the > security mechanism. Must they? What is to be protected? What does "protect" mean? I think these two last questions form the core of our arguments. However, it is difficult to articulate each of these without delving into solutions. > My assumption, and I should be corrected if I am wrong, > was that MD5/IPSec type mechanisms would be sufficient for attributes that > are usually non-transitive (communities/localpref etc...). Communities are transitive. :-) > Blaine --=20 Jeff Haas=20 NextHop Technologies _______________________________________________ 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 Jan 26 12:36: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 MAA19455 for ; Wed, 26 Jan 2005 12:36:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtrMG-0005DB-2a for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 12:53:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctqvz-00067I-8G; Wed, 26 Jan 2005 12:26:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtqrW-00044g-9n for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 12:21:50 -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 MAA17899 for ; Wed, 26 Jan 2005 12:21:47 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctr8R-0004jI-VL for rpsec@ietf.org; Wed, 26 Jan 2005 12:39:22 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0QHIEHs014258 for ; Wed, 26 Jan 2005 12:18:14 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAlOaW1B; Wed, 26 Jan 05 12:18:11 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0QHJvd9028777; Wed, 26 Jan 2005 12:19:57 -0500 (EST) Date: Wed, 26 Jan 2005 12:19:57 -0500 (EST) From: Sandy Murphy Message-Id: <200501261719.j0QHJvd9028777@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Situation with BGP security reqs draft X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad > b3) It SHOULD be verifyable that each party on the path > was authorized to readvertise the route to exactly > the next AS. ("transit authorization") Could you expand on this? A sends something to B and says "you may advertise this to C and D but not E"? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 12:41: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 MAA19860 for ; Wed, 26 Jan 2005 12:41:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtrRX-0005KT-N0 for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 12:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctr6c-0000vw-2S; Wed, 26 Jan 2005 12:37:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtqwU-0006Ee-RW for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 12:26: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 MAA18523 for ; Wed, 26 Jan 2005 12:26:55 -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 1CtrDR-0004ux-Ll for rpsec@ietf.org; Wed, 26 Jan 2005 12:44:30 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j0QHQcKN032620; Wed, 26 Jan 2005 17:26:38 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j0QHQbNG032617; Wed, 26 Jan 2005 17:26:37 GMT Date: Wed, 26 Jan 2005 17:26:37 +0000 From: bmanning@vacation.karoshi.com To: Susan Hares Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050126172637.GC32505@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: 7d33c50f3756db14428398e2bdedd581 Cc: rpsec@ietf.org, Jeffrey Haas , 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > > My assumption, and I should be corrected if I am wrong, > > was that MD5/IPSec type mechanisms would be sufficient for attributes > that > > are usually non-transitive (communities/localpref etc...). > > Communities are transitive. :-) > > > Blaine > > -- > Jeff Haas except in cases where multi-hop BGP is used, the "normal" case peering session is on a p2p link (altho p2p links these days are not nearly as physically protected as in the dim past) and so tapping the link to expose BGP data was harder. MD5 is a reasonable tool in such cases also - while communities are transitive, trust is not. --bill _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 12:51: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 MAA22675 for ; Wed, 26 Jan 2005 12:51:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtrbQ-0005lJ-ED for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 13:09:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctr8P-0001MJ-JW; Wed, 26 Jan 2005 12:39:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctr39-0007sS-78 for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 12:33: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 MAA19102 for ; Wed, 26 Jan 2005 12:33:48 -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 1CtrK5-00054Z-IT for rpsec@ietf.org; Wed, 26 Jan 2005 12:51:22 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id ED6142D4A78 for ; Wed, 26 Jan 2005 12:33: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 18483-01-93 for ; Wed, 26 Jan 2005 12:33:14 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 9A8312D49CC for ; Wed, 26 Jan 2005 12:33:14 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] proposed message to the IESG Date: Wed, 26 Jan 2005 12:33:14 -0500 Message-ID: Thread-Topic: [RPSEC] proposed message to the IESG Thread-Index: AcT/Qz2w4PedbopqT9q6Gh5qQ9muogEhR48A From: "Susan Hares" To: "Blaine Christian" , "Sandy Murphy" , "Jeffrey Haas" X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Blaine: I'm catching up on a 4 days of exciting email. In reading through the email, I'd like to make sure I understand this point:=20 -----Original Message----- From: Blaine Christian [mailto:blaine@blaines.net]=20 Sent: Thursday, January 20, 2005 5:38 PM To: Sandy Murphy; Jeffrey Haas Cc: rpsec@ietf.org; kent@bbn.com Subject: Re: [RPSEC] proposed message to the IESG =20 I could not agree more. BGP has a LOT of wiggle room in it. This must make security oriented folks nuts. I am only into security operationally. However, I have quite a bit of background in the "hey your implementation of BGP broke me" realm. Heck, a lot of times it was our specific manner of implementing BGP that broke people (MED route oscillation due to confederations comes to mind). While we will probably not be able to come up with a complete requirement that solves everything I do firmly believe we can improve the current state of affairs while letting the older implementations age out gracefully. =20 1st - Could you comment if the current BGP draft makes this better or worse?=20 2nd - BGP is Path Vector - that is Distance Vector (DV) with a Path. =20 Many of the DV characteristics are "rumor" based protocols - which by nature give the security folks fits. Can you give a list of the=20 policy issues you are concerned with?=20 Sue _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 13:01: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 NAA24027 for ; Wed, 26 Jan 2005 13:01:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctrku-000685-KM for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 13:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtrKj-0004RU-Ag; Wed, 26 Jan 2005 12:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtrB2-0001u5-DI for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 12:42: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 MAA19926 for ; Wed, 26 Jan 2005 12:41:57 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtrRz-0005LE-0T for rpsec@ietf.org; Wed, 26 Jan 2005 12:59:32 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0QHcVvB016538 for ; Wed, 26 Jan 2005 12:38:31 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAARwaWrG; Wed, 26 Jan 05 12:38:26 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0QHeD4l029609; Wed, 26 Jan 2005 12:40:13 -0500 (EST) Date: Wed, 26 Jan 2005 12:40:13 -0500 (EST) From: Sandy Murphy Message-Id: <200501261740.j0QHeD4l029609@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Situation with BGP security reqs draft X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >It is impossible to secure a protocol without a specification > that defines a reference model describing its behavior. >... > If some operational practice isn't explicitly spelled out, > but falls within the BGP framework (e.g. route reorigination vs route > aggregation within BGP), we simply have to deal with it and point out > the security implications. If the reality contradicts the spec, then it is > either that the implementation decided to be non-compliant and we shouldn't > have to deal with it, or the spec needs to be fixed and we need to advise > the IDR WG. So - can I conclude that you think it would be a good idea to list the operational uses that we will deal with? And a list of those we won't? As you and Joel have said - trying to decide security for an unspecified system is not a good idea/doomed to failure/etc. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 13:40: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 NAA27796 for ; Wed, 26 Jan 2005 13:40:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtsMP-0007LB-OB for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 13:57:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctrxm-0000VO-0L; Wed, 26 Jan 2005 13:32:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtrqF-0005ab-Es for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 13:24: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 NAA26343 for ; Wed, 26 Jan 2005 13:24:32 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cts7C-0006pt-5g for rpsec@ietf.org; Wed, 26 Jan 2005 13:42:07 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0QIL5pg021667 for ; Wed, 26 Jan 2005 13:21:05 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAWEa4tQ; Wed, 26 Jan 05 13:21:03 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0QIMnE5001308; Wed, 26 Jan 2005 13:22:49 -0500 (EST) Date: Wed, 26 Jan 2005 13:22:49 -0500 (EST) From: Sandy Murphy Message-Id: <200501261822.j0QIMnE5001308@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Situation with BGP security reqs draft X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 About prepending ... I finally came across the language in the spec that explicitly allows prepending ("or including" - why that caveat I don't know) more than one instance of your AS number. (Sections 5.1.2) So we don't have to consider this an operation use to be covered - it is part of the base spec. (NOT, I hasten to add, that anyone was considering disallowing this.) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 13:42:41 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 NAA27924 for ; Wed, 26 Jan 2005 13:42:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtsOm-0007OA-It for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 14:00:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctrxr-0000a1-DI; Wed, 26 Jan 2005 13:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtrsE-0006G5-RJ for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 13:26: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 NAA26560 for ; Wed, 26 Jan 2005 13:26:35 -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 1Cts9A-0006t4-KT for rpsec@ietf.org; Wed, 26 Jan 2005 13:44:10 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B290D2D4D6B for ; Wed, 26 Jan 2005 13:18:13 -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 21838-02-65 for ; Wed, 26 Jan 2005 13:18:09 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 8E4BF2D49CC for ; Wed, 26 Jan 2005 13:18:09 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] proposed message to the IESG Date: Wed, 26 Jan 2005 13:18:09 -0500 Message-ID: Thread-Topic: [RPSEC] proposed message to the IESG Thread-Index: AcT/4fKfNJgRzu2RSnK0PIgqSHArGAD8TR2Q From: "Susan Hares" To: , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Russ and all: I would like to know if the conflicts between the BGP spec And operational practices are between the Draft BGP specification or the RFC 1771. Sue Hares -----Original Message----- From: sthaug@nethelp.no [mailto:sthaug@nethelp.no]=20 Sent: Friday, January 21, 2005 12:44 PM To: kent@bbn.com Cc: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG > Finally, you close with "This document is intended to present a set=20 > of requirements from the operator community to the folks creating the=20 > standards ..." I have to admit that I do not recall hearing that=20 > characterization of the goal for this document. The WG charter does=20 > not convey the notion that this document is to represent the operator=20 > view of security requirements for BGP. I don't see a need for the document to represent *only* the operator view of security requirements for BGP. However, if the operator view is not represented at all, there is a high probability that anything based on this document would be ignored by many operators. Working for an operator myself, I clearly feel that if there is a conflict between the BGP spec and the way BGP is actually used by a significant number of operators, the operational practices need to be taken into consideration - and the conflict should be explicitly spelled out. Steinar Haug, Nethelp consulting, sthaug@nethelp.no _______________________________________________ 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 Jan 26 13:53: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 NAA29239 for ; Wed, 26 Jan 2005 13:53:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtsZb-0007nm-Fk for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 14:11:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtsBY-000588-5x; Wed, 26 Jan 2005 13:46:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cts1u-0001WH-78 for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 13:36:38 -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 NAA27529 for ; Wed, 26 Jan 2005 13:36:35 -0500 (EST) Received: from nutshell.tislabs.com ([192.94.214.100] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtsIs-0007Fy-Cs for rpsec@ietf.org; Wed, 26 Jan 2005 13:54:10 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0QIXA4m023383 for ; Wed, 26 Jan 2005 13:33:10 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAALzaWQT; Wed, 26 Jan 05 13:33:07 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0QIYsxl001799; Wed, 26 Jan 2005 13:34:54 -0500 (EST) Date: Wed, 26 Jan 2005 13:34:54 -0500 (EST) From: Sandy Murphy Message-Id: <200501261834.j0QIYsxl001799@tislabs.com> To: rpsec@ietf.org Subject: Re: [RPSEC] Situation with BGP security reqs draft X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 >interactions with static routes Hm. Static routes. Won't we have to include this for consideration when we're talking about the "first AS" authorization? That is, I imagine that section 9.4 (Originating BGP Routes - "injecting routing information acquired by some other means") is supposed to cover static routes, yes? So forwarding interactions with static routes aren't controllable by BGP and are so out of scope, but routing information interactiosn with static routes are controllable by BGP and so are in scope? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 13:57: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 NAA29811 for ; Wed, 26 Jan 2005 13:57:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctsd0-0007yD-5A for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 14:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtsK9-0007yk-C9; Wed, 26 Jan 2005 13:55:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtsDZ-0006C2-7N for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 13:48:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28821 for ; Wed, 26 Jan 2005 13:48: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 1CtsUW-0007eb-Et for rpsec@ietf.org; Wed, 26 Jan 2005 14:06:13 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 31F2D2D4B7A for ; Wed, 26 Jan 2005 13:48:09 -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 24632-02-26 for ; Wed, 26 Jan 2005 13:48:06 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 877F52D49CC for ; Wed, 26 Jan 2005 13:48:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] proposed message to the IESG - Aggregation issues Date: Wed, 26 Jan 2005 13:48:06 -0500 Message-ID: Thread-Topic: [RPSEC] proposed message to the IESG - Aggregation issues Thread-Index: AcT/1fq2R+D/yYK+TB+SLLML0C7hDAD+sFIA From: "Susan Hares" To: "Stephen Kent" , "Russ White" X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.3 (/) X-Scan-Signature: 37030b2bac457674481619d2da4b0c52 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="===============1699796002==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c075d775af780178ad8663695edfd43a This is a multi-part message in MIME format. --===============1699796002== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C503D7.92ACBEF6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C503D7.92ACBEF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen, Russ and Blaine:=20 =20 For aggregation issues regarding draft-26,=20 I would suggest you review the implementation=20 report on BGP (draft-26). Look at the questions regarding aggregation. These are contained in: =20 section 3.46 Pages 72-75. =20 This is a description of the aggregation functions per the BGP specification and the results from a set of vendors as to the capability.=20 =20 Perhaps this language will provide details from 3 vendors (cisco, Nexthop, Laurel networks). =20 =20 Of course, I'd be glad to collect additional responses from BGP implementers on the survey or this portion. =20 =20 Sue =20 =20 _____ =20 From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Friday, January 21, 2005 11:09 AM To: Russ White Cc: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG =20 At 2:00 PM -0500 1/20/05, Russ White wrote: In contrast, Russ White, a co-chair of the WG and a contributor to this RPSEC document, has asserted that operational experience should be the primary driver for the requirements document. Russ has stated that the BGP spec cited above does not accurately reflect BGP implementation and deployment patterns, and thus is not a suitable basis for the security requirements document that the WG is slated to develop. =09 Rephrase this to: Russ White.... believes the specifications requirement should be based on an analysis of what is provable within an internetwork using BGP as its routing protocol, rather than the proving the processes within the BGP specification have been followed, specifically. =20 In one of your messages on 1/6 you said: =20 And at some point, the WG has to decide which of these two models is valid. I believe that I've made a strong case to consider the operational use as a valid model, because of gaps in the alternative model. =20 This was in response to my comment: =20 We both have prejudices in approaching this problem. One can fairly say that I used the BGP spec as the basis for developing the security requirements model that we then addressed with S-BGP. Likewise, you adopted an operations-oriented view of security when you developed soBGP. That does not make either approach intrinsically valid or invalid. =20 So, based on your comment above, my wording of the fundamental issue seems accurate. =20 =20 I don't claim the BGP spec is wrong, just that the important questions aren't about process, but how the information in the system matches reality. =20 =20 You and I have argued over whether the path in an UPDATE is representative of the path via which the UPDATE was transmitted. You said no, yet the spec says yes, as I pointed out. This seems like a clear example where you believe that the way BGP works does not match the spec. =20 Also, a message from Iljitsch on 1/6/05 includes the comment: =20 Now all of this non-RFC-compliant aggregation works without any problems because of the longest match first rule. =20 We have discussed whether aggregation is performed as specified in the spec, e.g., with regard to use of the ATOMIC AGGREGATE attribute. I asked colleague to analyze UPDATEs from RV, for all of 2004, and I reported the results in a message earlier this week. It shows that about 6% or all UPDATEs contain this attribute. Yet have received messages from folks who say that this attribute is almost certainly being used in a non-conformant fashion today. =20 I can revise the text to say that you and others have questioned whether the BGP spec matches the way BGP is used in practice. =20 Russ has stated that many of these do not reflect BGP implementation and deployment, hence his insistence on a different basis for requirements development. I have objected because Russ has not been able to cite IETF-approved documents that describe the basis he supports. =09 See above. It's not a matter of citing other specifications. Many of the things which need to be secured are outside IETF specifications to begin with. For instance, the authorization to advertise a specific block of addresses is completely outside the BGP specification, since the BGP specification doesn't cover such things as how to get an address block, etc. And yet, I think we all agree that this is a critical requirement. =20 so, the simple form of your response is that there are no IETF standards for what you feel are critical aspects of what needs to be considered re BGP security. Sounds like what I said. =20 =09 -- =09 =09 It seems inappropriate for the IETF to adopt a BGP security requirements document that employs rationale that conflicts with the BGP spec, especially when both are developed in the same area. =20 Could you please cite a specific instance where the requirements document actually contradicts the BGP specification? =20 The question is not whether the security requirements contradict the BGP spec, but whether the rationale for most of the requirements derives from the BGP spec. A security requirement can be stated that neither conforms to the spec nor contradicts it, but that does not make it an appropriate requirement. Unless we agree on the basis for the requirements, we can't objectively decide which ones are reasonable and which are not. That is the argument we are having, and the one that needs to be resolved before we can make progress. =20 Steve ------_=_NextPart_001_01C503D7.92ACBEF6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [RPSEC] proposed message to the IESG

Stephen, = Russ and Blaine:

 

For = aggregation issues regarding draft-26,

I would = suggest you review the implementation

report = on BGP (draft-26).  Look at the

questions regarding aggregation. These are contained = in:

 

 section 3.46

 Pages 72-75.

 

This is = a description of the aggregation functions

per the = BGP specification and the results from

a set of = vendors as to the capability.

 

Perhaps = this language will provide details from 3 = vendors

(cisco, = Nexthop, Laurel networks).   

 

Of = course, I’d be glad to collect additional responses

from BGP = implementers on the survey or this portion.

 

 

Sue

 

 

From: = Stephen Kent [mailto:kent@bbn.com]
Sent: Friday, January 21, = 2005 11:09 AM
To: Russ White
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] = proposed message to the IESG

 

At 2:00 PM -0500 1/20/05, Russ White = wrote:

In contrast, Russ White, a co-chair of the WG and a contributor = to this RPSEC document, has asserted that operational experience should be the = primary driver for the requirements document. Russ has stated that the BGP spec = cited above does not accurately reflect BGP implementation and deployment = patterns, and thus is not a suitable basis for the security requirements document = that the WG is slated to develop.


Rephrase this to:

Russ White.... believes the specifications requirement should be = based on an analysis of what is provable within an internetwork using BGP as = its routing protocol, rather than the proving the processes within the BGP specification have been followed, = specifically.

 

In one of your messages on 1/6 you = said:

 

And at some point, the WG = has to decide which of these two models is valid. I believe that I've made a = strong case to consider the operational use as a valid model, because of gaps = in the alternative model.

 

This was in response to my comment:

 

We both have prejudices in approaching this problem.  One = can fairly say that I used the BGP spec as the basis for developing the = security requirements model that we then addressed with S-BGP. Likewise, you = adopted an operations-oriented view of security when you developed soBGP. That does = not make either approach intrinsically valid or = invalid.

 

So, based on your comment above, my wording of the fundamental = issue seems accurate.

 

 

I don't claim the BGP spec is wrong, just that the important = questions aren't about process, but how the information in the system matches = reality.

 

 

You and I have argued over whether the path in an UPDATE is representative of the path via which the UPDATE was transmitted. You = said no, yet the spec says yes, as I pointed out. This seems like a clear example = where you believe that the way BGP works does not match the = spec.

 

Also, a message from Iljitsch on 1/6/05 includes the = comment:

 

Now all of this = non-RFC-compliant aggregation works without any problems because of the longest match = first rule.

 

We have discussed whether aggregation is performed as specified = in the spec, e.g., with regard to use of the ATOMIC AGGREGATE attribute. I = asked colleague to analyze UPDATEs from RV, for all of 2004, and I reported = the results in a message earlier this week. It shows that about 6% or all = UPDATEs contain this attribute.  Yet have received messages from folks who = say that this attribute is almost certainly being used in a non-conformant = fashion today.

 

I can revise the text to say that you and others have = questioned whether the BGP spec matches the way BGP is used in = practice.

 

Russ has stated that many of these do not reflect BGP = implementation and deployment, hence his insistence on a different basis for = requirements development. I have objected because Russ has not been able to cite IETF-approved documents that describe the basis he = supports.


See above. It's not a matter of citing other specifications. Many of the = things which need to be secured are outside IETF specifications to begin with. = For instance, the authorization to advertise a specific block of addresses = is completely outside the BGP specification, since the BGP specification = doesn't cover such things as how to get an address block, etc. And yet, I think = we all agree that this is a critical requirement.

 

so, the simple form of your response is that there are no IETF standards for what you feel are critical aspects of what needs to be = considered re BGP security. Sounds like what I said.

 


--

It seems inappropriate for the IETF to adopt a BGP security requirements document that employs rationale that conflicts with the BGP = spec, especially when both are developed in the same = area.

 

Could you please cite a specific instance where the requirements document actually contradicts the BGP = specification?

 

The question is not whether the security requirements contradict = the BGP spec, but whether the rationale for most of the requirements derives = from the BGP spec. A security requirement can be stated that neither conforms = to the spec nor contradicts it, but that does not make it an appropriate = requirement. Unless we agree on the basis for the requirements, we can't objectively = decide which ones are reasonable and which are not. That is the argument we are having, and the one that needs to be resolved before we can make = progress.

 

Steve

------_=_NextPart_001_01C503D7.92ACBEF6-- --===============1699796002== 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 --===============1699796002==-- From rpsec-bounces@ietf.org Wed Jan 26 14:05:48 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 OAA00720 for ; Wed, 26 Jan 2005 14:05:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctsl7-0008EI-8i for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 14:23:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtsT5-0001rj-6f; Wed, 26 Jan 2005 14:04:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtsMq-0000Oh-EC for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 13:58:16 -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 NAA29904 for ; Wed, 26 Jan 2005 13:58:15 -0500 (EST) Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctsdo-000801-LW for rpsec@ietf.org; Wed, 26 Jan 2005 14:15:48 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id j0QIsmgd026656 for ; Wed, 26 Jan 2005 13:54:48 -0500 (EST) Received: from filbert.tislabs.com(10.66.1.10) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKoaOd0; Wed, 26 Jan 05 13:54:45 -0500 Received: (from sandy@localhost) by tislabs.com (8.12.9/8.12.9) id j0QIuOfJ002977; Wed, 26 Jan 2005 13:56:24 -0500 (EST) Date: Wed, 26 Jan 2005 13:56:24 -0500 (EST) From: Sandy Murphy Message-Id: <200501261856.j0QIuOfJ002977@tislabs.com> To: blaine@blaines.net, jhaas@nexthop.com, rpsec@ietf.org, sandy@tislabs.com, shares@nexthop.com Subject: RE: [RPSEC] proposed message to the IESG X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: sandy@tislabs.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad > Many of the DV characteristics are "rumor" based protocols - >which by nature give the security folks fits. I like the "rumor" characterization. I sometimes liken it to a "whisper game". (The "give the security folks fits" part is also accurate as a depiction of the difficulty factor.) --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 14:11:20 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 OAA00999 for ; Wed, 26 Jan 2005 14:11:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtsqT-0008KR-Mq for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 14:28:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtsT9-0001vp-HC; Wed, 26 Jan 2005 14:04:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtsQQ-0001EF-70 for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 14:01: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 OAA00286 for ; Wed, 26 Jan 2005 14:01:56 -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 1CtshN-00085P-8U for rpsec@ietf.org; Wed, 26 Jan 2005 14:19:30 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id AAB6F2D4C6B for ; Wed, 26 Jan 2005 14:01:21 -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 25898-02-17 for ; Wed, 26 Jan 2005 14:01:17 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 787182D4B3D for ; Wed, 26 Jan 2005 14:01:17 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] proposed message to the IESG Date: Wed, 26 Jan 2005 14:01:17 -0500 Message-ID: Thread-Topic: [RPSEC] proposed message to the IESG Thread-Index: AcT/2ZItrDHEjTZ6QGiXSVsUDCXPiAD/rjEg From: "Susan Hares" To: "Russ White" , "Sandy Murphy" X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Russ: The RPSL protocol for the IRR had a authorization on the policy passed (per RFC 2725). It is possible to create something like the IRRs with policy and delegation that can be used to handle authorization that provides allocation policy.=20 It is possible to go to IRRs as a source of "trusted bgp policy" on aggregation or ownership of routes. It is possible for this trust to be given to the IRR and delegated from the IRR. This hierarchical delegation can be called a transitive trust model or a web of trust model. =20 When you mean transitive trust, do you mean to: - exclude the IRR and RPSL mechanisms or - include the IRR and RPLS mechanisms? Sue -----Original Message----- From: Russ White [mailto:ruwhite@cisco.com]=20 Sent: Friday, January 21, 2005 11:36 AM To: Sandy Murphy Cc: rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG >> -- Overlapping address spaces exist. > > I don't know what you mean by this. I get the mental image of the same=20 > address being used by two hosts, but surely that's not what's meant, so=20 > I'm guessing you mean that authorization for the same address space can=20 > overlap - that is, two organizations can be allocated the same address > space. In a sense, yes, and in a sense, no. -- A is allocated 10.1.0.0/16. -- A suballocates 10.1.1.0/24 to B. IMHO, we care about routes, not updates, and routes contain prefixes. One=20 of the questions we can ask about those prefixes is: Is the originator=20 authorized to advertise the address space in the route? In this case, A can=20 advertise 10.1.0.0/16, and the answer is yes, even though it actually=20 contains 10.1.1.0/24, for which the answer is technically no. So, in a sense, this address space, 10.1.1.0/24, is legally "owned" by two=20 entities within the system. Other than redoing the entire allocation=20 scheme, or disallowing aggregation (forcing A not to advertise 10.1.0.0/16=20 when it suballocates space out of it), I don't see how you get around this=20 problem. It's certainly easier to just say: "We'll just worry about the path the=20 update takes, and not worry about this problem. We'll assume that if you're=20 authorized to readvertise the update, you're authorized to transit for this=20 address space, and we'll also assume you're authorized to allow me to=20 readvertise this address space." IMHO, this sort of transitive trust can't exist within a routing system. We=20 need to focus on the questions we can ask, and base the requirements on=20 them, rather than the process used to handle updates according to the BGP=20 specification. :-) 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 Wed Jan 26 15:04: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 PAA07721 for ; Wed, 26 Jan 2005 15:04:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cttfi-0001e4-7t for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 15:21:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CttKC-0006ax-3V; Wed, 26 Jan 2005 14:59:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CttEI-00057s-AM for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 14:53: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 OAA06195 for ; Wed, 26 Jan 2005 14:53:28 -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 1CttVD-00017D-5y for rpsec@ietf.org; Wed, 26 Jan 2005 15:11: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 j0QJqa9T022171 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Wed, 26 Jan 2005 14:52:37 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 26 Jan 2005 14:52:28 -0500 Subject: Re: [RPSEC] proposed message to the IESG From: Blaine Christian To: Susan Hares , Sandy Murphy , Jeffrey Haas 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: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, kent@bbn.com X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit Just to make it very clear. Drafts are like armpits, everyone has them and everyone elses stinks. There are, at least, two annoying grammatical errors in the requirements draft for example. There are also numerous changes that need to be made (I am trying to keep track of the wonderful arguments and when phraseology is good I am dropping it in a mail folder for potential draft insertion). So, I will point out potential issues with the newest BGP spec draft and I want everyone to note that the requirements draft is significantly behind in development when compared to the BGP draft. I am reading draft-ietf-idr-bgp4-26.txt and basing my comments on it... On 1/26/05 12:33 PM, "Susan Hares" wrote: > Blaine: > > I'm catching up on a 4 days of exciting email. In reading through the > email, I'd like to make sure I understand this point: > > > -----Original Message----- > From: Blaine Christian [mailto:blaine@blaines.net] > Sent: Thursday, January 20, 2005 5:38 PM > To: Sandy Murphy; Jeffrey Haas > Cc: rpsec@ietf.org; kent@bbn.com > Subject: Re: [RPSEC] proposed message to the IESG > > > > I could not agree more. BGP has a LOT of wiggle room in it. This must > make > security oriented folks nuts. I am only into security operationally. > However, I have quite a bit of background in the "hey your > implementation of > BGP broke me" realm. Heck, a lot of times it was our specific manner of > implementing BGP that broke people (MED route oscillation due to > confederations comes to mind). While we will probably not be able to > come > up with a complete requirement that solves everything I do firmly > believe we > can improve the current state of affairs while letting the older > implementations age out gracefully. > > > > 1st - Could you comment if the current BGP draft makes this better or > worse? > Second page, third paragraph, last sentence. "BGP can support only the policies conforming to the destination-based forwarding paradigm." BGP already does support source-based policies using communities. Communities have been used to create source based forwarding policy decisions on two vendors that I know of. Of course this is more internal than external but BGP is a rather common tool for internally propagating information and the same communities based tools are available across EBGP sessions by the very nature of the implementation. BTW, the next sentence says... " This specification covers only the exchange of IP version 4 network reachability information." Which seems to state that all the other uses for BGP are not covered under the draft. Is that true? Page 6, second paragraph, last sentence. " The value of the BGP Identifier is determined on startup and is the same for every local interface and every BGP peer. " Should probably be stated as "The value of the BGP Identifier is determined on startup and MUST be the same for every local interace and every BGP peer." If you want to ensure folks follow the standard . Saying "is the same" may be making a rash assumption. Page 9, paragraph three, This talks about how an AS is considered a part of the a coherent system to external AS's. What stands out, as missing, is reference to confederations, which each have their own AS and communicate via EIBGP (just a tiny bit different than EBGP WRT the local decision process and propagation). I know Yakov is not fond of confederations anymore but hey... Now we are stuck with them . Page 10, last paragraph, " If a BGP speaker chooses to advertise a previously received route, it MAY add to or modify the path attributes of the route before adver- tising it to a peer." If it is an IBGP peer I can understand not modifying the path attribute. However, an EBGP peer it MUST modify the path attribute (by prepending it's own AS) right? I guess the MAY in this context is confusing. Page 28, first paragraph, " A BGP speaker SHALL NOT install a route with itself as the next hop." This comes close to breaking some nifty blackhole routing stuff folks are doing nowadays. I think it would still be manageable with communities but would it be more appropriate to say that a BGP speaker SHALL NOT install a route received from an EBGP peer with itself as the next hop? It just may be a good idea to be careful about breaking the ability to do black hole routing. Note the additional language about outbound interfaces that comes in the paragraph immediately following may need to be revised... We do not lose this valuable tool (by accident). Page 29, MEDs, It is probably a good idea to discourage internal use of MEDs for implementations that use Route reflectors or confederations. ---Things to add?--- Prefix limits: If both sides of an EBGP session "know" of the prefix limits it would work a heck of a lot better than to just break a session during a route table explosion. An attribute that captures prefix limits could be communicated between BGP peers. Strengthen AS insertion language: Only permit AS prepend of your EBGP neighbor AS inbound and your own AS EBGP outbound? Just a thought... I know of one person who actually wants insert other folks AS's outbound/inbound. Most people find it pretty evil to do so. Perhaps this can be worked in over time. Please note that the language in the draft comes very close to saying this on page 27. Enforce First AS: If we can solidify this as a BGP security requirement it should probably go in the BGP spec. But, then again, a whole lot of stuff would be slated for insertion. I ran out of energy and have to get back to work... I did want you to have this chunk because I suspect it is going to generate a bit of discussion. > 2nd - BGP is Path Vector - that is Distance Vector (DV) with a Path. > Many of the DV characteristics are "rumor" based protocols - > which by nature give the security folks fits. Can you give a > list of the > policy issues you are concerned with? I love the rumor based bit . I always envision BGP as leaking puddles of prefixes. For me, I am most concerned that I am dealing with the right prefix advertisement in the first place. I am sure there are a lot of criteria we can come up with to take care of this. I mentioned to the group in one email that "knowing" that every session along the path had enforce first AS "on" AND was doing some form of session security would go a long way to proving the validity of the path. Combined with a prefix trust mechanism it seems that we can raise the bar significantly. With respect to explicit policy: It is completely within the right of each operator to manage BGP internal to their network (and distribute/not distribute prefixes). It is also completely within the right of the other peers to ignore their advertisements. This is where I think we can not force policy on users. We have to encourage policy by users. In other words, internal to your own network, the choice with what to do about advertisements is completely yours. INCLUDING whether the advertisement is propagated. If external networks have a better view of your policy they can make a determination whether they are willing to use your advertisements. So, a better view of the policies applied would be good. For example, knowing about enforce first As and session security seem like policies that might be good to know about from a route "choice" perspective. I hope this is meaty enough to stir some more conversation. Let me know what you think! Regards, Blaine _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 15:11: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 PAA08912 for ; Wed, 26 Jan 2005 15:11:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cttmv-0001sL-4r for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 15:29:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CttR5-0002Ii-W0; Wed, 26 Jan 2005 15:06:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CttM1-0007Uf-Nu for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 15:01:29 -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 PAA07455 for ; Wed, 26 Jan 2005 15:01:27 -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 1Cttcy-0001YB-V6 for rpsec@ietf.org; Wed, 26 Jan 2005 15:19:02 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E6D0D2D49A4 for ; Wed, 26 Jan 2005 15:00:56 -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 31020-01-2 for ; Wed, 26 Jan 2005 15:00:54 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A721E2D493C for ; Wed, 26 Jan 2005 15:00:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] Back to the Basics: The AS Path Date: Wed, 26 Jan 2005 15:00:54 -0500 Message-ID: Thread-Topic: [RPSEC] Back to the Basics: The AS Path Thread-Index: AcUCYeRhMWFnrECuTo2L33n1w611JABf8ySA From: "Susan Hares" To: "Sandy Murphy" , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable X-BeenThere: rpsec@ietf.org 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 Content-Transfer-Encoding: quoted-printable AS confederations use e-BGP within an AS. Private AS are used there. Jeff gave you 65000 example. sue -----Original Message----- From: Sandy Murphy [mailto:sandy@tislabs.com]=20 Sent: Monday, January 24, 2005 4:54 PM To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: Re: [RPSEC] Back to the Basics: The AS Path >Private ASes can be used for whatever purpose you want. However, they're >not supposed to be visible in the public Internet. > >In order for private ASes to be visible, you have to put them in your eBGP >sessions. Can I put these two statements together to conclude that private AS's aren't supposed to be in your eBGP sessions? --Sandy _______________________________________________ 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 Jan 26 15:32: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 PAA12320 for ; Wed, 26 Jan 2005 15:32:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctu7N-0002VF-Rb for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 15:50:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cttli-0000KF-0S; Wed, 26 Jan 2005 15:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cttfh-0005QS-62 for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 15:21:49 -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 PAA10507 for ; Wed, 26 Jan 2005 15:21:47 -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 1Cttwf-0002A6-79 for rpsec@ietf.org; Wed, 26 Jan 2005 15:39:22 -0500 Received: from [172.17.19.3] (helo=[172.17.19.3]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1Cttfe-00029Z-2i; Wed, 26 Jan 2005 21:21:46 +0100 Message-ID: <41F7FBCE.3030703@schlund.net> Date: Wed, 26 Jan 2005 21:21:34 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sandy Murphy Subject: Re: [RPSEC] Situation with BGP security reqs draft References: <200501261719.j0QHJvd9028777@tislabs.com> In-Reply-To: <200501261719.j0QHJvd9028777@tislabs.com> 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: 769a46790fb42fbb0b0cc700c82f7081 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0075091105==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0075091105== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBFDBAA04133DABD183B24462" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBFDBAA04133DABD183B24462 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sandy Murphy wrote: >> b3) It SHOULD be verifyable that each party on the path >> was authorized to readvertise the route to exactly >> the next AS. ("transit authorization") >> >> > >Could you expand on this? A sends something to B and says >"you may advertise this to C and D but not E"? > e.g. a transit customer is not allowed to readvertise prefixes to peers or other transits, but he is allowed to readvertise them to hist transit customers. b3 aims at checking exactly that authorization.. I tried to build a checking system build on community markings, but it's not real security. Just in case you want wo have a look at it: http://www.mink.de/academics/self/IDRWS_2004_mink.pdf tschuess Stefan Mink -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigBFDBAA04133DABD183B24462 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.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9/vRehvPYvDU0roRAunvAJ9kecJBfRxcFTJww0AL7NcjHMQICgCg1Ev9 L61/tx+n8n/FYks/ka8WXGo= =gcW7 -----END PGP SIGNATURE----- --------------enigBFDBAA04133DABD183B24462-- --===============0075091105== 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 --===============0075091105==-- From rpsec-bounces@ietf.org Wed Jan 26 16:30: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 QAA22449 for ; Wed, 26 Jan 2005 16:30:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctv1Z-0005yI-Cp for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 16:48:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtuX0-0008Lh-7f; Wed, 26 Jan 2005 16:16:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtuOT-00005z-0A for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 16:08: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 QAA18775 for ; Wed, 26 Jan 2005 16:08:02 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtufN-0004n2-4D for rpsec@ietf.org; Wed, 26 Jan 2005 16:25:34 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CtuOM-0001u0-6z; Wed, 26 Jan 2005 21:07:58 +0000 Date: Wed, 26 Jan 2005 13:07:57 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <254931703.20050126130757@psg.com> To: Sandy Murphy Subject: Re: [RPSEC] Situation with BGP security reqs draft In-Reply-To: <200501261834.j0QIYsxl001799@tislabs.com> References: <200501261834.j0QIYsxl001799@tislabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) 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 Reply-To: Alex Zinin List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Sandy, > So forwarding interactions with static routes aren't controllable > by BGP and are so out of scope, that's what I meant. > but routing information interactiosn > with static routes are controllable by BGP and so are in scope? this may become a slippery slope. one can come up with different types of attacks using static routes (e.g. "ip route /32 null0"), which BGP will have no control over. from the route origination perspective, static routes are a source of routing info to inject. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 16:32: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 QAA22648 for ; Wed, 26 Jan 2005 16:32:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctv37-00062H-1B for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 16:50:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtucK-0003gY-MM; Wed, 26 Jan 2005 16:22:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtuR8-0002Ma-0V for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 16:10:50 -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 QAA19412 for ; Wed, 26 Jan 2005 16:10:47 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctui7-00051z-Er for rpsec@ietf.org; Wed, 26 Jan 2005 16:28:23 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CtuR6-0002V2-Ne; Wed, 26 Jan 2005 21:10:48 +0000 Date: Wed, 26 Jan 2005 13:10:47 -0800 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1639472530.20050126131047@psg.com> To: Sandy Murphy Subject: Re: [RPSEC] Situation with BGP security reqs draft In-Reply-To: <200501261740.j0QHeD4l029609@tislabs.com> References: <200501261740.j0QHeD4l029609@tislabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Sandy, > So - can I conclude that you think it would be a good idea to list > the operational uses that we will deal with? And a list of those > we won't? I think it would be an excellent idea. In fact, as part of this exercise, it may become obvious that some features require proper documentation in IDR. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 19:07:21 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 TAA05931 for ; Wed, 26 Jan 2005 19:07:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtxT1-0000lg-IF for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 19:24:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtxAc-0001y0-5F; Wed, 26 Jan 2005 19:05:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctx9V-0001Z1-UT for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 19:04:50 -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 TAA05705 for ; Wed, 26 Jan 2005 19:04:46 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtxQV-0000hQ-IJ for rpsec@ietf.org; Wed, 26 Jan 2005 19:22:24 -0500 Received: from pc6 (1Cust118.tnt24.lnd4.gbr.da.uu.net [62.188.151.118]) by ranger.systems.pipex.net (Postfix) with SMTP id A5700E00008F; Thu, 27 Jan 2005 00:04:13 +0000 (GMT) Message-ID: <00a301c503fb$21192da0$0601a8c0@pc6> From: "Tom Petch" To: "Blaine Christian" , "Susan Hares" References: Subject: Re: [RPSEC] proposed message to the IESG Date: Wed, 26 Jan 2005 23:58:58 +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: 50a516d93fd399dc60588708fd9a3002 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: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Tom Petch ----- Original Message ----- From: "Blaine Christian" Sent: Wednesday, January 26, 2005 8:52 PM Subject: Re: [RPSEC] proposed message to the IESG > So, I will point out potential issues with the newest BGP spec draft and I > want everyone to note that the requirements draft is significantly behind in > development when compared to the BGP draft. > > I am reading draft-ietf-idr-bgp4-26.txt and basing my comments on it... > > Second page, third paragraph, last sentence. > > "BGP can > support only the policies conforming to the destination-based > forwarding paradigm." > > BGP already does support source-based policies using communities. > Communities have been used to create source based forwarding policy > decisions on two vendors that I know of. Of course this is more internal > than external but BGP is a rather common tool for internally propagating > information and the same communities based tools are available across EBGP > sessions by the very nature of the implementation. > > BTW, the next sentence says... > > " This specification covers only the exchange of IP version 4 network > reachability information." > > Which seems to state that all the other uses for BGP are not covered under > the draft. Is that true? > Yes. I think this is a key point. Look hard and you will not find Confederations, Route Reflectors, VPNs, Communities, IPv6, Route Flap Damping etc etc etc in this draft, all very valid aspects of BGP. The aim of this draft does not include those functions (although the relevant RFC are listed as informative references with no references in this draft to them:-). So is BGP security looking at the scope of BGP as defined in this basic document (give or take some operator licence with prepending or aggregation); or at the scope of BGP as defined in a much wider set of RFC and I-D? If the latter, which documents are included? _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Jan 26 20:30: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 UAA14391 for ; Wed, 26 Jan 2005 20:30:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctylj-0002dJ-8a for rpsec-web-archive@ietf.org; Wed, 26 Jan 2005 20: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 1CtyO6-00016Y-Tg; Wed, 26 Jan 2005 20:23:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtyJc-0000J7-2d for rpsec@megatron.ietf.org; Wed, 26 Jan 2005 20:19: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 UAA12289 for ; Wed, 26 Jan 2005 20:19:18 -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 1Ctyab-0002Kq-00 for rpsec@ietf.org; Wed, 26 Jan 2005 20:36:55 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j0R1J6KN002425; Thu, 27 Jan 2005 01:19:06 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j0R1J5jO002422; Thu, 27 Jan 2005 01:19:05 GMT Date: Thu, 27 Jan 2005 01:19:05 +0000 From: bmanning@vacation.karoshi.com To: Tom Petch Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050127011905.GC1809@vacation.karoshi.com.> References: <00a301c503fb$21192da0$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a301c503fb$21192da0$0601a8c0@pc6> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: rpsec@ietf.org, Susan Hares X-BeenThere: rpsec@ietf.org 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: 97adf591118a232206bdb5a27b217034 > > " This specification covers only the exchange of IP version 4 network > > reachability information." > > > > Which seems to state that all the other uses for BGP are not covered under > > the draft. Is that true? > > Yes. > > I think this is a key point. Look hard and you will not find Confederations, > Route Reflectors, VPNs, Communities, IPv6, Route Flap Damping etc etc etc in > this draft, all very valid aspects of BGP. The aim of this draft does not > include those functions (although the relevant RFC are listed as informative > references with no references in this draft to them:-). > > So is BGP security looking at the scope of BGP as defined in this basic document > (give or take some operator licence with prepending or aggregation); or at the > scope of BGP as defined in a much wider set of RFC and I-D? If the latter, > which documents are included? it would seem best to stay tightly focused on the core spec, since new stuff is allowed (and used to be encouraged) to emerge to deal w/ changing situations... like the short list above! > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 27 08:02:20 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 IAA28621 for ; Thu, 27 Jan 2005 08:02:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu9Z5-0001hQ-RT for rpsec-web-archive@ietf.org; Thu, 27 Jan 2005 08:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu9Df-0001qk-H7; Thu, 27 Jan 2005 07:57:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu9Bb-0001Mn-Du for rpsec@megatron.ietf.org; Thu, 27 Jan 2005 07:55: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 HAA28067 for ; Thu, 27 Jan 2005 07:55:45 -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 1Cu9Sh-0001ZH-6G for rpsec@ietf.org; Thu, 27 Jan 2005 08:13:29 -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 j0RCt69T001225 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Thu, 27 Jan 2005 07:55:07 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 27 Jan 2005 07:54:58 -0500 Subject: Re: [RPSEC] proposed message to the IESG From: Blaine Christian To: , Tom Petch Message-ID: In-Reply-To: <20050127011905.GC1809@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: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org, Susan Hares X-BeenThere: rpsec@ietf.org 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 On 1/26/05 8:19 PM, "bmanning@vacation.karoshi.com" wrote: >>> " This specification covers only the exchange of IP version 4 network >>> reachability information." >>> >>> Which seems to state that all the other uses for BGP are not covered under >>> the draft. Is that true? >> >> Yes. >> >> I think this is a key point. Look hard and you will not find Confederations, >> Route Reflectors, VPNs, Communities, IPv6, Route Flap Damping etc etc etc in >> this draft, all very valid aspects of BGP. The aim of this draft does not >> include those functions (although the relevant RFC are listed as informative >> references with no references in this draft to them:-). >> >> So is BGP security looking at the scope of BGP as defined in this basic >> document >> (give or take some operator licence with prepending or aggregation); or at >> the >> scope of BGP as defined in a much wider set of RFC and I-D? If the latter, >> which documents are included? > > it would seem best to stay tightly focused on the core spec, > since new stuff is allowed (and used to be encouraged) to emerge > to deal w/ changing situations... like the short list above! > I am comfortable with that... But we have actually left the language in the requirements doc much more open WRT BGP. The document actually went under one revision where it was about inter-domain routing not BGP specifically. Does anyone have thoughts on wording to the effect that, for the purposes of the document, we come up with a term that represents a network that could be comprised of multiple AS's? I think the new term could reference AS as it's progenitor but might more accurately characterize the current environment. Of specific interest are the private AS space bits since the private AS space is used internally in many networks. But it may be worth reviewing whether a group of public AS numbers would be appropriate to group together under the "one key one network" thought. Also, the one "standout" in the list Tom presented was IPv6. IPv6 is one of the few, in my opinion, that has odds of being globally transitive like IPv4. The rest of the bits mentioned are likely to be local and remain so. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 27 09:38: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 JAA10705 for ; Thu, 27 Jan 2005 09:38:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuB4T-0004dz-LC for rpsec-web-archive@ietf.org; Thu, 27 Jan 2005 09:56:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuAdT-0000yV-7u; Thu, 27 Jan 2005 09:28:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuAaX-0007zp-FB for rpsec@megatron.ietf.org; Thu, 27 Jan 2005 09:25:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09339 for ; Thu, 27 Jan 2005 09:25:35 -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 1CuArf-0004HM-Cc for rpsec@ietf.org; Thu, 27 Jan 2005 09:43:20 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 0BCDA2D4A4A; Thu, 27 Jan 2005 09:25:05 -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 27679-01-99; Thu, 27 Jan 2005 09:25:03 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id E9EBC2D4A1D; Thu, 27 Jan 2005 09:25:02 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0REOvQ13607; Thu, 27 Jan 2005 09:24:57 -0500 (EST) Date: Thu, 27 Jan 2005 09:24:57 -0500 From: Jeffrey Haas To: Blaine Christian Subject: Re: [RPSEC] proposed message to the IESG Message-ID: <20050127142457.GW5850@nexthop.com> References: <20050127011905.GC1809@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.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: rpsec@ietf.org, bmanning@vacation.karoshi.com, Tom Petch , Susan Hares X-BeenThere: rpsec@ietf.org 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, Jan 27, 2005 at 07:54:58AM -0500, Blaine Christian wrote: > Also, the one "standout" in the list Tom presented was IPv6. IPv6 is one of > the few, in my opinion, that has odds of being globally transitive like > IPv4. The rest of the bits mentioned are likely to be local and remain so. The pairing of NLRI with path attributes is still, in both IPv4 and IPv6, the thing that we're trying to secure. The one bit of implementation (and thus solution-specific) based kinkiness is that anything besides IPv4 unicast reachability (and not always then) is represented as a field in the path attributes. Confederations are a possible sticky point when you have more than one "internal" entity that wants to run secured ebgp in the confederation. Our requirements shouldn't preclude this. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 27 10:13:17 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 KAA15358 for ; Thu, 27 Jan 2005 10:13:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuBbm-0005iS-2q for rpsec-web-archive@ietf.org; Thu, 27 Jan 2005 10:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuBDu-0005Mq-99; Thu, 27 Jan 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 1CuB95-0002zS-G5 for rpsec@megatron.ietf.org; Thu, 27 Jan 2005 10:01: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 KAA13115 for ; Thu, 27 Jan 2005 10:01:16 -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 1CuBQC-0005JR-MM for rpsec@ietf.org; Thu, 27 Jan 2005 10:19:01 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id A547E2D4DE3 for ; Thu, 27 Jan 2005 10:00:42 -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 31486-01-19 for ; Thu, 27 Jan 2005 10:00:40 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id C773C2D4ABB for ; Thu, 27 Jan 2005 10:00:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RPSEC] proposed message to the IESG Date: Thu, 27 Jan 2005 10:00:32 -0500 Message-ID: Thread-Topic: [RPSEC] proposed message to the IESG Thread-Index: AcUEDjvwCX+Wca7eSaOMsRxK7UHSzAAbIWDg From: "Susan Hares" To: , "Tom Petch" X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Bill and Tom: I agree. BGP as a protocol implemented in the world includes many specifications. (AS the IDR web page will attest to).=20 BGP as an implemented protocol does include AS Confederations, Route Reflectors, VPNs, Communities, IPv6, Route Flap Damping. (etc). Any plans to focus on a secure BGP that does not support current operational BGP would find itself limited in it's deployment.=20 Sue -----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com]=20 Sent: Wednesday, January 26, 2005 8:19 PM To: Tom Petch Cc: Blaine Christian; Susan Hares; rpsec@ietf.org Subject: Re: [RPSEC] proposed message to the IESG > > " This specification covers only the exchange of IP version 4 network > > reachability information." > > > > Which seems to state that all the other uses for BGP are not covered under > > the draft. Is that true? >=20 > Yes. >=20 > I think this is a key point. Look hard and you will not find Confederations, > Route Reflectors, VPNs, Communities, IPv6, Route Flap Damping etc etc etc in > this draft, all very valid aspects of BGP. The aim of this draft does not > include those functions (although the relevant RFC are listed as informative > references with no references in this draft to them:-). >=20 > So is BGP security looking at the scope of BGP as defined in this basic document > (give or take some operator licence with prepending or aggregation); or at the > scope of BGP as defined in a much wider set of RFC and I-D? If the latter, > which documents are included? it would seem best to stay tightly focused on the core spec, since new stuff is allowed (and used to be encouraged) to emerge to deal w/ changing situations... like the short list above! >=20 >=20 > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 27 10:46: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 KAA20640 for ; Thu, 27 Jan 2005 10:46:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuC8D-0006il-I0 for rpsec-web-archive@ietf.org; Thu, 27 Jan 2005 11:04:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuBkJ-0002gG-Ad; Thu, 27 Jan 2005 10:39:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuBZO-0007Yu-N4 for rpsec@megatron.ietf.org; Thu, 27 Jan 2005 10:28: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 KAA18061 for ; Thu, 27 Jan 2005 10:28:27 -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 1CuBqX-0006Br-9c for rpsec@ietf.org; Thu, 27 Jan 2005 10:46:13 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id AD3B32D4CEA; Thu, 27 Jan 2005 10:25:47 -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 34110-01-10; Thu, 27 Jan 2005 10:25:46 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 81A192D4C74; Thu, 27 Jan 2005 10:25:46 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0RFPka13785; Thu, 27 Jan 2005 10:25:46 -0500 (EST) Date: Thu, 27 Jan 2005 10:25:46 -0500 From: Jeffrey Haas To: Russ White Subject: Re: [RPSEC] Situation with BGP security reqs draft Message-ID: <20050127152546.GZ5850@nexthop.com> References: <706348933.20050125183426@psg.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: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Alex Zinin , 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: 4d87d2aa806f79fed918a62e834505ca On Wed, Jan 26, 2005 at 12:56:51AM -0500, Russ White wrote: > In order to start this portion of the discussion, I _think_ the two > wordings currently proposed for the meaning of "secure the AS Path" are: > > -- 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. > > -- 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. I think these cover the points quite well. > -- 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. Agreed (caveats on the proxy aggregation case). > [-] OR [-] > > -- A BGP speaker MUST, on receiving a route from a peer, be able to > verify the routing information has passed through every pair wise > peering relationship listed in the AS Path attribute. This MUST is stronger than the SHOULD in your first point cited at the top of this mail. Also, that first point cited notes that we want include "information which can be used to verify..." whereas this one cites the AS_PATH. I personally think the AS_PATH covers much of this capability. However, to be clear for the requirements, the "information which can be used to verify" is closer to what I think we mean. Securing the AS_PATH, like securing the other path attributes, will likely be a goal, depending on what we mean by securing path attributes. However, the goal of preventing against man in the middle attacks is what I think we actually want out of this functionality. > Russ -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 27 10:48:36 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 KAA20843 for ; Thu, 27 Jan 2005 10:48:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuCA1-0006mQ-Ma for rpsec-web-archive@ietf.org; Thu, 27 Jan 2005 11:06:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuBkq-0002uI-1x; Thu, 27 Jan 2005 10:40:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuBc0-0008WC-3j for rpsec@megatron.ietf.org; Thu, 27 Jan 2005 10:31: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 KAA18524 for ; Thu, 27 Jan 2005 10:31:09 -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 1CuBt8-0006G3-QN for rpsec@ietf.org; Thu, 27 Jan 2005 10:48:55 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 61B072D49F8; Thu, 27 Jan 2005 10:30:36 -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 33653-02-66; Thu, 27 Jan 2005 10:30:33 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 5EF332D5191; Thu, 27 Jan 2005 10:30:33 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0RFUX213806; Thu, 27 Jan 2005 10:30:33 -0500 (EST) Date: Thu, 27 Jan 2005 10:30:33 -0500 From: Jeffrey Haas To: Stefan Mink Subject: Re: [RPSEC] Situation with BGP security reqs draft Message-ID: <20050127153032.GA5850@nexthop.com> References: <706348933.20050125183426@psg.com> <41F790EB.1030700@schlund.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41F790EB.1030700@schlund.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Alex Zinin , 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.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 On Wed, Jan 26, 2005 at 01:45:31PM +0100, Stefan Mink wrote: > A "secure AS path" is > > a) "authentic": > It MUST be verifyable who did which change to the > attribute. This includes "complete": deletion of > items can be detected and can be made visible. > (may be this should be generalized to the entire > route so no special treatment of the as-path > attribute is necessary) I think what you mean here is a form of integrity check. I'm somewhat concerned from an implementation standpoint that common changes will make integrity a hard thing to do. For example, the deletion of communities. > b) "authorized": > b1) It MUST be verifyable that the first AS in the path > was authorized to enter it into the internet routing > table ("origin authorization") > b2) It MUST be verifyable that each AS on the path > was authorized to use the route, i.e. the preceding AS > intentively announced the route to exactly this AS. > ("usage authorization") I agree with this two checks. I don't think authorized is the right word here. > b3) It SHOULD be verifyable that each party on the path > was authorized to readvertise the route to exactly > the next AS. ("transit authorization") I don't think we want to try to put this into the draft, based on your clarification message. This is not currently a feature of BGP. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Jan 27 12:19:10 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 MAA01732 for ; Thu, 27 Jan 2005 12:19:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuDZg-0000so-OC for rpsec-web-archive@ietf.org; Thu, 27 Jan 2005 12:36:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuD6n-0000la-Sn; Thu, 27 Jan 2005 12:07:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuCvL-0005on-9i for rpsec@megatron.ietf.org; Thu, 27 Jan 2005 11:55: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 LAA28809 for ; Thu, 27 Jan 2005 11:55:12 -0500 (EST) Received: from mxintern.kundenserver.de ([212.227.126.204] helo=mxintern.schlund.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuDCS-0000DA-Ux for rpsec@ietf.org; Thu, 27 Jan 2005 12:12:59 -0500 Received: from [172.17.16.31] (helo=[172.17.16.31]) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1CuCvF-0002yI-QD; Thu, 27 Jan 2005 17:55:10 +0100 Message-ID: <41F91CEB.8000005@schlund.net> Date: Thu, 27 Jan 2005 17:55:07 +0100 From: Stefan Mink User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Haas Subject: Re: [RPSEC] Situation with BGP security reqs draft References: <706348933.20050125183426@psg.com> <41F790EB.1030700@schlund.net> <20050127153032.GA5850@nexthop.com> In-Reply-To: <20050127153032.GA5850@nexthop.com> 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: a2c12dacc0736f14d6b540e805505a86 Cc: Alex Zinin , rpsec@ietf.org, Russ White X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1632944015==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1632944015== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEBA3B56AF60F18FF699EBA2F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEBA3B56AF60F18FF699EBA2F Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jeffrey, Jeffrey Haas wrote: > On Wed, Jan 26, 2005 at 01:45:31PM +0100, Stefan Mink wrote: >>A "secure AS path" is >> >>a) "authentic": >> It MUST be verifyable who did which change to the >> attribute. This includes "complete": deletion of >> items can be detected and can be made visible. >> (may be this should be generalized to the entire >> route so no special treatment of the as-path >> attribute is necessary) > > > I think what you mean here is a form of integrity check. an authenticity check always includes an integrity check, doesn't it? the difference is, you can not only see that the data is integer, but also who sent it. Authenticity is always connected to an identity (name or key). > I'm somewhat concerned from an implementation standpoint that common > changes will make integrity a hard thing to do. For example, the > deletion of communities. definitely! Every deletion/modification of attributes, that is not somehow reproducable from the data in the attributes, makes this check impossible. That's one of the reasons why S-BGP is complex. But without that check, you blindly accept data... >>b) "authorized": >> b1) It MUST be verifyable that the first AS in the path >> was authorized to enter it into the internet routing >> table ("origin authorization") >> b2) It MUST be verifyable that each AS on the path >> was authorized to use the route, i.e. the preceding AS >> intentively announced the route to exactly this AS. >> ("usage authorization") > > > I agree with this two checks. I don't think authorized is the right > word here. it's a question: allowed or not? This is usually called authorization check, but since I'm not a native english speaker, I'm open to proposals :) >> b3) It SHOULD be verifyable that each party on the path >> was authorized to readvertise the route to exactly >> the next AS. ("transit authorization") > > > I don't think we want to try to put this into the draft, based on > your clarification message. This is not currently a feature of BGP. for me, all authorization checks are outside of BGP, because BGP itself can't handle them naturally. External data sources supporting BGP are necessary. I don't see a difference here between origin authorization (based e.g. on IRR data) and transit authorization (based on contract data between providers). On the other side, without authorization checks, _IDR_ can not be secured. We can discuss if these checks are necessary to secure the _BGP protocol_. I must concede that I have problems to draw a clear line between these topics... tschuess Stefan -- Stefan Mink, Schlund+Partner AG (AS 8560) Primary key fingerprint: 389E 5DC9 751F A6EB B974 DC3F 7A1B CF62 F0D4 D2BA --------------enigEBA3B56AF60F18FF699EBA2F 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 iD8DBQFB+RzuehvPYvDU0roRAql/AKCJcu3EXzr90dWrzMOsZ/dFaNPLewCgj91Q +QFvJxkHgDyC6+dqRNjIdok= =ZoGZ -----END PGP SIGNATURE----- --------------enigEBA3B56AF60F18FF699EBA2F-- --===============1632944015== 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 --===============1632944015==-- From rpsec-bounces@ietf.org Thu Jan 27 12:22: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 MAA02345 for ; Thu, 27 Jan 2005 12:22:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuDcx-00012O-GN for rpsec-web-archive@ietf.org; Thu, 27 Jan 2005 12:40:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDI5-0006i9-Q8; Thu, 27 Jan 2005 12:18:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuD5N-0000Iw-M2 for rpsec@megatron.ietf.org; Thu, 27 Jan 2005 12:05:38 -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 MAA00054 for ; Thu, 27 Jan 2005 12:05:34 -0500 (EST) Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuDMV-0000TO-8B for rpsec@ietf.org; Thu, 27 Jan 2005 12:23:21 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with SMTP id j0RH4xPT010018; Thu, 27 Jan 2005 12:04:59 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by testing.research.panasonic.com (Postfix) with ESMTP id 40B2D3C8184; Thu, 27 Jan 2005 12:02:41 -0500 (EST) Received: from Brijesh2K (dhcp251.Research.Panasonic.COM [150.169.1.251])by redwood.research.panasonic.com (Postfix) with SMTP id 36BF73C817F; Thu, 27 Jan 2005 12:02:41 -0500 (EST) From: "Brijesh Kumar" To: Subject: RE: [RPSEC] proposed message to the IESG Date: Thu, 27 Jan 2005 12:09:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-imss-version: 2.8 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:21 M:0 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: bmanning@vacation.karoshi.com, Tom Petch , Susan Hares X-BeenThere: rpsec@ietf.org 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: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit I briefly looked at the draft - I too was wondering what is this draft trying to accomplish. It was n't very clear to me. I did some work way back on routing security ( Integration of security in network routing protocols Source ACM SIGSAC Review archive Volume 11 , Issue 2 Spring 1993, and Integrating security in inter-domain routing protocols Source ACM SIGCOMM Computer Communication Review archive Volume 23 , Issue 5 (October 1993)), and of course things have changed since then, but any discussion for routing protocol security still has only two aspects to it: 1. Subverted links 2. Subverted nodes (including byzantine failures, misconfugrations). Link security is n't an issue with the current version of BGP+MD5/SSL-TCP. Except, proposing mechanisms for subverted nodes, and misconfigurations, I don't see what else can comeout of this draft in terms of any solution. So unless, requirements discuss all BGP features like AS Confederations, Route Reflectors, VPNs, Communities, IPv6, Route Flap Damping, Like Sue, I too don't see how these requirements can be deemed complete. --bk > -----Original Message----- > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org]On Behalf Of > Susan Hares > Sent: Thursday, January 27, 2005 10:01 AM > To: bmanning@vacation.karoshi.com; Tom Petch > Cc: rpsec@ietf.org > Subject: RE: [RPSEC] proposed message to the IESG > > > Bill and Tom: > > I agree. BGP as a protocol implemented in the world includes many > specifications. (AS the IDR web page will attest to). > > BGP as an implemented protocol does include AS Confederations, > Route Reflectors, VPNs, Communities, IPv6, Route Flap Damping. (etc). > > Any plans to focus on a secure BGP that does not support current > operational BGP would find itself limited in it's deployment. > > Sue > > > -----Original Message----- > From: bmanning@vacation.karoshi.com > [mailto:bmanning@vacation.karoshi.com] > Sent: Wednesday, January 26, 2005 8:19 PM > To: Tom Petch > Cc: Blaine Christian; Susan Hares; rpsec@ietf.org > Subject: Re: [RPSEC] proposed message to the IESG > > > > " This specification covers only the exchange of IP version 4 > network > > > reachability information." > > > > > > Which seems to state that all the other uses for BGP are not covered > under > > > the draft. Is that true? > > > > Yes. > > > > I think this is a key point. Look hard and you will not find > Confederations, > > Route Reflectors, VPNs, Communities, IPv6, Route Flap Damping etc etc > etc in > > this draft, all very valid aspects of BGP. The aim of this draft does > not > > include those functions (although the relevant RFC are listed as > informative > > references with no references in this draft to them:-). > > > > So is BGP security looking at the scope of BGP as defined in this > basic document > > (give or take some operator licence with prepending or aggregation); > or at the > > scope of BGP as defined in a much wider set of RFC and I-D? If the > latter, > > which documents are included? > > it would seem best to stay tightly focused on the core spec, > since new stuff is allowed (and used to be encouraged) to emerge > to deal w/ changing situations... like the short list above! > > > > > > > _______________________________________________ > > RPSEC mailing list > > RPSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/rpsec > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Jan 29 12:26: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 MAA24999 for ; Sat, 29 Jan 2005 12:26:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cuwdz-00081S-U8 for rpsec-web-archive@ietf.org; Sat, 29 Jan 2005 12:44:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuwKQ-0005OH-Bp; Sat, 29 Jan 2005 12:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuwHf-0004pL-U7 for rpsec@megatron.ietf.org; Sat, 29 Jan 2005 12:21: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 MAA24650 for ; Sat, 29 Jan 2005 12:21:17 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuwZF-0007ti-JB for rpsec@ietf.org; Sat, 29 Jan 2005 12:39:30 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 29 Jan 2005 09:21:12 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j0THKiRO026745; Sat, 29 Jan 2005 09:20:45 -0800 (PST) Received: from boraw2k05 ([10.32.241.196]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AVZ85088; Sat, 29 Jan 2005 09:20:42 -0800 (PST) Message-Id: <200501291720.AVZ85088@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'Brijesh Kumar'" , Subject: Purpose of the BGP req draft (RE: [RPSEC] proposed message to the IESG) Date: Sat, 29 Jan 2005 09:20:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcUElPV5KUVnNFqhRhqgSrjQjsb32QBkC+1g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit Cc: bmanning@vacation.karoshi.com, "'Tom Petch'" , "'Susan Hares'" X-BeenThere: rpsec@ietf.org 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: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit I will try to address your question. The requirements document tries to address two primary issues: 1) Is the originator of an address range (prefix) authorized to advertise that address range. 2) When router A in a given AS receives a BGP Update message in which there exists an AS_PATH object, does the information contained in __that__ object appear to be authentic. While we did include the transport security in there, that is not the main concern of the draft. The arguments about the draft center on three areas: -- In (1) above what exactly does "authorized" mean? Although, I think this is the least contentious of all. Where I think all agree on the purpose, but there are technical details that need to be ironed out. -- In (2) lies the contention. One could achieve (2) in at least two ways: -- Using out of band information to construct a verification database via which the incoming AS_PATH information can be verified from -- By explicitly "signing" the AS_PATH at every BGP speaker that is on that path. Note that I put "signing" in quotes, because it is more than just appending a signature to each iteration of the AS_PATH, it also requires addition of other fields. Note that (1) and (2) above address the byzantine node problem, but they also address a lot more than that. What (1) and (2) do not address is a bgp blackhole that supresses a set of advertisements that are supposed to go through it but do not. Transport security is nice to have, but really, all we need out of transport is to guarantee the integrity of messages on a hop-by-hop basis. Bora > -----Original Message----- > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] > On Behalf Of Brijesh Kumar > Sent: Thursday, January 27, 2005 9:10 AM > To: rpsec@ietf.org > Cc: bmanning@vacation.karoshi.com; Tom Petch; Susan Hares > Subject: RE: [RPSEC] proposed message to the IESG > > > I briefly looked at the draft - I too was wondering what is > this draft trying to accomplish. It was n't very clear to me. > > I did some work way back on routing security ( Integration of > security in network routing protocols > Source ACM SIGSAC Review archive Volume 11 , Issue 2 Spring 1993, > and Integrating security in inter-domain routing protocols > Source ACM SIGCOMM Computer Communication Review archive > Volume 23 , Issue 5 (October 1993)), and of course things > have changed since then, but any discussion for routing > protocol security still has only two aspects to it: 1. > Subverted links 2. Subverted nodes (including byzantine > failures, misconfugrations). > > Link security is n't an issue with the current version of > BGP+MD5/SSL-TCP. Except, proposing mechanisms for subverted nodes, and > misconfigurations, I don't see what else can comeout of this > draft in terms of any solution. > > So unless, requirements discuss all BGP features like AS > Confederations, Route Reflectors, VPNs, Communities, IPv6, > Route Flap Damping, Like Sue, I too don't see how these > requirements can be deemed complete. > > > --bk > > > > > -----Original Message----- > > From: rpsec-bounces@ietf.org > [mailto:rpsec-bounces@ietf.org]On Behalf Of > > Susan Hares > > Sent: Thursday, January 27, 2005 10:01 AM > > To: bmanning@vacation.karoshi.com; Tom Petch > > Cc: rpsec@ietf.org > > Subject: RE: [RPSEC] proposed message to the IESG > > > > > > Bill and Tom: > > > > I agree. BGP as a protocol implemented in the world includes many > > specifications. (AS the IDR web page will attest to). > > > > BGP as an implemented protocol does include AS Confederations, > > Route Reflectors, VPNs, Communities, IPv6, Route Flap > Damping. (etc). > > > > Any plans to focus on a secure BGP that does not support current > > operational BGP would find itself limited in it's deployment. > > > > Sue > > > > > > -----Original Message----- > > From: bmanning@vacation.karoshi.com > > [mailto:bmanning@vacation.karoshi.com] > > Sent: Wednesday, January 26, 2005 8:19 PM > > To: Tom Petch > > Cc: Blaine Christian; Susan Hares; rpsec@ietf.org > > Subject: Re: [RPSEC] proposed message to the IESG > > > > > > " This specification covers only the exchange of IP version 4 > > network > > > > reachability information." > > > > > > > > Which seems to state that all the other uses for BGP > are not covered > > under > > > > the draft. Is that true? > > > > > > Yes. > > > > > > I think this is a key point. Look hard and you will not find > > Confederations, > > > Route Reflectors, VPNs, Communities, IPv6, Route Flap > Damping etc etc > > etc in > > > this draft, all very valid aspects of BGP. The aim of > this draft does > > not > > > include those functions (although the relevant RFC are listed as > > informative > > > references with no references in this draft to them:-). > > > > > > So is BGP security looking at the scope of BGP as defined in this > > basic document > > > (give or take some operator licence with prepending or > aggregation); > > or at the > > > scope of BGP as defined in a much wider set of RFC and > I-D? If the > > latter, > > > which documents are included? > > > > it would seem best to stay tightly focused on the core spec, > > since new stuff is allowed (and used to be > encouraged) to emerge > > to deal w/ changing situations... like the short list above! > > > > > > > > > > > _______________________________________________ > > > RPSEC mailing list > > > RPSEC@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > > > > _______________________________________________ > > RPSEC mailing list > > RPSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/rpsec > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Jan 29 14:09: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 OAA04410 for ; Sat, 29 Jan 2005 14:09:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuyG2-0001up-Uo for rpsec-web-archive@ietf.org; Sat, 29 Jan 2005 14:27:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuxx3-0007Lx-BH; Sat, 29 Jan 2005 14:08:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuxv5-00072V-Go for rpsec@megatron.ietf.org; Sat, 29 Jan 2005 14:06: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 OAA04301 for ; Sat, 29 Jan 2005 14:06:06 -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 1CuyCf-0001rU-Tn for rpsec@ietf.org; Sat, 29 Jan 2005 14:24:18 -0500 Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by karoshi.com (8.12.8/8.12.8) with ESMTP id j0TJ5vKN017068; Sat, 29 Jan 2005 19:05:57 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id j0TJ5uxk017065; Sat, 29 Jan 2005 19:05:56 GMT Date: Sat, 29 Jan 2005 19:05:56 +0000 From: bmanning@vacation.karoshi.com To: Bora Akyol Subject: Re: Purpose of the BGP req draft (RE: [RPSEC] proposed message to the IESG) Message-ID: <20050129190556.GB16819@vacation.karoshi.com.> References: <200501291720.AVZ85088@mira-sjc5-e.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501291720.AVZ85088@mira-sjc5-e.cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: rpsec@ietf.org, bmanning@vacation.karoshi.com, "'Tom Petch'" , "'Brijesh Kumar'" , "'Susan Hares'" X-BeenThere: rpsec@ietf.org 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: 0bc60ec82efc80c84b8d02f4b0e4de22 On Sat, Jan 29, 2005 at 09:20:42AM -0800, Bora Akyol wrote: > The requirements document tries to address two primary issues: > > 1) Is the originator of an address range (prefix) authorized to > advertise that address range. > > -- In (1) above what exactly does "authorized" mean? Although, I think > this is the least contentious of all. Where I think all agree on the > purpose, but there are technical details that need to be ironed out. > > Bora authorized ... by whom? ... by what methods? presuming one "handwaves" over these thorny, non-technical points, one has to ask how a prefix-holder, in collaberation with the AS-holder, will present such bonafides to the RPSEC engine(s)? then one can worry about your option #2. ... at least imho. --bill _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Jan 30 23:19: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 XAA00651 for ; Sun, 30 Jan 2005 23:19:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvTJu-0000Kc-S8 for rpsec-web-archive@ietf.org; Sun, 30 Jan 2005 23:37:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvSsk-0005Ab-Hk; Sun, 30 Jan 2005 23:09:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvSoF-0004HV-9i for rpsec@megatron.ietf.org; Sun, 30 Jan 2005 23:05: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 XAA29311 for ; Sun, 30 Jan 2005 23:05:04 -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 1CvT66-0008QM-JA for rpsec@ietf.org; Sun, 30 Jan 2005 23:23:35 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j0V452Ze018832 for ; Sun, 30 Jan 2005 23:05:02 -0500 (EST) Received: from tauberpc.llan.ll.mit.edu( ), claiming to be "LEN-Overlook.llan.ll.mit.edu" via SMTP by llpost, id smtpdAAAiMaiUK; Sun Jan 30 23:04:56 2005 Date: Sun, 30 Jan 2005 23:04:56 -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: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [RPSEC] Generic Threats Draft WG Last Call X-BeenThere: rpsec@ietf.org 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: de4f315c9369b71d7dd5909b42224370 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 Jan 31 08:22: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 IAA28428 for ; Mon, 31 Jan 2005 08:22:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvbnN-0003AC-H4 for rpsec-web-archive@ietf.org; Mon, 31 Jan 2005 08:40:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvbSj-0000Si-UQ; Mon, 31 Jan 2005 08:19:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvbM2-0007IS-M2 for rpsec@megatron.ietf.org; Mon, 31 Jan 2005 08:12: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 IAA25951 for ; Mon, 31 Jan 2005 08:12:32 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvbdy-0002o9-CG for rpsec@ietf.org; Mon, 31 Jan 2005 08:31:06 -0500 Received: from pc6 (1Cust150.tnt9.lnd4.gbr.da.uu.net [62.188.138.150]) by blaster.systems.pipex.net (Postfix) with SMTP id 48330E000222; Mon, 31 Jan 2005 13:11:41 +0000 (GMT) Message-ID: <037401c5078d$c8dc6f80$0601a8c0@pc6> From: "Tom Petch" To: "Bora Akyol" , References: <200501291720.AVZ85088@mira-sjc5-e.cisco.com> Subject: Re: Purpose of the BGP req draft (RE: [RPSEC] proposed message to the IESG) Date: Mon, 31 Jan 2005 13:05:26 +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: a8041eca2a724d631b098c15e9048ce9 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: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: 7bit Bora I think there is another aspect of this that needs to be nailed down. Does it cover Multi-Protocol Extensions? The implication of some posts recently is yes, in which case, which? Does it cover communities? Ditto, ditto ie all or some only in which case, which? And then there are other smaller topics like Graceful Restart, Capabilities, Route Flap Damping etc, etc. I am not very good at spotting loopholes through which the malicious can launch DoS attacks but I suspect that most of the I-D and RFC listed on the IDR charter web page could form the basis of an attack and should either be explicitly included or excluded in the scope of this work ie should be mentioned in your draft. Tom Petch ----- Original Message ----- From: "Bora Akyol" To: "'Brijesh Kumar'" ; Cc: ; "'Tom Petch'" ; "'Susan Hares'" Sent: Saturday, January 29, 2005 6:20 PM Subject: Purpose of the BGP req draft (RE: [RPSEC] proposed message to the IESG) > I will try to address your question. > > The requirements document tries to address two primary issues: > > 1) Is the originator of an address range (prefix) authorized to > advertise that address range. > > 2) When router A in a given AS receives a BGP Update message in which there > exists an AS_PATH object, does the information contained in __that__ object > appear to be authentic. > > While we did include the transport security in there, that is not the main > concern of the draft. > > The arguments about the draft center on three areas: > > -- In (1) above what exactly does "authorized" mean? Although, I think > this is the least contentious of all. Where I think all agree on the > purpose, but there are technical details that need to be ironed out. > -- In (2) lies the contention. One could achieve (2) in at least two ways: > -- Using out of band information to construct a verification > database via which the incoming AS_PATH information can be verified from > -- By explicitly "signing" the AS_PATH at every BGP speaker that is > on that path. > Note that I put "signing" in quotes, because it is more than just > appending a signature to each iteration of the AS_PATH, it also requires > addition of other fields. > > > Note that (1) and (2) above address the byzantine node problem, but they > also address a lot more than that. > > What (1) and (2) do not address is a bgp blackhole that supresses a set of > advertisements > that are supposed to go through it but do not. > > Transport security is nice to have, but really, all we need out of transport > is to guarantee the integrity of messages on a hop-by-hop basis. > > Bora > > > > -----Original Message----- > > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] > > On Behalf Of Brijesh Kumar > > Sent: Thursday, January 27, 2005 9:10 AM > > To: rpsec@ietf.org > > Cc: bmanning@vacation.karoshi.com; Tom Petch; Susan Hares > > Subject: RE: [RPSEC] proposed message to the IESG > > > > > > I briefly looked at the draft - I too was wondering what is > > this draft trying to accomplish. It was n't very clear to me. > > > > I did some work way back on routing security ( Integration of > > security in network routing protocols > > Source ACM SIGSAC Review archive Volume 11 , Issue 2 Spring 1993, > > and Integrating security in inter-domain routing protocols > > Source ACM SIGCOMM Computer Communication Review archive > > Volume 23 , Issue 5 (October 1993)), and of course things > > have changed since then, but any discussion for routing > > protocol security still has only two aspects to it: 1. > > Subverted links 2. Subverted nodes (including byzantine > > failures, misconfugrations). > > > > Link security is n't an issue with the current version of > > BGP+MD5/SSL-TCP. Except, proposing mechanisms for subverted nodes, and > > misconfigurations, I don't see what else can comeout of this > > draft in terms of any solution. > > > > So unless, requirements discuss all BGP features like AS > > Confederations, Route Reflectors, VPNs, Communities, IPv6, > > Route Flap Damping, Like Sue, I too don't see how these > > requirements can be deemed complete. > > > > > > --bk > > > > > > > > > -----Original Message----- > > > From: rpsec-bounces@ietf.org > > [mailto:rpsec-bounces@ietf.org]On Behalf Of > > > Susan Hares > > > Sent: Thursday, January 27, 2005 10:01 AM > > > To: bmanning@vacation.karoshi.com; Tom Petch > > > Cc: rpsec@ietf.org > > > Subject: RE: [RPSEC] proposed message to the IESG > > > > > > > > > Bill and Tom: > > > > > > I agree. BGP as a protocol implemented in the world includes many > > > specifications. (AS the IDR web page will attest to). > > > > > > BGP as an implemented protocol does include AS Confederations, > > > Route Reflectors, VPNs, Communities, IPv6, Route Flap > > Damping. (etc). > > > > > > Any plans to focus on a secure BGP that does not support current > > > operational BGP would find itself limited in it's deployment. > > > > > > Sue > > > > > > > > > -----Original Message----- > > > From: bmanning@vacation.karoshi.com > > > [mailto:bmanning@vacation.karoshi.com] > > > Sent: Wednesday, January 26, 2005 8:19 PM > > > To: Tom Petch > > > Cc: Blaine Christian; Susan Hares; rpsec@ietf.org > > > Subject: Re: [RPSEC] proposed message to the IESG > > > > > > > > " This specification covers only the exchange of IP version 4 > > > network > > > > > reachability information." > > > > > > > > > > Which seems to state that all the other uses for BGP > > are not covered > > > under > > > > > the draft. Is that true? > > > > > > > > Yes. > > > > > > > > I think this is a key point. Look hard and you will not find > > > Confederations, > > > > Route Reflectors, VPNs, Communities, IPv6, Route Flap > > Damping etc etc > > > etc in > > > > this draft, all very valid aspects of BGP. The aim of > > this draft does > > > not > > > > include those functions (although the relevant RFC are listed as > > > informative > > > > references with no references in this draft to them:-). > > > > > > > > So is BGP security looking at the scope of BGP as defined in this > > > basic document > > > > (give or take some operator licence with prepending or > > aggregation); > > > or at the > > > > scope of BGP as defined in a much wider set of RFC and > > I-D? If the > > > latter, > > > > which documents are included? > > > > > > it would seem best to stay tightly focused on the core spec, > > > since new stuff is allowed (and used to be > > encouraged) to emerge > > > to deal w/ changing situations... like the short list above! > > > > > > > > > > > > > > > _______________________________________________ > > > > RPSEC mailing list > > > > RPSEC@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > > > > > > > _______________________________________________ > > > RPSEC mailing list > > > RPSEC@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > > _______________________________________________ > > RPSEC mailing list > > RPSEC@ietf.org > > https://www1.ietf.org/mailman/listinfo/rpsec > > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 31 10:18: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 KAA11042 for ; Mon, 31 Jan 2005 10:18:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvdbo-0005vt-7d for rpsec-web-archive@ietf.org; Mon, 31 Jan 2005 10:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvdHf-0003Qm-Jm; Mon, 31 Jan 2005 10:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvd4s-00088H-Uz for rpsec@megatron.ietf.org; Mon, 31 Jan 2005 10:02: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 KAA09227 for ; Mon, 31 Jan 2005 10:02:57 -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 1CvdMo-0005Vb-0F for rpsec@ietf.org; Mon, 31 Jan 2005 10:21:33 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 04EC52D4FC6; Mon, 31 Jan 2005 10:02:24 -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 36068-01-71; Mon, 31 Jan 2005 10:02:20 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [65.247.36.31]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B7D022D4FC9; Mon, 31 Jan 2005 10:02:20 -0500 (EST) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.6/8.11.6) id j0VF2Ks04034; Mon, 31 Jan 2005 10:02:20 -0500 (EST) Date: Mon, 31 Jan 2005 10:02:20 -0500 From: Jeffrey Haas To: Bora Akyol Subject: Re: Purpose of the BGP req draft (RE: [RPSEC] proposed message to the IESG) Message-ID: <20050131150220.GA3965@nexthop.com> References: <200501291720.AVZ85088@mira-sjc5-e.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501291720.AVZ85088@mira-sjc5-e.cisco.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Sat, Jan 29, 2005 at 09:20:42AM -0800, Bora Akyol wrote: > Transport security is nice to have, but really, all we need out of transport > is to guarantee the integrity of messages on a hop-by-hop basis. Not being vulnerable to remote session resets is handy too. :-) > Bora -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 31 17:33: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 RAA14400 for ; Mon, 31 Jan 2005 17:33:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkPF-0004yg-Hq for rpsec-web-archive@ietf.org; Mon, 31 Jan 2005 17:52:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvjxo-0004h4-IN; Mon, 31 Jan 2005 17:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjIs-0002c7-7m for rpsec@megatron.ietf.org; Mon, 31 Jan 2005 16:41:50 -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 QAA01459 for ; Mon, 31 Jan 2005 16:41:48 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvjas-00019m-Gm for rpsec@ietf.org; Mon, 31 Jan 2005 17:00:28 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 31 Jan 2005 13:50:10 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0VLfENt011928; Mon, 31 Jan 2005 13:41:15 -0800 (PST) Received: from boraw2k05 (dhcp-128-107-163-127.cisco.com [128.107.163.127]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AWA76708; Mon, 31 Jan 2005 13:41:13 -0800 (PST) Message-Id: <200501312141.AWA76708@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'Tom Petch'" , Subject: RE: Purpose of the BGP req draft (RE: [RPSEC] proposed message to theIESG) Date: Mon, 31 Jan 2005 13:41:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <037401c5078d$c8dc6f80$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUHmAWUeGAIFAqkRq+A6X5BH3esnAART61A X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 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: 515708a075ffdf0a79d1c83b601e2afd Content-Transfer-Encoding: 7bit Hi Tom I think Multi-Protocol should be covered, I am not sure about communities. I think the rest of the items you mention (if I understand correctly), are between two peers and should be covered by transport integrity mechanisms; that is, the information does not get sent beyond the two peers unlike reachability which gets sent across the network. Bora > -----Original Message----- > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] > On Behalf Of Tom Petch > Sent: Monday, January 31, 2005 4:05 AM > To: Bora Akyol; rpsec@ietf.org > Subject: Re: Purpose of the BGP req draft (RE: [RPSEC] > proposed message to theIESG) > > Bora > > I think there is another aspect of this that needs to be nailed down. > > Does it cover Multi-Protocol Extensions? The implication of > some posts recently is yes, in which case, which? > > Does it cover communities? Ditto, ditto ie all or some only > in which case, which? > > And then there are other smaller topics like Graceful > Restart, Capabilities, Route Flap Damping etc, etc. > > I am not very good at spotting loopholes through which the > malicious can launch DoS attacks but I suspect that most of > the I-D and RFC listed on the IDR charter web page could form > the basis of an attack and should either be explicitly > included or excluded in the scope of this work ie should be > mentioned in your draft. > > Tom Petch > > ----- Original Message ----- > From: "Bora Akyol" > To: "'Brijesh Kumar'" ; > > Cc: ; "'Tom Petch'" > ; "'Susan Hares'" > Sent: Saturday, January 29, 2005 6:20 PM > Subject: Purpose of the BGP req draft (RE: [RPSEC] proposed > message to the IESG) > > > > I will try to address your question. > > > > The requirements document tries to address two primary issues: > > > > 1) Is the originator of an address range (prefix) authorized to > > advertise that address range. > > > > 2) When router A in a given AS receives a BGP Update > message in which > > there exists an AS_PATH object, does the information contained in > > __that__ object appear to be authentic. > > > > While we did include the transport security in there, that > is not the > > main concern of the draft. > > > > The arguments about the draft center on three areas: > > > > -- In (1) above what exactly does "authorized" mean? Although, I > > think this is the least contentious of all. Where I think > all agree on > > the purpose, but there are technical details that need to > be ironed out. > > -- In (2) lies the contention. One could achieve (2) in > at least two ways: > > -- Using out of band information to construct a > verification > > database via which the incoming AS_PATH information can be > verified from > > -- By explicitly "signing" the AS_PATH at every > BGP speaker > > that is on that path. > > Note that I put "signing" in quotes, because it is > more than just > > appending a signature to each iteration of the AS_PATH, it also > > requires addition of other fields. > > > > > > Note that (1) and (2) above address the byzantine node problem, but > > they also address a lot more than that. > > > > What (1) and (2) do not address is a bgp blackhole that supresses a > > set of advertisements that are supposed to go through it but do not. > > > > Transport security is nice to have, but really, all we need out of > > transport is to guarantee the integrity of messages on a > hop-by-hop basis. > > > > Bora > > > > > > > -----Original Message----- > > > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] On > > > Behalf Of Brijesh Kumar > > > Sent: Thursday, January 27, 2005 9:10 AM > > > To: rpsec@ietf.org > > > Cc: bmanning@vacation.karoshi.com; Tom Petch; Susan Hares > > > Subject: RE: [RPSEC] proposed message to the IESG > > > > > > > > > I briefly looked at the draft - I too was wondering what is this > > > draft trying to accomplish. It was n't very clear to me. > > > > > > I did some work way back on routing security ( Integration of > > > security in network routing protocols > > > Source ACM SIGSAC Review archive Volume 11 , Issue 2 > Spring 1993, > > > and Integrating security in inter-domain routing protocols Source > > > ACM SIGCOMM Computer Communication Review archive Volume > 23 , Issue > > > 5 (October 1993)), and of course things have changed since then, > > > but any discussion for routing protocol security still > has only two > > > aspects to it: 1. > > > Subverted links 2. Subverted nodes (including byzantine failures, > > > misconfugrations). > > > > > > Link security is n't an issue with the current version of > > > BGP+MD5/SSL-TCP. Except, proposing mechanisms for > subverted nodes, > > > BGP+and > > > misconfigurations, I don't see what else can comeout of > this draft > > > in terms of any solution. > > > > > > So unless, requirements discuss all BGP features like AS > > > Confederations, Route Reflectors, VPNs, Communities, IPv6, Route > > > Flap Damping, Like Sue, I too don't see how these > requirements can > > > be deemed complete. > > > > > > > > > --bk > > > > > > > > > > > > > -----Original Message----- > > > > From: rpsec-bounces@ietf.org > > > [mailto:rpsec-bounces@ietf.org]On Behalf Of > > > > Susan Hares > > > > Sent: Thursday, January 27, 2005 10:01 AM > > > > To: bmanning@vacation.karoshi.com; Tom Petch > > > > Cc: rpsec@ietf.org > > > > Subject: RE: [RPSEC] proposed message to the IESG > > > > > > > > > > > > Bill and Tom: > > > > > > > > I agree. BGP as a protocol implemented in the world > includes many > > > > specifications. (AS the IDR web page will attest to). > > > > > > > > BGP as an implemented protocol does include AS Confederations, > > > > Route Reflectors, VPNs, Communities, IPv6, Route Flap > > > Damping. (etc). > > > > > > > > Any plans to focus on a secure BGP that does not > support current > > > > operational BGP would find itself limited in it's deployment. > > > > > > > > Sue > > > > > > > > > > > > -----Original Message----- > > > > From: bmanning@vacation.karoshi.com > > > > [mailto:bmanning@vacation.karoshi.com] > > > > Sent: Wednesday, January 26, 2005 8:19 PM > > > > To: Tom Petch > > > > Cc: Blaine Christian; Susan Hares; rpsec@ietf.org > > > > Subject: Re: [RPSEC] proposed message to the IESG > > > > > > > > > > " This specification covers only the exchange of IP > version 4 > > > > network > > > > > > reachability information." > > > > > > > > > > > > Which seems to state that all the other uses for BGP > > > are not covered > > > > under > > > > > > the draft. Is that true? > > > > > > > > > > Yes. > > > > > > > > > > I think this is a key point. Look hard and you will not find > > > > Confederations, > > > > > Route Reflectors, VPNs, Communities, IPv6, Route Flap > > > Damping etc etc > > > > etc in > > > > > this draft, all very valid aspects of BGP. The aim of > > > this draft does > > > > not > > > > > include those functions (although the relevant RFC > are listed as > > > > informative > > > > > references with no references in this draft to them:-). > > > > > > > > > > So is BGP security looking at the scope of BGP as defined in > > > > > this > > > > basic document > > > > > (give or take some operator licence with prepending or > > > aggregation); > > > > or at the > > > > > scope of BGP as defined in a much wider set of RFC and > > > I-D? If the > > > > latter, > > > > > which documents are included? > > > > > > > > it would seem best to stay tightly focused on the > core spec, > > > > since new stuff is allowed (and used to be > > > encouraged) to emerge > > > > to deal w/ changing situations... like the short > list above! > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > RPSEC mailing list > > > > > RPSEC@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > > > > > > > > > > _______________________________________________ > > > > RPSEC mailing list > > > > RPSEC@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > > > > _______________________________________________ > > > RPSEC mailing list > > > RPSEC@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 31 17: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 RAA14418 for ; Mon, 31 Jan 2005 17:33:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkPK-0004yp-LU for rpsec-web-archive@ietf.org; Mon, 31 Jan 2005 17:52:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvjxr-0004ld-5K; Mon, 31 Jan 2005 17:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjJL-0002qo-Fv for rpsec@megatron.ietf.org; Mon, 31 Jan 2005 16:42: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 QAA01595 for ; Mon, 31 Jan 2005 16:42:17 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvjbN-0001DO-7M for rpsec@ietf.org; Mon, 31 Jan 2005 17:00:57 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 31 Jan 2005 13:48:47 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0VLfhl2002725; Mon, 31 Jan 2005 13:41:43 -0800 (PST) Received: from boraw2k05 (dhcp-128-107-163-127.cisco.com [128.107.163.127]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id AWA76773; Mon, 31 Jan 2005 13:41:45 -0800 (PST) Message-Id: <200501312141.AWA76773@mira-sjc5-e.cisco.com> From: "Bora Akyol" To: "'Jeffrey Haas'" Subject: RE: Purpose of the BGP req draft (RE: [RPSEC] proposed message to theIESG) Date: Mon, 31 Jan 2005 13:41:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050131150220.GA3965@nexthop.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUHqDtBHOaF/prwSJKsUP2DH/O8yQANWHdg X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit > -----Original Message----- > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] > On Behalf Of Jeffrey Haas > Sent: Monday, January 31, 2005 7:02 AM > To: Bora Akyol > Cc: rpsec@ietf.org > Subject: Re: Purpose of the BGP req draft (RE: [RPSEC] > proposed message to theIESG) > > On Sat, Jan 29, 2005 at 09:20:42AM -0800, Bora Akyol wrote: > > Transport security is nice to have, but really, all we need out of > > transport is to guarantee the integrity of messages on a > hop-by-hop basis. > > Not being vulnerable to remote session resets is handy too. :-) > Yep, TCP does have its own set of problems, resets is one of them. Bora _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Jan 31 18:22: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 SAA21744 for ; Mon, 31 Jan 2005 18:22:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvlAM-0006kz-AN for rpsec-web-archive@ietf.org; Mon, 31 Jan 2005 18:41:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvknw-0007Cq-1D; Mon, 31 Jan 2005 18:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvkiE-0002Rj-Uw for rpsec@megatron.ietf.org; Mon, 31 Jan 2005 18:12: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 SAA20052 for ; Mon, 31 Jan 2005 18:12:04 -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 1Cvl0E-0006RD-08 for rpsec@ietf.org; Mon, 31 Jan 2005 18:30:45 -0500 Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 202282D4B45 for ; Mon, 31 Jan 2005 18:11:32 -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 80176-01-19 for ; Mon, 31 Jan 2005 18:11:28 -0500 (EST) Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id B0E752D4A60 for ; Mon, 31 Jan 2005 18:11:28 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Purpose of the BGP req draft (RE: [RPSEC] proposed message totheIESG) Date: Mon, 31 Jan 2005 18:11:28 -0500 Message-ID: Thread-Topic: Purpose of the BGP req draft (RE: [RPSEC] proposed message totheIESG) Thread-Index: AcUHmAWUeGAIFAqkRq+A6X5BH3esnAART61AAAJQWVA= From: "Susan Hares" To: "Bora Akyol" , "Tom Petch" , X-Virus-Scanned: by amavisd-new at nexthop.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Content-Transfer-Encoding: quoted-printable X-BeenThere: rpsec@ietf.org 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: 83867a50fd8f547996ccdaf89af24437 Content-Transfer-Encoding: quoted-printable Bora: Why do you not want to have BGP communities? Why not the other items - specifically: Graceful Restart or Route Reflectors or AS Confederation?=20 Are you eliminated Dynamic Capabilities because it is not widely deployed? (Mostly redback routers due to the earlier errors). Sue Hares -----Original Message----- From: Bora Akyol [mailto:bora@cisco.com]=20 Sent: Monday, January 31, 2005 4:41 PM To: 'Tom Petch'; rpsec@ietf.org Subject: RE: Purpose of the BGP req draft (RE: [RPSEC] proposed message totheIESG) Hi Tom I think Multi-Protocol should be covered, I am not sure about communities. I think=20 the rest of the items you mention (if I understand correctly), are between two peers and should be covered by transport integrity mechanisms; that is, the information does not get sent beyond the two peers unlike reachability which gets sent across the network. Bora =20 > -----Original Message----- > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org]=20 > On Behalf Of Tom Petch > Sent: Monday, January 31, 2005 4:05 AM > To: Bora Akyol; rpsec@ietf.org > Subject: Re: Purpose of the BGP req draft (RE: [RPSEC]=20 > proposed message to theIESG) >=20 > Bora >=20 > I think there is another aspect of this that needs to be nailed down. >=20 > Does it cover Multi-Protocol Extensions? The implication of=20 > some posts recently is yes, in which case, which? >=20 > Does it cover communities? Ditto, ditto ie all or some only=20 > in which case, which? >=20 > And then there are other smaller topics like Graceful=20 > Restart, Capabilities, Route Flap Damping etc, etc. >=20 > I am not very good at spotting loopholes through which the=20 > malicious can launch DoS attacks but I suspect that most of=20 > the I-D and RFC listed on the IDR charter web page could form=20 > the basis of an attack and should either be explicitly=20 > included or excluded in the scope of this work ie should be=20 > mentioned in your draft. >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Bora Akyol" > To: "'Brijesh Kumar'" ;=20 > > Cc: ; "'Tom Petch'"=20 > ; "'Susan Hares'" > Sent: Saturday, January 29, 2005 6:20 PM > Subject: Purpose of the BGP req draft (RE: [RPSEC] proposed=20 > message to the IESG) >=20 >=20 > > I will try to address your question. > > > > The requirements document tries to address two primary issues: > > > > 1) Is the originator of an address range (prefix) authorized to=20 > > advertise that address range. > > > > 2) When router A in a given AS receives a BGP Update=20 > message in which=20 > > there exists an AS_PATH object, does the information contained in=20 > > __that__ object appear to be authentic. > > > > While we did include the transport security in there, that=20 > is not the=20 > > main concern of the draft. > > > > The arguments about the draft center on three areas: > > > > -- In (1) above what exactly does "authorized" mean? Although, I=20 > > think this is the least contentious of all. Where I think=20 > all agree on=20 > > the purpose, but there are technical details that need to=20 > be ironed out. > > -- In (2) lies the contention. One could achieve (2) in=20 > at least two ways: > > -- Using out of band information to construct a=20 > verification=20 > > database via which the incoming AS_PATH information can be=20 > verified from > > -- By explicitly "signing" the AS_PATH at every=20 > BGP speaker=20 > > that is on that path. > > Note that I put "signing" in quotes, because it is=20 > more than just=20 > > appending a signature to each iteration of the AS_PATH, it also=20 > > requires addition of other fields. > > > > > > Note that (1) and (2) above address the byzantine node problem, but=20 > > they also address a lot more than that. > > > > What (1) and (2) do not address is a bgp blackhole that supresses a=20 > > set of advertisements that are supposed to go through it but do not. > > > > Transport security is nice to have, but really, all we need out of=20 > > transport is to guarantee the integrity of messages on a=20 > hop-by-hop basis. > > > > Bora > > > > > > > -----Original Message----- > > > From: rpsec-bounces@ietf.org [mailto:rpsec-bounces@ietf.org] On=20 > > > Behalf Of Brijesh Kumar > > > Sent: Thursday, January 27, 2005 9:10 AM > > > To: rpsec@ietf.org > > > Cc: bmanning@vacation.karoshi.com; Tom Petch; Susan Hares > > > Subject: RE: [RPSEC] proposed message to the IESG > > > > > > > > > I briefly looked at the draft - I too was wondering what is this=20 > > > draft trying to accomplish. It was n't very clear to me. > > > > > > I did some work way back on routing security ( Integration of=20 > > > security in network routing protocols > > > Source ACM SIGSAC Review archive Volume 11 , Issue 2 =20 > Spring 1993, > > > and Integrating security in inter-domain routing protocols Source=20 > > > ACM SIGCOMM Computer Communication Review archive Volume=20 > 23 , Issue=20 > > > 5 (October 1993)), and of course things have changed since then,=20 > > > but any discussion for routing protocol security still=20 > has only two=20 > > > aspects to it: 1. > > > Subverted links 2. Subverted nodes (including byzantine failures,=20 > > > misconfugrations). > > > > > > Link security is n't an issue with the current version of > > > BGP+MD5/SSL-TCP. Except, proposing mechanisms for=20 > subverted nodes,=20 > > > BGP+and > > > misconfigurations, I don't see what else can comeout of=20 > this draft=20 > > > in terms of any solution. > > > > > > So unless, requirements discuss all BGP features like AS=20 > > > Confederations, Route Reflectors, VPNs, Communities, IPv6, Route=20 > > > Flap Damping, Like Sue, I too don't see how these=20 > requirements can=20 > > > be deemed complete. > > > > > > > > > --bk > > > > > > > > > > > > > -----Original Message----- > > > > From: rpsec-bounces@ietf.org > > > [mailto:rpsec-bounces@ietf.org]On Behalf Of > > > > Susan Hares > > > > Sent: Thursday, January 27, 2005 10:01 AM > > > > To: bmanning@vacation.karoshi.com; Tom Petch > > > > Cc: rpsec@ietf.org > > > > Subject: RE: [RPSEC] proposed message to the IESG > > > > > > > > > > > > Bill and Tom: > > > > > > > > I agree. BGP as a protocol implemented in the world=20 > includes many=20 > > > > specifications. (AS the IDR web page will attest to). > > > > > > > > BGP as an implemented protocol does include AS Confederations,=20 > > > > Route Reflectors, VPNs, Communities, IPv6, Route Flap > > > Damping. (etc). > > > > > > > > Any plans to focus on a secure BGP that does not=20 > support current=20 > > > > operational BGP would find itself limited in it's deployment. > > > > > > > > Sue > > > > > > > > > > > > -----Original Message----- > > > > From: bmanning@vacation.karoshi.com=20 > > > > [mailto:bmanning@vacation.karoshi.com] > > > > Sent: Wednesday, January 26, 2005 8:19 PM > > > > To: Tom Petch > > > > Cc: Blaine Christian; Susan Hares; rpsec@ietf.org > > > > Subject: Re: [RPSEC] proposed message to the IESG > > > > > > > > > > " This specification covers only the exchange of IP=20 > version 4 > > > > network > > > > > > reachability information." > > > > > > > > > > > > Which seems to state that all the other uses for BGP > > > are not covered > > > > under > > > > > > the draft. Is that true? > > > > > > > > > > Yes. > > > > > > > > > > I think this is a key point. Look hard and you will not find > > > > Confederations, > > > > > Route Reflectors, VPNs, Communities, IPv6, Route Flap > > > Damping etc etc > > > > etc in > > > > > this draft, all very valid aspects of BGP. The aim of > > > this draft does > > > > not > > > > > include those functions (although the relevant RFC=20 > are listed as > > > > informative > > > > > references with no references in this draft to them:-). > > > > > > > > > > So is BGP security looking at the scope of BGP as defined in=20 > > > > > this > > > > basic document > > > > > (give or take some operator licence with prepending or > > > aggregation); > > > > or at the > > > > > scope of BGP as defined in a much wider set of RFC and > > > I-D? If the > > > > latter, > > > > > which documents are included? > > > > > > > > it would seem best to stay tightly focused on the=20 > core spec, > > > > since new stuff is allowed (and used to be > > > encouraged) to emerge > > > > to deal w/ changing situations... like the short=20 > list above! > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > RPSEC mailing list > > > > > RPSEC@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > > > > > > > > > > _______________________________________________ > > > > RPSEC mailing list > > > > RPSEC@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > > > > _______________________________________________ > > > RPSEC mailing list > > > RPSEC@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rpsec > > > >=20 >=20 > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec >=20 _______________________________________________ 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