- Ris-int - mailman.ripe.net

Fw: NCC#2005030185 [Re: Request for BGP Data]
by RIPE NCC RIS 04 Apr '05

04 Apr '05

I will offer him to have peer rrc00 or rrc03. Is that OK? Arife ----- Begin forwarded message ----- Date: Tue, 29 Mar 2005 12:52:00 -0600 From: Dave Deitrich <deitrich(a)cymru.com> To: RIPE NCC RIS <ris-request(a)ripe.net> Subject: Re: NCC#2005030185 Request for BGP Data Cc: Team Cymru <team-cymru(a)cymru.com> Message-Id: <d8fbe6c398357cfe9884421b75fc8394(a)cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 24, 2005, at 4:01 AM, RIPE NCC RIS wrote: > As you may already know, we have rawdata available on RIS Web site. > We collect BGP updates and the snaphost of RIB (3 times a day, bview > files). I'm just wondering those RIB dumps will help you or not. If > not, > could you give us more detail what kind of applications you are > planning > to implement, and also which RRCs you like to peer with. Greetings RIPE, Thank you very much for your reply. Most of our scripts are geared towards accepting data from live BGP feeds so we would generally prefer direct peering over RIB snapshots. Also, we like to monitor for anomalies on a near real-time basis so only seeing snapshot data 3 times a day is not really ideal for our needs. We use the BGP data to track the stability of critical infrastructure, such as the DNS root and gTLD name servers. One example of our monitoring is available on our DNS page at the following URL: <http://www.cymru.com/DNS/dns.html> We will send out alerts to certain folks when notable events occur; for example, when the actual BGP information does not match with the expected BGP information for a particular root nameserver. We also use the data to provide some interesting BGP statistics on our BGP monitoring page. <http://www.cymru.com/BGP/index.html> This includes the tracking of bogon prefixes, bogus ASNs, and a few other statistics. <http://www.cymru.com/BGP/robbgp-bogon.html> <http://www.cymru.com/BGP/asnbogusrep.html> Mostly we use the data to provide free insight to the wider community. This insight is both "push" and "pull," in that we send email alerts to those who subscribe to an automated alert service. This provides them with instant notification of bogon prefix announcements, bogus ASN leakage, and prefix hijacking. Obviously with more BGP feeds we get a wider view of the internet and are able to provide better insight to the Internet community. This is why we have been contacting people and asking if we could peer with them for visibility into their BGP data. If you are interested in helping us we'd love to peer with as many RCCs as you're willing to give us access to. If you have any additional questions please let us know. Thank you for your consideration. - -- DAVE DEITRICH deitrich(a)cymru.com -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQkmVx0iQQdywQH32EQLJJgCfUTBFRjDtcmyDJC3S2p5hDPKs42QAn3Jv 8zCTRqsmVwQHIK2tyX++9oar =FBbt -----END PGP SIGNATURE----- ------ End forwarded message ------

1 0

Fw: NCC#2004081420 [Re: RIPE beacon request!]
by RIPE NCC RIS 04 Apr '05

04 Apr '05

FYI ----- Begin forwarded message ----- Date: Thu, 24 Mar 2005 17:13:04 -0500 From: Hitesh Ballani <hitesh(a)cs.cornell.edu> To: RIPE NCC RIS <ris-request(a)ripe.net> Subject: Re: NCC#2004081420 RIPE beacon request! Message-Id: <1111702384.25482.28.camel(a)devilman.u.cs.cornell.edu> Hello Arife, > I was thinking to contact you about the latest change in Beacons. I hope > you noticed that. We were running out Beacon prefixes, and got new big > block from RIPE, and replace the previous ones with new one. > > Latest changes are here, > > http://www.ripe.net/projects/ris/docs/beaconlist.html Yep, I noticed that .. thanks! > About your request, I have to discuss with my colleagues and get back to > you. Sure! > BTW, do you have any results online about your previous experiement? It > would be nice to look at it. Lorenzo, a colleague of mine, is also doing > somework about anycast root servers. Its great to hear that other people are interested and working on anycast too. In the intervening weeks (months?) since we last talked, I have done a bunch of anycast measurements. Most of the earlier measurements were to support of our anycast architecture proposal (http://www.usenix.org/publications/library/proceedings/worlds04/tech/ballan…). Attached is our subsequent submission to SIGCOMM (please do not forward the paper outside your group) - section IV.A and IV.D describe those measurements. Beyond this, we realised that it would be good to do a detailed measurement study of current anycast deployments (i.e. DNS root-servers and AS-112 servers). This study was conducted over a period of 3 months. I summarize our main results here: 1. That anycast, as deployed today, is quite poor at selecting the closest server in terms of latency. We think we know why, and that it can be fixed, but nevertheless that is what we see. (Section IV.D of our SIGCOMM paper) 2. That anycast is quite good in preserving affinity - during the period of the study, I maintained a web-site which showed my latest results (http://www5.cs.cornell.edu/~hitesh/anycast-g2.html). This disagrees with data from a study done by the operators of J-root who argued against running connection oriented services on top of anycast based on their measurements. Hence the need to do a wider scale study and this is why i need your cooperation. We plan to describe these in a measurement paper and submit to IMC in May. It would be great to see what you guys are interested in and maybe I can help you out. -- Thanks, Hitesh p.s. the above description is highly condensed - feel free to ping me if you have any questions/comments. > Regards. > Arife > > On Thu, 10 Mar 2005 03:56:08 -0500, Hitesh Ballani wrote: > > Hello Arife, > > > > Thanks for your help with my last experiment - but I need an even bigger > > favor now. I am going to describe my requirements below - if you do not find > > them feasible, please feel free to tell me so. Also, if you have stopped > > leasing out beacons to external researchers, I totally understand. > > > > I need a prefix to be advertised to many RRCs (as many as possible) for the > > duration of a week or so. However, this time I also need the RRCs to run a > > nameserver and answer queries for a particular domain. My friend here at > > Cornell owns a domain name (guha.cc) and hence, I can point anycast.guha.cc > > to the anycast address you assign to me. So for example, assume you assign a > > prefix a.b.c.0/24 to my experiment and it is advertised by 8 RRCs. I want all > > the 8 RRCs to run a nameserver and answer DNS queries (type A) for > > anycast.guha.cc - each RRC will answer with a different address. Hence, the > > first RRC will answer with a.b.c.1, the second with a.b.c.2 and so on. The > > purpose of this is that such an arrangement allows me to use thousands of DNS > > servers which have recursion enabled to perform my measurements and hence, > > adds a lot of value to my anycast study. The above mentioned approach for > > measurement is known as KING and was developed at U.Wash (described here > > http://www.cs.toronto.edu/~stefan/publications/imw/2002/imw.html). > > > > In case this sounds vaguely feasible, I would be more than happy to give you > > more details or clarify any doubts you may have. We have used the King > > approach for anycast measurements against the anycasted root-servers - and > > so, have some sense of what is required. You might have security concerns > > regarding running a name-server on your RRCs. I think there are standard > > techniques (eg. running BIND in a chroot JAIL) by which we can ensure that > > this experiment does not add any vulnerabilities to the RRCs - again, I can > > provide with more information/help in case you are interested. > > > > Thanks for your time, > > Hitesh > > ------ End forwarded message ------

1 0

Fw: NCC#2004081420 [RE: RIPE beacon request!]
by RIPE NCC RIS 04 Apr '05

04 Apr '05

Hi guys, What do you think about this request? James, what does OPS think to run named on RRCs? Arife ----- Begin forwarded message ----- Date: Thu, 10 Mar 2005 03:56:08 -0500 From: "Hitesh Ballani" <hitesh(a)cs.cornell.edu> To: "RIPE NCC RIS" <ris-request(a)ripe.net> Subject: RE: NCC#2004081420 RIPE beacon request! Message-Id: <2EE48095D8C21643B0B70EC95F9BFBAF0A3174(a)EXCHVS1.cs.cornell.edu> Hello Arife, Thanks for your help with my last experiment - but I need an even bigger favor now. I am going to describe my requirements below - if you do not find them feasible, please feel free to tell me so. Also, if you have stopped leasing out beacons to external researchers, I totally understand. I need a prefix to be advertised to many RRCs (as many as possible) for the duration of a week or so. However, this time I also need the RRCs to run a nameserver and answer queries for a particular domain. My friend here at Cornell owns a domain name (guha.cc) and hence, I can point anycast.guha.cc to the anycast address you assign to me. So for example, assume you assign a prefix a.b.c.0/24 to my experiment and it is advertised by 8 RRCs. I want all the 8 RRCs to run a nameserver and answer DNS queries (type A) for anycast.guha.cc - each RRC will answer with a different address. Hence, the first RRC will answer with a.b.c.1, the second with a.b.c.2 and so on. The purpose of this is that such an arrangement allows me to use thousands of DNS servers which have recursion enabled to perform my measurements and hence, adds a lot of value to my anycast study. The above mentioned approach for measurement is known as KING and was developed at U.Wash (described here http://www.cs.toronto.edu/~stefan/publications/imw/2002/imw.html). In case this sounds vaguely feasible, I would be more than happy to give you more details or clarify any doubts you may have. We have used the King approach for anycast measurements against the anycasted root-servers - and so, have some sense of what is required. You might have security concerns regarding running a name-server on your RRCs. I think there are standard techniques (eg. running BIND in a chroot JAIL) by which we can ensure that this experiment does not add any vulnerabilities to the RRCs - again, I can provide with more information/help in case you are interested. Thanks for your time, Hitesh > -----Original Message----- > From: RIPE NCC RIS [mailto:ris-request@ripe.net] > Sent: Monday, September 20, 2004 8:13 AM > To: Hitesh Ballani > Subject: Re: NCC#2004081420 RIPE beacon request! > > Hi Hitesh, > > > Lets start off with a prefix (I presume 195.80.238.0/24) being > advertised as > > normal (i.e. no periodic withdrawals) from 6 locations : RRC01 (Lon,UK), > > RRC02 (Paris,UK), RRC05 (Vienna,AT), RRC06 (Otemcahi, JP), RRC08 (San > > Jose,US), RRC11(NY,USA). As I mentioned earlier, the purpose is to get > > baseline measurements for an anycasted prefix when there are no flaps > (at > > least, no intentional flaps). Then, later we can introduce flaps for > other > > experiments. > > I configured on rrc01, rrc02, rrc05, rrc06, and rrc11. rrc08 is offline > by now. It's replacement would be rrc14 at PAIX, but it's not online > yet. > > > Actually, what I would like to do is to have the prefix advertised in a > > stable fashion (i.e. no intentional withdrawals) from 7 RRC locations > with > > the locations changing every couple of days .... i.e. of the 13 RRCs, 7 > are > > always advertising the prefix but the set of seven changes every couple > of > > days ...since, I would like the non-european sites (3 of them) to always > be > > part of the advertising set, so we are left with choose(13 - 3, 7 -3) = > > choose(10,4) = 1260 combinations ... while this is not certainly not > > possible, I was wondering if we could try out 5-7 odd combinations so > that > > the entire experiment finishes in a couple of weeks and then, we can > move > > onto the experiments with periodic withdrawals ... however, I am not > sure if > > this can be automated (I would be happy to write any scripts needed for > this) > > because it would be a pain for you to do this manually .. if this is > > possible, then I would be more than happy to send you a chart of the 5-7 > sets > > of 7 RRCs, each set advertising the prefix for 2 (or whatever u are > > comfortable with) days .. However, if this is not feasible, then we > could > > start with the pattern mentioned in the previous paragraph and make 1 or > 2 > > changes (2 weeks, one change a week gives us 2 combinations to try out). > > Comments?? > > I do not have any comments by now. Should think about it. > > Thanks for offer. We will see how much of time is required from our side. > Then, we can do something about it. We have already some scripts that > do the config changes on zebra/bgd. We can modify that one. > > > > > By the way, are you going to set up interfaces on these machines so that > I > > can also do end-to-end experiments? > > I've configured an interface on those RRCs, IP address, 195.80.238.1. You > can try to ping that address. In a few minutes, I will send an e-mail to > those IXs mailinglists also to allow transit that prefix. > > Regards. > Arife ------ End forwarded message ------

3 2

LFT traceroute & RISwhois
by Rene Wilhelm 22 Mar '05

22 Mar '05

Following last week's thread on nanog re: "traceroute with asn" the author of LFT traceroute, Victor Oppleman, approached me offering to add riswhois lookups to the next version of LFT. (see attached e-mail). Replacing "one-connection/one-query" lookups to RADB by lookups to RISwhois was done in a jiffy, but recognizing the potential of RISwhois, he continued spending time adding support for bulk queries (all queries over one connection) In this process it turned out there was a need for an additional riswhois option: a "-1" flag which restricts the output to one and only one route object per prefix. In combination with -M this flag ensures LFT receives at most one origin for each IP. Having checked various prefixes on the Moas page (http://www.ris.ripe.net/moas/moas.html), it does make sense to report only 1 origin for each IP: most of the time the second origin is either one with a handfull of ris peers, or a private AS. As the required modifications in riswhoisd weren't too difficult and I wanted to keep the momentum going ("het ijzer smeden als het heet is"), I took care of adapting riswhoisd last sunday and for testing purposes started it on halfweg's port 4444. Of course, I overlooked the default deny-all firewall rules, so had to wait 'till monday for Ops to punch a temporary hole to allow Victor to test his LFT-with-RISwhois development. (thanks Emil!) All tests were succesful, so now it's time to follow a proper installation procedure for new riswhoisd (will create a ticket with ris(a)ripe.net for that) Last but not least, I leave you with this quote from Victor: [...] I have things to attend to also, but I was just excited seeing as though the RIS is a cool (very cool) service/infrastructure and I think it may be the most trustworthy way of attaining this information with regard to the LFT user community. I really appreciate what you guys have done and I'm glad we can interoperate. -- Rene ========================================== From: Victor Oppleman <victor(a)oppleman.com> Subject: LFT & RISwhois Date: Tue, 15 Mar 2005 15:48:16 -0700 To: wilhelm(a)ripe.net Hi Rene, I just saw this note (a friend just forwarded to me). The new (as yet unreleased) version of LFT supports querying not only the RADB/IRR (formerly the default when using the -A (asn lookup) option), but also the pWhoIs project (sounds like the same thing RISwhois is doing--we wrote one too) OR Cymru (another source of prefix-based whois data). If you're using pWhoIs or Cymru, it's *really* fast because it can grab the ASNs in bulk (one connection/query) instead of one connection per each query. If you'd like, I'm happy to code in an option to use data from your project (RISwhois), I just hadn't heard of it yet. Does it support bulk queries or should I do it like I do with RADB/IRR and hit it once for each query? Thanks! > From: Rene Wilhelm <wilhelm(a)ripe.net> > Date: Tue, 15 Mar 2005 05:57:03 -0700 > To: <bep(a)whack.org> > Cc: Ziggy David Lubowa <ziggy(a)trueafrican.com>, Joe Shen > <joe_hznm(a)yahoo.com.sg>, Raymond Dijkxhoorn <raymond(a)prolocation.net>, > NANGO > <nanog(a)merit.edu> > Subject: Re: Traceroute with ASN > > > >> | Doesnt look like you have to, below is the link to the tarball >> | >> | http://oppleman.com/dl/?file=lft-2.3.tar.gz >> | >> >> >> According to the doc, it relies on RADB for its info, so it *might* >> not be >> as accurate as an actual BGP feed. > > Indeed. That's why we've created "RISwhois" [1], a whois interface to > the BGP data collected by RIPE NCC's RIS project [2]. You query > riswhois.ripe.net like you'd query whois.ra.net, but the data > returned are from active BGP feeds, not manually registered objects. > > Since RISwhois uses the same format as RADB, it's trivial to have lft > consult the RIS BGP tables: simply replace the string "whois.ra.net" > by "riswhois.ripe.net" in the whois.c file and recompile. > > -- Rene > > [1] > http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-eof- > riswhois.pd > f > > [2] http://www.ripe.net/projects/ris/index.html > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rene Wilhelm RIPE Network Coordination Centre > Email: wilhelm(a)ripe.net Amsterdam, the Netherlands > Phone: +31 20 535 4417 Fax: +31 20 535 4445 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1 0

Fw: NCC#2005030185 [Request for BGP Data]
by RIPE NCC RIS 21 Mar '05

21 Mar '05

Hello all, What do you think about this request? Cheers, Vasco ----- Begin forwarded message ----- Date: Tue, 1 Mar 2005 19:17:02 -0600 From: Dave Deitrich <deitrich(a)cymru.com> To: rispeering(a)ripe.net Subject: NCC#2005030185 Request for BGP Data Cc: bruce.campbell(a)ripe.net, Rob Thomas <robt(a)cymru.com> Message-Id: <9c251485ff037119c294a661ebc8f84c(a)cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, My name is Dave Deitrich and I'm a member of Team Cymru (http://www.cymru.com). We were wondering if it would be possible to establish a BGP peering session with you in order to receive copies of some of the routing data that you use for the RIPE RIS project. The prefix data will be used to help enhance our Internet monitoring utilities. These utilities look for general aberrations such as routing instability, worm outbreaks, prefix hijackings, etc. so the more peering data we have the better. We recently posted a request for more peers to a security list and Bruce Campbell suggested that you might be able to help us. If so we would love to discuss this with you. Please let us know if you think that this would be feasible. Thanks very much for your attention. - -- DAVE DEITRICH deitrich(a)cymru.com -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiUEXkiQQdywQH32EQJnQQCg5Zhq+yGLvrkGpTfPcqA8G1h/vrQAoIY8 77nM12Obk8qE4o1+Dtj9jD1W =9cP9 -----END PGP SIGNATURE----- ------ End forwarded message ------ --

5 9

Re: [ris-int] Fw: NCC#2005030185 [Request for BGP Data]
by Rene Wilhelm 17 Mar '05

17 Mar '05

> I have the concerns Lorenzo pointed. We say our peers we just set up peering > sessions to collect BGP data, and not to pass any other peers even if it's > research purpose. I don't see that as an issue; in terms of data disclosure, it hardly matters if you pass the routing information via eBGP or via RIB dumps/updates. BGP feeds will even give them less data. > My feelings say that just tell them to no, and point them to use RIB snapshots. They probably just want to add RIS peering sessions to the 17 they already have and use their existing tools to prepare reports and (quoting the original message) "look for general aberrations such as routing instability, worm outbreaks, prefix hijackings, etc." RIB dumps and updates would require special processing, more difficult to use in their analysis. I don't think setting Team Cymru up with feeds will hit back on us, on the contrary, if we would not set them up, we could be seen as being overly possesive, not wanting to collaborate. However, I do agree with Henk that we should insist on being given proper credit. Looking at http://www.cymru.com/BGP/ there's no information whatsoever on who are 'donating' Team Cymru's current 17 eBGP peering sessions. -- Rene

1 0

Re: NCC#2005030185 Request for BGP Data
by RIPE NCC RIS 16 Mar '05

16 Mar '05

Hello Dave, Thanks for your e-mail. We are discussing this request internally. We will let you know as soon as we have some more information about it. Best regards, Vasco Asturiano -------------------------- Software Engineering Dept. RIPE-NCC On Tue, 1 Mar 2005 19:17:02 -0600, Dave Deitrich wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Greetings, > > My name is Dave Deitrich and I'm a member of Team Cymru > (http://www.cymru.com). We were wondering if it would be possible to > establish a BGP peering session with you in order to receive copies of > some of the routing data that you use for the RIPE RIS project. The > prefix data will be used to help enhance our Internet monitoring > utilities. These utilities look for general aberrations such as > routing instability, worm outbreaks, prefix hijackings, etc. so the > more peering data we have the better. > > We recently posted a request for more peers to a security list and > Bruce Campbell suggested that you might be able to help us. If so we > would love to discuss this with you. Please let us know if you think > that this would be feasible. > > Thanks very much for your attention. > > - -- > DAVE DEITRICH > deitrich(a)cymru.com > > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.1 > > iQA/AwUBQiUEXkiQQdywQH32EQJnQQCg5Zhq+yGLvrkGpTfPcqA8G1h/vrQAoIY8 > 77nM12Obk8qE4o1+Dtj9jD1W > =9cP9 > -----END PGP SIGNATURE----- --

1 0

nice site
by Arife Vural 15 Mar '05

15 Mar '05

Just saw this site, it's pretty good. Maybe, we should ask them to create links for RIS tools. RIS Looking Glass is already there. http://www.bgp6.com/tools/ Arife

3 2

RIS meeting on Mon
by Arife Vural 13 Mar '05

13 Mar '05

Hi, Does anybody have any agenda item for Mon? Arife

1 1

experiments on AS-sets cancelled
by Giuseppe Di Battista 07 Mar '05

07 Mar '05

Dear all, I am sending this e-mail with the purpose of stating the position of the Computer Networks Research Group (in the following CNRG) at Roma Tre University about the AS-SET experiments. This mail covers only organization issues and is not on technical stuff. We shall address technical problems in a separate e-mail in the next few days. Until now, the relationship between RIS and CNRG has been maintained by Lorenzo. We have complete confidence in Lorenzo and he will continue to be the interface between our two groups. This e-mail does not intend to bypass him. 1. A group of researchers at CNRG, including Lorenzo, has developed new techniques for network discovery, at BGP level. Several experiments have already been done in the labs and in the ipv6 network. 2. We were interested in carrying on experiments on the ipv4 network. 3. Lorenzo discussed the issue with people at RIS. There was an agreement to use 84.205.73.0/24 and 84.205.89.0/24, originated in AS12654, for the experiments. 4. Around Feb 20 Lorenzo prepared an e-mail to be sent to a couple of mailing lists announcing the experiments. The e-mail was explicitely approved by, at least, Henk, Arife, Shane. 5. The e-mail was sent on Feb 25 to a large audience. There were a few reactions. 6. We scheduled the experiments for Feb 28- Mar 1. 7. Since we knew that the experiments could have been perceived with some suspect from the network operators, we decided to be more cautious than the RIS itself. Hence, we asked further advice by calling people at RIS on Feb 28. The answer was essentially: "people shouldn't get upset". Also, we decided to post an even more explicit message on the nanog mailing list. 8. There were many reactions, most negative. 9. Henk decided to stop the experiments. I fully agree with the decision. I do not agree with the contents of the e-mail that was sent at nanog. In my opinion the e-mail put in a bad light Lorenzo, CNRG, and RIS: - Lorenzo was presented as an "overenthusiastic student" that behaves irresponsibly. This is clearly not true (see above). - CNRG and RIS are presented as a light-heart organizations that put extremely important issues in the hands of a student without control. I also disagree on the method. Since Lorenzo was in charge of announcing the experiments, he was the one to announce their cancellation. Sincerely, Pino

2 2