Re: Heads up: Long AS-sets announced in the next few days
James A. T. Rice wrote:
So, the ASn's are not picked at random, yet mine might be included if I don't specifically ask for them not to be included, yet you decline to tell how my ASn might have been selected for this.
Ok, I realize I might have given the wrong impression here. Sorry. So here's what we are doing: by artificially inserting ASes into the AS-set of an announcement, the ISP that makes the announcement can control where the announcement is propagated and thus discover paths followed by its announcements that are not usually visible, giving it a more complete knowledge of network topology in the vicinity. Since this is a new technique, it's not clear if it is actually effective, and to measure this we need to test it in the real world. If the experiments show that the technique performs as we hope, we intend to publish the results and provide the details for public use. We will post appropriate references to this list as soon as we have some hard data and have put it into a presentable form. But first we need to do the experiments... Regards, Lorenzo
Ok, I realize I might have given the wrong impression here. Sorry.
So here's what we are doing: by artificially inserting ASes into the AS-set of an announcement, the ISP that makes the announcement can control where the announcement is propagated and thus discover paths followed by its announcements that are not usually visible, giving it a more complete knowledge of network topology in the vicinity.
Please just clarify the following point: do you intend to advertise paths containing AS numbers belonging to other entities on the public Internet without the permission of the owners of those AS numbers? You admit that you don't know what the consequences of this injection will be. It seems to me that there are enough issues with this type of experimentation *with* the permission of the AS numbers you plan to use. But the ethical issues with using them without such permission seems to me to be insurmountable. DS
On 2 Mar 2005, at 22:30, David Schwartz wrote:
Please just clarify the following point: do you intend to advertise paths containing AS numbers belonging to other entities on the public Internet without the permission of the owners of those AS numbers? You admit that you don't know what the consequences of this injection will be.
Prepending announcements with remote AS numbers has been a well-known technique for preventing prefixes from propagating to particular ASes for a long time. The AS_PATH attribute is a loop detection mechanism, and a determinant in path selection. What other magic is there in it that requires such careful consideration? Why should anybody need to get permission from remote operators before deciding what attributes to include in their own advertisements? Do I need to get permission from Sprint before I include 1239:100 as a community-string attribute on my own advertisement, too?
It seems to me that there are enough issues with this type of experimentation *with* the permission of the AS numbers you plan to use. But the ethical issues with using them without such permission seems to me to be insurmountable.
The ethical issues seem to be non-existent, to my way of thinking, and hence trivial to surmount :-) Joe
On 2 Mar 2005, at 22:30, David Schwartz wrote:
Please just clarify the following point: do you intend to advertise paths containing AS numbers belonging to other entities on the public Internet without the permission of the owners of those AS numbers? You admit that you don't know what the consequences of this injection will be.
Prepending announcements with remote AS numbers has been a well-known technique for preventing prefixes from propagating to particular ASes for a long time.
The AS_PATH attribute is a loop detection mechanism, and a determinant in path selection. What other magic is there in it that requires such careful consideration? Why should anybody need to get permission from remote operators before deciding what attributes to include in their own advertisements?
Do I need to get permission from Sprint before I include 1239:100 as a community-string attribute on my own advertisement, too?
It seems to me that there are enough issues with this type of experimentation *with* the permission of the AS numbers you plan to use. But the ethical issues with using them without such permission seems to me to be insurmountable.
The ethical issues seem to be non-existent, to my way of thinking, and hence trivial to surmount :-)
Joe
It is my humble little opinion that if joe-public looked at AS paths, it may be somewhat of an ethical issue, as some companies wouldn't want to be associated with others. ( "hey, it says right here that Sprint gets it connection from the isp down the street!") However, most who see the as paths have a clue, and are smart enough to know that anyone can prepend pretty much anything thing pretty much any way they want to, so it's really not an issue. Those that look at AS paths, and aren't cluefull enough to know the difference.... well.... does anyone really care what those people think anyway? ;-) -Jerry
On 2 Mar 2005, at 22:30, David Schwartz wrote:
Please just clarify the following point: do you intend to advertise paths containing AS numbers belonging to other entities on the public Internet without the permission of the owners of those AS numbers? You admit that you don't know what the consequences of this injection will be.
Prepending announcements with remote AS numbers has been a well-known technique for preventing prefixes from propagating to particular ASes for a long time.
And therefore such use would not be considered experimental. We are talking about experimenting with routes that falsely claim to have passed through another autonymous system.
The AS_PATH attribute is a loop detection mechanism, and a determinant in path selection. What other magic is there in it that requires such careful consideration? Why should anybody need to get permission from remote operators before deciding what attributes to include in their own advertisements?
Every piece of BGP documentation I have ever seen says that this attribute documents the ASes that the route has actually passed through.
Do I need to get permission from Sprint before I include 1239:100 as a community-string attribute on my own advertisement, too?
You certainly need their permission before you can advertise routes that falsely came to have passed through their network! And yes, I would argue that you do need permission to attach someone else's community string to your routes and that it would be considered at least terribly bad manners to use undocumented community strings from other people's ASes. (Documentation, of course, equates to permission.)
It seems to me that there are enough issues with this type of experimentation *with* the permission of the AS numbers you plan to use. But the ethical issues with using them without such permission seems to me to be insurmountable.
The ethical issues seem to be non-existent, to my way of thinking, and hence trivial to surmount :-)
I'm curious where you would draw the line then. And I'm curious what you think is the point of registering AS numbers at all, if it's okay to use other people's without their permission. DS
David Schwartz wrote:
Prepending announcements with remote AS numbers has been a well-known technique for preventing prefixes from propagating to particular ASes for a long time.
And therefore such use would not be considered experimental. We are talking about experimenting with routes that falsely claim to have passed through another autonymous system.
They are experimental in that yes, we are experimenting with a new technique for topology discovery which to our knowledge has not been proposed before. As regards "falsely claim to have passed through an autonomous system", that is not accurate: 1. RFC 1771, paragraph 5.1.6 says that in the presence of an ATOMIC_AGGREGATE attribute, "the actual path to destinations, [...] may traverse ASs that are not listed in the AS_PATH attribute." So an AS-path does not claim to contain all the ASes that the announcement has passed through. 2. Given an AS-set such as {1,2}, if you concluded that the announcement had passed through both AS1 and AS2, you would be wrong (most of the time, at least). So an AS-path does not claim that all the ASes in the path are ASes that the announcement has passed through. So, given these considerations, is everyone announcing an AS-set announcing "routes that falsely claim to have passed through another autonymous system"?
Every piece of BGP documentation I have ever seen says that this attribute documents the ASes that the route has actually passed through.
I think the above paragraph of RFC 1771 disagrees with you. Regards, Lorenzo
* lorenzo@ripe.net (Lorenzo Colitti) [Fri 04 Mar 2005, 00:09 CET]:
David Schwartz wrote:
Every piece of BGP documentation I have ever seen says that this attribute documents the ASes that the route has actually passed through. I think the above paragraph of RFC 1771 disagrees with you.
Please quote properly; the context was AS_path, not AS_set. David Schwartz was right on the mark here.
You certainly need their permission before you can advertise routes that falsely came to have passed through their network! And yes, I would argue that you do need permission to attach someone else's community string to your routes and that it would be considered at least terribly bad manners to use undocumented community strings from other people's ASes. (Documentation, of course, equates to permission.)
This latter half is nonsense. A community is a 32-bit number with no guarantee of uniqueness; it's up to some kind-hearted fellow network operators to act upon certain `magical' values (apart from well-known ones as no-announce and no-export, of course) that they may have described in an object's remarks in some IRR's database. ASNs are uniquely assigned to autonomous systems; preloading other AS_paths than your own in an advertisement should be frowned upon (just like adding fake Path: entries to your Usenet postings, or adding Received: headers to e-mail if the e-mail in question did not pass through those systems). -- Niels. -- The idle mind is the devil's playground
Niels Bakker wrote:
Every piece of BGP documentation I have ever seen says that this attribute documents the ASes that the route has actually passed through.
I think the above paragraph of RFC 1771 disagrees with you.
Please quote properly; the context was AS_path, not AS_set. David Schwartz was right on the mark here.
As far as the RFC is concerned, the AS-set is part of the AS-path. See Section 4.3, which says the AS-path is "a well-known mandatory attribute that is composed of a sequence of AS path segments. Each AS path segment is represented by a triple <path segment type, path segment length, path segment value>," where path segment type is 1 for AS_SEQUENCE and 2 for AS_SET. The RFC also says:
An AS_SET implies that the destinations listed in the NLRI can be reached through paths that traverse at least some of the constituent autonomous systems.
which is exactly what we are doing. Regards, Lorenzo
* lorenzo@ripe.net (Lorenzo Colitti) [Fri 04 Mar 2005, 02:09 CET]:
As far as the RFC is concerned, the AS-set is part of the AS-path. See Section 4.3, which says the AS-path is "a well-known mandatory attribute that is composed of a sequence of AS path segments. Each AS path segment is represented by a triple <path segment type, path segment length, path segment value>," where path segment type is 1 for AS_SEQUENCE and 2 for AS_SET.
I stand corrected.
The RFC also says:
An AS_SET implies that the destinations listed in the NLRI can be reached through paths that traverse at least some of the constituent autonomous systems.
which is exactly what we are doing.
Which would be planning to advertise routes with attributes claiming a topology that does not conform to reality? -- Niels. -- The idle mind is the devil's playground
The RFC also says:
An AS_SET implies that the destinations listed in the NLRI can be reached through paths that traverse at least some of the constituent autonomous systems.
which is exactly what we are doing.
Yes, you can cite sections of the RFC that you don't violate. That doesn't change a single thing about the sections you *do* violate. Nobody is arguing that you violate every single paragraph of the RFC. DS
David Schwartz wrote:
Prepending announcements with remote AS numbers has been a well-known technique for preventing prefixes from propagating to particular ASes for a long time.
And therefore such use would not be considered experimental. We are talking about experimenting with routes that falsely claim to have passed through another autonymous system.
They are experimental in that yes, we are experimenting with a new technique for topology discovery which to our knowledge has not been proposed before.
So you do not know what affect your announcements will have.
As regards "falsely claim to have passed through an autonomous system", that is not accurate:
I stand by it.
1. RFC 1771, paragraph 5.1.6 says that in the presence of an ATOMIC_AGGREGATE attribute, "the actual path to destinations, [...] may traverse ASs that are not listed in the AS_PATH attribute." So an AS-path does not claim to contain all the ASes that the announcement has passed through.
I never said anything about what the absence of an AS entry means, I only talked about what the presence of an AS entry meant.
2. Given an AS-set such as {1,2}, if you concluded that the announcement had passed through both AS1 and AS2, you would be wrong (most of the time, at least). So an AS-path does not claim that all the ASes in the path are ASes that the announcement has passed through.
The issue is not what conclusions I draw from an AS-set but what the rules are for including an AS in an AS-set.
So, given these considerations, is everyone announcing an AS-set announcing "routes that falsely claim to have passed through another autonymous system"?
Yes. From RFC1771: 1 AS_SET: unordered set of ASs a route in the UPDATE message has traversed ... AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems through which routing information carried in this UPDATE message has passed. The components of this list can be AS_SETs or AS_SEQUENCEs. ... In fact, RFC1771 goes on to specifically state under what conditions an AS can be added to the set: b) When a given BGP speaker advertises the route to a BGP speaker located in a neighboring autonomous system, then the advertising speaker shall update the AS_PATH attribute as follows: 1) if the first path segment of the AS_PATH is of type AS_SEQUENCE, the local system shall prepend its own AS number as the last element of the sequence (put it in the leftmost position). 2) if the first path segment of the AS_PATH is of type AS_SET, the local system shall prepend a new path segment of type AS_SEQUENCE to the AS_PATH, including its own AS number in that segment. When a BGP speaker originates a route then: a) the originating speaker shall include its own AS number in the AS_PATH attribute of all UPDATE messages sent to BGP speakers located in neighboring autonomous systems. (In this case, the AS number of the originating speaker's autonomous system will be the only entry in the AS_PATH attribute). b) the originating speaker shall include an empty AS_PATH attribute in all UPDATE messages sent to BGP speakers located in its own autonomous system. (An empty AS_PATH attribute is one whose length field contains the value zero). So you are violating RFC1771, plain and simple. To then go and cite one small section of RFC1771 in your defense is hypocritical.
Every piece of BGP documentation I have ever seen says that this attribute documents the ASes that the route has actually passed through.
I think the above paragraph of RFC 1771 disagrees with you.
Since you obviously feel totally free to violate RFC 1771, the one paragraph that vaguely supports what you're doing really doesn't help you. Especially since it says nothing about the *presence* of an AS set. DS
David Schwartz wrote:
They are experimental in that yes, we are experimenting with a new technique for topology discovery which to our knowledge has not been proposed before.
So you do not know what affect your announcements will have.
We don't know the effectiveness of the technique. That depends on the topology of the Internet, where you run the announcements from, etc. etc. We do know the effect that the announcements will have on BGP routers, i.e., cause them to ignore the path if they are in the AS-set, and accept them otherwise (modulo policy, max aspath length, etc. etc., of course).
So, given these considerations, is everyone announcing an AS-set announcing "routes that falsely claim to have passed through another autonymous system"?
Yes. From RFC1771:
Ok, so if everyone announcing an AS-set is announcing "routes that falsely claim to have passed through another autonymous system", and you are saying this shouldn't be done, then why aren't you complaining with everyone who is announcing an AS-set?
[Quote of section 5.1.2 almost in its entirety]
So you are violating RFC1771, plain and simple. To then go and cite one small section of RFC1771 in your defense is hypocritical.
You quote Section 5.1.2, but you don't mention that if you follow Section 5.1.2 to the letter there is no way that an AS-path may contain an AS-set. To summarize the whole of section 5.1.2, the various cases are: Propagating a route learned from an UPDATE message: a) To another router in same AS: don't modify AS-path b) To a neighboring AS: 1. Path starts with AS_SEQUENCE: prepend own ASn 2. Path starts with AS_SET: prepend new AS_SEQUENCE with own AS in it Originating a route: a) To neighboring AS: announce own ASn as only element in path b) To another router in same AS: announce empty AS-path If you follow this to the letter, you must rule out both prepending "(In this case, the AS number of the originating speaker's autonomous system will be the only entry in the AS_PATH attribute)" and any form of AS-set, since there is no way, following these rules, that an AS-set may enter the AS-path in the first place. If we are violating this section, then everyone else announcing an AS-set, and - at least the way I read it - anyone doing prepending, is doing so too. But nobody is suggesting that these things shouldn't be done. Regards, Lorenzo
lorenzo, i think we're ratholing here. can you tell us in simple words o what you are trying to learn with your experiment and why it will help us understand or better manage our networks (thanks rodney) o why the way you are doing it is safe and will not affect the packets we're trying to move for our customers in negative ways thanks randy
I think this nicely summarizes it. If you answer these questions, most people will be happy, Henk At 02:19 04/03/2005, Randy Bush wrote:
lorenzo,
i think we're ratholing here. can you tell us in simple words
o what you are trying to learn with your experiment and why it will help us understand or better manage our networks (thanks rodney)
o why the way you are doing it is safe and will not affect the packets we're trying to move for our customers in negative ways
thanks
randy
------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine)
Randy Bush wrote:
i think we're ratholing here. can you tell us in simple words
Indeed. Therefore, we are working on a document that will provide a detailed explanation of our methods, why we believe they are useful, and why we believe they are safe. Once it is ready we will post a link to this list and elsewhere so people can comment on it, discussion can continue, and hopefully a consensus can be found on the use of the techniques. We hope to have something ready in two to three weeks. Regards, Lorenzo
So, given these considerations, is everyone announcing an AS-set announcing "routes that falsely claim to have passed through another autonymous system"?
Yes. From RFC1771:
Ok, so if everyone announcing an AS-set is announcing "routes that falsely claim to have passed through another autonymous system", and you are saying this shouldn't be done, then why aren't you complaining with everyone who is announcing an AS-set?
I never said that this shouldn't be done. I said it shouldn't be done without the consent of the owners of the ASes you wish to include. In addition, the things I don't complain about don't constitute a defense to the things I do complain about.
[Quote of section 5.1.2 almost in its entirety]
So you are violating RFC1771, plain and simple. To then go and cite one small section of RFC1771 in your defense is hypocritical.
You quote Section 5.1.2, but you don't mention that if you follow Section 5.1.2 to the letter there is no way that an AS-path may contain an AS-set. To summarize the whole of section 5.1.2, the various cases are:
Propagating a route learned from an UPDATE message:
a) To another router in same AS: don't modify AS-path b) To a neighboring AS: 1. Path starts with AS_SEQUENCE: prepend own ASn 2. Path starts with AS_SET: prepend new AS_SEQUENCE with own AS in it
Originating a route:
a) To neighboring AS: announce own ASn as only element in path b) To another router in same AS: announce empty AS-path
If you follow this to the letter, you must rule out both prepending "(In this case, the AS number of the originating speaker's autonomous system will be the only entry in the AS_PATH attribute)" and any form of AS-set, since there is no way, following these rules, that an AS-set may enter the AS-path in the first place.
Section 9.2.4.2 documents how an AS-set can enter the AS-path as part of aggregating routes. As far as I can tell, the use of AS-sets is permitted only to aggregate routes.
If we are violating this section, then everyone else announcing an AS-set, and - at least the way I read it - anyone doing prepending, is doing so too. But nobody is suggesting that these things shouldn't be done.
Lovely straw man. I complained about the lack of *consent* and you talk about people prepending their *own* AS numbers? Are you suggesting they lack their own consent?! DS
On Thu, Mar 03, 2005 at 02:28:43PM -0800, David Schwartz wrote: [ snip ]
Every piece of BGP documentation I have ever seen says that this attribute documents the ASes that the route has actually passed through.
Do I need to get permission from Sprint before I include 1239:100 as a community-string attribute on my own advertisement, too?
You certainly need their permission before you can advertise routes that falsely came to have passed through their network!
What kind of specific _technical_ issue do I create by prepending another ASN on AS_PATHs I advertise, without such "owner"'s permission?
that you do need permission to attach someone else's community string to your routes and that it would be considered at least terribly bad manners to use undocumented community strings from other people's ASes. (Documentation, of course, equates to permission.)
Please, that's ridiculous. [ snip ]
I'm curious where you would draw the line then. And I'm curious what you think is the point of registering AS numbers at all, if it's okay to use other people's without their permission.
If you are concerned about accuracy of registration records, I would advise that you ensure that your origin AS (aka the last ASN showing up before 'i' on Cisco or 'I' on Juniper in show output) in the AS_PATH is accurate. I don't see any technical pitfalls to include someone else's ASN in the transit path to avoid that particular ASNs from seeing it, other than the fact that is generally a frowned-upon or tasteless act to do. -J
On Mar 3, 2005, at 7:22 PM, James wrote:
You certainly need their permission before you can advertise routes that falsely came to have passed through their network!
What kind of specific _technical_ issue do I create by prepending another ASN on AS_PATHs I advertise, without such "owner"'s permission?
Oh, I don't know, increasing the size of an already bloated global routing table; possibly crashing routers which are already starving for FIB RAM? A certain level of stability is to be expected on the global routing table. Playing with it isn't a 'good thing'. Besides the fact that they are experimenting with the core of the Internet. What if their experiments had an unwanted effect? What is the global financial impact of backbone instability? That is an awful big grenade they are chucking about. I think it is irresponsible for someone, no matter how educated or well intentioned to throw experiments into the middle of the network. -Matt
On Thu, Mar 03, 2005 at 07:40:53PM -0500, Matthew Crocker wrote: [ snip ]
Oh, I don't know, increasing the size of an already bloated global routing table; possibly crashing routers which are already starving for FIB RAM?
Probably not FIB, may be the BGP RIB for the most people that may be affected. If it is FIB that we are concerned about, well.. its only two additional prefixes to be held. I think the top polluters on www.cidr-report.org are more so on the critical path than this experiment.
A certain level of stability is to be expected on the global routing table. Playing with it isn't a 'good thing'. Besides the fact that they are experimenting with the core of the Internet.
They are not playing with the core. The result of what they are doing is dependent on specific topology and level of direction they are throwing prefixes at.
What if their experiments had an unwanted effect? What is the global financial impact of backbone instability? That is an awful big grenade they are chucking about.
I think it is irresponsible for someone, no matter how educated or well intentioned to throw experiments into the middle of the network.
While I will not dispute your statement, I believe that every ASN should be responsible of their own and should not trust the General Internet to not cause harm on their network. If your router is going to crash b/c of someone advertising an unusual AS_PATH, I don't view that differently from a box getting owned because it was running unpatched OS since 1999 without any firewall rules either. -J
participants (9)
-
David Schwartz -
Henk Uijterwaal -
James -
Jerry Pasker -
Joe Abley -
Lorenzo Colitti -
Matthew Crocker -
Niels Bakker -
Randy Bush