[ris-int] Fw: NCC#2004081420 [RE: RIPE beacon request!]

> >
> >What do you think about this request?
> 
> I would be against this.  The RRC's are set up as route collectors,
> not as machines to run named or whatever for 3rd parties.  We have
> our agreements with hosts, let's not do things we have not agreed
> just because a student somewhere asks.

Agree with that. I will let him know.

Arife

> 
> Henk
> 
> 
> 
> 
> >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 at cs.cornell.edu>
> >To: "RIPE NCC RIS" <ris-request at ripe.net>
> >Subject: RE: NCC#2004081420 RIPE beacon request!
> >Message-Id: <2EE48095D8C21643B0B70EC95F9BFBAF0A3174 at 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 at 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 ------
> 
> ------------------------------------------------------------------------------
> 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)