Heads up: Long AS-sets announced in the next few days
David Schwartz
davids at webmaster.com
Fri Mar 4 00:06:06 UTC 2005
> 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
More information about the NANOG
mailing list