From exim@www1.ietf.org Wed Nov 5 10:49:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10833 for ; Wed, 5 Nov 2003 10:49:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPuF-00012R-As for rpsec-archive@odin.ietf.org; Wed, 05 Nov 2003 10:49:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5FnFva003985 for rpsec-archive@odin.ietf.org; Wed, 5 Nov 2003 10:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPuF-00012C-6F for rpsec-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 10:49:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10825 for ; Wed, 5 Nov 2003 10:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPuC-00062M-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 10:49:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHPuC-00062I-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 10:49:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPu0-00010v-7a; Wed, 05 Nov 2003 10:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPtY-00010S-Ei for rpsec@optimus.ietf.org; Wed, 05 Nov 2003 10:48:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10784; Wed, 5 Nov 2003 10:48:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPtV-00062F-00; Wed, 05 Nov 2003 10:48:29 -0500 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 1AHPtV-000623-00; Wed, 05 Nov 2003 10:48:29 -0500 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id hA5FlqX16549; Wed, 5 Nov 2003 10:47:57 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Wed, 5 Nov 2003 10:47:52 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: agenda@ietf.org cc: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] RPSEC Agenda for IETF 58 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Routing Protocol Security Requirements WG (rpsec) Wednesday, November 12 at 1300-1500 =================================== CHAIRS: Russ White Tony Tauber AGENDA: Agenda Bashing Threats document status draft-ietf-rpsec-routing-threats-03.txt Requirements document draft-puig-rpsec-generic-requirements-01.txt Charter Discussion BGP Attack Tree draft-convery-bgpattack-01.txt OSPF Vulnerability Analysis draft-jones-OSPF-vuln-01.txt Path Security draft-white-path-considerations-00.txt _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Nov 5 13:04:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15103 for ; Wed, 5 Nov 2003 13:04:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHS0k-00010t-AM for rpsec-archive@odin.ietf.org; Wed, 05 Nov 2003 13:04:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5I46pe003889 for rpsec-archive@odin.ietf.org; Wed, 5 Nov 2003 13:04:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHS0k-00010e-6K for rpsec-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 13:04:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15094 for ; Wed, 5 Nov 2003 13:03:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHS0i-00000Y-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 13:04:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHS0h-00000V-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 13:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHS0f-0000zS-A7; Wed, 05 Nov 2003 13:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHS0Z-0000zH-2A for rpsec@optimus.ietf.org; Wed, 05 Nov 2003 13:03:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15091 for ; Wed, 5 Nov 2003 13:03:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHS0S-00000S-00 for rpsec@ietf.org; Wed, 05 Nov 2003 13:03:48 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1AHS0R-00000C-00 for rpsec@ietf.org; Wed, 05 Nov 2003 13:03: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 hA5I2wJ6029313; Wed, 5 Nov 2003 13:02:58 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 5 Nov 2003 13:02:14 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Considerations in Path Security for BGP Cc: Routing Protocols Security Working Group Content-Type: multipart/alternative; boundary="============_-1144067154==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , --============_-1144067154==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Russ, One good goal for a memo like this is to help set realistic assumptions for what sort of security we might be able to achieve for BGP, without making dramatic changes to the underlying protocol. The Abstract section of your memo seems to suggest that as the primary goal for the I-D, but I was not entirely sure, as I read through the I-D. This is something that we have tried to do in the papers we have published on S-BGP. It is useful as it helps set realistic expectations and avoids confusion. Assuming that this is the primary goal for your I-D, here are some comments. Section 1: You assert that the best one can do is to verify "that the advertiser has at least one known path to the destination advertised." In S-BGP, we can verify that a router that that advertised a path is affiliated with the (2nd) AS indicated in the path, that each AS long the path was authorized by the preceding AS in the path to advertise the prefix in the UPDATE, and that the origin AS is authorized to advertise that prefix. This seems like a lot stronger than what you describe here. We agree that one cannot ensure that traffic will actually follow the advertised path, but this is true for ANY routing protocol. You argue that the path cannot be verified to be consistent with policies of all the ASes along the route. This is true, but I'm not sure we should care too much about this. In general, the policies of an AS are locally imposed, and not disclosed to others. So, it may not be possible for anyone external to an AS to determine whether the AS is even following its own policies. Moreover, it is silly to assume that one AS can impose its policies on another AS, not under its administrative control. So, the bottom line is that an AS policy re routing is purely a local (intra-domain) matter and in an effort to secure intra-domain routing it is not of much relevance. This also relates to a comment at the end of Section 2: "Second, ASes can remove routes from the routing system in accordance with their own policy; such an action can, in some cases, prevent another AS from enforcing its own policy." Every As should understand that its ability to enforce its local policy is limited by the info it receives from other ASes. This seems like a more general observation, and it suggests security requirements, i.e., that the received info be verifiable in terms of its integrity and authenticity. Also, we can verify whether the assertions encoded in the data are verifiable from an authorization perspective, based on available data, but that data generally would not include the policy of the ASes along the path. Finally, the I-D brings up here and later the topic of data that is discarded as an advertisement progresses through the Internet. This is true, but it is not an intrinsic limitation of BGP. For example, in S-BGP, we carry some data that is discarded (e.g., due to aggregation) to facilitate signature verification at later ASes. This does not modify the semantics of BGP, but rather represents a sort of housekeeping activity by S-BGP, to facilitate authorization checks. I don't consider that to be out of bounds re security measures we can employ with BGP, and thus I don't agree with all of the observations about the implications of discarded data relative to security capabilities for BGP. Section 2: The phrase "these techniques do not ensure various aspects of the information carried within routing protocols" is pretty vague ought to be replaced, when discussing the limitations of point-to-point integrity mechanisms such as the MD5 checksum. You also state that "This document does not discuss the authorization to advertise a given destination, or prefix." I agree that the I-D does not address this but I am puzzled as to why this discussion is omitted. We feel that authorization is central to discussions of the security of BGP. The I-D specifies three questions that are cast as the essential criteria re route validity. The first one is interesting, but maybe not essential, the second seems like a red herring. The third one, which is the authorization issue that this I-D largely ignores, seems most important. The first question is interesting in that if the path does not exist, then clearly there is a problem with the advertisement. But, even if the path does exist, we don't know that traffic will follow that path, as you noted earlier. Also, in general it is very difficult to know if a specified path exists, given the realistic limitations on dissemination of information about AS connectivity. So I question whether this is a useful question to be asking. The second questions strikes me as inappropriate. Only if I were aware of the policies of every AS along a path would I be able to determine if each AS had properly applied its local policy to the advertisement I have received. But, as noted earlier, this information is NOT generally available, so it seems very unlikely that an AS can know the answer to this question. Moreover, why do I care whether each AS has followed its own policy? What I really care about is whether the advertisement is authentic and authorized, because if the advertisement is not authentic or it is it unauthorized, then it is bad and should be ignored, to avoid misrouting. Based on our S-BGP work, which addresses the third question, I have to disagree with your assertion that authorization to advertise cannot be established. Finally, at the end of section 2 you list three things that protocols like BGP were not intended to do. I agree with the assertions in this list, but how did you choose to name only these items? There are lots of things BGP does not do and so one needs to explain why one would choose any subset to enumerate here. Section 2.1 seems to be an example to show why the first of the three assertions is true. OK, but, as noted above, you first need to justify why this needs to be demonstrated. Is the notion that this is a widely held, but inaccurate belief? Section 3 begins with a discussion of how info may be legitimately removed from an advertisement as it passes from one AS to another. The intro ends with an assertion that the removal of info in this fashion limits what an AS can verify re an advertisement. This is true, but it ignores the possibility that a security extension to a protocol like BGP could choose to carry some of the discarded information, when it is necessary to support path authorization. That's what we do in S-BGP. So, I have to disagree with the stated conclusion about the inherent limitations of security measures in this regard. So long as we don't change how the protocol operates, e.g., the effects of aggregation are preserved, I think its fair to carry the "discarded" info in support of security features. The example that compromises section 3.1 ends with phrases like "safer" and "more secure." These terms are not defined any where in the I-D and seem irrelevant to the discussion. I'd delete the last sentence. The example that comprises section 3.2 seems to be missing some details. There are no examples of any advertisements from D to B re the 10.1.2.0 space. Absent such advertisements, B would not be able to create an authentic advertisement to 10.1.2.0/24 or /23, at least in S-BGP. The last sentence of this section is very long, and confusing. It says: "Thus, lack of information cannot, in a routing system, be construed to mean lack of authorization to transit a given path, or provide reachability to a given destination, unless all possible routing information towards a given destination can be removed, and all possible points of origin for that information are under the administrative control of the owner of the route." The "owner" of an address prefix does have control over the adjacent ASes that advertise it. At best the owner chooses which adjacent ASes he authorizes to advertise the prefix, but that is the extent of his control. After that, these Ases can choose to advertise the prefix, or not. So, given that capability, does the final clause of the sentence become false and thus the premise of the sentence is false too? I can't tell. Section 4, the summary, begins with a statement that seems to be a big jump from much of the rest of the analysis in the I-D. It says: "While it is tempting to set policy, or to infer policy, from the existence or non-existence of information within a routing system, it isn't possible to do so, since routing systems remove information on a regular basis. Further, it appears logical that policy could be set based on the path advertised in a path vector protocol, however, since routing information is regularly removed from the routing system, it isn't possible to do so." I don't recall much discussion of setting or inferring policy in this I-D. I assume operators of an AS set local policy based on various inputs, including business arrangements with subscribers and peers, traffic engineering decisions, etc. None of this is primarily or exclusively a function of advertisements they receive from other ASes, and so the comments here seem out of place. Also, it is not clear why one should try to infer the policy of an AS from advertisements, so the second aspect of this assertion is also puzzling. Overall I don't know what to make of this sentence. Steve --============_-1144067154==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] Considerations in Path Security for BGP
Russ,
One good goal for a memo like this is to help set realistic assumptions for what sort of security we might be able to achieve for BGP, without making dramatic changes to the underlying protocol. The Abstract section of your memo seems to suggest that as the primary goal for the I-D, but I was not entirely sure, as I read through the I-D. This is something that we have tried to do in the papers we have published on S-BGP. It is useful as it helps set realistic expectations and avoids confusion. Assuming that this is the primary goal for your I-D, here are some comments.

Section 1:

You assert that the best one can do is to verify "that the advertiser has at least one known path to the destination advertised." In S-BGP, we can verify that a router that that advertised a path is affiliated with the (2nd) AS indicated in the path, that each AS long the path was authorized by the preceding AS in the path to advertise the prefix in the UPDATE, and that the origin AS is authorized to advertise that prefix.  This seems like a lot stronger than what you describe here.

We agree that one cannot ensure that traffic will actually follow the advertised path, but this is true for ANY routing protocol.

You argue that the path cannot be verified to be consistent with policies of all the ASes along the route. This is true, but I'm not sure we should care too much about this. In general, the policies of an AS are locally imposed, and not disclosed to others. So, it may not be possible for anyone external to an AS to determine whether the AS is even following its own policies. Moreover, it is silly to assume that one AS can impose its policies on another AS, not under its administrative control. So, the bottom line is that an AS policy re routing is purely a local (intra-domain) matter and  in an effort to secure intra-domain routing it is not of much relevance.

This also relates to a comment at the end of Section 2: "Second, ASes can remove routes from the routing system in accordance with their own policy; such an action can, in some cases, prevent another AS from enforcing its own policy." Every As should understand that its ability to enforce its local policy is limited by the info it receives from other ASes. This seems like a more general observation, and it suggests security requirements, i.e., that the received info be verifiable in terms of its integrity and authenticity. Also, we can verify whether the assertions encoded in the data are verifiable from an authorization perspective, based on available data, but that data generally would not include the policy of the ASes along the path.

Finally, the I-D brings up here and later the topic of data that is discarded as an advertisement progresses through the Internet. This is true, but it is not an intrinsic limitation of BGP. For example, in S-BGP, we carry some data that is discarded (e.g., due to aggregation) to facilitate signature verification at later ASes. This does not modify the semantics of BGP, but rather represents a sort of housekeeping activity by S-BGP, to facilitate authorization checks. I don't consider that to be out of bounds re security measures we can employ with BGP, and thus I don't agree with all of the observations about the implications of discarded data relative to security capabilities for BGP.


Section 2:

The phrase "these techniques do not ensure various aspects of the information carried within routing protocols" is pretty vague ought to be replaced, when discussing the limitations of point-to-point integrity mechanisms such as the MD5 checksum.

You also state that "This document does not discuss the authorization to advertise a given destination, or prefix." I agree that the I-D does not address this but I am puzzled as to why this discussion is omitted. We feel that authorization is central to discussions of the security of BGP.

The I-D specifies three questions that are cast as the essential criteria re route validity. The first one is interesting, but maybe not essential, the second seems like a red herring. The third one, which is the authorization issue that this I-D largely ignores, seems most important.

The first question is interesting in that if the path does not exist, then clearly there is a problem with the advertisement. But, even if the path does exist, we don't know that traffic will follow that path, as you noted earlier. Also, in general it is very difficult to know if a specified path exists, given the realistic limitations on dissemination of information about AS connectivity. So I question whether this is a useful question to be asking.

The second questions strikes me as inappropriate. Only if I were aware of the policies of every AS along a path would I be able to determine if each AS had properly applied its local policy to the advertisement I have received. But, as noted earlier, this information is NOT generally available, so it seems very unlikely that an AS can know the answer to this question. Moreover, why do I care whether each AS has followed its own policy? What I really care about is whether the advertisement is authentic and authorized, because if the advertisement is not authentic or it is it unauthorized, then it is bad and should be ignored, to avoid misrouting. Based on our S-BGP work, which addresses the third question, I have to disagree with your assertion that authorization to advertise cannot be established.


Finally, at the end of section 2 you list three things that protocols like BGP were not intended to do. I agree with the assertions in this list, but how did you choose to name only these items? There are lots of things BGP does not do and so one needs to explain why one would choose any subset to enumerate here.

Section 2.1 seems to be an example to show why the first of the three assertions is true. OK, but, as noted above, you first need to justify why this needs to be demonstrated. Is the notion that this is a widely held, but inaccurate belief? 

Section 3 begins with a discussion of how info may be legitimately removed from an advertisement as it passes from one AS to another. The intro ends with an assertion that the removal of info in this fashion limits what an AS can verify re an advertisement. This is true, but it ignores the possibility that a security extension to a protocol like BGP could choose to carry some of the discarded information, when it is necessary to support path authorization. That's what we do in S-BGP. So, I have to disagree with the stated conclusion about the inherent limitations of security measures in this regard. So long as we don't change how the protocol operates, e.g., the effects of aggregation are preserved, I think its fair to carry the "discarded" info in support of security features.

The example that compromises section 3.1 ends with phrases like "safer" and "more secure." These terms are not defined any where in the I-D and seem irrelevant to the discussion. I'd delete the last sentence.

The example that comprises section 3.2 seems to be missing some details. There are no examples of any advertisements from D to B re the 10.1.2.0 space.  Absent such advertisements, B would not be able to create an authentic advertisement to 10.1.2.0/24 or /23, at least in S-BGP.

The last sentence of this section is very long, and confusing. It says: "Thus, lack of information cannot, in a routing system, be construed to mean lack of authorization to transit a given path, or provide reachability to a given destination, unless all possible routing information towards a given destination can be removed, and all possible points of origin for that information are under the administrative control of the owner of the route."

The "owner" of an address prefix does have control over the adjacent ASes that advertise it. At best the owner chooses which adjacent ASes he authorizes to advertise the prefix, but that is the extent of his control. After that, these Ases can choose to advertise the prefix, or not.  So, given that capability, does the final clause of the sentence become false and thus the premise of the sentence is false too? I can't tell.

Section 4, the summary, begins with a statement that seems to be a big jump from much of the rest of the analysis in the I-D. It says: "While it is tempting to set policy, or to infer policy, from the existence or non-existence of information within a routing system, it isn't possible to do so, since routing systems remove information on a regular basis. Further, it appears logical that policy could be set based on the path advertised in a path vector protocol, however, since routing information is regularly removed from the routing system, it isn't possible to do so."

I don't recall much discussion of setting or inferring policy in this I-D. I assume operators of an AS set local policy based on various inputs, including business arrangements with subscribers and peers, traffic engineering decisions, etc. None of this is primarily or exclusively a function of advertisements they receive from other ASes, and so the comments here seem out of place. Also, it is not clear why one should try to infer the policy of an AS from advertisements, so the second aspect of this assertion is also puzzling. Overall I don't know what to make of this sentence.

Steve

--============_-1144067154==_ma============-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Nov 5 14:31:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18934 for ; Wed, 5 Nov 2003 14:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTN4-0006zA-PC for rpsec-archive@odin.ietf.org; Wed, 05 Nov 2003 14:31:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5JVEXu026848 for rpsec-archive@odin.ietf.org; Wed, 5 Nov 2003 14:31:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTN4-0006yx-Ka for rpsec-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:31:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18876 for ; Wed, 5 Nov 2003 14:31:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTN1-0001QR-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 14:31:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTN1-0001QO-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 14:31:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTMs-0006vh-H4; Wed, 05 Nov 2003 14:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTMM-0006uU-C3 for rpsec@optimus.ietf.org; Wed, 05 Nov 2003 14:30:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18809 for ; Wed, 5 Nov 2003 14:30:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTMJ-0001Oz-00 for rpsec@ietf.org; Wed, 05 Nov 2003 14:30:27 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AHTMJ-0001LP-00 for rpsec@ietf.org; Wed, 05 Nov 2003 14:30:27 -0500 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 05 Nov 2003 11:31:33 -0800 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JTnDM028623; Wed, 5 Nov 2003 14:29:50 -0500 (EST) Received: from russpc.whitehouse.intra (rtp-vpn2-364.cisco.com [10.82.241.108]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA13385; Wed, 5 Nov 2003 14:29:49 -0500 (EST) Date: Wed, 5 Nov 2003 14:29:45 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Stephen Kent cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] Considerations in Path Security for BGP In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > One good goal for a memo like this is to help set realistic assumptions > for what sort of security we might be able to achieve for BGP, without > making dramatic changes to the underlying protocol. The Abstract section > of your memo seems to suggest that as the primary goal for the I-D, but I > was not entirely sure, as I read through the I-D. This is something that > we have tried to do in the papers we have published on S-BGP. It is > useful as it helps set realistic expectations and avoids confusion. > Assuming that this is the primary goal for your I-D, here are some > comments. > > Section 1: > > You assert that the best one can do is to verify "that the advertiser has > at least one known path to the destination advertised." In S-BGP, we can > verify that a router that that advertised a path is affiliated with the > (2nd) AS indicated in the path, that each AS long the path was authorized > by the preceding AS in the path to advertise the prefix in the UPDATE, > and that the origin AS is authorized to advertise that prefix. This > seems like a lot stronger than what you describe here. Actually, you can't. You are assuming that signed advertisement==authorization, but you've not clarified _whose_ authorization. This is precisely the problem with policies in a distributed system, in genera, somce you alude to later in your email. For instance, if I have this small internetwork: AS5 | +--AS3--+ AS1 AS4 +--AS2--+ Suppose AS1 is advertising 10.1.1.0/24 to both AS3 and AS2. They intend that AS5's traffic should pass through AS3, but that AS4's traffic should only pass through AS2. How can they enforce this policy? Suppose they can, in some way, force AS3 to only advertise the route to AS5, and not to AS4. This appears to solve the problem. Only that they also have to force AS3 to not advertise any possible _supernet_ of the same route to AS4, or their policy simply won't be enforced. You can't count on longest match enforcing policy when you can't gaurentee that routes won't be filtered out of the table. So, again, who's policy? AS1's policy, or AS3's policy? The way BGP currently works, AS3's policy takes precedence over the originator's policy. And, because of this, you _cannot_ garauntee what you assert above, that you can prove authorization through advertisment. In this case, for instance, AS1 has, in no way, authorized AS3 to transit traffic from AS4 to AS1. But, because of the way BGP works, there is absolutely no way to prevent AS3 from doing so. You can place packet filters on the border, but that just drops your traffic. > We agree that one cannot ensure that traffic will actually follow the > advertised path, but this is true for ANY routing protocol. Agreed. This is another reason why attempting to "secure the path" doesn't make any sense in a routing protocol. > You argue that the path cannot be verified to be consistent with policies > of all the ASes along the route. This is true, but I'm not sure we should > care too much about this. In general, the policies of an AS are locally > imposed, and not disclosed to others. So, it may not be possible for > anyone external to an AS to determine whether the AS is even following > its own policies. Moreover, it is silly to assume that one AS can impose > its policies on another AS, not under its administrative control. So, the > bottom line is that an AS policy re routing is purely a local > (intra-domain) matter and in an effort to secure intra-domain routing it > is not of much relevance. But, in fact, AS' _do_ impose their policies on other AS'. They do so today, through Local Preference, for instance, and even communities. Again, the fundamental question is: Whose policies? > Finally, the I-D brings up here and later the topic of data that is > discarded as an advertisement progresses through the Internet. This is > true, but it is not an intrinsic limitation of BGP. For example, in > S-BGP, we carry some data that is discarded (e.g., due to aggregation) to > facilitate signature verification at later ASes. This does not modify the > semantics of BGP, but rather represents a sort of housekeeping activity > by S-BGP, to facilitate authorization checks. I don't consider that to be > out of bounds re security measures we can employ with BGP, and thus I > don't agree with all of the observations about the implications of > discarded data relative to security capabilities for BGP. The point of the section is that you can't secure removed data. In the example above, you cannot secure AS1's policies, since AS1's routes have been removed from the system by AS3's policy, for instance. The only thing you could do is to provide a "do not route this direction" symantic, rather than the "route this direction" that BGP currently provides, but I'm not certain, as a routing person, that you want to do this. > The phrase "these techniques do not ensure various aspects of the > information carried within routing protocols" is pretty vague ought to be > replaced, when discussing the limitations of point-to-point integrity > mechanisms such as the MD5 checksum. MD5 verifies the information carried between peering; it is, fundementally, a peering mechanism. If you think of a routing protocol as a database (in rough terms), then MD5 verifies the communications between the servers. This prevents someone along the way from injecting bad data, etc, but it does not prevent one of the legetimate servers from injecting bad data. > You also state that "This document does not discuss the authorization to > advertise a given destination, or prefix." I agree that the I-D does not > address this but I am puzzled as to why this discussion is omitted. We > feel that authorization is central to discussions of the security of BGP. Because the point of the document is that you cannot, in any way, try to enforce policy within a path, with the current semantics of BGP. Authorization of origination are clearly handled by soBGP and S-BGP. The problem we're trying to address is this: What, exactly, can you actually secure? One thing we know you can't secure is the AS Path. > The I-D specifies three questions that are cast as the essential criteria > re route validity. The first one is interesting, but maybe not essential, > the second seems like a red herring. The third one, which is the > authorization issue that this I-D largely ignores, seems most important. The first is the most important, in terms of a routing protocols security system. The second is not a red herring, it is actually what most security systems appear to be attempting to prove (authorization to advertise something you've learned from a third party). The third, again, is not a concern, since it is important, and it can be proven, in many ways. > The second questions strikes me as inappropriate. Only if I were aware of > the policies of every AS along a path would I be able to determine if > each AS had properly applied its local policy to the advertisement I have > received. Exactly. And the point of many security systems currently proposed to validate exactly those policies. They cannot be validated. > Finally, at the end of section 2 you list three things that protocols > like BGP were not intended to do. I agree with the assertions in this > list, but how did you choose to name only these items? There are lots of > things BGP does not do and so one needs to explain why one would choose > any subset to enumerate here. Simply to point them out. There are, as you say, a lot of things BGP wasn't designed to do, such as converge in a couple of milliseconds. But these aren't really important to the discussion at hand. :-) > Section 2.1 seems to be an example to show why the first of the three > assertions is true. OK, but, as noted above, you first need to justify > why this needs to be demonstrated. Is the notion that this is a widely > held, but inaccurate belief? Based on at least some of the currently proposed security systems, it is an assumption which is widely held. > Section 3 begins with a discussion of how info may be legitimately > removed from an advertisement as it passes from one AS to another. The > intro ends with an assertion that the removal of info in this fashion > limits what an AS can verify re an advertisement. This is true, but it > ignores the possibility that a security extension to a protocol like BGP > could choose to carry some of the discarded information, when it is > necessary to support path authorization. This is precisely the concept of "do not route this direction," or rather, a "negative update." BGP has no such beast today. > That's what we do in S-BGP. So, I have to disagree with the stated > conclusion about the inherent limitations of security measures in this > regard. So long as we don't change how the protocol operates, e.g., the > effects of aggregation are preserved, I think its fair to carry the > "discarded" info in support of security features. Actually, you only carry this information in the case of aggregation, not re-origination. So, the information is still dropped from the system. Second, even if you do carry the information in the aggregate, you don't know which specific prefixes that information applied to. This is akin to forcing AS3, in the example above, not to advertise a supernet of 10.1.1.0/24 to AS4. > The example that compromises section 3.1 ends with phrases like "safer" > and "more secure." These terms are not defined any where in the I-D and > seem irrelevant to the discussion. I'd delete the last sentence. I'll take a look. > The example that comprises section 3.2 seems to be missing some details. > There are no examples of any advertisements from D to B re the 10.1.2.0 > space. Absent such advertisements, B would not be able to create an > authentic advertisement to 10.1.2.0/24 or /23, at least in S-BGP. I suppose it's an assumption in the draft which needs to be clarified. D is, in fact, advertising the shorter prefix to B and C, and the longer prefix just to C. > The last sentence of this section is very long, and confusing. It says: > "Thus, lack of information cannot, in a routing system, be construed to > mean lack of authorization to transit a given path, or provide > reachability to a given destination, unless all possible routing > information towards a given destination can be removed, and all possible > points of origin for that information are under the administrative > control of the owner of the route." > > The "owner" of an address prefix does have control over the adjacent ASes > that advertise it. At best the owner chooses which adjacent ASes he > authorizes to advertise the prefix, but that is the extent of his > control. After that, these Ases can choose to advertise the prefix, or > not. So, given that capability, does the final clause of the sentence > become false and thus the premise of the sentence is false too? I can't > tell. Exactly. So, you would agree that you cannot prove authorization to advertise in a routing system such as BGP? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Nov 5 16:24:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24636 for ; Wed, 5 Nov 2003 16:24:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8l-0005iV-Bx for rpsec-archive@odin.ietf.org; Wed, 05 Nov 2003 16:24:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LOZLk021959 for rpsec-archive@odin.ietf.org; Wed, 5 Nov 2003 16:24:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8k-0005gc-Er for rpsec-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 16:24:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24376 for ; Wed, 5 Nov 2003 16:24:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHV8g-0003an-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:30 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHV8f-0003aI-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 16:24:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8I-0005Jt-HU; Wed, 05 Nov 2003 16:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHU6o-0002oZ-P7 for rpsec@optimus.ietf.org; Wed, 05 Nov 2003 15:18:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22284 for ; Wed, 5 Nov 2003 15:18:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHU6n-0002RN-00 for rpsec@ietf.org; Wed, 05 Nov 2003 15:18:29 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1AHU6m-0002R3-00 for rpsec@ietf.org; Wed, 05 Nov 2003 15:18:28 -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 hA5KHpJ6007875; Wed, 5 Nov 2003 15:17:51 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 5 Nov 2003 15:14:08 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Considerations in Path Security for BGP Cc: Routing Protocols Security Working Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Russ, >Actually, you can't. You are assuming that signed >advertisement==authorization, but you've not clarified _whose_ >authorization. This is precisely the problem with policies in a distributed >system, in genera, somce you alude to later in your email. For instance, if >I have this small internetwork: we seem to be speaking different languages. From my perspective, authorization in BGP relates to the right to advertise a prefix, and is granted by an AS when is sends an UPDATE to a neighbor containing the prefix. > > AS5 > | > +--AS3--+ >AS1 AS4 > +--AS2--+ > >Suppose AS1 is advertising 10.1.1.0/24 to both AS3 and AS2. They intend >that AS5's traffic should pass through AS3, but that AS4's traffic should >only pass through AS2. How can they enforce this policy? they can't and they ought not expect to be able to enforce that policy! As I noted in my comments, there is no presumed ability of ASa to control to whom ABb advertises a route once ASa has authorized ASb to advertise it. There is no transitive control over advertisement, something we both agree upon, I think. >So, again, who's policy? AS1's policy, or AS3's policy? The way BGP >currently works, AS3's policy takes precedence over the originator's >policy. And, because of this, you _cannot_ garauntee what you assert above, >that you can prove authorization through advertisment. In this case, for >instance, AS1 has, in no way, authorized AS3 to transit traffic from AS4 to >AS1. But, because of the way BGP works, there is absolutely no way to >prevent AS3 from doing so. You can place packet filters on the border, but >that just drops your traffic. As I see it we agree on the limitations inherent in this sort of routing, and we are just having trouble agreeing on the right terms. > > We agree that one cannot ensure that traffic will actually follow the >> advertised path, but this is true for ANY routing protocol. > >Agreed. This is another reason why attempting to "secure the path" doesn't >make any sense in a routing protocol. we disagree, strongly! while it is true that we cannot ensure that traffic we hand off to another As will traverse the advertised path, in most cases we have no choice, i.e., it's the best (or only) game in town based on the externally available knowledge. thus is it reasonable to ensure that at least the info we use to make the decision is accurate in so far as the externally available info permits. > > You argue that the path cannot be verified to be consistent with policies >> of all the ASes along the route. This is true, but I'm not sure we should >> care too much about this. In general, the policies of an AS are locally >> imposed, and not disclosed to others. So, it may not be possible for >> anyone external to an AS to determine whether the AS is even following > > its own policies. Moreover, it is silly to assume that one AS can impose >> its policies on another AS, not under its administrative control. So, the >> bottom line is that an AS policy re routing is purely a local >> (intra-domain) matter and in an effort to secure intra-domain routing it >> is not of much relevance. > >But, in fact, AS' _do_ impose their policies on other AS'. They do so >today, through Local Preference, for instance, and even communities. Again, >the fundamental question is: Whose policies? Your examples show the opposite. Each AS can decide what to advertise to its neighbors, but it cannot force another AS to carry traffic via these advertisements. It can only hope to influence their decisions, and that influence is limited. > > Finally, the I-D brings up here and later the topic of data that is >> discarded as an advertisement progresses through the Internet. This is >> true, but it is not an intrinsic limitation of BGP. For example, in >> S-BGP, we carry some data that is discarded (e.g., due to aggregation) to >> facilitate signature verification at later ASes. This does not modify the > > semantics of BGP, but rather represents a sort of housekeeping activity >> by S-BGP, to facilitate authorization checks. I don't consider that to be >> out of bounds re security measures we can employ with BGP, and thus I >> don't agree with all of the observations about the implications of >> discarded data relative to security capabilities for BGP. > >The point of the section is that you can't secure removed data. In the >example above, you cannot secure AS1's policies, since AS1's routes have >been removed from the system by AS3's policy, for instance. The only thing >you could do is to provide a "do not route this direction" symantic, rather >than the "route this direction" that BGP currently provides, but I'm not >certain, as a routing person, that you want to do this. again, we seem to be talking at cross purposes. I get the feeling that you are trying to establishing a strawman re what an AS might try to do and why it cannot be successful. I never see an ability for one AS to control what other AS does, so I see no surprises in your examples. If you feel that there are folks who are confused about this issue, then it is appropriate to state it clearly, once, and explain why they are confused. But there is no need to generate a lot of text belaboring the point. > >> The phrase "these techniques do not ensure various aspects of the >> information carried within routing protocols" is pretty vague ought to be >> replaced, when discussing the limitations of point-to-point integrity >> mechanisms such as the MD5 checksum. > >MD5 verifies the information carried between peering; it is, fundementally, >a peering mechanism. If you think of a routing protocol as a database (in >rough terms), then MD5 verifies the communications between the servers. >This prevents someone along the way from injecting bad data, etc, but it >does not prevent one of the legetimate servers from injecting bad data. yes, I agree. I was pointing out that the words you chose were vague and did not convey clearly what the MD5 mechanism does. in conventional communication security terms, this mechanism provides point-to-point integrity at the transport layer, and data origin authentication, assuming that the keys used are pairwise unique. that is a concise, technically accurate characterization of the mechanism. > >> You also state that "This document does not discuss the authorization to >> advertise a given destination, or prefix." I agree that the I-D does not >> address this but I am puzzled as to why this discussion is omitted. We >> feel that authorization is central to discussions of the security of BGP. > >Because the point of the document is that you cannot, in any way, try to >enforce policy within a path, with the current semantics of BGP. >Authorization of origination are clearly handled by soBGP and S-BGP. The >problem we're trying to address is this: What, exactly, can you actually >secure? One thing we know you can't secure is the AS Path. I don't know what that phrase "secure the AS path" is supposed to mean. One can allow an AS to verify whether the advertised path is authorized, and I have explained why I think that is exactly what an AS should try to verify, i.e., it is the underlying semantic of BGP. However, you are correct that this security capability will not allow one As to project its policy onto other ASes, or ensure that subscriber traffic will, in fact, follow the path. > >> The I-D specifies three questions that are cast as the essential criteria >> re route validity. The first one is interesting, but maybe not essential, >> the second seems like a red herring. The third one, which is the >> authorization issue that this I-D largely ignores, seems most important. > >The first is the most important, in terms of a routing protocols security >system. The second is not a red herring, it is actually what most security >systems appear to be attempting to prove (authorization to advertise >something you've learned from a third party). The third, again, is not a >concern, since it is important, and it can be proven, in many ways. Well, I guess we just don't read the words the same way. > > The second questions strikes me as inappropriate. Only if I were aware of >> the policies of every AS along a path would I be able to determine if >> each AS had properly applied its local policy to the advertisement I have >> received. > >Exactly. And the point of many security systems currently proposed to >validate exactly those policies. They cannot be validated. what systems are you talking about? Certainly not S-BGP, and presumably not soBGP, so to what, precisely do you refer here? > > Finally, at the end of section 2 you list three things that protocols >> like BGP were not intended to do. I agree with the assertions in this >> list, but how did you choose to name only these items? There are lots of > > things BGP does not do and so one needs to explain why one would choose >> any subset to enumerate here. > >Simply to point them out. There are, as you say, a lot of things BGP wasn't >designed to do, such as converge in a couple of milliseconds. But these >aren't really important to the discussion at hand. :-) one needs to justify the choices of what to argue BGP does not do, else the choices seem arbitrary. why not note that BGP fails to make underwear brighter? > > Section 2.1 seems to be an example to show why the first of the three >> assertions is true. OK, but, as noted above, you first need to justify >> why this needs to be demonstrated. Is the notion that this is a widely >> held, but inaccurate belief? > >Based on at least some of the currently proposed security systems, it is an >assumption which is widely held. Again, you might to be more specific, and say what systems you have in mind, to justify the discussion. We know it's no S-BGP and presumably no soBGP ... > > Section 3 begins with a discussion of how info may be legitimately >> removed from an advertisement as it passes from one AS to another. The >> intro ends with an assertion that the removal of info in this fashion >> limits what an AS can verify re an advertisement. This is true, but it >> ignores the possibility that a security extension to a protocol like BGP >> could choose to carry some of the discarded information, when it is >> necessary to support path authorization. > >This is precisely the concept of "do not route this direction," or rather, >a "negative update." BGP has no such beast today. as noted above, several times, you can't force another AS to do or not do something re route propagation. What you can do, e.g., with a system like S-BGP, is to allow other ASes to determine whether or not the advertisements they receive are authorized by all of the ASes along the path, where authorized is the very simple statement I have made several times already. > > That's what we do in S-BGP. So, I have to disagree with the stated >> conclusion about the inherent limitations of security measures in this >> regard. So long as we don't change how the protocol operates, e.g., the >> effects of aggregation are preserved, I think its fair to carry the >> "discarded" info in support of security features. > >Actually, you only carry this information in the case of aggregation, not >re-origination. So, the information is still dropped from the system. >Second, even if you do carry the information in the aggregate, you don't >know which specific prefixes that information applied to. This is akin to >forcing AS3, in the example above, not to advertise a supernet of >10.1.1.0/24 to AS4. I have to admit that I don't now what re-origination is, so I'll get back to you on that topic. But, with regard to the second half of your comment, we all agree that once cannot force another AS to NOT advertise or to NOT advertise something, so I don't see the point. > >> The example that compromises section 3.1 ends with phrases like "safer" >> and "more secure." These terms are not defined any where in the I-D and >> seem irrelevant to the discussion. I'd delete the last sentence. > >I'll take a look. > >> The example that comprises section 3.2 seems to be missing some details. >> There are no examples of any advertisements from D to B re the 10.1.2.0 >> space. Absent such advertisements, B would not be able to create an > > authentic advertisement to 10.1.2.0/24 or /23, at least in S-BGP. > >I suppose it's an assumption in the draft which needs to be clarified. D >is, in fact, advertising the shorter prefix to B and C, and the longer >prefix just to C. > >> The last sentence of this section is very long, and confusing. It says: >> "Thus, lack of information cannot, in a routing system, be construed to >> mean lack of authorization to transit a given path, or provide >> reachability to a given destination, unless all possible routing >> information towards a given destination can be removed, and all possible >> points of origin for that information are under the administrative >> control of the owner of the route." >> >> The "owner" of an address prefix does have control over the adjacent ASes >> that advertise it. At best the owner chooses which adjacent ASes he >> authorizes to advertise the prefix, but that is the extent of his >> control. After that, these Ases can choose to advertise the prefix, or >> not. So, given that capability, does the final clause of the sentence >> become false and thus the premise of the sentence is false too? I can't >> tell. > >Exactly. So, you would agree that you cannot prove authorization to >advertise in a routing system such as BGP? > >:-) > >Russ What I agree is that you need to work on your exposition, to make a sentence like the one quoted above comprehensible. then we can figure out what may be wrong (or right) with it. :-) Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Nov 5 16:45:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25609 for ; Wed, 5 Nov 2003 16:45:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVSn-0000MK-NI for rpsec-archive@odin.ietf.org; Wed, 05 Nov 2003 16:45:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LjHTb001374 for rpsec-archive@odin.ietf.org; Wed, 5 Nov 2003 16:45:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVSn-0000M5-Iz for rpsec-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 16:45:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25469 for ; Wed, 5 Nov 2003 16:45:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVSl-0003zm-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 16:45:15 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHVSX-0003yC-01 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 16:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8O-0005RG-QM; Wed, 05 Nov 2003 16:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHUK7-00035z-VE for rpsec@optimus.ietf.org; Wed, 05 Nov 2003 15:32:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22855 for ; Wed, 5 Nov 2003 15:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHUK6-0002xf-00 for rpsec@ietf.org; Wed, 05 Nov 2003 15:32:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AHUK6-0002xT-00 for rpsec@ietf.org; Wed, 05 Nov 2003 15:32:14 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 05 Nov 2003 12:33:26 -0800 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA5KVfxg023958; Wed, 5 Nov 2003 15:31:41 -0500 (EST) Received: from russpc.whitehouse.intra (rtp-vpn2-364.cisco.com [10.82.241.108]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA17325; Wed, 5 Nov 2003 15:31:41 -0500 (EST) Date: Wed, 5 Nov 2003 15:31:37 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Stephen Kent cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] Considerations in Path Security for BGP In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > >Actually, you can't. You are assuming that signed > >advertisement==authorization, but you've not clarified _whose_ > >authorization. This is precisely the problem with policies in a > >distributed system, in genera, somce you alude to later in your email. > >For instance, if I have this small internetwork: > > we seem to be speaking different languages. From my perspective, > authorization in BGP relates to the right to advertise a prefix, and is > granted by an AS when is sends an UPDATE to a neighbor containing the > prefix. > > > AS5 > > | > > +--AS3--+ > >AS1 AS4 > > +--AS2--+ > > > >Suppose AS1 is advertising 10.1.1.0/24 to both AS3 and AS2. They intend > >that AS5's traffic should pass through AS3, but that AS4's traffic should > >only pass through AS2. How can they enforce this policy? > > they can't and they ought not expect to be able to enforce that policy! > As I noted in my comments, there is no presumed ability of ASa to control > to whom ABb advertises a route once ASa has authorized ASb to advertise > it. There is no transitive control over advertisement, something we both > agree upon, I think. Yes, but if you enlarge this to the next step, you'll understand the point of the draft itself. -- AS1 cannot force AS2 to advertise something it has authorized AS2 to advertise. -- AS1 cannot force AS3 not to advertise something which overlaps that which it has _not_ authorized AS3 to advertise. In other words, AS1 can refuse to authorize AS3 the ability to advertise 10.1.1.0/24. But, it could so happen that AS3 has the authorization to advertise 10.1.0.0/16 through some other source, reorigination, perhaps, or learning it from any other peer. In this case, AS3 will advertise 10.1.0.0/16, which, in fact, overlaps and encompasses 10.1.1.0/24, which AS1 expressly does _not_ want AS3 to advertise. Thus, AS1 has no say in whether or not AS3 will advertise 10.1.1.0/24, in fact. You could argue that AS1 can create a "hole" in the 10.1.0.0/16 address space AS3 is advertising (legitimately) by advertising the longer prefix through another path, but that advertisement may be removed at any point, so that argument doesn't work, either. You can prove a valid path exists, but to prove "authorization," you're going to have to define it more closely than it's currently defined. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Nov 5 16:45:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25624 for ; Wed, 5 Nov 2003 16:45:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVSo-0000Mm-Hb for rpsec-archive@odin.ietf.org; Wed, 05 Nov 2003 16:45:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LjIgx001402 for rpsec-archive@odin.ietf.org; Wed, 5 Nov 2003 16:45:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVSo-0000MX-EN for rpsec-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 16:45:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25480 for ; Wed, 5 Nov 2003 16:45:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVSm-0003zu-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 16:45:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHVSZ-0003yM-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 16:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHV8b-0005aB-0o; Wed, 05 Nov 2003 16:24:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHUtz-0004vw-Tv for rpsec@optimus.ietf.org; Wed, 05 Nov 2003 16:09:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23913 for ; Wed, 5 Nov 2003 16:09:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHUty-0003Ng-00 for rpsec@ietf.org; Wed, 05 Nov 2003 16:09:18 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1AHUtx-0003N8-00 for rpsec@ietf.org; Wed, 05 Nov 2003 16:09:17 -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 hA5L85J6011017; Wed, 5 Nov 2003 16:08:05 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 5 Nov 2003 16:03:35 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Considerations in Path Security for BGP Cc: Routing Protocols Security Working Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 15:31 -0500 11/5/03, Russ White wrote: > > >Actually, you can't. You are assuming that signed >> >advertisement==authorization, but you've not clarified _whose_ >> >authorization. This is precisely the problem with policies in a >> >distributed system, in genera, somce you alude to later in your email. >> >For instance, if I have this small internetwork: >> >> we seem to be speaking different languages. From my perspective, >> authorization in BGP relates to the right to advertise a prefix, and is >> granted by an AS when is sends an UPDATE to a neighbor containing the >> prefix. >> >> > AS5 >> > | >> > +--AS3--+ >> >AS1 AS4 >> > +--AS2--+ >> > >> >Suppose AS1 is advertising 10.1.1.0/24 to both AS3 and AS2. They intend >> >that AS5's traffic should pass through AS3, but that AS4's traffic should >> >only pass through AS2. How can they enforce this policy? >> >> they can't and they ought not expect to be able to enforce that policy! >> As I noted in my comments, there is no presumed ability of ASa to control >> to whom ABb advertises a route once ASa has authorized ASb to advertise >> it. There is no transitive control over advertisement, something we both >> agree upon, I think. > >Yes, but if you enlarge this to the next step, you'll understand the point >of the draft itself. > >-- AS1 cannot force AS2 to advertise something it has authorized AS2 to advertise. >-- AS1 cannot force AS3 not to advertise something which overlaps that > which it has _not_ authorized AS3 to advertise. we seem to be coming back to a wording problem. I don't hear anyone other than you saying that any AS can force any other AS to advertise or not advertise anything. certainly S-BGP does not use these terms. Rather, we talk in terms of what an AS can verify re the advertisements it receives. >In other words, AS1 can refuse to authorize AS3 the ability to advertise >10.1.1.0/24. But, it could so happen that AS3 has the authorization to >advertise 10.1.0.0/16 through some other source, reorigination, perhaps, or >learning it from any other peer. In this case, AS3 will advertise >10.1.0.0/16, which, in fact, overlaps and encompasses 10.1.1.0/24, which >AS1 expressly does _not_ want AS3 to advertise. In your example, if AS3 is authorized by some other source to advertise 10.1.1.0/24, then that's OK. For example, if a subscriber is multi-homed to AS1 and AS3, then the subscriber should be able to authorized both of them to advertise the prefix. There is no conflict there. >Thus, AS1 has no say in whether or not AS3 will advertise 10.1.1.0/24, in >fact. You could argue that AS1 can create a "hole" in the 10.1.0.0/16 >address space AS3 is advertising (legitimately) by advertising the longer >prefix through another path, but that advertisement may be removed at any >point, so that argument doesn't work, either. > >You can prove a valid path exists, but to prove "authorization," you're >going to have to define it more closely than it's currently defined. S-BGP needs to be more precise about how an AS receiving an advertisement determines the authorization of another AS to advertise a prefix of a specific length. My initial model didn't take into account the significance of longer prefixes in route selection, and so our model was too simplistic. Randy Bush and Steve Bellovin pointed out the problem when we did a demo of S-BGP last fall. I believe we have a fix for this, but I don't recall if the latest S-BGP I-D describes the algorithm for determining authorization relative to prefix length. I am open to constructive suggestions on how to improve the definition so that it is as good a characterization of the BGP semantics as possible, and hopefully, still concise and understandable. We all need to agree on these terms to make progress in discussing the issues, as well as in discussing the merits of proposed solutions. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Wed Nov 5 16:45:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25711 for ; Wed, 5 Nov 2003 16:45:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVT8-0000QP-H3 for rpsec-archive@odin.ietf.org; Wed, 05 Nov 2003 16:45:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5LjcPO001623 for rpsec-archive@odin.ietf.org; Wed, 5 Nov 2003 16:45:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVT8-0000Q4-5e for rpsec-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 16:45:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25578 for ; Wed, 5 Nov 2003 16:45:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVT5-00042w-00 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 16:45:35 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHVSr-00040n-05 for rpsec-web-archive@ietf.org; Wed, 05 Nov 2003 16:45:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVIs-0007O7-Lg; Wed, 05 Nov 2003 16:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVHz-0007ND-Hk for rpsec@optimus.ietf.org; Wed, 05 Nov 2003 16:34:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25096 for ; Wed, 5 Nov 2003 16:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVHx-0003r6-00 for rpsec@ietf.org; Wed, 05 Nov 2003 16:34:05 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AHVHx-0003qf-00 for rpsec@ietf.org; Wed, 05 Nov 2003 16:34:05 -0500 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA5LXWxg008288; Wed, 5 Nov 2003 16:33:32 -0500 (EST) Received: from russpc.whitehouse.intra (rtp-vpn2-364.cisco.com [10.82.241.108]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA20725; Wed, 5 Nov 2003 16:33:31 -0500 (EST) Date: Wed, 5 Nov 2003 16:33:28 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Stephen Kent cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] Considerations in Path Security for BGP In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > > > >Actually, you can't. You are assuming that signed > >> >advertisement==authorization, but you've not clarified _whose_ > >> >authorization. This is precisely the problem with policies in a > >> >distributed system, in genera, somce you alude to later in your email. > >> >For instance, if I have this small internetwork: > >> > >> we seem to be speaking different languages. From my perspective, > >> authorization in BGP relates to the right to advertise a prefix, and is > >> granted by an AS when is sends an UPDATE to a neighbor containing the > >> prefix. > >> > >> > AS5 > >> > | > >> > +--AS3--+ > >> >AS1 AS4 > >> > +--AS2--+ > >> > > >> >Suppose AS1 is advertising 10.1.1.0/24 to both AS3 and AS2. They intend > >> >that AS5's traffic should pass through AS3, but that AS4's traffic should > >> >only pass through AS2. How can they enforce this policy? > >> > >> they can't and they ought not expect to be able to enforce that policy! > >> As I noted in my comments, there is no presumed ability of ASa to control > >> to whom ABb advertises a route once ASa has authorized ASb to advertise > >> it. There is no transitive control over advertisement, something we both > >> agree upon, I think. > > > >Yes, but if you enlarge this to the next step, you'll understand the point > >of the draft itself. > > > >-- AS1 cannot force AS2 to advertise something it has authorized AS2 to > advertise. > >-- AS1 cannot force AS3 not to advertise something which overlaps that > > which it has _not_ authorized AS3 to advertise. > > we seem to be coming back to a wording problem. I don't hear anyone other > than you saying that any AS can force any other AS to advertise or not > advertise anything. certainly S-BGP does not use these terms. Rather, we > talk in terms of what an AS can verify re the advertisements it receives. Could you please define what you mean by "authorization?" In my mind, when I say that I authorize you to advertise my prefixes to your peers, then I'm saying that I authorize you to transit traffic from those peers to me. If I refuse to authorize you to advertise my prefixes to your peers, then my intent is that you will not be able to advertise my address space, and thus your peers will not know how to reach my address space through you. Is this correct? If so, then what I'm saying is that you cannot enforce this sort of authorization in BGP, because you can't force another AS not to advertise a shorter prefix containing the prefix you're originating. It's not the same prefix through another path, it's a completely different prefix. AS1 is saying to AS3: "Do _not_ advertise 10.1.1.0/24." AS3 is complying with that policy, as far as it can. AS3 is, however, advertising 10.1.0.0/16, which happens to _contain_ 10.1.1.0/24. Thus, there is no way for AS3 not to advertise the address space AS1 is telling it not to advertise. AS1's lack of authorization to AS3 (which is an expression of policy) is null and void. If you would state that authorization means the ability to prove that a path exists, and expresses nothing about the policies along that path (for instance, AS1's policy is that it won't receive traffic through AS3, but that policy has been overridden, and is thus null and void), then I would agree that you can "authorize" a path. But, then, authorizing a path only means proving the path exists, not that it is "valid" in some policy related way. You can validate the origination, and you can prove a path exists, but "authorization to advertise a prefix received from a peer" simply cannot be proven in BGP. "Authorization" is an expression of policy, and falls within the bounds of not being able validate policies within BGP, simply because of the structure of the routing system. That's the point of the draft. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Nov 6 17:20:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04832 for ; Thu, 6 Nov 2003 17:20:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsUL-0000tY-8y for rpsec-archive@odin.ietf.org; Thu, 06 Nov 2003 17:20:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6MKPAH003436 for rpsec-archive@odin.ietf.org; Thu, 6 Nov 2003 17:20:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsUL-0000tL-4W for rpsec-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 17:20:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04729 for ; Thu, 6 Nov 2003 17:20:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsUI-0001rz-00 for rpsec-web-archive@ietf.org; Thu, 06 Nov 2003 17:20:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsUI-0001rv-00 for rpsec-web-archive@ietf.org; Thu, 06 Nov 2003 17:20:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsTy-0000lk-Ha; Thu, 06 Nov 2003 17:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsTB-0000iF-JL for rpsec@optimus.ietf.org; Thu, 06 Nov 2003 17:19:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04673 for ; Thu, 6 Nov 2003 17:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsT9-0001qg-00 for rpsec@ietf.org; Thu, 06 Nov 2003 17:19:11 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1AHsT8-0001pv-00 for rpsec@ietf.org; Thu, 06 Nov 2003 17:19: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 hA6MIVPd015199; Thu, 6 Nov 2003 17:18:31 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 6 Nov 2003 17:15:51 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Considerations in Path Security for BGP Cc: Routing Protocols Security Working Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > > we seem to be coming back to a wording problem. I don't hear anyone other >> than you saying that any AS can force any other AS to advertise or not >> advertise anything. certainly S-BGP does not use these terms. Rather, we >> talk in terms of what an AS can verify re the advertisements it receives. > >Could you please define what you mean by "authorization?" In my mind, >when I say that I authorize you to advertise my prefixes to your peers, >then I'm saying that I authorize you to transit traffic from those peers to >me. If I refuse to authorize you to advertise my prefixes to your peers, >then my intent is that you will not be able to advertise my address space, >and thus your peers will not know how to reach my address space through >you. > >Is this correct? yes, this is essentially correct. I tend to use terms that are more directly linked to the mechanics of the advertisement, rather than the implications of the advertisement, but either approach is reasonable. >If so, then what I'm saying is that you cannot enforce this sort of >authorization in BGP, because you can't force another AS not to advertise a >shorter prefix containing the prefix you're originating. It's not the same >prefix through another path, it's a completely different prefix. OK, we finally have a clear statement of what I assume is the residual issue, i.e., advertisements of a longer prefix by an AS, relative to the prefix that the AS received in an advertisement. is that right? >AS1 is saying to AS3: "Do _not_ advertise 10.1.1.0/24." I don't agree with this characterization. AS1 can advertise to AS3 and use the community attribute NO_EXPORT to expressly indicate that AS3 is NOT authorized to propagate that advertisement, but you did not mention use of that attribute in your example. (BTW, S-BGP can cover this attribute with the signature applied to UPDATE data, and thus support the enforcement of this control.) But, that's not really the crux of the problem. >AS3 is complying with that policy, as far as it can. >AS3 is, however, advertising 10.1.0.0/16, which happens to _contain_ >10.1.1.0/24. > >Thus, there is no way for AS3 not to advertise the address space AS1 is >telling it not to advertise. AS1's lack of authorization to AS3 (which is >an expression of policy) is null and void. I don't completely agree with the words you are using here. AS3 is legitimately advertising the address space it has been allocated. Yes, that address space subsumes the AS1 address space, because AS3 delegated that space to AS1. The need is for other ASes to be able to determine that the AS1 delegation has occurred. The problem is the inability of BGP to ensure propagation of the AS1 advertisement. The tricky part is that if ASa sees the AS3 advertisement and not the AS1 advertisement, and if ASa has no other source of information to alert it to the AS1 delegation, then ASa has no way of knowing that AS1 has not authorized AS3 to advertise the longer prefix that AS1 now controls. As I mentioned earlier, one ought not talk in terms of an AS projecting its policy onto other ASes, because that is not a concept generally offered by BGP (except in the limited case of the community attribute) and because it is generally unenforceable. Your example is, I fear, not a good one, for the point you are trying to make. Let me suggest a refinement of your original example. First, AS5 has only one path in your example, which makes it a poor choice to run BGP. Also, since that path is through AS3, it is obvious that AS5 is at the mercy of AS3, i.e., AS5 will never learn anything about the rest of the Internet except what AS3 tells it. In a situation of this sort, since AS5 really has only path to the rest of the Internet, it's pretty clear that we can't do much to help it in many practical respects. But, we could revise your example and still use it to examine the issue you are trying to explore. Just add a path from AS5 to a new AS (AS6), and from AS6 to AS4, resulting in the following diagram: AS5--AS6-+ | | +--AS3--+ | AS1 AS4-+ +--AS2--+ Now, I'll set the stage, filling in some details that were not made explicit in your initial description of the example, and add some of my own details that I think make this a better example: AS1 is a subscriber originating 10.1.1.0/24, a sub-allocation from AS3 AS3 is an ISP, originating 10.1.0.0/16 AS2 is an ISP to which AS1 is also attached assume AS4, 5 and 6 are ISPs, wlog What is AS1 trying to do? You were not completely clear on the goal of AS1. If AS1 has totally unrealistic expectations then it is hopeless. Let's say that AS1's goal is to not have any traffic destined to its /24 address block transit AS3. So AS1 ought to advertise to AS3 using the community attribute NO_EXPORT, which is an explicit of saying that the advertisement is meant only for local consumption. I assume that AS1 does want traffic from AS3 subscribers to flow over this link. Otherwise, if AS1 wants NO traffic to ever enter it via AS3, why have the link to AS3? if the link is for backup, then we need to talk about the validity period for an authorization, but let's not address that for now. Now AS1 can advertise 10.1.1.0/24 to AS2 in hopes that traffic from the rest of the Internet will flow to this prefix via AS2, the only other connection that AS1 has to the rest of the Internet. This will work IF the rest of the Internet sees the advertisement from AS1. But there is no guarantee that this will happen, e.g., if AS2's local policy causes it to not propagate the AS1 advertisement, then AS1's goal is thwarted. But, if AS2 didn't propagate the AS1 advertisement there would be a serious misunderstanding between these two peers, so let's assume that AS2 does not suppress the AS1 advertisement, i.e., AS2 does propagate the AS1 advertisement to AS4. AS3 is legitimately advertising its prefix, 10.1.0.0/16 to AS4 and AS5. AS4, having received both the /16 and /24 advertisements would choose the /24 for the AS1 traffic, as intended, if AS4 is operating properly. So far so good. Note that AS4 might well send the AS1 advertisement it received from AS2, to AS3. If AS3 passes this advertisement on to AS5, then AS5 might send AS1 traffic to AS3, legitimately. So, AS1 really should understand that it cannot prevent some traffic destined to it's /24 from traversing AS3, because AS3 might legitimately be on a path to AS1 from some other ASes! This again raises the question of what AS1 thinks it will accomplish by not explicitly authorizing AS3 to advertise the /24. But, to focus on what I think was the point of your example, let's assume that AS4 does not pass on the AS1 advertisement to AS3, due to some local policy rule in AS4. Also, the folks at AS6, for some local policy reason, fail to propagate the AS1 advertisement they receive from AS4. That means that AS5 will see only the AS3 advertisement for 10.1.0.0/16, and not the 10.1.1.0/24 advertisement originated by AS1. Now AS5 will send traffic for AS1 to AS3, even though that was exactly what AS1 did not want to happen, and even though AS1 did its best to prevent this traffic flow by NOT authorizing AS3 to advertise the longer prefix. This, I believe was your point. Let's try to make a more general statement of the problem. When there are two prefixes P and P', with P' a subset of P, then if an AS does not see advertisements for P' (e.g., because of local policies in ASes that lie on paths between the origin for P' and these other ASes), but does see an advertisement for P, it will accept the advertisement for P, all else being equal. ASes that do not see an advertisement for P' will naturally route traffic for P' via paths for P, because P subsumes P'. In this case, I would say that the advertisement for P is authorized, but the lack of pervasive knowledge of the existence of a distinct advertisement for P' means that the subsuming advertisement is misleading for those folks who fail to learn about the path for P'. Now this problem arises because of the inability of AS1 to ensure that its longer prefix will be seen by all other ASes. Yes, I agree that this is a limitation intrinsic in BGP. A fair question to ask is what can be done to ameliorate this problem. One can also ask how serious is the problem? After all, AS1 encountered the problem because it had a prefix that was allocated by AS3, and then it decided that it didn't want to have AS3 be a transit AS for its traffic. Althought it might be a painful exercise, AS1 could renumber using a newly assigned prefix, e.g., acquired from an RIR, and avoid the problem. More significantly, as noted above, there is generally no way for ANY AS to ensure that traffic for a prefix originated by it will NOT traverse another AS, at least from some sources. This is true even if the prefix originated by the AS in question is directly allocated by an RIR. it would seem that the best we can do is to limit the number of ASes that can create advertisements for the prefix in question, to minimize the opportunities for misrouting. In S-BGP, we provide some mechanisms that are relevant to this problem. First we allow attributes other than the path attribute to be included in the signed data. So, for example, the community attribute can be protected and, as noted above, that would prevent AS3 from using an advertisement by AS1 to AS3 from being further propagated. (If AS3 forwarded the advertisement with the NO-EXPORT flag, other ASes would reject it, and if AS3 stripped the attribute, other ASes would detect the tampering.) S-BGP uses repositories to distribute certs, AAs, and CRLs. The AA and cert databases would indicate that AS1 is the owner of the longer prefix (10.1.1.0/24), and would contain an AA issued under that cert to AS1, because AS1 would post that information. So any AS that participated in S-BGP would learn of the existence of the /24 prefix and would know that AS1, not AS3, was the origin for this prefix. If AS1 did not authorize AS3 to advertise the /24, then AS3's advertisement of the /16 would not cause other ASes to send the /24 traffic to AS3, since they would know that the /16 was not an authorization for the /24 that it subsumes. That does not ensure that other ASes will ever learn of ANY route to AS1 for its /24 prefix, because we cannot guarantee that routes are propagated everywhere. Thus ASes might be left knowing that the advertisement they have for the /16 is NOT authorized for the /24 traffic, but they still might not know what to do with that /24 traffic. But at least we have a means of preventing AS3 from advertising the AS1 address space if AS1 does not want AS3 to do so. Also, S-BGP says that an AS may not use its authorization to advertise a prefix P to advertise a prefix P' of greater length, subsumed by P. Sorry for the length of this message, but it seemed necessary to fully describe the example and to explore in detail the issues you raised about what it means to be authorized to advertise a path, and what are the realistic expectations that an AS can have re the implications of authorized advertisements. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Nov 6 19:34:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10195 for ; Thu, 6 Nov 2003 19:34:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHuZj-0000d0-Ql for rpsec-archive@odin.ietf.org; Thu, 06 Nov 2003 19:34:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA70Y7sd002414 for rpsec-archive@odin.ietf.org; Thu, 6 Nov 2003 19:34:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHuZj-0000cr-Jc for rpsec-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 19:34:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10189 for ; Thu, 6 Nov 2003 19:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHuZh-0003WZ-00 for rpsec-web-archive@ietf.org; Thu, 06 Nov 2003 19:34:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHuZh-0003WW-00 for rpsec-web-archive@ietf.org; Thu, 06 Nov 2003 19:34:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHuZc-0000bb-6t; Thu, 06 Nov 2003 19:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHuZY-0000bN-9Z for rpsec@optimus.ietf.org; Thu, 06 Nov 2003 19:33:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10183 for ; Thu, 6 Nov 2003 19:33:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHuZW-0003WN-00 for rpsec@ietf.org; Thu, 06 Nov 2003 19:33:54 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AHuZV-0003WB-00 for rpsec@ietf.org; Thu, 06 Nov 2003 19:33:54 -0500 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA70XLxg009444; Thu, 6 Nov 2003 19:33:22 -0500 (EST) Received: from russpc.whitehouse.intra (rtp-vpn2-37.cisco.com [10.82.240.37]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA17416; Thu, 6 Nov 2003 19:33:21 -0500 (EST) Date: Thu, 6 Nov 2003 19:33:17 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Stephen Kent cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] Considerations in Path Security for BGP In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > > we seem to be coming back to a wording problem. I don't hear anyone > > other than you saying that any AS can force any other AS to advertise > > or not advertise anything. certainly S-BGP does not use these terms. > > Rather, we talk in terms of what an AS can verify re the advertisements > > it receives. > > > >Could you please define what you mean by "authorization?" In my mind, > >when I say that I authorize you to advertise my prefixes to your peers, > >then I'm saying that I authorize you to transit traffic from those peers > >to me. If I refuse to authorize you to advertise my prefixes to your > >peers, then my intent is that you will not be able to advertise my > >address space, and thus your peers will not know how to reach my address > >space through you. > > > >Is this correct? > > yes, this is essentially correct. I tend to use terms that are more > directly linked to the mechanics of the advertisement, rather than the > implications of the advertisement, but either approach is reasonable. > > >If so, then what I'm saying is that you cannot enforce this sort of > >authorization in BGP, because you can't force another AS not to > >advertise a shorter prefix containing the prefix you're originating. > >It's not the same prefix through another path, it's a completely > >different prefix. > > OK, we finally have a clear statement of what I assume is the residual > issue, i.e., advertisements of a longer prefix by an AS, relative to the > prefix that the AS received in an advertisement. is that right? No, a shorter prefix, not a longer one. > >AS1 is saying to AS3: "Do _not_ advertise 10.1.1.0/24." > > I don't agree with this characterization. AS1 can advertise to AS3 and > use the community attribute NO_EXPORT to expressly indicate that AS3 is > NOT authorized to propagate that advertisement, but you did not mention > use of that attribute in your example. (BTW, S-BGP can cover this > attribute with the signature applied to UPDATE data, and thus support the > enforcement of this control.) But, that's not really the crux of the > problem. I'm not arguing S-BGP here, or any other specific mechanism. I'm discussing what is possible within the routing system, not what is possible to encode in the advertisements. It doesn't matter how you encode, at AS1, that AS3 should not advertise AS1's address space. AS1 cannot enforce this policy, because AS3 can, through other means, simply advertise a shorter prefix, an aggregate, or a reorigination. It's not the same thing at all. Since AS1's address space happens to be contained within the address space AS3 is advertising, there is no way to actually encode this policy--"don't use this path"--in any meaningful way within BGP, or any other routing system, actually. > >AS3 is complying with that policy, as far as it can. > >AS3 is, however, advertising 10.1.0.0/16, which happens to _contain_ > >10.1.1.0/24. > > > >Thus, there is no way for AS3 not to advertise the address space AS1 is > >telling it not to advertise. AS1's lack of authorization to AS3 (which is > >an expression of policy) is null and void. > > I don't completely agree with the words you are using here. AS3 is > legitimately advertising the address space it has been allocated. Yes, > that address space subsumes the AS1 address space, because AS3 delegated > that space to AS1. The need is for other ASes to be able to determine > that the AS1 delegation has occurred. The problem is the inability of BGP > to ensure propagation of the AS1 advertisement. Or perhaps AS3 is picking up the aggregate from someplace else, it doesn't matter how or why AS3 ias actually advertising the aggregate. 10.1.0.0/16 contains 10.1.1.0/24, in IP terms. If you're "authorized" to advertise a route to 10.1.0.0/16, then you're stating you're "authorized" to route every possible subnet of the /16, including one that you've been specifically told, through any means you might choose, _not_ to route for. There's no way, in BGP, or any other routing protocol, to provide a "negative update." > The tricky part is that if ASa sees the AS3 advertisement and not the AS1 > advertisement, and if ASa has no other source of information to alert it > to the AS1 delegation, then ASa has no way of knowing that AS1 has not > authorized AS3 to advertise the longer prefix that AS1 now controls. As I > mentioned earlier, one ought not talk in terms of an AS projecting its > policy onto other ASes, because that is not a concept generally offered > by BGP (except in the limited case of the community attribute) and > because it is generally unenforceable. In reality, the last AS that handles the prefix _always_ projects it's policy on every AS before it in the AS Path. This is true because the last AS in the path can simply filter it. Again, it comes down to: "whose policy?" > Your example is, I fear, not a good one, for the point you are trying to > make. Let me suggest a refinement of your original example. > > First, AS5 has only one path in your example, which makes it a poor > choice to run BGP. Also, since that path is through AS3, it is > obvious that AS5 is at the mercy of AS3, i.e., AS5 will never learn > anything about the rest of the Internet except what AS3 tells it. In > a situation of this sort, since AS5 really has only path to the rest > of the Internet, it's pretty clear that we can't do much to help it > in many practical respects. > > But, we could revise your example and still use it to examine the > issue you are trying to explore. Just add a path from AS5 to a new AS > (AS6), and from AS6 to AS4, resulting in the following diagram: > > > AS5--AS6-+ > | | > +--AS3--+ | > AS1 AS4-+ > +--AS2--+ > > > Now, I'll set the stage, filling in some details that were not made > explicit in your initial description of the example, and add some of > my own details that I think make this a better example: > > AS1 is a subscriber originating 10.1.1.0/24, a sub-allocation from AS3 > AS3 is an ISP, originating 10.1.0.0/16 > AS2 is an ISP to which AS1 is also attached > assume AS4, 5 and 6 are ISPs, wlog > .... > But, to focus on what I think was the point of your example, let's assume > that AS4 does not pass on the AS1 advertisement to AS3, due to some local > policy rule in AS4. Also, the folks at AS6, for some local policy > reason, fail to propagate the AS1 advertisement they receive from AS4. > That means that AS5 will see only the AS3 advertisement for 10.1.0.0/16, > and not the 10.1.1.0/24 advertisement originated by AS1. > > Now AS5 will send traffic for AS1 to AS3, even though that was exactly > what AS1 did not want to happen, and even though AS1 did its best to > prevent this traffic flow by NOT authorizing AS3 to advertise the longer > prefix. This, I believe was your point. > > Let's try to make a more general statement of the problem. When there are > two prefixes P and P', with P' a subset of P, then if an AS does not see > advertisements for P' (e.g., because of local policies in ASes that lie > on paths between the origin for P' and these other ASes), but does see an > advertisement for P, it will accept the advertisement for P, all else > being equal. ASes that do not see an advertisement for P' will naturally > route traffic for P' via paths for P, because P subsumes P'. > > In this case, I would say that the advertisement for P is authorized, but > the lack of pervasive knowledge of the existence of a distinct > advertisement for P' means that the subsuming advertisement is misleading > for those folks who fail to learn about the path for P'. Thus, the path in the "authorized" advertisement can say nothing about the policies of the AS' along the path, including their willingness to accept traffic along the path. Which means that a path cannot be "authorized" in the way it's defined in the beginning of this email. It can only be proven to exist, or not to exist. > Now this problem arises because of the inability of AS1 to ensure that > its longer prefix will be seen by all other ASes. Yes, I agree that this > is a limitation intrinsic in BGP. A fair question to ask is what can be > done to ameliorate this problem. One can also ask how serious is the > problem? After all, AS1 encountered the problem because it had a prefix > that was allocated by AS3, and then it decided that it didn't want to > have AS3 be a transit AS for its traffic. Althought it might be a painful > exercise, AS1 could renumber using a newly assigned prefix, e.g., > acquired from an RIR, and avoid the problem. > > More significantly, as noted above, there is generally no way for ANY AS > to ensure that traffic for a prefix originated by it will NOT traverse > another AS, at least from some sources. This is true even if the prefix > originated by the AS in question is directly allocated by an RIR. it > would seem that the best we can do is to limit the number of ASes that > can create advertisements for the prefix in question, to minimize the > opportunities for misrouting. Exactly. Then you cannot "secure" a path in the sense that an advertiser is _gauranteed_ to be "authorized" to transit traffic for the address blocks in the advertisement. The rest of this concerns S-BGP, which I'm not trying to discuss here, so I've snipped it out. If the above is true, it doesn't matter how many signatures, databases, and other security measures you wrap around BGP, the information isn't in BGP to secure. So, there's no way, with the current routing system, to "gaurantee" that an "authorized" advertisement also implies "authorization to transit," or imply any sort of other policy from that advertisement. You could always attempt to _add_ this information, but aggregration, reorigination, and other systems of this type are the key to scalable routing. You either have a choice of elimintating aggregation and filtering, or simply not attempting to claim "authorization" within a routing system in this way. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Thu Nov 6 20:39:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11962 for ; Thu, 6 Nov 2003 20:39:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvag-00044J-RP for rpsec-archive@odin.ietf.org; Thu, 06 Nov 2003 20:39:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA71dAmc015633 for rpsec-archive@odin.ietf.org; Thu, 6 Nov 2003 20:39:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvag-000444-Mp for rpsec-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 20:39:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11948 for ; Thu, 6 Nov 2003 20:38:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvae-0004IS-00 for rpsec-web-archive@ietf.org; Thu, 06 Nov 2003 20:39:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHvad-0004IP-00 for rpsec-web-archive@ietf.org; Thu, 06 Nov 2003 20:39:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvaX-00042c-G4; Thu, 06 Nov 2003 20:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHva6-0003yr-9w for rpsec@optimus.ietf.org; Thu, 06 Nov 2003 20:38:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11928 for ; Thu, 6 Nov 2003 20:38:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHva3-0004Hr-00 for rpsec@ietf.org; Thu, 06 Nov 2003 20:38:31 -0500 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=arneill-py.sacramento.ca.us) by ietf-mx with esmtp (Exim 4.12) id 1AHva3-0004HJ-00 for rpsec@ietf.org; Thu, 06 Nov 2003 20:38:31 -0500 Subject: RE: [RPSEC] Considerations in Path Security for BGP MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Nov 2003 17:38:01 -0800 Content-class: urn:content-classes:message Message-ID: x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: [RPSEC] Considerations in Path Security for BGP Thread-Index: AcOkxtjwwygUmlf8R8eJh8XTAdpv9AABzZyQ From: "Michel Py" To: "Russ White" Cc: "Routing Protocols Security Working Group" Content-Transfer-Encoding: quoted-printable Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Russ and rpsec folks, > Russ White wrote: > Or perhaps AS3 is picking up the aggregate from someplace > else, it doesn't matter how or why AS3 ias actually > advertising the aggregate. 10.1.0.0/16 contains 10.1.1.0/24, > in IP terms. If you're "authorized" to advertise a route to > 10.1.0.0/16, then you're stating you're "authorized" to > route every possible subnet of the /16, including one that > you've been specifically told, through any means you might > choose, _not_ to route for. > There's no way, in BGP, or any other routing protocol, to > provide a "negative update." I'm sorry I missed a large part of this thread; I've been distracted by annoyances such as work, customers, bugs and so on :-) Anyway, concerning "negative updates", you might want to have a quick look at: http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-01.txt Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Nov 7 10:34:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18806 for ; Fri, 7 Nov 2003 10:34:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8cr-0003MP-74 for rpsec-archive@odin.ietf.org; Fri, 07 Nov 2003 10:34:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7FYHen012911 for rpsec-archive@odin.ietf.org; Fri, 7 Nov 2003 10:34:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8cr-0003MA-1l for rpsec-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 10:34:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18801 for ; Fri, 7 Nov 2003 10:34:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8co-0006TB-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 10:34:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI8co-0006T8-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 10:34:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8ca-0003Kd-Ra; Fri, 07 Nov 2003 10:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8cL-0003KM-Eb for rpsec@optimus.ietf.org; Fri, 07 Nov 2003 10:33:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18793 for ; Fri, 7 Nov 2003 10:33:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8cJ-0006Sr-00 for rpsec@ietf.org; Fri, 07 Nov 2003 10:33:43 -0500 Received: from wolfe.bbn.com ([128.89.80.22]) by ietf-mx with esmtp (Exim 4.12) id 1AI8cI-0006SU-00 for rpsec@ietf.org; Fri, 07 Nov 2003 10:33:42 -0500 Received: by wolfe.bbn.com (Postfix, from userid 13538) id 15EEE16484; Fri, 7 Nov 2003 10:33:07 -0500 (EST) From: Charles Lynn To: rpsec@ietf.org Message-Id: <20031107153307.15EEE16484@wolfe.bbn.com> Date: Fri, 7 Nov 2003 10:33:07 -0500 (EST) Subject: [RPSEC] Use of external information for RP security Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Trying to step back from the recent dialog on the subject of: Considerations in Path Security for BGP do folks think that there is an issue with using information not carried in a given RP's PDUs to increase the security of the RP? A few examples of possible information or databases are: * Certificates (of whatever flavor) * DNS[SEC] * Internet Routing Registry * NOC "configuration" files (at least for intra-AS RPs) * RADIUS/Diameter/IPsec * Regional Internet Registry * etc. If such "external" sources of information are used, I think that they would need to be included within the "security perimeter"; their integrity, correctness, authentication, availability, and "freshness" would have to be considered when evaluating risks and threats for an RP. Should such external sources be "in scope" or "out of scope" as mechanisms that to be be considered when securing an RP? If some are in scope, but others out of scope, where should the line be drawn? A la "there is more to a protocol than PDU formats", but how much more. Charlie _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Nov 7 13:43:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28545 for ; Fri, 7 Nov 2003 13:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBZg-0006aT-N9 for rpsec-archive@odin.ietf.org; Fri, 07 Nov 2003 13:43:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7IhCPw025315 for rpsec-archive@odin.ietf.org; Fri, 7 Nov 2003 13:43:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBZg-0006aE-JK for rpsec-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 13:43:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28533 for ; Fri, 7 Nov 2003 13:43:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBZe-00013D-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 13:43:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIBZd-000138-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 13:43:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBZV-0006ZQ-5Z; Fri, 07 Nov 2003 13:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBZN-0006Z4-55 for rpsec@optimus.ietf.org; Fri, 07 Nov 2003 13:42:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28522 for ; Fri, 7 Nov 2003 13:42:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBZK-00012n-00 for rpsec@ietf.org; Fri, 07 Nov 2003 13:42:50 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AIBZK-00012d-00 for rpsec@ietf.org; Fri, 07 Nov 2003 13:42:50 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 79E1C3586F for ; Fri, 7 Nov 2003 19:41:13 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 6D1573F494 for ; Fri, 7 Nov 2003 17:26:09 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003110717260805525 for ; Fri, 07 Nov 2003 17:26:08 +0100 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 101103F494 for ; Fri, 7 Nov 2003 17:25:29 +0100 (CET) Received: from jjp by localhost with local id 1AI9Py-0000LW-00 for ; Fri, 07 Nov 2003 17:25:02 +0100 Date: Fri, 7 Nov 2003 17:25:02 +0100 From: Jean-Jacques Puig To: rpsec@ietf.org Subject: Re: [RPSEC] Use of external information for RP security Message-ID: <20031107162502.GB32054@ivan.int-evry.fr> Mail-Followup-To: rpsec@ietf.org References: <20031107153307.15EEE16484@wolfe.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031107153307.15EEE16484@wolfe.bbn.com> Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Hi ! On Fri, Nov 07, 2003 at 10:33:07AM -0500, Charles Lynn wrote: > Trying to step back from the recent dialog on the subject of: > Considerations in Path Security for BGP > do folks think that there is an issue with using information not > carried in a given RP's PDUs to increase the security of the RP? Availability of the information when there are no routes may be :). There may also be stupid locks (I want to check the cert server for validity of the route leading to the cert server...). However, I'm also interested in these methods. I think there is very little hope to get some inter-domain security without these. > > A few examples of possible information or databases are: > * Certificates (of whatever flavor) > * DNS[SEC] > * Internet Routing Registry > * NOC "configuration" files (at least for intra-AS RPs) > * RADIUS/Diameter/IPsec > * Regional Internet Registry > * etc. > > If such "external" sources of information are used, I think that they > would need to be included within the "security perimeter"; their > integrity, correctness, authentication, availability, and "freshness" > would have to be considered when evaluating risks and threats for an RP. True. I plan to develop on this in the requirements doc. > Should such external sources be "in scope" or "out of scope" as > mechanisms that to be be considered when securing an RP? I think so. But may be we should discuss on this in the rpsec session ? > If some are in scope, but others out of scope, where should the line > be drawn? A la "there is more to a protocol than PDU formats", but > how much more. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Nov 7 14:57:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04092 for ; Fri, 7 Nov 2003 14:57:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICjP-0004Kr-Vu for rpsec-archive@odin.ietf.org; Fri, 07 Nov 2003 14:57:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7JvJgL016659 for rpsec-archive@odin.ietf.org; Fri, 7 Nov 2003 14:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICjP-0004Kc-SN for rpsec-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 14:57:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04081 for ; Fri, 7 Nov 2003 14:57:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICjM-000295-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 14:57:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AICjA-00028z-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 14:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICj7-0004GP-Lr; Fri, 07 Nov 2003 14:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICi9-0004Dp-9P for rpsec@optimus.ietf.org; Fri, 07 Nov 2003 14:56:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04053 for ; Fri, 7 Nov 2003 14:55:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICi6-00028D-00 for rpsec@ietf.org; Fri, 07 Nov 2003 14:55:58 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1AICi5-00027L-00 for rpsec@ietf.org; Fri, 07 Nov 2003 14:55:57 -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 hA7Jt5Pd004021; Fri, 7 Nov 2003 14:55:05 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 7 Nov 2003 14:52:31 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Considerations in Path Security for BGP Cc: Routing Protocols Security Working Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > > > OK, we finally have a clear statement of what I assume is the residual >> issue, i.e., advertisements of a longer prefix by an AS, relative to the >> prefix that the AS received in an advertisement. is that right? > >No, a shorter prefix, not a longer one. OK, from your perspective its the advertisement of the shorter prefix that is the problem, and from my perspective it is the non-advertisement of the longer one that's the problem. Half-full vs half-empty? > >I'm not arguing S-BGP here, or any other specific mechanism. I'm discussing >what is possible within the routing system, not what is possible to encode >in the advertisements. It doesn't matter how you encode, at AS1, that AS3 >should not advertise AS1's address space. AS1 cannot enforce this policy, >because AS3 can, through other means, simply advertise a shorter prefix, an >aggregate, or a reorigination. we agree on the inability of ANY AS to impose its policy on another AS. I've said that several times, so I am at a loss to understand why you keep raising this as an issue. It makes no sense to speak in terms of ASx enforcing its policy outside the context of ASx! It is not a limitation of this example of of path authorization, it is intrinsic in the nature of BGP. >It's not the same thing at all. Since AS1's address space happens to be >contained within the address space AS3 is advertising, there is no way to >actually encode this policy--"don't use this path"--in any meaningful way >within BGP, or any other routing system, actually. Ido not understand why you keep saying that AS1 is trying to prevent traffic for its /24 from traversing AS3. We know AS1 cannot cause this to happen; I gave an example showing why such traffic might legitimately traverse AS3 even if every other AS is aware of the advertisement from AS1. Your statement re the inability to express "don't use this path" is certainly true here, but its not relevant to the discussion. > > >Or perhaps AS3 is picking up the aggregate from someplace else, it doesn't >matter how or why AS3 ias actually advertising the aggregate. 10.1.0.0/16 >contains 10.1.1.0/24, in IP terms. If you're "authorized" to advertise a >route to 10.1.0.0/16, then you're stating you're "authorized" to route >every possible subnet of the /16, including one that you've been >specifically told, through any means you might choose, _not_ to route for. > >There's no way, in BGP, or any other routing protocol, to provide a >"negative update." Russ, you keep creating phrases, e.g., "negative update" to support some notion, but you are not communicating this notion effectively. > >SNIP> > >In reality, the last AS that handles the prefix _always_ projects it's >policy on every AS before it in the AS Path. This is true because the last >AS in the path can simply filter it. Again, it comes down to: "whose >policy?" Nonsense. An AS choose what info to pass to its peers. But, it cannot control what info these peers receive via connections to other ASes, in general. And it certainly cannot control HOW the other ASes use the info that is provided. So it just seems silly to think than an AS projects its policy on its peers. After all, AS stands for AUTONOMOUS system. That should be a hint :-) > > > >Thus, the path in the "authorized" advertisement can say nothing about the >policies of the AS' along the path, including their willingness to accept >traffic along the path. Which means that a path cannot be "authorized" in >the way it's defined in the beginning of this email. It can only be proven >to exist, or not to exist. You seem to be redefining the term "authorized" so as to use it as a strawman. Please stop doing that; it's not constructive. > > >Exactly. Then you cannot "secure" a path in the sense that an advertiser is >_gauranteed_ to be "authorized" to transit traffic for the address blocks >in the advertisement. You've moved from "authorized path" to "secure a path," another term you have defined to serve your purposes. The pile of strawmen you are trying to create is way too high at this point :-) > > >You could always attempt to _add_ this information, but aggregration, >reorigination, and other systems of this type are the key to scalable >routing. You either have a choice of elimintating aggregation and >filtering, or simply not attempting to claim "authorization" within a >routing system in this way. Aggregation is not a problem; one can preserve the authorization info from the advertisements that an AS receives and that transitively authorize it to send an aggregated advertisement. That is consistent with the authorization model we have developed. I looked for the term "reorigination" and didn't find it in any BGP spec. I've been told that this term refers to a practice in which an AS asserts itself as an origin for a prefix, when in fact if is not. Where I come from this is called "lying" :-) Nonetheless, we already make use of a mechanism that allows the owner of a prefix to authorize an AS to advertise itself as an origin AS. The normal use of this is to authorize an AS to which one is attached to advertise in this fashion, but if reorigination really is a requirement I suspect it can be supported as well, using this mechanism; it would just be an example of delegation of authorization to advertise in a different context. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Nov 7 15:54:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07289 for ; Fri, 7 Nov 2003 15:54:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDcK-0007my-Bh for rpsec-archive@odin.ietf.org; Fri, 07 Nov 2003 15:54:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Ks48O029934 for rpsec-archive@odin.ietf.org; Fri, 7 Nov 2003 15:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDcK-0007mj-8L for rpsec-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 15:54:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07281 for ; Fri, 7 Nov 2003 15:53:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDcI-0002nb-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 15:54:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDcI-0002nY-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 15:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDcH-0007lA-2r; Fri, 07 Nov 2003 15:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDcE-0007kw-PF for rpsec@optimus.ietf.org; Fri, 07 Nov 2003 15:53:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07275 for ; Fri, 7 Nov 2003 15:53:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDcD-0002nP-00 for rpsec@ietf.org; Fri, 07 Nov 2003 15:53:57 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AIDcC-0002nD-00 for rpsec@ietf.org; Fri, 07 Nov 2003 15:53:56 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2003 12:55:52 -0800 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA7KrOxg008953; Fri, 7 Nov 2003 15:53:24 -0500 (EST) Received: from russpc.whitehouse.intra (rtp-vpn2-37.cisco.com [10.82.240.37]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA29283; Fri, 7 Nov 2003 15:53:23 -0500 (EST) Date: Fri, 7 Nov 2003 15:53:20 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Stephen Kent cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] Considerations in Path Security for BGP In-Reply-To: Message-ID: References: X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > >It's not the same thing at all. Since AS1's address space happens to be > >contained within the address space AS3 is advertising, there is no way to > >actually encode this policy--"don't use this path"--in any meaningful way > >within BGP, or any other routing system, actually. > > I do not understand why you keep saying that AS1 is trying to prevent > traffic for its /24 from traversing AS3. We know AS1 cannot cause > this to happen; I gave an example showing why such traffic might > legitimately traverse AS3 even if every other AS is aware of the > advertisement from AS1. Your statement re the inability to express > "don't use this path" is certainly true here, but its not relevant to > the discussion. -- Going back a couple of emails: > Could you please define what you mean by "authorization?" In my mind, > when I say that I authorize you to advertise my prefixes to your peers, > then I'm saying that I authorize you to transit traffic from those peers > to me. If I refuse to authorize you to advertise my prefixes to your > peers, then my intent is that you will not be able to advertise my > address space, and thus your peers will not know how to reach my address > space through you. > > Is this correct? And you said: > yes, this is essentially correct. I tend to use terms that are more > directly linked to the mechanics of the advertisement, rather than the > implications of the advertisement, but either approach is reasonable. -- So, if this is still a correct definition of authorization: -- AS Paths cannot contain authorization in any sense -- Receipt of an update cannot prove authorization -- Lack of an update cannot prove lack of authorization You can prove an AS Path is valid, in the sense that it exists, but you cannot, in any sense, claim any sort of "authorization" to do anything expressed through the receipt or lack of receipt of an advertisement. > Nonsense. An AS choose what info to pass to its peers. But, it cannot > control what info these peers receive via connections to other ASes, in > general. And it certainly cannot control HOW the other ASes use the info > that is provided. So it just seems silly to think than an AS projects its > policy on its peers. After all, AS stands for AUTONOMOUS system. That > should be a hint :-) Okay, so you're saying that when I set my MED, I'm not expressing a policy, and when you set your Local Pref, you're not overriding my policy? You may choose to advertise a /25 to me, and I choose to block it inbound at my border. How, exactly, is that not imposing my policy on you? > >Thus, the path in the "authorized" advertisement can say nothing about > >the policies of the AS' along the path, including their willingness to > >accept traffic along the path. Which means that a path cannot be > >"authorized" in the way it's defined in the beginning of this email. It > >can only be proven to exist, or not to exist. > > You seem to be redefining the term "authorized" so as to use it as a > strawman. Please stop doing that; it's not constructive. No, I'm using it as it's defined above--the definition you agreed is correct. > Aggregation is not a problem; one can preserve the authorization info > from the advertisements that an AS receives and that transitively > authorize it to send an aggregated advertisement. That is consistent with > the authorization model we have developed. So, what do you mean by "authorization" in the above sentence, in reference to an AS Path or an update? You state you are authorizing a peer to readvertise an update, but what, exactly, do you intend to imply with this authorization? According to the definition above, the authorization to transit traffic through the path. > I looked for the term "reorigination" and didn't find it in any BGP spec. > I've been told that this term refers to a practice in which an AS asserts > itself as an origin for a prefix, when in fact if is not. Where I come > from this is called "lying" :-) Then ISP's must commonly lie. :-) Re-origination means: I own 10.1.0.0/16, and I hand off to you 10.1.1.0/24. At my border, I simply block your advertisement of 10.1.1.0/24, and instead, originate 10.1.0.0/16. Thus, I'm "re-originating" your address space, within a larger address space. The difference, in Cisco IOS terms, is this: router bgp xxx aggregate-address 10.1.0.0 255.255.0.0 summary-only and ip route 10.1.0.0 255.255.0.0 null ! router bgp xxx network 10.1.0.0 mask 255.255.0.0 Others may call it something else, but it's a fairly common practice, and it wipes out all the prior AS Path information. It's also perfectly legal, etc. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Nov 7 19:06:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15414 for ; Fri, 7 Nov 2003 19:06:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGcN-0003TR-06 for rpsec-archive@odin.ietf.org; Fri, 07 Nov 2003 19:06:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA806IKN013352 for rpsec-archive@odin.ietf.org; Fri, 7 Nov 2003 19:06:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGcM-0003TH-St for rpsec-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 19:06:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15392 for ; Fri, 7 Nov 2003 19:06:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIGcJ-0005NK-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 19:06:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIGcI-0005NG-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 19:06:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGc5-0003QY-RB; Fri, 07 Nov 2003 19:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIGbV-0003Nj-Ag for rpsec@optimus.ietf.org; Fri, 07 Nov 2003 19:05:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15361 for ; Fri, 7 Nov 2003 19:05:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIGbS-0005MK-00 for rpsec@ietf.org; Fri, 07 Nov 2003 19:05:22 -0500 Received: from ginseng.lcs.mit.edu ([18.31.0.38] ident=[2Dl2t+cGHqqPLyHwjf196FNjw2TWNtOW]) by ietf-mx with esmtp (Exim 4.12) id 1AIGbR-0005MH-00 for rpsec@ietf.org; Fri, 07 Nov 2003 19:05:21 -0500 Received: from ginseng.lcs.mit.edu (localhost.localdomain [127.0.0.1]) by ginseng.lcs.mit.edu (8.12.9/8.12.5) with ESMTP id hA804uH3015754; Fri, 7 Nov 2003 19:04:56 -0500 Received: (from feamster@localhost) by ginseng.lcs.mit.edu (8.12.9/8.12.9/Submit) id hA804t5D015752; Fri, 7 Nov 2003 19:04:55 -0500 Date: Fri, 7 Nov 2003 19:04:55 -0500 From: Nick Feamster To: Stephen Kent Cc: Russ White , Routing Protocols Security Working Group Subject: Re: [RPSEC] Considerations in Path Security for BGP Message-ID: <20031108000455.GB15599@lcs.mit.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Hi Steve, > We agree that one cannot ensure that traffic will actually follow the > advertised path, but this is true for ANY routing protocol. I think the larger point is that BGP can have inconsistencies (say, introduced by IGP and iBGP, inconsistencies within an AS, etc.) that cause an AS to "say one thing and do another", depending on which router in that AS you're considering. > You argue that the path cannot be verified to be consistent with > policies of all the ASes along the route. This is true, but I'm not > sure we should care too much about this. In general, the policies of > an AS are locally imposed, and not disclosed to others. So, it may > not be possible for anyone external to an AS to determine whether the > AS is even following its own policies. > Moreover, it is silly to > assume that one AS can impose its policies on another AS, not under > its administrative control. So, the bottom line is that an AS policy > re routing is purely a local (intra-domain) matter and in an effort > to secure intra-domain routing it is not of much relevance. The point is not that one AS cannot impose policies on another. The point is that an AS cannot ensure that its own policies are satisfied, because other ASes may do things that counteract that AS's policies (e.g., the aggregation example we present). > Finally, the I-D brings up here and later the topic of data that is > discarded as an advertisement progresses through the Internet. This > is true, but it is not an intrinsic limitation of BGP. For example, > in S-BGP, we carry some data that is discarded (e.g., due to > aggregation) to facilitate signature verification at later ASes. This > does not modify the semantics of BGP, but rather represents a sort of > housekeeping activity by S-BGP, to facilitate authorization checks. I > don't consider that to be out of bounds re security measures we can > employ with BGP, and thus I don't agree with all of the observations > about the implications of discarded data relative to security > capabilities for BGP. Discarded data can throw away policy information. If you agree that a "valid route" involves conformance to policy, then what we say is true. > You also state that "This document does not discuss the authorization > to advertise a given destination, or prefix." I agree that the I-D > does not address this but I am puzzled as to why this discussion is > omitted. We feel that authorization is central to discussions of the > security of BGP. Yes, authorization is a necessary *but not sufficient* condition to ensure that the routing protocol advertises valid paths. There are other aspects that must be considered, and that's what we're talking about in this draft. > The I-D specifies three questions that are cast as the essential > criteria re route validity. The first one is interesting, but maybe > not essential, the second seems like a red herring. The third one, > which is the authorization issue that this I-D largely ignores, seems > most important. The second question is important (and appropriate) because a route should not be used (i.e., considered valid) if using it would violate the wishes of some AS along that path. > The first question is interesting in that if the path does not exist, > then clearly there is a problem with the advertisement. But, even if > the path does exist, we don't know that traffic will follow that > path, as you noted earlier. Also, in general it is very difficult to > know if a specified path exists, given the realistic limitations on > dissemination of information about AS connectivity. So I question > whether this is a useful question to be asking. Our inability to answer this question with today's protocols does not make it a useless question. > What I really care > about is whether the advertisement is authentic and authorized, > because if the advertisement is not authentic or it is it > unauthorized, then it is bad and should be ignored, to avoid > misrouting. Yes, we care about authorization, but policy conformance is also important, for the reasons mentioned above. To reiterate, authorization is necessary, but not sufficient. > Section 2.1 seems to be an example to show why the first of the three > assertions is true. OK, but, as noted above, you first need to > justify why this needs to be demonstrated. Is the notion that this is > a widely held, but inaccurate belief? You seem to be saying that making sure that everyone who advertises a path is authorized to do so is all we have to do to get valid paths, but the example in 2.1 demonstrates why, in BGP, simply performing authorization checks is not enough. Cheers, Nick _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Fri Nov 7 19:32:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16320 for ; Fri, 7 Nov 2003 19:32:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIH1J-0004zA-7V for rpsec-archive@odin.ietf.org; Fri, 07 Nov 2003 19:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA80W5pk019158 for rpsec-archive@odin.ietf.org; Fri, 7 Nov 2003 19:32:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIH1J-0004yv-2d for rpsec-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 19:32:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16285 for ; Fri, 7 Nov 2003 19:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIH1H-0005nM-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 19:32:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIH1G-0005nJ-00 for rpsec-web-archive@ietf.org; Fri, 07 Nov 2003 19:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIH1G-0004wu-C0; Fri, 07 Nov 2003 19:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIH0v-0004wQ-Og for rpsec@optimus.ietf.org; Fri, 07 Nov 2003 19:31:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16274 for ; Fri, 7 Nov 2003 19:31:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIH0t-0005mn-00 for rpsec@ietf.org; Fri, 07 Nov 2003 19:31:40 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AIH0t-0005m9-00 for rpsec@ietf.org; Fri, 07 Nov 2003 19:31:39 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2003 16:32:14 -0800 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA80V6mU027023; Fri, 7 Nov 2003 16:31:07 -0800 (PST) Received: from russpc.whitehouse.intra (rtp-vpn2-37.cisco.com [10.82.240.37]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA08069; Fri, 7 Nov 2003 19:31:06 -0500 (EST) Date: Fri, 7 Nov 2003 19:31:02 -0500 (Eastern Standard Time) From: Russ White Reply-To: Russ White To: Jean-Jacques Puig cc: rpsec@ietf.org Subject: Re: [RPSEC] Use of external information for RP security In-Reply-To: <20031107162502.GB32054@ivan.int-evry.fr> Message-ID: References: <20031107153307.15EEE16484@wolfe.bbn.com> <20031107162502.GB32054@ivan.int-evry.fr> X-X-Sender: ruwhite@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > > Trying to step back from the recent dialog on the subject of: > > Considerations in Path Security for BGP > > do folks think that there is an issue with using information not > > carried in a given RP's PDUs to increase the security of the RP? > > Availability of the information when there are no routes may be :). There > may also be stupid locks (I want to check the cert server for validity of > the route leading to the cert server...). However, I'm also interested in > these methods. I think there is very little hope to get some inter-domain > security without these. I would never want to depend on interdomain routing to secure interdomain routing, I don't think. Adding this dimension to the problem opens a number of alternate places where the security mechanism itself can be attacked, and since these sorts of security systems are bound to be fail safe, you wind up with more opportunities for denial of service, it seems to me (?). And, I'm not positive there's no way to get interdomain security without some sort of "master server." In fact, I would argue the opposite is true--the more a security mechanism relies on a "settled infrastructure," the less likely it is to be deployed. The more distributed a system is, the more likely it is to be deployed, I think. But, those are just guesses, from talking to providers and others, and trying to ask that specific question, rather than information from any sort of "scientific survey." :-) > > A few examples of possible information or databases are: > > * Certificates (of whatever flavor) > > * DNS[SEC] > > * Internet Routing Registry > > * NOC "configuration" files (at least for intra-AS RPs) > > * RADIUS/Diameter/IPsec > > * Regional Internet Registry > > * etc. > > > > If such "external" sources of information are used, I think that they > > would need to be included within the "security perimeter"; their > > integrity, correctness, authentication, availability, and "freshness" > > would have to be considered when evaluating risks and threats for an RP. > > True. I plan to develop on this in the requirements doc. I would think that any such databases which a security system relies on should be included within the purview of threats and requirements. > > Should such external sources be "in scope" or "out of scope" as > > mechanisms that to be be considered when securing an RP? > > I think so. But may be we should discuss on this in the rpsec session ? I would say in scope. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Nov 10 10:18:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24060 for ; Mon, 10 Nov 2003 10:18:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDoL-0001HE-Pe for rpsec-archive@odin.ietf.org; Mon, 10 Nov 2003 10:18:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAFIbQK004904 for rpsec-archive@odin.ietf.org; Mon, 10 Nov 2003 10:18:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDoL-0001H1-M7 for rpsec-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 10:18:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23977 for ; Mon, 10 Nov 2003 10:18:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJDoJ-0005ud-00 for rpsec-web-archive@ietf.org; Mon, 10 Nov 2003 10:18:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJDoI-0005uU-00 for rpsec-web-archive@ietf.org; Mon, 10 Nov 2003 10:18:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDnk-0001E6-Uo; Mon, 10 Nov 2003 10:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDnL-0001DK-4c for rpsec@optimus.ietf.org; Mon, 10 Nov 2003 10:17:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23877 for ; Mon, 10 Nov 2003 10:17:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJDnI-0005tP-00 for rpsec@ietf.org; Mon, 10 Nov 2003 10:17:32 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1AJDnH-0005so-00 for rpsec@ietf.org; Mon, 10 Nov 2003 10:17:31 -0500 Received: from [130.129.139.103] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAAFGf9m005828; Mon, 10 Nov 2003 10:16:53 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <20031108000455.GB15599@lcs.mit.edu> References: <20031108000455.GB15599@lcs.mit.edu> Date: Sun, 9 Nov 2003 17:21:33 -0500 To: Nick Feamster From: Stephen Kent Subject: Re: [RPSEC] Considerations in Path Security for BGP Cc: Routing Protocols Security Working Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 19:04 -0500 11/7/03, Nick Feamster wrote: >Hi Steve, > >> We agree that one cannot ensure that traffic will actually follow the >> advertised path, but this is true for ANY routing protocol. > >I think the larger point is that BGP can have inconsistencies (say, >introduced by IGP and iBGP, inconsistencies within an AS, etc.) that >cause an AS to "say one thing and do another", depending on which router >in that AS you're considering. i don't see any disagreement here. Surely we all know that a routing system provides inputs for traffic forwarding, but those inputs do no really guarantee that forwarding tasks place as advertised. For example, an ISP may place its own AS # in a path multiple times in an effort to influence other AS to not use this route unless its the only one around. However, if traffic does flow to the As for the prefix associated with the route, nobody expects the ISP to cause the traffic to loop through it! Thus there are lots of ways traffic forwarding may differ from route advertisements. A major goal for secure routing is to allow an AS to detect bogus (not authorized) routes, so that the AS can at least avoid making forwarding decisions based on bad data. > > You argue that the path cannot be verified to be consistent with >> policies of all the ASes along the route. This is true, but I'm not >> sure we should care too much about this. In general, the policies of >> an AS are locally imposed, and not disclosed to others. So, it may >> not be possible for anyone external to an AS to determine whether the >> AS is even following its own policies. > >> Moreover, it is silly to >> assume that one AS can impose its policies on another AS, not under >> its administrative control. So, the bottom line is that an AS policy >> re routing is purely a local (intra-domain) matter and in an effort >> to secure intra-domain routing it is not of much relevance. > >The point is not that one AS cannot impose policies on another. The >point is that an AS cannot ensure that its own policies are satisfied, >because other ASes may do things that counteract that AS's policies >(e.g., the aggregation example we present). I see no difference between what I said and what you said, in any practical sense. > > Finally, the I-D brings up here and later the topic of data that is >> discarded as an advertisement progresses through the Internet. This >> is true, but it is not an intrinsic limitation of BGP. For example, >> in S-BGP, we carry some data that is discarded (e.g., due to >> aggregation) to facilitate signature verification at later ASes. This >> does not modify the semantics of BGP, but rather represents a sort of >> housekeeping activity by S-BGP, to facilitate authorization checks. I >> don't consider that to be out of bounds re security measures we can >> employ with BGP, and thus I don't agree with all of the observations >> about the implications of discarded data relative to security >> capabilities for BGP. > >Discarded data can throw away policy information. If you agree that a >"valid route" involves conformance to policy, then what we say is true. BGP discards data when aggregation is performed, but a security system need not discard that data. That's what we chose to do in S-BGP; we carry data that BGP discards (and that we need for authorization checking) in our optional attribute. Who says you can't do this? The fact that BGP discarded the data does not imply that a security enhancement to BGP must do so as well. > > You also state that "This document does not discuss the authorization >> to advertise a given destination, or prefix." I agree that the I-D >> does not address this but I am puzzled as to why this discussion is >> omitted. We feel that authorization is central to discussions of the >> security of BGP. > >Yes, authorization is a necessary *but not sufficient* condition to >ensure that the routing protocol advertises valid paths. There are >other aspects that must be considered, and that's what we're talking >about in this draft. I didn't see a clear articulation of what those other aspects were. Moreover, the theme of the I-D seemed to be that "authorization" was irrelevant, or at best a secondary concern. Of course we disagree about what authorization means in this context, so it's not surprising that we should disagree about its significance. > > The I-D specifies three questions that are cast as the essential >> criteria re route validity. The first one is interesting, but maybe >> not essential, the second seems like a red herring. The third one, >> which is the authorization issue that this I-D largely ignores, seems >> most important. > >The second question is important (and appropriate) because a route >should not be used (i.e., considered valid) if using it would violate >the wishes of some AS along that path. This seems like wishful thinking, at best. This is precisely the notion that any AS can impose its "wishes" on other ASes, which is what you and I disagreed about above. > > The first question is interesting in that if the path does not exist, > > then clearly there is a problem with the advertisement. But, even if >> the path does exist, we don't know that traffic will follow that >> path, as you noted earlier. Also, in general it is very difficult to >> know if a specified path exists, given the realistic limitations on >> dissemination of information about AS connectivity. So I question >> whether this is a useful question to be asking. > >Our inability to answer this question with today's protocols does not >make it a useless question. We ought to be consistent about what is fair game. Above you seem, to argue that if BGP discards data, then no security mechanism should be able to preserve that data and use it to determine authorization. yet here you argue that one ought not be bound by extant, real world constraints when considering security issues. I think you cannot have it both ways! > > What I really care >> about is whether the advertisement is authentic and authorized, >> because if the advertisement is not authentic or it is it >> unauthorized, then it is bad and should be ignored, to avoid >> misrouting. > >Yes, we care about authorization, but policy conformance is also >important, for the reasons mentioned above. To reiterate, authorization >is necessary, but not sufficient. To reiterate, policy is local and not enforceable on other ASes. > > Section 2.1 seems to be an example to show why the first of the three >> assertions is true. OK, but, as noted above, you first need to >> justify why this needs to be demonstrated. Is the notion that this is >> a widely held, but inaccurate belief? > >You seem to be saying that making sure that everyone who advertises a >path is authorized to do so is all we have to do to get valid paths, but >the example in 2.1 demonstrates why, in BGP, simply performing >authorization checks is not enough. I no longer recall what numbers were assigned to which examples in your I-D, and I do not have a copy with me as I write this note. Still But, what is a "valid" path anyway? did you define this term in the I-D? I'm not being facetious, just noting that we've been devoting a lot of energy discussing what an authorized path is and what it implies, so we ought to do the same for any other term that plays a major role in a proposal. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Nov 10 10:54:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26068 for ; Mon, 10 Nov 2003 10:54:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEMk-00049V-Pv for rpsec-archive@odin.ietf.org; Mon, 10 Nov 2003 10:54:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAFsAn9015954 for rpsec-archive@odin.ietf.org; Mon, 10 Nov 2003 10:54:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEMk-00049F-Cq for rpsec-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 10:54:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26055 for ; Mon, 10 Nov 2003 10:53:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEMh-0006an-00 for rpsec-web-archive@ietf.org; Mon, 10 Nov 2003 10:54:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEMh-0006ak-00 for rpsec-web-archive@ietf.org; Mon, 10 Nov 2003 10:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEMb-000479-Is; Mon, 10 Nov 2003 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEMJ-00046g-Se for rpsec@optimus.ietf.org; Mon, 10 Nov 2003 10:53:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26033 for ; Mon, 10 Nov 2003 10:53:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEMH-0006aA-00 for rpsec@ietf.org; Mon, 10 Nov 2003 10:53:41 -0500 Received: from ginseng.lcs.mit.edu ([18.31.0.38] ident=[NKnL8K+zlleMDEUzEILszJUcVKiTGBbp]) by ietf-mx with esmtp (Exim 4.12) id 1AJEMG-0006a7-00 for rpsec@ietf.org; Mon, 10 Nov 2003 10:53:40 -0500 Received: from ginseng.lcs.mit.edu (localhost.localdomain [127.0.0.1]) by ginseng.lcs.mit.edu (8.12.9/8.12.5) with ESMTP id hAAFrXH3006827; Mon, 10 Nov 2003 10:53:33 -0500 Received: (from feamster@localhost) by ginseng.lcs.mit.edu (8.12.9/8.12.9/Submit) id hAAFrXmG006825; Mon, 10 Nov 2003 10:53:33 -0500 Date: Mon, 10 Nov 2003 10:53:33 -0500 From: Nick Feamster To: Stephen Kent Cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] Considerations in Path Security for BGP Message-ID: <20031110155333.GA6460@lcs.mit.edu> References: <20031108000455.GB15599@lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > >> We agree that one cannot ensure that traffic will actually follow the > >> advertised path, but this is true for ANY routing protocol. > > > >I think the larger point is that BGP can have inconsistencies (say, > >introduced by IGP and iBGP, inconsistencies within an AS, etc.) that > >cause an AS to "say one thing and do another", depending on which router > >in that AS you're considering. > > i don't see any disagreement here. Surely we all know that a routing > system provides inputs for traffic forwarding, but those inputs do no > really guarantee that forwarding tasks place as advertised. For > example, an ISP may place its own AS # in a path multiple times in an > effort to influence other AS to not use this route unless its the > only one around. However, if traffic does flow to the As for the > prefix associated with the route, nobody expects the ISP to cause the > traffic to loop through it! Thus there are lots of ways traffic > forwarding may differ from route advertisements. A major goal for > secure routing is to allow an AS to detect bogus (not authorized) > routes, so that the AS can at least avoid making forwarding decisions > based on bad data. Sounds as though we agree. btw, it's not just loops; bogus iBGP configurations can also cause packets to be forwarded through other ASes that are not on the advertised AS path. > > > You argue that the path cannot be verified to be consistent with > >> policies of all the ASes along the route. This is true, but I'm not > >> sure we should care too much about this. In general, the policies of > >> an AS are locally imposed, and not disclosed to others. So, it may > >> not be possible for anyone external to an AS to determine whether the > >> AS is even following its own policies. > > > >> Moreover, it is silly to > >> assume that one AS can impose its policies on another AS, not under > >> its administrative control. So, the bottom line is that an AS policy > >> re routing is purely a local (intra-domain) matter and in an effort > >> to secure intra-domain routing it is not of much relevance. > > > >The point is not that one AS cannot impose policies on another. The > >point is that an AS cannot ensure that its own policies are satisfied, > >because other ASes may do things that counteract that AS's policies > >(e.g., the aggregation example we present). > > I see no difference between what I said and what you said, in any > practical sense. I think they are different. It's one thing for an AS to be able to know that all paths that it advertises will conform to its policies, even as it advertises them to others. For example, specifying that it want to use one upstream as a backup is a totally reasonable thing to do. It's something else for that AS to be able to impose arbitrary policies on other ASes that have nothing to do with its own policies. > > > Finally, the I-D brings up here and later the topic of data that is > >> discarded as an advertisement progresses through the Internet. This > >> is true, but it is not an intrinsic limitation of BGP. For example, > >> in S-BGP, we carry some data that is discarded (e.g., due to > >> aggregation) to facilitate signature verification at later ASes. This > >> does not modify the semantics of BGP, but rather represents a sort of > >> housekeeping activity by S-BGP, to facilitate authorization checks. I > >> don't consider that to be out of bounds re security measures we can > >> employ with BGP, and thus I don't agree with all of the observations > >> about the implications of discarded data relative to security > >> capabilities for BGP. > > > >Discarded data can throw away policy information. If you agree that a > >"valid route" involves conformance to policy, then what we say is true. > > BGP discards data when aggregation is performed, but a security > system need not discard that data. That's what we chose to do in > S-BGP; we carry data that BGP discards (and that we need for > authorization checking) in our optional attribute. Who says you can't > do this? The fact that BGP discarded the data does not imply that a > security enhancement to BGP must do so as well. I forwarding is still LPM, right? So aggregation would still mess things up with respect to conforming to the policy that the origin AS wanted (i.e., punching a hole to specify traffic should be sent a certain way). Maybe I'm misunderstanding what S-BGP does or missed the discussion of this in the ID. > > > > You also state that "This document does not discuss the authorization > >> to advertise a given destination, or prefix." I agree that the I-D > >> does not address this but I am puzzled as to why this discussion is > >> omitted. We feel that authorization is central to discussions of the > >> security of BGP. > > > >Yes, authorization is a necessary *but not sufficient* condition to > >ensure that the routing protocol advertises valid paths. There are > >other aspects that must be considered, and that's what we're talking > >about in this draft. > > I didn't see a clear articulation of what those other aspects were. > Moreover, the theme of the I-D seemed to be that "authorization" was > irrelevant, or at best a secondary concern. Of course we disagree > about what authorization means in this context, so it's not > surprising that we should disagree about its significance. OK, perhaps the draft should be refined in this respect. I don't see it as irrelevant at all. I do think it's one piece of a larger puzzle. That is, even if you have S-BGP/soBGP/whatever, you still have to consider various other things...which is what we're trying to say. > > > The I-D specifies three questions that are cast as the essential > >> criteria re route validity. The first one is interesting, but maybe > >> not essential, the second seems like a red herring. The third one, > >> which is the authorization issue that this I-D largely ignores, seems > >> most important. > > > >The second question is important (and appropriate) because a route > >should not be used (i.e., considered valid) if using it would violate > >the wishes of some AS along that path. > > This seems like wishful thinking, at best. This is precisely the > notion that any AS can impose its "wishes" on other ASes, which is > what you and I disagreed about above. One example: one AS wants to specify that a certain path is backup. What's so unreasonable about asking other ASes to enforce that policy? Now, I agree, you probably have to draw the line somewhere---can't just impose arbitrary policies. However, if one AS wants a particular path used as backup, I think it's reasonable to try to make sure that happens. > > > The first question is interesting in that if the path does not exist, > > > then clearly there is a problem with the advertisement. But, even if > >> the path does exist, we don't know that traffic will follow that > >> path, as you noted earlier. Also, in general it is very difficult to > >> know if a specified path exists, given the realistic limitations on > >> dissemination of information about AS connectivity. So I question > >> whether this is a useful question to be asking. > > > >Our inability to answer this question with today's protocols does not > >make it a useless question. > > We ought to be consistent about what is fair game. Above you seem, to > argue that if BGP discards data, then no security mechanism should be > able to preserve that data and use it to determine authorization. yet > here you argue that one ought not be bound by extant, real world > constraints when considering security issues. I think you cannot have > it both ways! In both cases, these are things that cannot be done with today's protocols (assuming we're talking about policy conformance; I'll avoid using the word "authorization" ;). I don't see any inconsistency here. The point is that these are things we should be able to do today, but can't. > > > What I really care > >> about is whether the advertisement is authentic and authorized, > >> because if the advertisement is not authentic or it is it > >> unauthorized, then it is bad and should be ignored, to avoid > >> misrouting. > > > >Yes, we care about authorization, but policy conformance is also > >important, for the reasons mentioned above. To reiterate, authorization > >is necessary, but not sufficient. > > To reiterate, policy is local and not enforceable on other ASes. Agreed, but it doesn't (and, in some cases, shouldn't) have to be that way. That is, in some sense, one of the main points of the draft. > > > Section 2.1 seems to be an example to show why the first of the three > >> assertions is true. OK, but, as noted above, you first need to > >> justify why this needs to be demonstrated. Is the notion that this is > >> a widely held, but inaccurate belief? > > > >You seem to be saying that making sure that everyone who advertises a > >path is authorized to do so is all we have to do to get valid paths, but > >the example in 2.1 demonstrates why, in BGP, simply performing > >authorization checks is not enough. > > I no longer recall what numbers were assigned to which examples in > your I-D, and I do not have a copy with me as I write this note. > Still > > But, what is a "valid" path anyway? did you define this term in the > I-D? Quoting from the draft: "The validity of a path advertised by a given router actually consists of at least three parts: Does a path from the advertising router to the destination advertised actually exist? Does the path advertised fall within the policies of the receiver? Is the advertising router authorized to advertise a path to the destination?" > I'm not being facetious, just noting that we've been devoting a > lot of energy discussing what an authorized path is and what it > implies, so we ought to do the same for any other term that plays a > major role in a proposal. Cheers, -Nick _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Nov 10 11:04:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24062 for ; Mon, 10 Nov 2003 10:18:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDoM-0001HW-3x for rpsec-archive@odin.ietf.org; Mon, 10 Nov 2003 10:18:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAFIcVC004920 for rpsec-archive@odin.ietf.org; Mon, 10 Nov 2003 10:18:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDoL-0001HH-Vy for rpsec-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 10:18:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23978 for ; Mon, 10 Nov 2003 10:18:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJDoJ-0005ua-00 for rpsec-web-archive@ietf.org; Mon, 10 Nov 2003 10:18:35 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJDoI-0005uV-00 for rpsec-web-archive@ietf.org; Mon, 10 Nov 2003 10:18:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDnl-0001EE-B4; Mon, 10 Nov 2003 10:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDnR-0001Dg-9p for rpsec@optimus.ietf.org; Mon, 10 Nov 2003 10:17:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23893 for ; Mon, 10 Nov 2003 10:17:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJDnO-0005tq-00 for rpsec@ietf.org; Mon, 10 Nov 2003 10:17:38 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1AJDnO-0005t4-00 for rpsec@ietf.org; Mon, 10 Nov 2003 10:17:38 -0500 Received: from [130.129.139.103] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id hAAFGf9k005828; Mon, 10 Nov 2003 10:16:49 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: References: Date: Sun, 9 Nov 2003 17:27:29 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Considerations in Path Security for BGP Cc: Routing Protocols Security Working Group Content-Type: multipart/alternative; boundary="============_-1143645124==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , --============_-1143645124==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 15:53 -0500 11/7/03, Russ White wrote: > > >It's not the same thing at all. Since AS1's address space happens to be >> >contained within the address space AS3 is advertising, there is no way to >> >actually encode this policy--"don't use this path"--in any meaningful way >> >within BGP, or any other routing system, actually. >> >> I do not understand why you keep saying that AS1 is trying to prevent >> traffic for its /24 from traversing AS3. We know AS1 cannot cause >> this to happen; I gave an example showing why such traffic might >> legitimately traverse AS3 even if every other AS is aware of the >> advertisement from AS1. Your statement re the inability to express >> "don't use this path" is certainly true here, but its not relevant to >> the discussion. > >-- > >Going back a couple of emails: > >> Could you please define what you mean by "authorization?" In my mind, >> when I say that I authorize you to advertise my prefixes to your peers, >> then I'm saying that I authorize you to transit traffic from those peers >> to me. If I refuse to authorize you to advertise my prefixes to your >> peers, then my intent is that you will not be able to advertise my >> address space, and thus your peers will not know how to reach my address >> space through you. >> >> Is this correct? > >And you said: > >> yes, this is essentially correct. I tend to use terms that are more >> directly linked to the mechanics of the advertisement, rather than the >> implications of the advertisement, but either approach is reasonable. > >-- > >So, if this is still a correct definition of authorization: > >-- AS Paths cannot contain authorization in any sense >-- Receipt of an update cannot prove authorization >-- Lack of an update cannot prove lack of authorization > >You can prove an AS Path is valid, in the sense that it exists, but you >cannot, in any sense, claim any sort of "authorization" to do anything >expressed through the receipt or lack of receipt of an advertisement. I agreed with your characterization in general terms, but noted that I prefer to talk in terms of the mechanisms vs. the implications. Hence, for example, it may be intent of AS1 in your example that AS3 not transit traffic destined for AS1, but we know that AS1 cannot enforce this intent. If one talks in terms of the implications of an advertisement, then one has to be careful to restrict ones expectations of the implications. Looking at your bullets above, we very much disagree about 1 & 2; the wording of 3 is sufficiently indirect that I won't comment on it one way of another. I cannot see any basis for these assertions, at least not 1 & 2 above. How do you interpret the semantics of BGP if you believe that AS paths do not imply authorization to advertise? > >> Nonsense. An AS choose what info to pass to its peers. But, it cannot >> control what info these peers receive via connections to other ASes, in >> general. And it certainly cannot control HOW the other ASes use the info >> that is provided. So it just seems silly to think than an AS projects its >> policy on its peers. After all, AS stands for AUTONOMOUS system. That >> should be a hint :-) > >Okay, so you're saying that when I set my MED, I'm not expressing a policy, >and when you set your Local Pref, you're not overriding my policy? You may >choose to advertise a /25 to me, and I choose to block it inbound at my >border. How, exactly, is that not imposing my policy on you? Please Russ, don't try to put words in my mouth; I'm really much better at it than you :-) Of course an AS can express aspects of policy in its interactions with other ASes. What I said was that it cannot enforce its policy outside its own domain. Your example above re the advertisement of a /25, makes my argument, i.e., one AS's attempt to impose its policy on a neighbor is rejected by the neighbor. > > >Thus, the path in the "authorized" advertisement can say nothing about >> >the policies of the AS' along the path, including their willingness to > > >accept traffic along the path. Which means that a path cannot be >> >"authorized" in the way it's defined in the beginning of this email. It >> >can only be proven to exist, or not to exist. >> >> You seem to be redefining the term "authorized" so as to use it as a >> strawman. Please stop doing that; it's not constructive. > >No, I'm using it as it's defined above--the definition you agreed is >correct. I agree that the words were about right, but you have started with those words and extrapolated in a fashion with which I don't agree. > > Aggregation is not a problem; one can preserve the authorization info >> from the advertisements that an AS receives and that transitively >> authorize it to send an aggregated advertisement. That is consistent with >> the authorization model we have developed. > >So, what do you mean by "authorization" in the above sentence, in reference >to an AS Path or an update? You state you are authorizing a peer to >readvertise an update, but what, exactly, do you intend to imply with this >authorization? According to the definition above, the authorization to >transit traffic through the path. You keep emphasizing the part of the definition about which I expressed reservations, and which I have rejected in a number of messages. The word "implication" is probably the wrong one to use here. What I think you are referring to are the "intentions" of the advertiser, and we have seen that the intentions are not enforceable and if one has unrealistic expectations, the intentions are not likely to realized. > > I looked for the term "reorigination" and didn't find it in any BGP spec. >> I've been told that this term refers to a practice in which an AS asserts >> itself as an origin for a prefix, when in fact if is not. Where I come >> from this is called "lying" :-) > >Then ISP's must commonly lie. :-) Re-origination means: I own 10.1.0.0/16, >and I hand off to you 10.1.1.0/24. At my border, I simply block your >advertisement of 10.1.1.0/24, and instead, originate 10.1.0.0/16. Thus, I'm >"re-originating" your address space, within a larger address space. The >difference, in Cisco IOS terms, is this: > >router bgp xxx > aggregate-address 10.1.0.0 255.255.0.0 summary-only > >and > >ip route 10.1.0.0 255.255.0.0 null >! >router bgp xxx > network 10.1.0.0 mask 255.255.0.0 > >Others may call it something else, but it's a fairly common practice, and >it wipes out all the prior AS Path information. It's also perfectly legal, >etc. > In your sparse example, the owner of the /24 authorized the advertisement of its prefix by the owner of the subsuming /16, i.e., you indicated that the former sent an advertisement to the latter, who blocked it. If one makes provision for the advertisement of the /16 to convey the authorization provided by the owner of the /24, then reorigination can be managed securely. Yes, I know that BGP itself does not convey the data needed to verify the authorization, but we have ways to convey that data securely. So, this example is consistent with what I said in my previous message on this topic, i.e., if there is underlying authorization, then reorigination is not a problem and we just need to choose a means of conveying the underlying authorization. Steve --============_-1143645124==_ma============ Content-Type: text/html; charset="us-ascii" Re: [RPSEC] Considerations in Path Security for BGP
At 15:53 -0500 11/7/03, Russ White wrote:
> >It's not the same thing at all. Since AS1's address space happens to be
> >contained within the address space AS3 is advertising, there is no way to
> >actually encode this policy--"don't use this path"--in any meaningful way
> >within BGP, or any other routing system, actually.
>
> I do not understand why you keep saying that AS1 is trying to prevent
> traffic for its /24 from traversing AS3. We know AS1 cannot cause
> this to happen; I gave an example showing why such traffic might
> legitimately traverse AS3 even if every other AS is aware of the
> advertisement from AS1. Your statement re the inability to express
> "don't use this path" is certainly true here, but its not relevant to
> the discussion.

--

Going back a couple of emails:

> Could you please define what you mean by "authorization?" In my mind,
> when I say that I authorize you to advertise my prefixes to your peers,
> then I'm saying that I authorize you to transit traffic from those peers
> to me. If I refuse to authorize you to advertise my prefixes to your
> peers, then my intent is that you will not be able to advertise my
> address space, and thus your peers will not know how to reach my address
> space through you.
>
> Is this correct?

And you said:

> yes, this is essentially correct. I tend to use terms that are more
> directly linked to the mechanics of the advertisement, rather than the
> implications of the advertisement, but either approach is reasonable.

--

So, if this is still a correct definition of authorization:

-- AS Paths cannot contain authorization in any sense
-- Receipt of an update cannot prove authorization
-- Lack of an update cannot prove lack of authorization

You can prove an AS Path is valid, in the sense that it exists, but you
cannot, in any sense, claim any sort of "authorization" to do anything
expressed through the receipt or lack of receipt of an advertisement.

I agreed with your characterization in general terms, but noted that I prefer to talk in terms of the mechanisms vs. the implications. Hence, for example, it may be intent of AS1 in your example that AS3 not transit traffic destined for AS1, but we know that AS1 cannot enforce this intent. If one talks in terms of the implications of an advertisement, then one has to be careful to restrict ones expectations of the implications.

Looking at your bullets above, we very much disagree about 1 & 2; the wording of 3 is sufficiently indirect that I won't comment on it one way of another. I cannot see any basis for these assertions, at least not 1 & 2 above. How do you interpret the semantics of BGP if you believe that AS paths do not imply authorization to advertise?


> Nonsense. An AS choose what info to pass to its peers. But, it cannot
> control what info these peers receive via connections to other ASes, in
> general. And it certainly cannot control HOW the other ASes use the info
> that is provided. So it just seems silly to think than an AS projects its
> policy on its peers. After all, AS stands for AUTONOMOUS system. That
> should be a hint :-)

Okay, so you're saying that when I set my MED, I'm not expressing a policy,
and when you set your Local Pref, you're not overriding my policy? You may
choose to advertise a /25 to me, and I choose to block it inbound at my
border. How, exactly, is that not imposing my policy on you?

Please Russ, don't try to put words in my mouth; I'm really much better at it than you :-)

Of course an AS can express aspects of policy in its interactions with other ASes. What I said was that it cannot enforce its policy outside its own domain. Your example above re the advertisement of a /25, makes my argument, i.e., one AS's attempt to impose its policy on a neighbor is rejected  by the neighbor.

> >Thus, the path in the "authorized" advertisement can say nothing about
> >the policies of the AS' along the path, including their willingness to
> >accept traffic along the path. Which means that a path cannot be
> >"authorized" in the way it's defined in the beginning of this email. It
> >can only be proven to exist, or not to exist.
>
> You seem to be redefining the term "authorized" so as to use it as a
> strawman. Please stop doing that; it's not constructive.

No, I'm using it as it's defined above--the definition you agreed is
correct.

I agree that the words were about right, but you have started with those words and extrapolated in a fashion with which I don't agree.

> Aggregation is not a problem; one can preserve the authorization info
> from the advertisements that an AS receives and that transitively
> authorize it to send an aggregated advertisement. That is consistent with
> the authorization model we have developed.

So, what do you mean by "authorization" in the above sentence, in reference
to an AS Path or an update? You state you are authorizing a peer to
readvertise an update, but what, exactly, do you intend to imply with this
authorization? According to the definition above, the authorization to
transit traffic through the path.

You keep emphasizing the part of the definition about which I expressed reservations, and which I have rejected in a number of messages. The word  "implication" is probably the wrong one to use here. What I think you are referring to are the "intentions" of the advertiser, and we have seen that the intentions are not enforceable and if one has unrealistic expectations,  the intentions are not likely to realized.

> I looked for the term "reorigination" and didn't find it in any BGP spec.
> I've been told that this term refers to a practice in which an AS asserts
> itself as an origin for a prefix, when in fact if is not.  Where I come
> from this is called "lying" :-)

Then ISP's must commonly lie. :-) Re-origination means: I own 10.1.0.0/16,
and I hand off to you 10.1.1.0/24. At my border, I simply block your
advertisement of 10.1.1.0/24, and instead, originate 10.1.0.0/16. Thus, I'm
"re-originating" your address space, within a larger address space. The
difference, in Cisco IOS terms, is this:

router bgp xxx
 aggregate-address 10.1.0.0 255.255.0.0 summary-only

and

ip route 10.1.0.0 255.255.0.0 null
!
router bgp xxx
 network 10.1.0.0 mask 255.255.0.0

Others may call it something else, but it's a fairly common practice, and
it wipes out all the prior AS Path information. It's also perfectly legal,
etc.


In your sparse example, the owner of the /24 authorized the advertisement of its prefix by the owner of the subsuming /16, i.e., you indicated that the former sent an advertisement to the latter, who blocked it. If one makes provision for the advertisement of the /16 to convey the authorization provided by the owner of the /24, then reorigination can be managed securely. Yes, I know that BGP itself does not convey the data needed to verify the authorization, but we have ways to convey that data securely. So, this example is consistent with what I said in my previous message on this topic, i.e., if there is underlying authorization, then reorigination is not a problem and we just need to choose a means of conveying the underlying authorization.

Steve
--============_-1143645124==_ma============-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Mon Nov 10 16:13:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13830 for ; Mon, 10 Nov 2003 16:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJLM-0003Ga-US for rpsec-archive@odin.ietf.org; Mon, 10 Nov 2003 16:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAALD4xO012552 for rpsec-archive@odin.ietf.org; Mon, 10 Nov 2003 16:13:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJLM-0003GN-R5 for rpsec-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 16:13:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13825 for ; Mon, 10 Nov 2003 16:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJLK-0004jy-00 for rpsec-web-archive@ietf.org; Mon, 10 Nov 2003 16:13:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJLK-0004jv-00 for rpsec-web-archive@ietf.org; Mon, 10 Nov 2003 16:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJLI-0003FB-VW; Mon, 10 Nov 2003 16:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJKa-0003EB-W5 for rpsec@optimus.ietf.org; Mon, 10 Nov 2003 16:12:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13814 for ; Mon, 10 Nov 2003 16:12:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJKZ-0004js-00 for rpsec@ietf.org; Mon, 10 Nov 2003 16:12:15 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJJKY-0004ji-00 for rpsec@ietf.org; Mon, 10 Nov 2003 16:12:14 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2003 13:14:59 -0800 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAALBexg007445; Mon, 10 Nov 2003 16:11:40 -0500 (EST) Received: from dyn132-231.ietf58.ietf.org (rtp-vpn2-49.cisco.com [10.82.240.49]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA00998; Mon, 10 Nov 2003 16:11:39 -0500 (EST) Date: Mon, 10 Nov 2003 16:11:48 -0500 (EST) From: Russ White X-X-Sender: ruwhite@rwlaptop.ietf58.ietf.org Reply-To: Russ White To: Stephen Kent cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] Considerations in Path Security for BGP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > >Going back a couple of emails: > > > >> Could you please define what you mean by "authorization?" In my mind, > >> when I say that I authorize you to advertise my prefixes to your peers, > >> then I'm saying that I authorize you to transit traffic from those peers > >> to me. If I refuse to authorize you to advertise my prefixes to your > >> peers, then my intent is that you will not be able to advertise my > >> address space, and thus your peers will not know how to reach my address > >> space through you. > >> > >> Is this correct? > > > >And you said: > > > >> yes, this is essentially correct. I tend to use terms that are more > >> directly linked to the mechanics of the advertisement, rather than the > >> implications of the advertisement, but either approach is reasonable. > > > >-- > > > >So, if this is still a correct definition of authorization: > > > >-- AS Paths cannot contain authorization in any sense > >-- Receipt of an update cannot prove authorization > >-- Lack of an update cannot prove lack of authorization > > > >You can prove an AS Path is valid, in the sense that it exists, but you > >cannot, in any sense, claim any sort of "authorization" to do anything > >expressed through the receipt or lack of receipt of an advertisement. > > I agreed with your characterization in general terms, but noted that I > prefer to talk in terms of the mechanisms vs. the implications. Hence, > for example, it may be intent of AS1 in your example that AS3 not transit > traffic destined for AS1, but we know that AS1 cannot enforce this > intent. If one talks in terms of the implications of an advertisement, > then one has to be careful to restrict ones expectations of the > implications. Well, it's the implications of the advertisement or lack of advertisement that I care about, from a routing perspective. > Looking at your bullets above, we very much disagree about 1 & 2; the > wording of 3 is sufficiently indirect that I won't comment on it one way > of another. I cannot see any basis for these assertions, at least not 1 & > 2 above. How do you interpret the semantics of BGP if you believe that AS > paths do not imply authorization to advertise? The symantics of BGP are built around reachabile destinations, and not "authorization." The only reason for the AS Path is to prove the path is not a loop. There's no concept of "authorization through advertisement" in BGP, that I know of. There is only point in the BGP routing system where "authorization to advertise" has any meaning, and that's at the originator. > >> Nonsense. An AS choose what info to pass to its peers. But, it cannot > >> control what info these peers receive via connections to other ASes, in > >> general. And it certainly cannot control HOW the other ASes use the info > >> that is provided. So it just seems silly to think than an AS projects its > >> policy on its peers. After all, AS stands for AUTONOMOUS system. That > >> should be a hint :-) > > > >Okay, so you're saying that when I set my MED, I'm not expressing a policy, > >and when you set your Local Pref, you're not overriding my policy? You may > >choose to advertise a /25 to me, and I choose to block it inbound at my > >border. How, exactly, is that not imposing my policy on you? > > Please Russ, don't try to put words in my mouth; I'm really much > better at it than you :-) > > Of course an AS can express aspects of policy in its interactions > with other ASes. What I said was that it cannot enforce its policy > outside its own domain. Your example above re the advertisement of a > /25, makes my argument, i.e., one AS's attempt to impose its policy > on a neighbor is rejected by the neighbor. Or the other way around--one AS' policy of advertising a /25 is overridden by another AS' policy of not accepting them. But you didn't address the MED/Local Preference issue, either. > > > Aggregation is not a problem; one can preserve the authorization info > >> from the advertisements that an AS receives and that transitively > >> authorize it to send an aggregated advertisement. That is consistent with > >> the authorization model we have developed. > > > >So, what do you mean by "authorization" in the above sentence, in reference > >to an AS Path or an update? You state you are authorizing a peer to > >readvertise an update, but what, exactly, do you intend to imply with this > >authorization? According to the definition above, the authorization to > >transit traffic through the path. > > You keep emphasizing the part of the definition about which I expressed > reservations, and which I have rejected in a number of messages. The word > "implication" is probably the wrong one to use here. What I think you are > referring to are the "intentions" of the advertiser, and we have seen > that the intentions are not enforceable and if one has unrealistic > expectations, the intentions are not likely to realized. No, I'm referring to the policy of the advertiser. From the best I can see, you're claiming that if I advertise a prefix in a way that prevents my peer from readvertising it, I'm expressing a policy that that peer should not transit traffic destinated to addresses within that prefix to me. I'm stating that this sort of policy, in this way, is impossible to enforce or even encode within BGP. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Nov 11 11:53:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09674 for ; Tue, 11 Nov 2003 11:53:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJblZ-0008Dx-JD for rpsec-archive@odin.ietf.org; Tue, 11 Nov 2003 11:53:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABGrLAS031613 for rpsec-archive@odin.ietf.org; Tue, 11 Nov 2003 11:53:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJblZ-0008Do-Fm for rpsec-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 11:53:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09649 for ; Tue, 11 Nov 2003 11:53:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJblY-0005wE-00 for rpsec-web-archive@ietf.org; Tue, 11 Nov 2003 11:53:20 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJblX-0005wA-00 for rpsec-web-archive@ietf.org; Tue, 11 Nov 2003 11:53:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJblG-000895-Ec; Tue, 11 Nov 2003 11:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJblE-00088I-3d for rpsec@optimus.ietf.org; Tue, 11 Nov 2003 11:53:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09640 for ; Tue, 11 Nov 2003 11:52:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJblC-0005w0-00 for rpsec@ietf.org; Tue, 11 Nov 2003 11:52:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJblC-0005vD-00 for rpsec@ietf.org; Tue, 11 Nov 2003 11:52:58 -0500 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2003 08:56:02 -0800 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABGqPDM008080; Tue, 11 Nov 2003 11:52:25 -0500 (EST) Received: from dyn069-218.ietf58.ietf.org (rtp-vpn2-655.cisco.com [10.82.242.143]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA03473; Tue, 11 Nov 2003 11:52:25 -0500 (EST) Date: Tue, 11 Nov 2003 11:52:34 -0500 (EST) From: Russ White X-X-Sender: ruwhite@dyn069-218.ietf58.ietf.org Reply-To: Russ White To: Stephen Kent cc: Routing Protocols Security Working Group Subject: Re: [RPSEC] Considerations in Path Security for BGP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , > > I agreed with your characterization in general terms, but noted that I > > prefer to talk in terms of the mechanisms vs. the implications. > > Hence, for example, it may be intent of AS1 in your example that AS3 > > not transit traffic destined for AS1, but we know that AS1 cannot > > enforce this intent. If one talks in terms of the implications of an > > advertisement, then one has to be careful to restrict ones expectations > > of the implications. BTW, it might help to "reverse the characterization," then, and put it in terms of advertisements, maybe? So, let's say that some AS, AS1, advertises 10.1.1.0/24 to AS2 in way that it cannot advertise 10.1.1.0/24 to AS3. However, AS2 also has, from some other source (it doesn't matter where), an update for 10.1.0.0/16 that it can advertise to AS3. Since 10.1.0.0/16 contains 10.1.1.0/24, there's no way that AS1 can prevent AS2 from advertising 10.1.1.0/24 to AS3--as a part of 10.1.0.0/16. I hope this makes more sense--I'll try and work this type of characterization into a new revision of the draft, as well as the other suggestions you made earlier. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Nov 18 17:33:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22032 for ; Tue, 18 Nov 2003 17:33:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEPR-0005pM-9j for rpsec-archive@odin.ietf.org; Tue, 18 Nov 2003 17:33:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIMXLfE022396 for rpsec-archive@odin.ietf.org; Tue, 18 Nov 2003 17:33:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEPR-0005p9-5P for rpsec-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 17:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22023 for ; Tue, 18 Nov 2003 17:33:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMEPO-0000zy-00 for rpsec-web-archive@ietf.org; Tue, 18 Nov 2003 17:33:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMEPO-0000zu-00 for rpsec-web-archive@ietf.org; Tue, 18 Nov 2003 17:33:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEP6-0005mw-V5; Tue, 18 Nov 2003 17:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEOF-0005iu-Mb for rpsec@optimus.ietf.org; Tue, 18 Nov 2003 17:32:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21980 for ; Tue, 18 Nov 2003 17:31:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMEOD-0000yL-00 for rpsec@ietf.org; Tue, 18 Nov 2003 17:32:05 -0500 Received: from herculanum.int-evry.fr ([157.159.11.15]) by ietf-mx with esmtp (Exim 4.12) id 1AMEOC-0000xH-00 for rpsec@ietf.org; Tue, 18 Nov 2003 17:32:04 -0500 Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 0A08334A99 for ; Tue, 18 Nov 2003 23:31:33 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id E739A3F42C for ; Tue, 18 Nov 2003 23:31:32 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003111823313217829 for ; Tue, 18 Nov 2003 23:31:32 +0100 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id CBDCC3F42A for ; Tue, 18 Nov 2003 23:31:32 +0100 (CET) Received: from jjp by localhost with local id 1AMEMY-0003Wt-00 for ; Tue, 18 Nov 2003 23:30:22 +0100 Date: Tue, 18 Nov 2003 23:30:22 +0100 From: Jean-Jacques Puig To: rpsec@ietf.org Message-ID: <20031118223022.GB13207@ivan.int-evry.fr> Mail-Followup-To: rpsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [RPSEC] Slides from the meeting Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Hi ! I know many of us (including myself) have to report on the sessions they were attending during the meeting. 'hope the slides will help you: http://www-lor.int-evry.fr/~puig/ietf-58/rpsec/ I plan to repost the requirements doc as a wg item by the end of the week, thus the version will not be new, though comments are still welcome :-). -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Nov 25 10:58:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24506 for ; Tue, 25 Nov 2003 10:58:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfZv-0003PU-Rr for rpsec-archive@odin.ietf.org; Tue, 25 Nov 2003 10:58:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFwFJj013107 for rpsec-archive@odin.ietf.org; Tue, 25 Nov 2003 10:58:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfZv-0003PK-NS for rpsec-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:58:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24498 for ; Tue, 25 Nov 2003 10:57:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfZr-0007c7-00 for rpsec-web-archive@ietf.org; Tue, 25 Nov 2003 10:58:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOfZr-0007c3-00 for rpsec-web-archive@ietf.org; Tue, 25 Nov 2003 10:58:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfZg-0003Ny-Qo; Tue, 25 Nov 2003 10:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfZ3-0003NM-DR for rpsec@optimus.ietf.org; Tue, 25 Nov 2003 10:57:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24456; Tue, 25 Nov 2003 10:57:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfZ0-0007aH-00; Tue, 25 Nov 2003 10:57:18 -0500 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOfZ0-0007Zh-00; Tue, 25 Nov 2003 10:57:18 -0500 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id hAPFukN11887; Tue, 25 Nov 2003 10:56:46 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Tue, 25 Nov 2003 10:56:46 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: proceedings@ietf.org cc: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] RPSEC Minutes (IETF 58 - Minn) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Routing Protocol Security Requirements WG (rpsec) Wednesday, November 12 at 1300-1500 CHAIRS: Russ White Tony Tauber Agenda Bashing - Tony Tauber no comments Threats document status - Tony Tauber draft-ietf-rpsec-routing-threats-03.txt Went through WG Last Call Went through IESG review Comments received, will be sent out Need to: - integrate comments - revise, review and/or respond - return to the process to progress. No other comments from the microphone Requirements document - Danny McPherson draft-puig-rpsec-generic-requirements-01.txt Building off Threats document in large part and figuring what items in there ought to receive mitigation and what level of requirements (eg. MAY, SHOULD, MUST) is warranted. Also touches on system resource concerns. Needs much help from the community. How many have read this document? 4 or 5 hands. Consensus call: Should this draft be accepted as a WG work item? Sense of the room: Yes Will be taken to the list for confirmation. Charter Discussion - Tony Tauber Routing ADs would accept protocol specific work on the charter Generic work muct be completed before the protocol specific work How many would commit to work on protocol specific documents? Some hands How many would commit to comment on protocol specific documents? Some hands Should the charter be modified to accept protocol-specific work in this WG with the provision that it not advance ahead of current chartered work (ie. Generic Threats and Requirements documents)? Consensus call: Should the charter be ammended to include protocol-specific work? Sense of the room: Generably favorable, with at least one opposed. At the microphone: Steve Kent suggested that this work should go to the protocol specific groups, because the issues are different enough for each protocol to warrant seperate work by the experts in those protocols, and the participation isn't heavy enough in RPsec to do the work. WG Chairs will revise charter and send to the list for consideration and comments. Consensus call: Should this draft be accepted as a WG work item? Sense of the room: Yes Will be taken to the list for confirmation. BGP Attack Tree - Sean Convery draft-convery-bgpattack-01.txt Presented information on the updates made since the last revision. Discussed presentations to the operational community. Discussed lab and real world testing of BGP security. Consensus call: Should this draft be accepted as a WG work item Sense of the room: Clearly in favor with no opposition. If modified charter is accepted on list, then this item will be accepted as a WG item. OSPF Vulnerability Analysis - Emmanuele Jones draft-jones-OSPF-vuln-01.txt At the microphone: Acee Lindem: No disagreements on the vulnerabilities, other than the flooding, most people have implemented the flooding steps in the opposite direction. Check for its for me, before flooding the LSA. Once you are on someone's network, you could cause other damage. Tony Tauber: What sort of mitigations are avaiable? Emmanuele Jones: OSPF security is important, even if you could do other things. You have to bypass authentication/etc. Felix Wu: Some of this has to do with implementation, is this a protocol design issue? Emmanuele Jones: It is a protocol design issue, since the RFC does state the order of steps to take, which allows the attacker this hole. Vassilis Prevelakis: The approach between generic threats and the OSPF threats seem to be quite different. Should we try to standardize the framework of these sorts of drafts? Padma: I believe that we can't do much against insider attacks. I would prefer to have more protection against outsider attacks. I would like to see outsider/insider attacks addressed in the doc. We should copy this draft to the OSPF list, as well. Emmanuele Jones: The draft does address insider and outsider attacks, but they are not easy to seperate. Tony Tauber: There's the notion of Byzantine failure, detection, recovery which is mentioned in the Threats draft and well discussed in other literature. This threat relates to mis-behaving insiders (routers) and it's not really acceptable just to write off threats related to compromised routers entirely. Consider at least checking and reporting errors such as receiving packets on unexpected interfaces, with unexpected source addresses, etc. Some of that's done today. Acee Lindem: To defend this work, most implementations have some way to drop things cooming from unexpected interfaces, though they are not in the specs. Tony Tauber: Then we should consider those things. Acee Lindem: Say you have a unix box running OSPF with no authentication, there's no checking of where packets came from, so it's good to document that the implementations should check this sort of stuff. Felix Wu: Is it a protocol design issue really or implementation? Emmanuele Jones: Yes. Per the spec, order is problematic. Should this work be accepted as a WG item? Yes: Lots of hands No: One vote If the WG charter amendments are accepted, this item will be accepted as a WG item. Path Security - Russ White draft-white-path-considerations-00.txt Point is that some amount of information in distance-vector and path-vector protocols is hidden or removed as a matter of course (eg. for reasons of optimization or policy). Attempts to derive security for those protocols must take into account this property. Steve Kent: Understand what you're trying to say. Wasn't entirely clear in the draft. Russ White: Yes, the fact that the draft's language needs clarification been made obvious by some of the feedback and revision is planned already. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From exim@www1.ietf.org Tue Nov 25 15:27:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07901 for ; Tue, 25 Nov 2003 15:27:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjmM-0006MN-Sg for rpsec-archive@odin.ietf.org; Tue, 25 Nov 2003 15:27:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPKRMH2024442 for rpsec-archive@odin.ietf.org; Tue, 25 Nov 2003 15:27:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjmM-0006M8-LI for rpsec-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 15:27:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07786 for ; Tue, 25 Nov 2003 15:27:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjmL-0004zm-00 for rpsec-web-archive@ietf.org; Tue, 25 Nov 2003 15:27:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjmK-0004zj-00 for rpsec-web-archive@ietf.org; Tue, 25 Nov 2003 15:27:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjlt-00069U-1C; Tue, 25 Nov 2003 15:26:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjkV-0005tt-Ue for rpsec@optimus.ietf.org; Tue, 25 Nov 2003 15:25:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07520 for ; Tue, 25 Nov 2003 15:25:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjkR-0004wM-00 for rpsec@ietf.org; Tue, 25 Nov 2003 15:25:23 -0500 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOjkQ-0004vT-00 for rpsec@ietf.org; Tue, 25 Nov 2003 15:25:23 -0500 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id hAPK9oX12051; Tue, 25 Nov 2003 15:09:51 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Tue, 25 Nov 2003 15:09:50 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Abbie Barbir , Yi Yang cc: Sandy Murphy , Russ White , rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] IESG comments on draft-ietf-rpsec-routing-threats (fwd) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Hi folks, These are the comments received by IESG review. They all need to be fixed or somehow addressed if the critique is non-sensical. Sorry for having sat on them for so long; it's been a busy month. Please post a revised doc and send the revisions to the list or post proposed revisions to the list for comment or recommendation if desired. Thanks, Tony ---------- Forwarded message ---------- Date: Fri, 31 Oct 2003 12:52:40 -0800 From: Alex Zinin To: Russ White , Tony Tauber Subject: IESG comments on draft-ietf-rpsec-routing-threats Russ, Tony- Below are the comments from the IESG on the draft. They are also checked into the data tracker (Russ'es are under IESG discussion, and others are in comments) Alex Russ Housley (Comments): Comments: draft-ietf-rpsec-routing-threats-03 draft-ietf-rpsec-routing-threats-03.txt Generic Threats to Routing Protocols (Informational) Very nice document! I did notice a few typos. In section 3.1.1: s/form outsiders/from outsiders/ s/A link become subverted/A link is said to be subverted/ s/when an attacker gain access/when an attacker gains access/ Ted Hardie: Comment: The definition of threat wavers between "an adversary" and the "opportunity for an adversary to hurt you"; this is especially true in Section 3.1 Consistency here seems pretty important. In 3.1.2, this definition is given: "Blackhole: large amounts of traffic are directed to be forwarded through one router that cannot handle the increased level of traffic and drops many/most/all packets". I thought the aim here was to describe consequences,not how they are achieved. The consequence here seems to be "packets go in, but go nowhere". Nits: Both abstract and introduction have this statement: "The document provides a summary of generic threats that affects routing protocols." -->that affect (otherwise it reads as if the summary is doing the affecting). Section 2. "routing protocols may need to maintain the state of their" -->maintain knowledge about the state? "Routing protocol data plane uses messages to exchange information" -->The (or A) Routing protocol? Section 3. "Routing protocols are subject to treats at the control and data" --->threats. Section 3.1.2 "Disruption: This consequence occurs when a legitimate router's operation is being interrupted or prevented. Subvert links can" " interfering routing exchanges, or system integrity."--> interfering with? --->subverted From ops-dir: From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: donderdag 30 oktober 2003 0:10 To: Randy Bush Cc: ops directorate Subject: draft-ietf-rpsec-routing-threats-03.txt Hi, Comments below. First time I read it. Feel free to expose, as always. High-order bit: so-and-so. Looks like an OK document, but I'm not sure how much usefulness there is to it. The classification of threats etc. is made in such a way that a real analysis whether some important pieces could be missing from the consideration is difficult. That is, it's nice to read through the document, but I'm not sure if the characterizations, document organization, threat models etc. are really the useful ones, enabling easier analysis of the content. But as I don't have any bright ideas at the moment myself, I think it should be OK. Just don't expect to build any other documents on top of that (e.g., protocol-specific documents looking at how they've addressed the generic threats) and you should be ok. If you intend to build new work on top of this document, it might make sense to think whether the structure needs beefing up a bit more. On Fri, 24 Oct 2003, Randy Bush wrote: > 3. Document Actions > 3.1 WG Submissions > 3.1.1 New Item > **** o draft-ietf-rpsec-routing-threats-03.txt > Generic Threats to Routing Protocols (Informational) - 3 of 3 > Token: Alex Zinin more or less substantial comments --------------------------------- This documents investigates general threats to routing functions. In this work, the "owner" of an address prefix or an AS [17] number is an organization that has been granted the right to use that prefix or number. Each Regional Internet Registry (RIR) acquires prefixes and AS numbers from IANA, and further distributes (delegates use of) them to organizations such as ISPs and multi-homed subscribers. For address prefixes, delegation typically involves assigning a subset of a prefix to an organization, which may, in turn, further delegate subsets to other organizations, e.g., subscribers or downstream providers. ==> overly verbose on IP addressing, which is not leveraged later in the document, may be outside of the scope? Definitely needs rewording if it's staying.. A router's functions can be divided into control and data plane (protocol traffic vs. data traffic). In a similar fashion, a routing protocol has a control and a data plane. A routing protocol has a control plane that exchanges messages that are intended only for control of the protocol state. Routing protocol data plane uses messages to exchange information that is intended to be used in the forwarding function. For example, the information can be used to establish a forwarding table in each router or to return a description of the route to be used. Routing functions may affect the control and the data planes. However, there may be an emphasis on one of the planes as opposed to the other. For example, neighbor maintenance is likely to focus on the routing protocol control plane, while database maintenance may focus on the data plane. ==> IMHO, the separation of data and control planes in a router is a simple concept. However, the separation of data/control planes in a routing protocol is not (actually, I've very rarely even heard anyone mention something like that). And this description (IMHO) does not flesh it out properly. If it's staying, I'd recommend trying to reword to be clearer what which of them entails. Threats can originate form outsiders or insiders. An insider is an authorized participant in the routing protocol. An outsider is any other host or network. A particular router determines if a host is an outsider or an insider. An authorized protocol speaker can be an outsider to a particular router if the router does not consider it to be a legitimate peer (as could conceivably happen on a multi-access link). ==> by the first definition of "insider", the third definition is already "insider" because it's authorized.. or maybe I don't understand what you're talking about with the authorized speaker which is an outsider.. o Threats that result from subverted links: A link become subverted when an attacker gain access (or control) to it through a physical medium. The attacker can then take control over the link. This threat can result from the lack (or the use of weak) access control mechanisms as applied to physical mediums or channels. The attacker may eavesdrop, replay, delay, or drop routing messages, or break routing sessions between authorized routers, without participating in the routing exchange. ==> this is one-sided view of the subject. This seems clearly look at the threat from the perspective of getting physical access to the link between two routers. However, there is another case like this: router providing connectivity to a stub network, e.g., running an OSPF protocol without passive mode towards a LAN. These threats are different, at least to a degree, because typically in these stub network cases, the routing protocol packets do destined to the third parties do not traverse through the stub network. That is, e.g. replay and drop are not really relevant threats.. Not sure to which degree these should be fleshed out separately.. ... For example, an OSPF router will form a peering relationship with any attached device which appears to be running OSPF, unless MD5 authentication (or some other means) is used to prevent the neighboring relationship from forming. ==> this may need to be considered with the above in mind. This concentrates on IP-level protection, which may not be relevant if someone is able to come in as a middleman in the communication (depends on whether plain-text is used for authentication -- that is, if I see the communication, does it help me at all unless I know the key, requring a router compromise instead of a link -- I guess in most cases some hashes or others are used instead). .... 4.1 Deliberate Exposure Deliberate Exposure occurs when an attacker takes control of a router and intentionally releases routing information directly to other routers. In some cases, the receiving routers may not be authorized to access the leaked routing information. Deliberate exposure is always a threat action, however, the exposure of routing information may not be. ==> this is written as if this threat was limited to exposing information to other _routers_. In fact, the attackers goal might be to expose it to _himself_, a web page, mail posting, etc. (ie., not necessarily to other routers) as well. This would be a subset of the original threat. 4.2 Sniffing Sniffing is an action whereby attackers monitor and/or record the routing exchanges between authorized routers. Attackers can use subverted links to sniff for routing information. ==> this is a limited case of this threat. In addition to sniffing the routing information, being in a position like this, it is typically also possible to sniff the data plane as well? 4.3 Traffic Analysis Traffic analysis is action whereby attackers gain routing information by analyzing the characteristics of the data traffic on a subverted link. Traffic analysis threats can affect any data that is sent in the clear over a communication link. This threat is not peculiar to routing protocols and is included here for completeness. ==> this is not limited to clear-text communication. You can typically analyze many interesting things out of encrypted traffic as well (e.g. even if all traffic is protected by IPsec ESP). For example, looking at the destination addresses on the link should yield which prefixes are (at least) used in the routing protocol, or looking at which IP addresses communicate might help you guess about multihop iBGP sessions, etc. For example, if an attacker succeeds in spoofing the identity of a router, the subverted router can act as a masquerading router. ==> which router does "subverted" refer to? This seems to assume that spoofing would imply hijacking someone else's identity, which need not be the case (e.g., if a router has configured that everyone in a specific prefix is allowed to form adjacencies, but you spoof an address in that prefix but not one that was already used, you don't hijack an identity) -- similar later The consequences of spoofing are: o The deception of peer relationship: The authorized routers, which exchange routing messages with the spoofed router, do not realize they are neighboring with a router that is faking another router's identity. ==> this actually includes a lot of other consequences, need to spell it out -- be able to do everything authorized, e.g. blackhole, loop, forge routing information to eavesdrop, etc.etc. o Where disruption is concerned, the consequence zone includes the routers that are on the path of misdirected data traffic (Router B in Figure 2 and Figure 3). ==> plus those routers in the path in the internet which got this traffic they would not otherwise get.. 4.5.1.2 Misclaiming A misclaiming threat is defined as an attacker action advertising its authorized control of some network resources in a way that is not intended by the authoritative network administrator. ==> this is exactly what seems to happen with overclaiming as well. Apparently these two issues haven't been sufficiently well spelled out as I'm missing something.. (note: the next section on forwarder attacks lists only misstatement, not e.g. overstatement :-) editorial: ---------- in BGP, if a router receives a CEASE message, it can lead to breaking of its neighboring relationship to other routers. ==> s/breaking of/breaking off/ ? (or remove "of" ?) A PIM router might transmit a JOIN message to receive multicast data it would otherwise not receive ==> s/receive/receive./ when an attacker gain access (or control) to it through a physical ==> s/gain/gains/ Subverted links and/or subverted device (routers)can cause this ==> s/device (routers)/devices (routers) / (2 typos) routing message integrity, routing message origin, authentication or peer router authentication. ==> different variations of authentication twice, intentional or a typo? operation is being interrupted or prevented. Subvert links can ==> s/Subvert/Subverted/ devices (router) can cause this consequence by sending false ==> s/router/routers/ Subverted routers can cause this consequence by sending false routing information, interfering routing exchanges, or system integrity. ==> "or system integrity" is abrupt -- something missing? However, Router B is compromised and advertises a lower metric. ==> s/lower/better/ (lower is not always better :-) subverted links to sniff for routing information. ==> s/links /links/ attacker's location and what data traffic has passed through. A ==> s/and /and/ Falsification is an intentional action whereby false routing information is sent by a subverted router. To falsify the routing information, an attacker has to be either the originator or a forwarder of the routing information. False routing information describes the network in an unrealistic fashion, whether or not intended by the authoritative network administrator. To falsify the routing information, an attacker has to be either the originator or a forwarder of the routing information. It cannot be a receiver-only. ==> Remove "To falsify ..." sentence from the first paragraph, roughly duplicates.. the attacker(Router C in Figure 2 and Figure 3). ==> s/attacker(/attacker (/ A misclaiming threat is defined as an attacker action advertising its authorized control of some network resources in a way that is not ==> s/attacker action/action where an attacker is/ ? might increase the path cost by two hops instead of one. In BGP, the attacker might delete some AS numbers from the AS PATH. ==> s/AS/AS_/ ? The threat consequence area and period are also similar. ==> s/area/zone/ ? or by replaying out-dated packets, or by delaying responses, or by denial of receipts, and breaking synchronization. ==> s/and/or by/ for consistency ? Subverted, unauthorized and masquerading routers can slowdown their ==> s/slow/slow / [8] Cheung, S. et. al., "Protecting Routing Infrastructures from Denial of Service using co-operative intrusion detection", In Proceedings of the 1995 IEEE Symposium on Security and Privacy , May 1995. [9] Bradley, K. et. al., "A distributed Network Monitoring approach", Published , November 2001. ==> some references are not used, and these could be removed. There are probably more of them than just these two.. Appendix B. Acronyms AODV - Ad-hoc On-demand Distance Vector routing protocol ==> similarly, the acronyms should be cleaned of those that are not used in the text or aren't otherwise relevant. administration. Each AS normally uses a single interior gateway ==> kill the extra spaces :-) 5. Security Considerations This entire document is security related. Specifically the document addresses security of routing protocols as associated with threats to those protocols. [...] This document discusses inter- and intra-domain routing protocol threats that are currently known [...] ==> the section should probably be more explicit that this document is supposed to be protocol-independent. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec