Heads up: Long AS-sets announced in the next few days

Mailman List Mirror (Read Only)
21

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

22

[ 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

23

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

24

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

25

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

26

[ 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

27

* 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.

28

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

29

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

30

>>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

31

I think this nicely summarizes it. If you answer these questions,
most people will be happy,

Henk

32

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