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