Sonia,
1. Prototype 1U TB, +/- 2001, commit 200106017
2. Pre 1997 Dell PC
3. Celeron 333, 64 MB, +/- 1998, works
4. Unknown, TTec Cabinet
5. Same as #1 but from different vendor.
6. PE350, 1 of the machines from commit 200110011
7. Old RIS box, +/- 2001. Broken.
8. Assorted hard disks, these have been removed from old PC's.
9-14: Rackmounts, some containing broken PC parts.
The cabinets are +/- 100 euro's in the shop.
15: BW monitor, pre 1997
16: Color monitor, unknown.
Henk
ps. Folks, if you recognize any of this hardware and it still servers a
function, please remove it.
------------------------------------------------------------------------------
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)
(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.
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 ------
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 ------
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 ------
