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

Mailman List Mirror (Read Only)
1

Hi,

as announced to the RIPE routing working group mailing list [1] and elsewhere, over the next few days the Computer Networks research group at Roma Tre University, in collaboration with the RIPE NCC RIS project, will be performing experiments involving announcements with large AS-sets in the AS-path. We are doing this to test innovative network discovery methodologies we developed to allow ISPs to determine how their prefixes are seen by the rest of the Internet. The announcements will be for prefixes 84.205.73.0/24 and 84.205.89.0/24 and will originate in AS12654.

We have been performing similar experiments over IPv6, in collaboration with the NAMEX internet exchange, since December 2004 with no ill effects; furthermore, our announcements are standard BGP, so conformant implementations should be able to process them, and very long AS-sets have already been observed in the past (e.g. [2], [3]). However, we want to be careful to avoid router bugs on legacy devices, old firmware versions and the like, so we are first sending out test announcements with progressively longer AS-sets. Should you encounter a problem with these advertisements, please let us know and we will withdraw them.

The proposed timetable of the test announcements is as follows.

2005-03-04:
  14:00 UTC: 10-element AS-set
  14:30 UTC: withdrawal
  16:00 UTC: 25-element AS-set
  16:30 UTC: withdrawal

and, if there are no problems:

2005-03-07:
  14:00 UTC: 50-element AS-set
  14:30 UTC: withdrawal
  16:00 UTC: 100-element AS-set
  16:30 UTC: withdrawal

Note: For reference, the AS-sets already observed in [2] and [3] contained 123 and 124 ASes respectively.

For questions/comments, please contact compunet@dia.uniroma3.it or lorenzo@ripe.net.

Regards,
Lorenzo Colitti
On behalf of the Roma Tre Computer Networks Research group

[1] http://www.ripe.net/ripe/maillists/archives/routing-wg/2005/msg00021.html
[2] http://www.ripe.net/projects/ris/Talks/0101_RIPE38_AA/sld003.html
[3] http://www.ripe.net/maillists/ncc-archives/ris-users/2002/msg00044.html

2

AS-Sets, not AS-Paths...

Regards,
Daniel

3

An example of which I received recently:
Feb 27 19:54:16: %BGP-6-ASPATH: Long AS path 20965 1299 3320 15589 15589 5397 {33,109,145,293,559,816,1103,1273,1275,1752,1853,1930,2042,2200,2497,2500,2914,3257,3265,3333,3352,3425,3549,4691,4697,4716,4725,5511,5539,5609,5623,6175,6435,6453,6762,6830,6939,7580,7660,8447,8472,8763,9264,10566,12779,12793,12859,13944,14277,15897,17715,17965,24136,24895,25358,29377,29686,31103,32266} received from 2001:798:201B:10AA::1: More than configured MAXAS-LIMIT

-Hank

4

different, but related to:
Feb 1 20:47:01.608: %BGP-6-ASPATH: Long AS path 3356 6770
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
received from x.y.a.b: More than configured MAXAS-LIMIT

hey, 8282/Fido, perhaps you don't really need a 100 as as-path? :slight_smile:

-Chris

5

uhm, back in my hole... this is a month ago :slight_smile:

6

Gert Doering wrote:

2005-03-04:
14:00 UTC: 10-element AS-set
14:30 UTC: withdrawal
16:00 UTC: 25-element AS-set
16:30 UTC: withdrawal

Please do not announce AS-sets that contain 5539. We are not part of
your experiment, and we don't want to see our AS appear in other people's
router error messages.

Ok, no problem: we will not include AS 5539 in any of the AS-sets we announce.

Regards,
Lorenzo

7

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

8

James A. T. Rice wrote:

This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use.

In which case please keep AS8330, AS8550, and AS8943 out of your experiments too.

Using not yet allocated ASns out of RIPEs asn-blocks would have been more sensible, IMHO.

James,

we are not picking ASes at random. The AS-set announcements are part of new techniques we are developing for ISPs who wish to discover how their prefixes are seen by the rest of the Internet. We believe this will come to be a useful tool for operators.

However, since this is still work in progress, and in scientific research there is no room for second place, I can't really reveal any more than that at the moment.

I would like to point out, though, that our research group does have a proven track record in the field network discovery (examples available on request), and has created software useful to the operator community such as BGPlay [1][2].

That said, if you want us to exclude those ASes from our AS-sets, then we will do so.

Regards,
Lorenzo

[1] RIPEstat - BGPlay
[2] http://bgplay.routeviews.org/bgplay/

9

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

10

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

11

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

12

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

Joe

13

I am probably telling you what you already know, but for the ones who
don't know it yet:

Secure BGP (S-BGP):
http://www.ir.bbn.com/projects/s-bgp/
http://www.nanog.org/mtg-0306/pdf/bellovinsbgp.pdf
http://www.nwfusion.com/details/6484.html?def

and of course the sister by amongst others Cisco:

Secure Origin BGP (SO-BGP):
http://bgp.potaroo.net/ietf/idref/ draft-ng-sobgp-bgp-extensions/
http://www.nwfusion.com/details/6485.html
http://www.nanog.org/mtg-0306/pdf/alvaro.pdf

etc... most people know how to google I guess :wink:

Aka BGP with certificates and other nice tricks.

Greets,
Jeroen

14

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? :wink:

-Jerry

15

I am probably telling you what you already know, but for the ones who
don't know it yet:

Secure BGP (S-BGP):
http://www.ir.bbn.com/projects/s-bgp/
http://www.nanog.org/mtg-0306/pdf/bellovinsbgp.pdf
http://www.nwfusion.com/details/6484.html?def

and of course the sister by amongst others Cisco:

Secure Origin BGP (SO-BGP):
http://bgp.potaroo.net/ietf/idref/ draft-ng-sobgp-bgp-extensions/
http://www.nwfusion.com/details/6485.html
http://www.nanog.org/mtg-0306/pdf/alvaro.pdf

etc... most people know how to google I guess :wink:

Aka BGP with certificates and other nice tricks.

And, of course, the RPSEC working group draft that is supposed to target the
BGP requirements for those proposed systems is...

http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-01.txt

The folks who worked on S-BGP and SO-BGP participated in it's creation (as
well as several operators). Please note that there are more than just two
proposed mechanisms for securing BGP. The two mentioned above are just the
most popular <grin>.

16

Thanks for the new reading material, I had not seen that one yet...
*print* will be a nice read

(hmmm, actually I should swear at you for even more reading material,
for which I have no time, oh well :slight_smile:

Greets,
Jeroen

17

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

  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

18

James A. T. Rice wrote:

You appear to be trying to take advantage of a side effect of this behaviour, in order to see what other ASn transitive adjacancies are available that would not normally be used, by inserting the ASns of transit AS's that would normally be used, into the as path you are announcing.

Yes, that's more or less what we are proposing.

I'm sure this was never an intended use for BGP as paths

No, obviously not. But many things in the protocols we use today are used in ways that the original authors didn't have in mind. Examples I can think of at the moment are IP-in-IP tunnels, TCP congestion control (bolted on to TCP long after it was first designed), NAT and private addresses, ..., but I'm sure there are many more.

So I think a more relevant question than "was this intended", rather "is this useful? If so, does it break existing stuff?"

More to the point, you are breaking a very fundemenatal convention
and expectation that if you see a given ASn in an as path, that route
will have transited that given ASn.

That is not true in all cases. RFC 1771, paragraph 5.1.6, says:

A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute needs to be cognizant of the fact that the actual path to
destinations, as specified in the NLRI of the route, while having the
loop-free property, may traverse ASs that are not listed in the
AS_PATH attribute.

I think that most of the the AS-sets you see announced in the Internet today have this property, and ours are no different: the sequence before the AS-set shows which ASes the announcement has passed through, and the AS-set which ASes the announcement "might have passed through".

As such, inserting others ASns into an as path is about as helpful to
debugging as policy routing all your ICMP traffic to a box running
fakeroute!

I don't understand why this should be the case. If you exclude the
AS-set, then you get exactly the path that was followed by the
announcement. How does that hamper debugging?

Regards,
Lorenzo

19

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

20

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