March 2005 - Ris-int - mailman.ripe.net

Trip Report: DHS Routing Security Workshop
by Daniel Karrenberg 04 Apr '05

04 Apr '05

(Homeland Security) HSARPA: - requirements driven research - very flexible contract instruments - small, agile group www.hsarpabaa.com (note .com) www.hsarpabsbir.com HSARPA CYBER PGMS: DNSSEC (Steve Crocker, Russ Mundy, mentions DISI, Olaf) SPRI Routing Security - economics, incentives, deployability This is the first of 5 workshops. Next is probably being after NANOG Seattle, operational requirements. 12 mo (may , summer, sept, nov) HSARPA is about Development, Deployment, less about Research. Want to accelerate processes already happening. Quicker than IETF pace. I'll leave all the discussions to a reference to the position papers which I do not have yet. I'll forward it as soon as I get it. Main points: The main problem remains lack of ISP motivation to do routing security. Business cases are not clear and current level of incidents is clearly below the nuisance level. There appears to be a strong perception that address allocation registries are not accurate, especially for older assignments. Then there is a registry nereded to link address space to routes and their origin addresses. Minor points: There continues to be a need for reliable data about "irregular routes". Idea (Crocker): Intelligently filter routing data and make an "interesting bogon" list. Something for the RIS. Once we get squatting on unallocated addresses dealt with, addresses allocated but not routed will be targeted. RIS mentioned several times as "more accurate and better" than route views. Still route views used most of the time. RIRs mentioned several times as natural places for registries supporting routing security: address space (we do), route origination (new), other policies (maybe). Major consequences for us: We need to quantify the quality of RS data somehow and give a more clear picture of what still needs to be cleaned up and the plan for achieving this including time frames. Appraently we are being too vague. Better do this proactively than in response to an increasing level of questions. We need to keep the RIPE community informed and "in the loop" of routing security developments. We need to consider the route origin registry more stringent and separate from the current routing registry and the address allocation registry. Maybe we want to run things. Minor consequences: Consider a "not routed on the public Internet" attribute for the address space registry. "irregular routes" sifting of RIS. Miscellaneous: RS (still) does not use RIS when it could. (re ASNs). Ginny Listman to chair a group looking into address registries. We need to have someone there.

2 2

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

Re: URGENT Re: Heads up: Long AS-sets announced in the next few days
by Lorenzo Colitti 04 Mar '05

04 Mar '05

[ris in CC field changed to ris-int to avoid replies being ticketized. Also CCing my co-authors in Rome] Daniel Karrenberg wrote: > If there is resistance like that, even uninformed resistance, we > cannot push things like this. I agree. Obviously the NCC is the least appropriate entity to push anything in the face of the community, since its charter is to do what the community wants it to do. And since it will be AS12654 doing the announcements, the buck stops here. I do think that Henk's message lacked finesse though. This is not me being overenthusiastic, this is a serious research project from a group with a proven record in the field of network discovery and a history of providing useful services to the community. Of course you can debate whether it is a good idea or not; every new technique has its fair share of detractors. And we wouldn't have gone ahead with the experiments in the face of such resistance either. But writing this off with a simple "On this occasion, he became a bit overenthusiastic though" is a little demeaning of the group's work. Anyway, with that behind us: > I beleive you should compose a very well drafted message explaining exactly > > - what we are proposing to do > - what effects we expect > - why the effects people are concerned about will not occur > > and ask for comments. This message should be OKed by Henk and maybe it > would be good to have it signed by both Henk and Lorenzo. We should do > this relatively quickly but without loosing the "well drafted". I would be happy to do this if you think it stands a chance. The issue I fear is that people in favour or neutral to these experiments won't reply to the thread and only a (possibly small number of) more conservative and/or uninformed people will be quick to criticize and opt-out. How much detail do you think we need? Do you think that to convince people we need to describe all our algorithms (some of which we haven't even fully developed yet), or do you think a more general description would be enough? Of course we would still provide much more detail on the principles we want to use and how we are trying to accomplish it. Cheers, Lorenzo

3 2