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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-02, at 19.38, 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.

Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiYNZ6arNKXTPFCVEQL/sgCdHCBV87HM9jIgNATJhpW5aON/1TwAniAR i1p06marP5ra05ey9YcxX90f =W+rc -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-03, at 10.27, Geoff Huston wrote:

...

On 2005-03-02, at 19.38, 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.

Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs?

Isn't this a case of illustrating how easy it is to tell lies in BGP today? I don't see what hitting the RIRs has do to with this. The problem appears to be more basic than that - its just too easy to tell lies in BGP and get the lies propagated globally.

Well agreed. And that is an important point in itself. The reference to the RIRs was me trying to be ironic as when we have prefix hijacks that seems to be reported to the RIRs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQibejKarNKXTPFCVEQKO6ACeIzkX5j04JA3RK3Y48fSsXM0DMLEAoM+k 6+j6phNoiKSg5Qai2CNSloLa =TWvV -----END PGP SIGNATURE-----

At 04:02 AM 4/03/2005, Jeroen Massar wrote:

On Thu, 2005-03-03 at 20:27 +1100, Geoff Huston wrote:

...

...

On 2005-03-02, at 19.38, 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.

Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs?

Isn't this a case of illustrating how easy it is to tell lies in BGP today? I don't see what hitting the RIRs has do to with this. The problem appears to be more basic than that - its just too easy to tell lies in BGP and get the lies propagated globally.

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

precisely - I think we've now managed to reach a common understanding that looking for "lies" in BGP is a difficult and expensive task and more often than not the "lies" get through anyway. The approaches above clearly flag what is intended to be "truth", with the inference that what is not clearly traceable back to originating attestations is a potential lie. We really should be moving in this direction now! Geoff

On Thu, 2005-03-03 at 13:51 -0500, Blaine Christian wrote:

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

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 :) Greets, Jeroen

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.

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. So, yes, please do keep my ASns out of this cloak and dagger research. I would have thought it prudent to seek permission from the particular ASn operators before even considering using them for this experiment. Regards James PS, curious if AS7007 is part of your set of selected ASns, however they may have been selected.

On Thu, 3 Mar 2005, Lorenzo Colitti wrote:

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

Hi Lorenzo, Its a basic design function to keep the net loop free, of BGP to not accept a route with the routers own ASn in the path from an external peer. 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. I'm sure this was never an intended use for BGP as paths (or as sets, but that could be confused with the as-set object in the ripe database, which is something different, so i'll say as-paths). 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. 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! There are various 'better than regular bgp bestpath' platforms out there, such as those internap implements, routescience, sockeye, netvmg.. Are you certain that these products do not take into account the amount of churn of a given ASn? By inserting operators ASns into announcements for your research, you are artifically increasing the amount of churn seen for their ASn. I note from your initial email "The announcements will be for prefixes 84.205.73.0/24 and 84.205.89.0/24 and will originate in AS12654." I'd like to point you at https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html and note that the smallest allocation from 84/8 is a /21, so by doing your announcements with /24s, you are probably going to hit some operators prefix length filters, thus tainting your results. You might be better off with some swamp space, which will be accepted globally as /24s. Sorry to be a wet blanket, but I think inserting other operators ASns without their permission is lunacy. I'm also concerned that this might lead to a convention where inserting other operators ASns into a path becomes more seen as 'acceptable', whereas it is currently regarded as a big 'no no'. And I suspect that prefix length filtering on your /24s from /21 space is going to taint the results anyway. Regards James

Dear All,

But first we need to do the experiments...

Given the large number of complaints on the various lists, I have decided to cancel this experiment for the time being. We may reschedule it at a later date, but only after we have posted a list of AS# to be used and given people a chance to opt-out beforehand. How exactly we are going to do this, has not been decided. As the RIPE NCC, we place great value in the support that you have given to our measurement experiments over the last years. I do not want to be responsible for destroying that trust with an experiment that may affect the reachability of 100+ AS's for a few hours during office hours. In Lorenzo's defence, I have to say that he is a very enthousiastic student who has been doing great stuff in the routing area. On this occasion, he became a bit overenthousiastic though. Henk ------------------------------------------------------------------------------ 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)

Please exclude AS8220. Regards, Neil.

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Lorenzo Colitti Sent: 02 March 2005 19:35 To: James A. T. Rice Cc: Gert Doering; nanog@merit.edu; routing-wg@ripe.net; ris-users@ripe.net; compunet@dia.uniroma3.it Subject: Re: Heads up: Long AS-sets announced in the next few days

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] http://www.ris.ripe.net/bgplay/ [2] http://bgplay.routeviews.org/bgplay/