From leigh at insnet.net Wed Sep 1 13:33:03 1999 From: leigh at insnet.net (Leigh Porter) Date: Wed, 01 Sep 1999 12:33:03 +0100 Subject: Tracking stealth portscan/pepsi attacks References: <19990831132437.A16300@xlink.net> Message-ID: <37CD0EEF.3369FDF9@insnet.net> Petra Zeidler wrote: Hiya, INS try to be very co-operative in tracking down the source of any such attacks and in the past I have had nothing but complete co-operation and help from our peers in tracking the source of attacks. It would be interesting though to have a forum in which to dicsuss inter-providor co-operation though with the RIPE database it is usually just a case of calling the NOC of network at the ingress point to your network who would then trace the source to the ingress point of their network and so on. Since these DoS attacks usually last for quite some time this is pretty easy however tracing stealth portscans that could potentially last for a few days could be more interesting. -- Leigh Porter > I'd like to have a chance to catch the perpetrators. This would need to be > a multi-provider cooperation in the majority of cases. > Do we have an appropriate forum to discuss this at the next RIPE meeting? From j.luster at cert.gigabell.net Wed Sep 1 13:09:02 1999 From: j.luster at cert.gigabell.net (Jonas Luster) Date: Wed, 1 Sep 1999 13:09:02 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: <19990831132437.A16300@xlink.net> References: <19990831132437.A16300@xlink.net> Message-ID: <19990901130902.A15938@nethammer.qad.org> [ Quoting Petra Zeidler ]: > there seems to have been quite a wash of stealth portscans and/or pepsi > attacks lately (stealth portscan: you portscan with 99% of the sender Even worse (at least here): There's a modified Version of Pepsi5 around letting the attacker control his bot via ICMP which allow control even when the net is nearly down due to the UDP attacks. > cybercity.dk must have been seeing some of these attacks pass, first glance > judging from http://stat.cybercity.dk/ripe/ and the fallout in de.xlink > (where I positively know the addresses not to be routed) and de.zz (where > most of the address space is handled by RIPE nowadays). Same goes for de.IPF where these type of attacks caused quite a bit work and manpower to be wasted. The last few weeks I've been working fulltime just on these problems. > I'd like to have a chance to catch the perpetrators. This would need to be > a multi-provider cooperation in the majority of cases. > Do we have an appropriate forum to discuss this at the next RIPE meeting? I'd vote for a WG focussing on these things. IIRC there have been plans on a RIPE-Security WG around RIPE-29 or 30. If there's a bigger interest on this topics what about a Security-BOF next RIPE? In general, net-abuse has become one of the major problems these days, included but not limited to attacks, scans, mailbombs, a.s.o. regards, Jonas Luster -- Gigabell AG / Frankfurt Signed / encrypted maol welcome Chief Security Engineer Key to be found on the known places j.luster at cert.gigabell.net Securing the net of the future From leigh at insnet.net Thu Sep 2 11:44:39 1999 From: leigh at insnet.net (Leigh Porter) Date: Thu, 02 Sep 1999 10:44:39 +0100 Subject: Tracking stealth portscan/pepsi attacks References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> Message-ID: <37CE4706.3B3D44D8@insnet.net> Jonas Luster wrote: > I'd vote for a WG focussing on these things. IIRC there have been > plans on a RIPE-Security WG around RIPE-29 or 30. If there's a bigger > interest on this topics what about a Security-BOF next RIPE? In > general, net-abuse has become one of the major problems these days, > included but not limited to attacks, scans, mailbombs, a.s.o. Ahh now if we called it a RIPE-Security WG then that could encompass the whole lot and would IMO be a fine idea. As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier. -- Leigh From BERI at etf.bg.ac.yu Thu Sep 2 12:06:00 1999 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Thu, 2 Sep 1999 11:06 +0100 Subject: Tracking stealth portscan/pepsi attacks Message-ID: >> I'd vote for a WG focussing on these things. IIRC there have been >> plans on a RIPE-Security WG around RIPE-29 or 30. If there's a bigger >> interest on this topics what about a Security-BOF next RIPE? In >> general, net-abuse has become one of the major problems these days, >> included but not limited to attacks, scans, mailbombs, a.s.o. Three years ago, Daniel Karrenberg posted a proposal for creation of a pilot incident response team, called Security Incident Response and Coordination in Europe (SIRCE). The team should have been operating under the RIPE NCC umbrella. Everyone was pretty happy with the proposal itself, but when it came to finances - only a small number of ISPs agreed to participate in funding. Therefore, as far as I remember, the RIPE NCC had to widthdraw the proposal. That, however, doesn't mean we can't think about resurrection of SIRCE. At least, we can start with a WG, but a central IRT that will coordinate the incidents is really needed. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3218-350 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' -------------------------------------------------------------------- From BERI at etf.bg.ac.yu Thu Sep 2 12:13:00 1999 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Thu, 2 Sep 1999 11:13 +0100 Subject: Tracking stealth portscan/pepsi attacks Message-ID: >> As a side note, does anybody use anything to prevent address spoofing in >> their network? That would at prevent a lot of attacks completly and make >> tracing the rest much easier. RFC 2267 describes most of the measures that should be taken at the router level. I'm not sure how many ISPs implemented everything recommended in that document. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3218-350 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' -------------------------------------------------------------------- From patricks at support.nl Thu Sep 2 11:49:26 1999 From: patricks at support.nl (patricks at support.nl) Date: Thu, 2 Sep 1999 11:49:26 +0200 (CEST) Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: Message-ID: On Thu, 2 Sep 1999, Berislav Todorovic wrote: > RFC 2267 describes most of the measures that should be taken at the router > level. I'm not sure how many ISPs implemented everything recommended in > that document. This document doesn't mention the very important statement "no ip directed-broadcast" for dealing with smurf attacks. Please use this command on each interface whenever possible. Check your network at http://www.powertech.no/smurf/. Kind Regards, Patrick Schreurs. -- Ing. W.P. Schreurs S u p p o r t N e t Email: beheer at supportnet.nl Private: patrick at support.nl Partner in Web: http://www.supportnet.nl/ Internetworking Kruislaan 419, 1098 VA Amsterdam, The Netherlands Phone: +31 (0)20 693 54 54, Fax: +31 (0)20 668 61 66 From leigh at insnet.net Thu Sep 2 11:44:39 1999 From: leigh at insnet.net (Leigh Porter) Date: Thu, 02 Sep 1999 10:44:39 +0100 Subject: Tracking stealth portscan/pepsi attacks References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> Message-ID: <37CE4706.3B3D44D8@insnet.net> Jonas Luster wrote: > I'd vote for a WG focussing on these things. IIRC there have been > plans on a RIPE-Security WG around RIPE-29 or 30. If there's a bigger > interest on this topics what about a Security-BOF next RIPE? In > general, net-abuse has become one of the major problems these days, > included but not limited to attacks, scans, mailbombs, a.s.o. Ahh now if we called it a RIPE-Security WG then that could encompass the whole lot and would IMO be a fine idea. As a side note, does anybody use anything to prevent address spoofing in their network? That would at prevent a lot of attacks completly and make tracing the rest much easier. -- Leigh From joe at pavilion.net Thu Sep 2 10:53:43 1999 From: joe at pavilion.net (Josef Karthauser) Date: Thu, 2 Sep 1999 09:53:43 +0100 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: <37CE4706.3B3D44D8@insnet.net>; from Leigh Porter on Thu, Sep 02, 1999 at 10:44:39AM +0100 References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> <37CE4706.3B3D44D8@insnet.net> Message-ID: <19990902095343.J88479@pavilion.net> On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote: > Jonas Luster wrote: > > > I'd vote for a WG focussing on these things. IIRC there have been > > plans on a RIPE-Security WG around RIPE-29 or 30. If there's a bigger > > interest on this topics what about a Security-BOF next RIPE? In > > general, net-abuse has become one of the major problems these days, > > included but not limited to attacks, scans, mailbombs, a.s.o. > > Ahh now if we called it a RIPE-Security WG then that could encompass the > whole lot and would IMO be a fine idea. > > As a side note, does anybody use anything to prevent address spoofing in their > network? That would at prevent a lot of attacks completly and make tracing the > rest much easier. > Packet filters at all boundaries :) Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe at pavilion.net, joe at uk.freebsd.org, joe at tao.org.uk] From jonas at qad.org Thu Sep 2 11:28:55 1999 From: jonas at qad.org (Jonas Luster) Date: Thu, 2 Sep 1999 11:28:55 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: <37CE4706.3B3D44D8@insnet.net> References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> <37CE4706.3B3D44D8@insnet.net> Message-ID: <19990902112855.A1256@nethammer.qad.org> [ Quoting Leigh Porter ]: > As a side note, does anybody use anything to prevent address spoofing in their > network? That would at prevent a lot of attacks completly and make tracing the > rest much easier. We're in a switched network so Spoofing is only possible by ARP-Hijackiking. To prevent such attacks I've coupled Arpwatch, Hunt and some selfmade tools to inject NULL-Routes against any source of more than 30 Flip-Flops in a given time. Until now I only had one false positive and three false negatives. jonas From netmaster at space.net Thu Sep 2 11:44:12 1999 From: netmaster at space.net (Gert Doering, Netmaster) Date: Thu, 2 Sep 1999 11:44:12 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: <37CE4706.3B3D44D8@insnet.net>; from Leigh Porter on Thu, Sep 02, 1999 at 10:44:39AM +0100 References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> <37CE4706.3B3D44D8@insnet.net> Message-ID: <19990902114412.S13951@Space.Net> Hi, On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote: > As a side note, does anybody use anything to prevent address spoofing in their > network? That would at prevent a lot of attacks completly and make tracing the > rest much easier. Sure we do. On our ingress interfaces to our customers, we have very strict access lists ("permit ip any / deny ip any any log"). On our external interfaces from our upstreams we deny packets with a source address coming from one our network blocks. Interesting enough, we don't observe many attacks - what we do see is LOTS of broken end user configurations (leaking RFC 1918 networks, customers leaking IP addresses from other ISPs, ...). Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From leigh at insnet.net Thu Sep 2 12:46:02 1999 From: leigh at insnet.net (Leigh Porter) Date: Thu, 02 Sep 1999 11:46:02 +0100 Subject: Tracking stealth portscan/pepsi attacks References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> <37CE4706.3B3D44D8@insnet.net> <19990902114412.S13951@Space.Net> Message-ID: <37CE556A.3B97A29E@insnet.net> "Gert Doering, Netmaster" wrote: > Hi, > > On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote: > > As a side note, does anybody use anything to prevent address spoofing in their > > network? That would at prevent a lot of attacks completly and make tracing the > > rest much easier. > > Sure we do. > > On our ingress interfaces to our customers, we have very strict access > lists ("permit ip any / deny ip any any log"). How do you manage large BGP customers with lots of networks? I would also be interested to know performance hits on the routers for this. I do recall soemthing Cisco implemented that checked you have a route back to any source address that comes in on a suitably configured interface else it'll drop the packet as being spoofed, this soulds good - anybody tried it? -- Leigh From netmaster at space.net Thu Sep 2 11:51:15 1999 From: netmaster at space.net (Gert Doering, Netmaster) Date: Thu, 2 Sep 1999 11:51:15 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: <37CE556A.3B97A29E@insnet.net>; from Leigh Porter on Thu, Sep 02, 1999 at 11:46:02AM +0100 References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> <37CE4706.3B3D44D8@insnet.net> <19990902114412.S13951@Space.Net> <37CE556A.3B97A29E@insnet.net> Message-ID: <19990902115115.T13951@Space.Net> Hi, On Thu, Sep 02, 1999 at 11:46:02AM +0100, Leigh Porter wrote: > > > As a side note, does anybody use anything to prevent address spoofing in their > > > network? That would at prevent a lot of attacks completly and make tracing the > > > rest much easier. > > > > Sure we do. > > > > On our ingress interfaces to our customers, we have very strict access > > lists ("permit ip any / deny ip any any log"). > > How do you manage large BGP customers with lots of networks? Hmmm, I have to admit that I don't - we're not THAT large yet, so our BGP customers are usually pretty small and only have two or three network blocks, so filtering is feasible. (As I filter their BGP announcements anyway, adding the networks to the incress access-list isn't much more effort). > I would also be interested to know performance hits on the routers > for this. The access lists per interface are usually no longer than up to 10 lines, and the routers seem to manage fine. > I do recall soemthing Cisco implemented that checked you have a route back to > any source address that comes in on a suitably configured interface else it'll > drop the packet as being spoofed, this soulds good - anybody tried it? This is in IOS 12.0, and you need to have CEF enabled to use it. As our production routers don't use IOS 12 yet, I haven't tried it. It would certainly be very nice. Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From fj at cdt.luth.se Thu Sep 2 14:55:57 1999 From: fj at cdt.luth.se (Fredrik Johansson) Date: Thu, 02 Sep 1999 14:55:57 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: Your message of Thu, 02 Sep 1999 10:44:39 BST. <37CE4706.3B3D44D8@insnet.net> Message-ID: <199909021255.OAA24759@basil.cdt.luth.se> > As a side note, does anybody use anything to prevent address spoofing in their > network? That would at prevent a lot of attacks completly and make tracing the > rest much easier. > > -- > Leigh I think that a serious provider *should* prevent address spoofing. This is a simple filter in the access router. If this is not done, how can an ISP prove that a customer has done something wrong. I think this for protection of the ISP as well as other customers. Fredrik Johansson From phk at critter.freebsd.dk Thu Sep 2 17:37:17 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 02 Sep 1999 17:37:17 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: Your message of "Thu, 02 Sep 1999 10:44:39 BST." <37CE4706.3B3D44D8@insnet.net> Message-ID: <1380.936286637@critter.freebsd.dk> In message <37CE4706.3B3D44D8 at insnet.net>, Leigh Porter writes: >As a side note, does anybody use anything to prevent address spoofing in their >network? That would at prevent a lot of attacks completly and make tracing the >rest much easier. We have egress filters, allowing only our "own" IP numbers in the source fields. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From BERI at etf.bg.ac.yu Fri Sep 3 18:21:00 1999 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Fri, 3 Sep 1999 17:21 +0100 Subject: Tracking stealth portscan/pepsi attacks Message-ID: >> How do you manage large BGP customers with lots of networks? One idea is to generate access lists automatically from the data in the route registry. However, that may have some significant drawbacks. First, there are many inconsistences between the IRR and reality, so some connectivity problems may arise. Aside of that, the amount of access lists might affect router perfomance. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3218-350 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' -------------------------------------------------------------------- From lmb at teuto.net Fri Sep 3 14:18:58 1999 From: lmb at teuto.net (Lars Marowsky-Bree) Date: Fri, 3 Sep 1999 14:18:58 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: <19990902114412.S13951@Space.Net>; from "Gert Doering, Netmaster" on 1999-09-02T11:44:12 References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> <37CE4706.3B3D44D8@insnet.net> <19990902114412.S13951@Space.Net> Message-ID: <19990903141858.H24626@pointer.teuto.de> On 1999-09-02T11:44:12, "Gert Doering, Netmaster" said: > On our ingress interfaces to our customers, we have very strict access > lists ("permit ip any / deny ip any any log"). Same here. A very good idea anyway, not just because of security, but because of customers who think "lets just continue increasing the last digit!". And I wish I had more time to work on the security issues. Fascinating topic. But there are so many fascinating topics and only 24hours plus the night per day... > On our external interfaces from our upstreams we deny packets with a > source address coming from one our network blocks. We also filter private addresses & martians. Sometimes a few of those come through. And on the outgoing interfaces we filter packets going to our own netblocks, so that we don't accidentially leak because of fucked up routing. And then there are the filters on the BGP4 sessions to prevent someone from injecting bogus routes into our AS (remember that EBGP learned routes take precedence over IGP, and more specific routes always take precendence, so if you don't filter correctly, someone might hijack one IP from your network). > Interesting enough, we don't observe many attacks - what we do see is LOTS > of broken end user configurations (leaking RFC 1918 networks, customers > leaking IP addresses from other ISPs, ...). Yeah. But it also helps to prevent smurf attacks etc. I do see a need for a RIPE Security WG to point these issues out to all ISPs/LIRs so at least those easy measures get taken. According to the annual report from last year, funding shouldn't be that much of a problem ;-) Sincerely, Lars Marowsky-Brie -- Lars Marowsky-Brie Network Management teuto.net Netzdienste GmbH From robert at easynet.de Fri Sep 3 14:19:38 1999 From: robert at easynet.de (Robert Kiessling) Date: Fri, 3 Sep 1999 14:19:38 +0200 (MEST) Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: <37CE556A.3B97A29E@insnet.net> References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> <37CE4706.3B3D44D8@insnet.net> <19990902114412.S13951@Space.Net> <37CE556A.3B97A29E@insnet.net> Message-ID: <14287.48346.930588.509543@delphi.local.easynet.de> Leigh Porter writes: > > On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote: > > > As a side note, does anybody use anything to prevent address spoofing in their > > > network? That would at prevent a lot of attacks completly and make tracing the > > > rest much easier. > > > > Sure we do. Same here. Both dialup and leased line customer source addresses are strictly verified. > How do you manage large BGP customers with lots of networks? The access lists are generated from combined sources, amoung them our internal database and the information from RIPE. For an update, the access lists are regenerated and the output is a diff in Cisco format for the bits that changed so that it can be directly copied onto the routers. > I do recall soemthing Cisco implemented that checked you have a route back to > any source address that comes in on a suitably configured interface else it'll > drop the packet as being spoofed, this soulds good - anybody tried it? No, but anyway this fails in more complex scenarios where symmetric routing cannot be guaranteed. Robert From phk at critter.freebsd.dk Fri Sep 3 14:25:19 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Fri, 03 Sep 1999 14:25:19 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: Your message of "Thu, 02 Sep 1999 11:46:02 BST." <37CE556A.3B97A29E@insnet.net> Message-ID: <6350.936361519@critter.freebsd.dk> In message <37CE556A.3B97A29E at insnet.net>, Leigh Porter writes: >"Gert Doering, Netmaster" wrote: > >> Hi, >> >> On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote: >> > As a side note, does anybody use anything to prevent address spoofing in their >> > network? That would at prevent a lot of attacks completly and make tracing the >> > rest much easier. >> >> Sure we do. >> >> On our ingress interfaces to our customers, we have very strict access >> lists ("permit ip any / deny ip any any log"). > >How do you manage large BGP customers with lots of networks? >I would also be interested to know performance hits on the routers >for this. You filter at your ingress points. If you have a leased-line customer you make sure they can't send from anything but the addresses they have from ripe. Dial up likewise. >I do recall soemthing Cisco implemented that checked you have a route back to >any source address that comes in on a suitably configured interface else it'll >drop the packet as being spoofed, this soulds good - anybody tried it? Hey, that sounds neat, more info ? -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From netmaster at space.net Fri Sep 3 14:10:15 1999 From: netmaster at space.net (Gert Doering, Netmaster) Date: Fri, 3 Sep 1999 14:10:15 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: <19990902112855.A1256@nethammer.qad.org>; from Jonas Luster on Thu, Sep 02, 1999 at 11:28:55AM +0200 References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> <37CE4706.3B3D44D8@insnet.net> <19990902112855.A1256@nethammer.qad.org> Message-ID: <19990903141015.X13951@Space.Net> Hi, On Thu, Sep 02, 1999 at 11:28:55AM +0200, Jonas Luster wrote: > > As a side note, does anybody use anything to prevent address spoofing in their > > network? That would at prevent a lot of attacks completly and make tracing the > > rest much easier. > > We're in a switched network so Spoofing is only possible by > ARP-Hijackiking. Oh? That's not how I understand the benefits of switching... How do you prevent somone from injecting packets with spoofed source address at your boundary routers? Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From phk at critter.freebsd.dk Fri Sep 3 14:32:20 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Fri, 03 Sep 1999 14:32:20 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: Your message of "Thu, 02 Sep 1999 11:44:12 +0200." <19990902114412.S13951@Space.Net> Message-ID: <6378.936361940@critter.freebsd.dk> In message <19990902114412.S13951 at Space.Net>, "Gert Doering, Netmaster" writes: >Interesting enough, we don't observe many attacks - what we do see is >LOTS of broken end user configurations (leaking RFC 1918 networks, >customers leaking IP addresses from other ISPs, ...). Talk about it. I don't log RFC1918 addresses anymore I just drop them. Some cheap NAT routers don't NAT UDP just pass it through. Most spoofed src attacks I've heard about happen from hi-jacked servers, so remember filters on your server parks too, in particular for co-hosted servers. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From michael.hallgren at fisystem.fr Fri Sep 3 14:37:50 1999 From: michael.hallgren at fisystem.fr (Michael Hallgren) Date: Fri, 3 Sep 1999 14:37:50 +0200 Subject: Tracking stealth portscan/pepsi attacks References: <199909021255.OAA24759@basil.cdt.luth.se> Message-ID: <019501bef609$22cab0c0$b8014b0a@fisystem.fr> > > > As a side note, does anybody use anything to prevent address spoofing in their > > network? That would at prevent a lot of attacks completly and make tracing the > > rest much easier. > > > > -- > > Leigh > > I think that a serious provider *should* prevent address spoofing. This is a > simple filter in the access router. > > If this is not done, how can an ISP prove that a customer has done something > wrong. I think this for protection of the ISP as well as other customers. I agree. A serious provider should also consider protecting itself from its customers. Michael > > > Fredrik Johansson > > > -- Michael Hallgren IT Consultant, Infrastructure FI System, Web Agency http://www.fisystem.fr michael.hallgren at fisystem.fr, Phone : +33 1 55 04 03 03 Always make mistakes. - E Dyson From netmaster at space.net Fri Sep 3 15:07:04 1999 From: netmaster at space.net (Gert Doering, Netmaster) Date: Fri, 3 Sep 1999 15:07:04 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: <19990903141858.H24626@pointer.teuto.de>; from Lars Marowsky-Bree on Fri, Sep 03, 1999 at 02:18:58PM +0200 References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> <37CE4706.3B3D44D8@insnet.net> <19990902114412.S13951@Space.Net> <19990903141858.H24626@pointer.teuto.de> Message-ID: <19990903150704.A13951@Space.Net> Hi, On Fri, Sep 03, 1999 at 02:18:58PM +0200, Lars Marowsky-Bree wrote: > > On our external interfaces from our upstreams we deny packets with a > > source address coming from one our network blocks. > > We also filter private addresses & martians. Sometimes a few of those come > through. While I'd like to do that, I'm still not sure what's worse - seeing 192.168.x.y addresses in an outgoing traceroute, or listening to customer complaints about "why is there a line ' * * * ' in my traceroute output? something must be wrong!" when filtering those. So right now, I let packets with RFC addresses pass (from upstream, not from our customers). But I still hope that people will stop using them for transit networks. > And on the outgoing interfaces we filter packets going to our own netblocks, > so that we don't accidentially leak because of fucked up routing. Interesting idea. I'm not sure how that problem could happen, but maybe our network's topology is too simple :-) > And then there are the filters on the BGP4 sessions to prevent someone from > injecting bogus routes into our AS (remember that EBGP learned routes take > precedence over IGP, and more specific routes always take precendence, so if > you don't filter correctly, someone might hijack one IP from your network). Plus filters for the transit networks on the usual exchange points (DE-CIX, MAE-Frankfurt, etc.) - because that could hose up routing massively if one of those networks appears in your iBGP... Thanks for the tip with "filter bogus routes from our own network blocks", I didn't yet think of that problem, but it's certainly worth considering. > > Interesting enough, we don't observe many attacks - what we do see is LOTS > > of broken end user configurations (leaking RFC 1918 networks, customers > > leaking IP addresses from other ISPs, ...). > > Yeah. But it also helps to prevent smurf attacks etc. Definitely - that's why I did it, but I just wanted to note that there are (well, "we observe") much more misconfiguration problems than active attacks. Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From leigh at insnet.net Fri Sep 3 16:11:43 1999 From: leigh at insnet.net (Leigh Porter) Date: Fri, 03 Sep 1999 15:11:43 +0100 Subject: Tracking stealth portscan/pepsi attacks References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> <37CE4706.3B3D44D8@insnet.net> <19990902114412.S13951@Space.Net> <37CE556A.3B97A29E@insnet.net> <14287.48346.930588.509543@delphi.local.easynet.de> Message-ID: <37CFD71F.C802EE61@insnet.net> Robert Kiessling wrote: > > How do you manage large BGP customers with lots of networks? > > The access lists are generated from combined sources, amoung them our > internal database and the information from RIPE. For an update, the > access lists are regenerated and the output is a diff in Cisco format > for the bits that changed so that it can be directly copied onto the > routers. Does that scale to say a network with 100 prefixes that takes say 100Mb? -- Leigh From Havard.Eidnes at runit.sintef.no Sat Sep 4 21:32:50 1999 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Sat, 04 Sep 1999 21:32:50 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: Your message of "Fri, 03 Sep 1999 14:25:19 +0200" <6350.936361519@critter.freebsd.dk> References: <6350.936361519@critter.freebsd.dk> Message-ID: <19990904213250C.he@runit.sintef.no> > >I do recall soemthing Cisco implemented that checked you have > >a route back to any source address that comes in on a suitably > >configured interface else it'll drop the packet as being > >spoofed, this soulds good - anybody tried it? > > Hey, that sounds neat, more info? It is an IOS 12.0 feature. It requires that you run CEF (most if not all platforms can do that in 12.0). The interface command is ip verify unicast reverse-path For each packet it checks that it has a route back to the source IP address pointing out the interface where the packet entered, and drops the packet if it doesn't. For rather obvious reasons this feature cannot be used where you have asymmetric traffic patterns. This commonly occurs in backbone networks with "hot-potato" routing between providers which peer in multiple places. But then again, this checking should be done on the edges of the network, where asymmetry should be much less of a problem. With early revisions of 12.0 there were issues with helper-address handling -- bootp requests from 0.0.0.0 would be dropped on the floor instead of being forwarded (ugh!). I think that is now fixed, though. And, yes, we are using the feature. - H?vard From neil at COLT.NET Sat Sep 4 12:07:04 1999 From: neil at COLT.NET (Neil J. McRae) Date: Sat, 04 Sep 1999 11:07:04 +0100 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: Your message of "Fri, 03 Sep 1999 15:11:43 BST." <37CFD71F.C802EE61@insnet.net> Message-ID: <199909041007.LAA18416@NetBSD.noc.COLT.NET> On Fri, 03 Sep 1999 15:11:43 +0100 Leigh Porter wrote: > Does that scale to say a network with 100 prefixes that takes say > 100Mb? We insist upon it. -- Neil J. McRae C O L T I N T E R N E T neil at COLT.NET From neil at COLT.NET Sat Sep 4 21:37:58 1999 From: neil at COLT.NET (Neil J. McRae) Date: Sat, 04 Sep 1999 20:37:58 +0100 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: Your message of "Sat, 04 Sep 1999 21:32:50 +0200." <19990904213250C.he@runit.sintef.no> Message-ID: <199909041937.UAA20815@NetBSD.noc.COLT.NET> On Sat, 04 Sep 1999 21:32:50 +0200 Havard.Eidnes at runit.sintef.no wrote: 11.1CC28 has new bug-fix [*] for dropping bad packet fragments also. We haven't tested it but it could be useful for some attacks we've seen in the past. * Some may call this a feature- but its definetly a bug fix. Regards, Neil. > > >I do recall soemthing Cisco implemented that checked you have > > >a route back to any source address that comes in on a suitably > > >configured interface else it'll drop the packet as being > > >spoofed, this soulds good - anybody tried it? > > > > Hey, that sounds neat, more info? > > It is an IOS 12.0 feature. It requires that you run CEF (most if > not all platforms can do that in 12.0). The interface command is > > ip verify unicast reverse-path > > For each packet it checks that it has a route back to the source > IP address pointing out the interface where the packet entered, > and drops the packet if it doesn't. > > For rather obvious reasons this feature cannot be used where you > have asymmetric traffic patterns. This commonly occurs in backbone > networks with "hot-potato" routing between providers which peer in > multiple places. But then again, this checking should be done on > the edges of the network, where asymmetry should be much less of a > problem. > > With early revisions of 12.0 there were issues with helper-address > handling -- bootp requests from 0.0.0.0 would be dropped on the > floor instead of being forwarded (ugh!). I think that is now fixed, > though. > > And, yes, we are using the feature. > > > - Hevard -- Neil J. McRae C O L T I N T E R N E T neil at COLT.NET From BERI at etf.bg.ac.yu Mon Sep 6 13:19:00 1999 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Mon, 6 Sep 1999 12:19 +0100 Subject: Tracking stealth portscan/pepsi attacks Message-ID: Dear collagues, The traffic on this list has increased rapidly since we started to discuss various security details. Regrettably, almost no persons from various CERTs are subscribed to this list, while they deal with day-to-day requests for intrusion and attack coordination. Therefore, a security-related RIPE WG might really be needed. Its aims would be to: * enhance incident coordination among ISPs; * ensure exchange of ideas and experiences in network and systems security; * issue security-related recommendations and BCP documents; * establish tighter relatioship between the ISPs and the CERTs. The group should be open to any interested party. The group should also elect a representative who would participate in activities of the CERT and IRT community (meetings, workshops, mailing lists etc.) and/or provide continuous input from various CERTs and IRTs. Few days ago, I received an interesting message from Karel Vietsch, Secretary General of TERENA, related to the subject we're talking about. I'm forwarding it, hoping it would be interesting for wider community (NOTE: the meeting, mentioned in Mr Vietsch's message is closed - only CERT community memebers can participate, but if we find time to create the Security-WG, a representative of the WG can apply to attend it): -------------------------- Begin included message -------------------------- Date: Fri, 03 Sep 1999 22:43:51 +0200 From: Karel Vietsch Subject: European collaboration between CERTs To: Berislav Todorovic Cc: B.Gilmore at ed.ac.uk, dyer at terena.nl, demchenko at terena.nl Dear Mr. Todorovic, A colleague drew my attention to your message below. Indeed, almost three years ago Daniel Karrenberg posted a proposal for a SIRCE service to be provided by the RIPE NCC but he could not realise this plan due to lack of financial commitments. Perhaps you are not aware that Daniel's initiative was actually a proposed response to a call for tender for the SIRCE pilot service, organised by TERENA. As mentioned above, the RIPE NCC was not able to put forward a proposal, but some other organisations did, the best proposal was selected and the SIRCE pilot service started in May 1997. It is currently being provided by UKERNA. See the SIRCE Web site for further details on the current pilot service. The pilot will come to an end later this month, and a meeting has been organised to discuss plans for future collaboration between CERTs in Europe, following on from the SIRCE pilot. This meeting will take place in Amsterdam on Friday 24 September 1999, immediately following the next RIPE meeting. See the invitation below. If you are interested in attending this meeting, please let me know. Best regards, Karel Vietsch TERENA Secretary General +++++++++++++++++++++++++++ Dear colleagues, It is my pleasure to invite you to a meeting to discuss the future collaboration of CERTs in Europe. The meeting will be held on Friday 24 September 1999, 11:00 - 15:00 hours, at the TERENA Secretariat in Amsterdam. Background Collaboration and co-ordination between CERTs in Europe has been under discussion at least since 1992. The report of the TERENA Task Force "CERTs in Europe" (1995) led to a pilot ("SIRCE") for a European CERT co-ordination service. This pilot, which started in May 1997 and is currently being provided by UKERNA, will come to an end later this month. In general the responses to the pilot service have been positive, and many have expressed their appreciation for the work done and the experiences gained during the past 2.5 years. Nevertheless, it has become clear that it will not be possible to establish a permanent operational European CERT co-ordination service at the end of the pilot phase. This is mainly because the needs of the various networks in Europe and their CERTs are so different that it is not possible to collect a sufficient critical mass to provide the (substantial) funds that would be needed to fund such a professional permanent service. Still there is a clear need for and willingness of CERTs in Europe to collaborate on issues of common interest. Such collaboration can take the form of exchange of information, limited work provided by one or more CERTs for the entire European CERT community and joint activities of CERTs who are interested in jointly solving a particular common problem. Rather than a model of a centrally provided service, one would then adopt a model of collaborative activities in one or more working groups, task forces and/or small projects. This thought has been put forward by a number of CERTs in the final discussions on SIRCE, and several examples of possible joint activities have been given. Now that the SIRCE pilot is being completed this month, the time seems ripe to discuss these suggestions in more detail and to agree on future activities. Purpose of the meeting The purpose of the meeting on 24 September 1999 is to identify issues that can be addressed, (information) services that can be provided, activities that can be undertaken and problems that can be jointly solved, through collaborative actions of CERTs in Europe. It is the intention to identify for each of these: which CERTs (and possibly other parties) are interested in the issue, how they feel the issue should be addressed and what they can commit (in manpower or other resources) to joint work on the issue. Agreements should then be reached as to when and how to start such work, and how to organize it. We would hope that the meeting will lead to one or more joint working groups, task forces and/or projects that can be started very soon. Who should attend the meeting? The envisaged participants in the meeting will be the (leading) staff members of CERTs in Europe. Many of the current active CERTs in Europe are attached to Research and Education Networks (NRENs), but representatives of other CERTs who are interested in collaboration with the NREN CERTs are most welcome to participate in the meeting. The host Having been instrumental in European CERT collaboration in recent years (e.g. through the TERENA Task Forces and by making the arrangements for the SIRCE pilot), TERENA feels it as its responsibility to facilitate the best possible future collaboration between CERTs in Europe now that the SIRCE pilot is nearing its completion. Hence TERENA , in consultation with the contributors to the SIRCE pilot, has taken the initiative to organize and host the meeting on 24 September to discuss future plans. The meeting will be chaired by Brian Gilmore, member of TERENA's Executive Committee. Meeting preparation An agenda and other documents for the meeting will be sent out during the next two weeks. Obviously it will help people to prepare for the meeting if those who have specific suggestions for collaborative activities of CERTs in the coming years, could briefly describe their ideas and circulate them to the other meeting participants. Please send your suggestions by e-mail to me at . Logistics The address of the TERENA Secretariat is: Singel 468, 1017 AW Amsterdam, The Netherlands. Phone: +31 20 5304488. Please see http://www.terena.nl/info/secretariat/location.html for a description of how to reach our office. The meeting on 24 September is scheduled to follow immediately on a RIPE meeting which will take place in Amsterdam during the preceding days, for the convenience of those who would be interested to attend both meetings. For others it is important to note that with the meeting starting at 11:00 and finishing before 15:00 hours it will be possible for most people in Europe to make this a one-day trip, travelling to Amsterdam early in the morning and back in the late afternoon. In case you will nevertheless need to spend one or more nights in Amsterdam, TERENA's Secretary Ms. Carol de Groot can help you find suitable accommodation. Since hotels in Amsterdam are extremely full, you are urged to make your hotel arrangements (either directly with the hotel or via Carol de Groot) ** as soon as possible **. Finally, in order to help us prepare for the meeting, please let me know as soon as possible whether you will be able to attend the meeting. My e-mail address is: . We will then include you in further mailings and send you the documents for the meeting. I am looking forward to seeing you in Amsterdam on Friday 24 September and I hope that we will have a very fruitful meeting! Best regards, Karel Vietsch TERENA Secretary General PS. : In case not you yourself but one of your colleagues will be the appropriate person to participate in the meeting: please pass on this invitation! ++++++++++++++++++++++++++++++++++++++++++++++ Karel Vietsch TERENA Secretary General Singel 468, 1017 AW Amsterdam, The Netherlands phone: +31 20 5304488 fax: +31 20 5304499 e-mail: WWW: http://www.terena.nl .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3218-350 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' -------------------------------------------------------------------- From joao at ripe.net Mon Sep 6 13:12:45 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 6 Sep 1999 13:12:45 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: References: Message-ID: Hi, here go my 2 cents (pick your favourite currency). - There is already a pilot European "CERT". As already said in a previous message this pilot is about to finish and a decision will be taken on its future, probably at the closed meeting mentioned previouly. - All it takes to create a RIPE working group are interested people and topics to work on. - A RIPE wg is not a service provided by the RIPE NCC, it is a gathering of people participating in the RIPE community to achieve a common goal. - Naturally, a RIPE wg may request services from the RIPE NCC. At this point is when potential financing would be involved (either through equipment or people to carry out the work). This thread has really initiated a lot of responses which seem to point towards some concerns. May be calling for a BOF at the coming RIPE meeting would be a good idea but also some consideration ought to be given to whether some exisiting wg(s) can do the work. Eg. would be better to produce a document recommending the use of router filters and anti-smurf configs better be done as a document inside the working group (much like the flad dampening recommendations)? The same goes for other subjects. If there are enough specific issues for a group I don't think there would be a problem creating one. However, I guess we all would like to avoid duplication of efforts. If there is interest in a BOF at the next RIPE meeting to disucss topics, then an initiative should be taken soon (probably this week). Regards, Joao At 12:19 +0100 6/9/99, Berislav Todorovic wrote: >Dear collagues, > >The traffic on this list has increased rapidly since we started to discuss >various security details. Regrettably, almost no persons from various >CERTs are subscribed to this list, while they deal with day-to-day >requests for intrusion and attack coordination. > >Therefore, a security-related RIPE WG might really be needed. Its aims >would be to: > >* enhance incident coordination among ISPs; >* ensure exchange of ideas and experiences in network and systems security; >* issue security-related recommendations and BCP documents; >* establish tighter relatioship between the ISPs and the CERTs. > >The group should be open to any interested party. > >The group should also elect a representative who would participate in >activities of the CERT and IRT community (meetings, workshops, mailing >lists etc.) and/or provide continuous input from various CERTs and IRTs. > >Few days ago, I received an interesting message from Karel Vietsch, >Secretary General of TERENA, related to the subject we're talking about. >I'm forwarding it, hoping it would be interesting for wider community >(NOTE: the meeting, mentioned in Mr Vietsch's message is closed - only >CERT community memebers can participate, but if we find time to create >the Security-WG, a representative of the WG can apply to attend it): > From ripe-dbm at ripe.net Mon Sep 6 17:45:54 1999 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Mon, 06 Sep 1999 17:45:54 +0200 Subject: Top 100 Maintainers List Message-ID: <199909061545.RAA22722@birch.ripe.net> Dear list members, This is biweekly report on inconsistent objects in the RIPE whois database. The first 100 maintainers are listed as a table below sorted according to number of their inconsistent objects in the database. The rest of the maintainers which have inconsistent objects can be found at http://www.ripe.net/db/state/mntnerreport1.html You can find further information about the Consistency Project at http://www.ripe.net/db/state/ Regards, RIPE NCC Database Group =============================================================== Maintainer no of name inconsistent objects 1 NL-DOMREG 51932 http://www.ripe.net/db/state/maintainers/NL-DOMREG.html 2 DENIC-P 34021 http://www.ripe.net/db/state/maintainers/DENIC-P.html 3 XLINK-MNT 30463 http://www.ripe.net/db/state/maintainers/XLINK-MNT.html 4 DK-DOMREG 23138 http://www.ripe.net/db/state/maintainers/DK-DOMREG.html 5 AS1849-MNT 6033 http://www.ripe.net/db/state/maintainers/AS1849-MNT.html 6 FR-NIC-MNT 2818 http://www.ripe.net/db/state/maintainers/FR-NIC-MNT.html 7 ROKA-P 2446 http://www.ripe.net/db/state/maintainers/ROKA-P.html 8 DTAG-NIC 1966 http://www.ripe.net/db/state/maintainers/DTAG-NIC.html 9 SCHLUND-P 1524 http://www.ripe.net/db/state/maintainers/SCHLUND-P.html 10 BO-DOMREG 1320 http://www.ripe.net/db/state/maintainers/BO-DOMREG.html 11 NACAMAR-NOC 1303 http://www.ripe.net/db/state/maintainers/NACAMAR-NOC.html 12 ECORE-NET 1287 http://www.ripe.net/db/state/maintainers/ECORE-NET.html 13 AS1717-MNT 1114 http://www.ripe.net/db/state/maintainers/AS1717-MNT.html 14 DENIC-N 1070 http://www.ripe.net/db/state/maintainers/DENIC-N.html 15 WWW-MNT 1009 http://www.ripe.net/db/state/maintainers/WWW-MNT.html 16 DKNET-MNT 651 http://www.ripe.net/db/state/maintainers/DKNET-MNT.html 17 SEKTORNET-MNT 539 http://www.ripe.net/db/state/maintainers/SEKTORNET-MNT.html 18 INTERNET-NOC 534 http://www.ripe.net/db/state/maintainers/INTERNET-NOC.html 19 NETTUNO 499 http://www.ripe.net/db/state/maintainers/NETTUNO.html 20 CSL-MNT 494 http://www.ripe.net/db/state/maintainers/CSL-MNT.html 21 DK-NIC 494 http://www.ripe.net/db/state/maintainers/DK-NIC.html 22 DFN-NTFY 474 http://www.ripe.net/db/state/maintainers/DFN-NTFY.html 23 PSINET-UK-SYSADMIN 435 http://www.ripe.net/db/state/maintainers/PSINET-UK-SYSADMIN.h 24 RAIN-TRANSPAC 385 http://www.ripe.net/db/state/maintainers/RAIN-TRANSPAC.html 25 DIGITALWEB-MNT 375 http://www.ripe.net/db/state/maintainers/DIGITALWEB-MNT.html 26 NACAMAR-RES 372 http://www.ripe.net/db/state/maintainers/NACAMAR-RES.html 27 HIGHSPEED-DOM 367 http://www.ripe.net/db/state/maintainers/HIGHSPEED-DOM.html 28 EU-IBM-NIC-MNT 360 http://www.ripe.net/db/state/maintainers/EU-IBM-NIC-MNT.html 29 SDT-NOC 354 http://www.ripe.net/db/state/maintainers/SDT-NOC.html 30 AS1267-MNT 352 http://www.ripe.net/db/state/maintainers/AS1267-MNT.html 31 AS5378-MNT 345 http://www.ripe.net/db/state/maintainers/AS5378-MNT.html 32 GLOBAL-MNT 343 http://www.ripe.net/db/state/maintainers/GLOBAL-MNT.html 33 AS6678-MNT 339 http://www.ripe.net/db/state/maintainers/AS6678-MNT.html 34 ITNET-MNT 334 http://www.ripe.net/db/state/maintainers/ITNET-MNT.html 35 NACAMAR-POP 324 http://www.ripe.net/db/state/maintainers/NACAMAR-POP.html 36 TDK-MNT 299 http://www.ripe.net/db/state/maintainers/TDK-MNT.html 37 DE-VOSS 298 http://www.ripe.net/db/state/maintainers/DE-VOSS.html 38 IDNET-MNT 298 http://www.ripe.net/db/state/maintainers/IDNET-MNT.html 39 AT-DOM-MNT 288 http://www.ripe.net/db/state/maintainers/AT-DOM-MNT.html 40 KNIPP-NOC-MNT 259 http://www.ripe.net/db/state/maintainers/KNIPP-NOC-MNT.html 41 IL-P 254 http://www.ripe.net/db/state/maintainers/IL-P.html 42 FR-EASYNET 248 http://www.ripe.net/db/state/maintainers/FR-EASYNET.html 43 RAK-NET 246 http://www.ripe.net/db/state/maintainers/RAK-NET.html 44 INX-MNT 233 http://www.ripe.net/db/state/maintainers/INX-MNT.html 45 MARIDAN-P 229 http://www.ripe.net/db/state/maintainers/MARIDAN-P.html 46 GIGABELL-MNT 223 http://www.ripe.net/db/state/maintainers/GIGABELL-MNT.html 47 EUROCONNECT 222 http://www.ripe.net/db/state/maintainers/EUROCONNECT.html 48 AS2120-MNT 211 http://www.ripe.net/db/state/maintainers/AS2120-MNT.html 49 AS1899-MNT 207 http://www.ripe.net/db/state/maintainers/AS1899-MNT.html 50 IWAY-NOC 205 http://www.ripe.net/db/state/maintainers/IWAY-NOC.html 51 AS5617-MNT 197 http://www.ripe.net/db/state/maintainers/AS5617-MNT.html 52 AS3233-MNT 195 http://www.ripe.net/db/state/maintainers/AS3233-MNT.html 53 IT-NIC 192 http://www.ripe.net/db/state/maintainers/IT-NIC.html 54 AS2529-MNT 189 http://www.ripe.net/db/state/maintainers/AS2529-MNT.html 55 NDH-P 187 http://www.ripe.net/db/state/maintainers/NDH-P.html 56 NLNET-MNT 183 http://www.ripe.net/db/state/maintainers/NLNET-MNT.html 57 EU-IBM-NIC-MNT2 181 http://www.ripe.net/db/state/maintainers/EU-IBM-NIC-MNT2.html 58 FREENAME-NOC 179 http://www.ripe.net/db/state/maintainers/FREENAME-NOC.html 59 IBGNET 179 http://www.ripe.net/db/state/maintainers/IBGNET.html 60 OLEANE-NOC 175 http://www.ripe.net/db/state/maintainers/OLEANE-NOC.html 61 ROM-MIKNET 158 http://www.ripe.net/db/state/maintainers/ROM-MIKNET.html 62 AS5427-MNT 156 http://www.ripe.net/db/state/maintainers/AS5427-MNT.html 63 TRMD-MNT 154 http://www.ripe.net/db/state/maintainers/TRMD-MNT.html 64 SL-CUS-MNT 153 http://www.ripe.net/db/state/maintainers/SL-CUS-MNT.html 65 EVOSYS-MNT 151 http://www.ripe.net/db/state/maintainers/EVOSYS-MNT.html 66 MBT-MNT 150 http://www.ripe.net/db/state/maintainers/MBT-MNT.html 67 AS1241-MNT 149 http://www.ripe.net/db/state/maintainers/AS1241-MNT.html 68 AS5551-MNT 135 http://www.ripe.net/db/state/maintainers/AS5551-MNT.html 69 AS2871-MNT 134 http://www.ripe.net/db/state/maintainers/AS2871-MNT.html 70 NNCC 125 http://www.ripe.net/db/state/maintainers/NNCC.html 71 NETCOLOGNE-MNT 124 http://www.ripe.net/db/state/maintainers/NETCOLOGNE-MNT.html 72 OMNILINK-MNT 124 http://www.ripe.net/db/state/maintainers/OMNILINK-MNT.html 73 ONE2ONE-MNT 121 http://www.ripe.net/db/state/maintainers/ONE2ONE-MNT.html 74 WESPE-MNT 117 http://www.ripe.net/db/state/maintainers/WESPE-MNT.html 75 IMAGINET-NOC-MNT 115 http://www.ripe.net/db/state/maintainers/IMAGINET-NOC-MNT.htm 76 AS3292-MNT 112 http://www.ripe.net/db/state/maintainers/AS3292-MNT.html 77 ROSNIIROS-MNT 108 http://www.ripe.net/db/state/maintainers/ROSNIIROS-MNT.html 78 ISB-MNT 107 http://www.ripe.net/db/state/maintainers/ISB-MNT.html 79 ECRC-MNT 103 http://www.ripe.net/db/state/maintainers/ECRC-MNT.html 80 FO-DOMREG 100 http://www.ripe.net/db/state/maintainers/FO-DOMREG.html 81 TELIANET-LIR 100 http://www.ripe.net/db/state/maintainers/TELIANET-LIR.html 82 ISMA-MNT 98 http://www.ripe.net/db/state/maintainers/ISMA-MNT.html 83 GARR-LIR 95 http://www.ripe.net/db/state/maintainers/GARR-LIR.html 84 SEICOM-MNT 93 http://www.ripe.net/db/state/maintainers/SEICOM-MNT.html 85 PROFI-MNT 92 http://www.ripe.net/db/state/maintainers/PROFI-MNT.html 86 AS6721-MNT 87 http://www.ripe.net/db/state/maintainers/AS6721-MNT.html 87 TINET-NOC 85 http://www.ripe.net/db/state/maintainers/TINET-NOC.html 88 XNC-MNT 84 http://www.ripe.net/db/state/maintainers/XNC-MNT.html 89 AS8875-MNT 82 http://www.ripe.net/db/state/maintainers/AS8875-MNT.html 90 ISTLD-MNT 82 http://www.ripe.net/db/state/maintainers/ISTLD-MNT.html 91 TPNET 80 http://www.ripe.net/db/state/maintainers/TPNET.html 92 JIPS-NOSC 78 http://www.ripe.net/db/state/maintainers/JIPS-NOSC.html 93 MDA-Z 78 http://www.ripe.net/db/state/maintainers/MDA-Z.html 94 PRHO-GUARDIAN 78 http://www.ripe.net/db/state/maintainers/PRHO-GUARDIAN.html 95 ISAR-NIC 77 http://www.ripe.net/db/state/maintainers/ISAR-NIC.html 96 INETWIRE-MNT 76 http://www.ripe.net/db/state/maintainers/INETWIRE-MNT.html 97 GLOBAL-ONE 74 http://www.ripe.net/db/state/maintainers/GLOBAL-ONE.html 98 MAINT-AS3352 70 http://www.ripe.net/db/state/maintainers/MAINT-AS3352.html 99 JO-YN14 67 http://www.ripe.net/db/state/maintainers/JO-YN14.html 100 WEB4YOU-MNT 66 http://www.ripe.net/db/state/maintainers/WEB4YOU-MNT.html From hank at ibm.net.il Mon Sep 6 17:52:42 1999 From: hank at ibm.net.il (Hank Nussbacher) Date: Mon, 6 Sep 1999 17:52:42 +0200 (IST) Subject: Top 100 Maintainers List In-Reply-To: <199909061545.RAA22722@birch.ripe.net> Message-ID: On Mon, 6 Sep 1999, RIPE Database Administration wrote: Is something wrong with auto-dbm at ripe.net? I have not received any reply from that id for the past 48 hours. -Hank > > Dear list members, > > This is biweekly report on inconsistent objects in the RIPE > whois database. The first 100 maintainers are listed as a table > below sorted according to number of their inconsistent objects > in the database. The rest ofthe maintainers which have inconsistent > objects can be found at > > http://www.ripe.net/db/state/mntnerreport1.html > > You can find further information about the Consistency Project at > > http://www.ripe.net/db/state/ > > Regards, > RIPE NCC Database Group > =============================================================== > Maintainer no of > name inconsistent > objects > 1 NL-DOMREG 51932 http://www.ripe.net/db/state/maintainers/NL-DOMREG.html > 2 DENIC-P 34021 http://www.ripe.net/db/state/maintainers/DENIC-P.html > 3 XLINK-MNT 30463 http://www.ripe.net/db/state/maintainers/XLINK-MNT.html > 4 DK-DOMREG 23138 http://www.ripe.net/db/state/maintainers/DK-DOMREG.html > 5 AS1849-MNT 6033 http://www.ripe.net/db/state/maintainers/AS1849-MNT.html > 6 FR-NIC-MNT 2818 http://www.ripe.net/db/state/maintainers/FR-NIC-MNT.html > 7 ROKA-P 2446 http://www.ripe.net/db/state/maintainers/ROKA-P.html > 8 DTAG-NIC 1966 http://www.ripe.net/db/state/maintainers/DTAG-NIC.html > 9 SCHLUND-P 1524 http://www.ripe.net/db/state/maintainers/SCHLUND-P.html > 10 BO-DOMREG 1320 http://www.ripe.net/db/state/maintainers/BO-DOMREG.html > 11 NACAMAR-NOC 1303 http://www.ripe.net/db/state/maintainers/NACAMAR-NOC.html > 12 ECORE-NET 1287 http://www.ripe.net/db/state/maintainers/ECORE-NET.html > 13 AS1717-MNT 1114 http://www.ripe.net/db/state/maintainers/AS1717-MNT.html > 14 DENIC-N 1070 http://www.ripe.net/db/state/maintainers/DENIC-N.html > 15 WWW-MNT 1009 http://www.ripe.net/db/state/maintainers/WWW-MNT.html > 16 DKNET-MNT 651 http://www.ripe.net/db/state/maintainers/DKNET-MNT.html > 17 SEKTORNET-MNT 539 http://www.ripe.net/db/state/maintainers/SEKTORNET-MNT.html > 18 INTERNET-NOC 534 http://www.ripe.net/db/state/maintainers/INTERNET-NOC.html > 19 NETTUNO 499 http://www.ripe.net/db/state/maintainers/NETTUNO.html > 20 CSL-MNT 494 http://www.ripe.net/db/state/maintainers/CSL-MNT.html > 21 DK-NIC 494 http://www.ripe.net/db/state/maintainers/DK-NIC.html > 22 DFN-NTFY 474 http://www.ripe.net/db/state/maintainers/DFN-NTFY.html > 23 PSINET-UK-SYSADMIN 435 http://www.ripe.net/db/state/maintainers/PSINET-UK-SYSADMIN.h > 24 RAIN-TRANSPAC 385 http://www.ripe.net/db/state/maintainers/RAIN-TRANSPAC.html > 25 DIGITALWEB-MNT 375 http://www.ripe.net/db/state/maintainers/DIGITALWEB-MNT.html > 26 NACAMAR-RES 372 http://www.ripe.net/db/state/maintainers/NACAMAR-RES.html > 27 HIGHSPEED-DOM 367 http://www.ripe.net/db/state/maintainers/HIGHSPEED-DOM.html > 28 EU-IBM-NIC-MNT 360 http://www.ripe.net/db/state/maintainers/EU-IBM-NIC-MNT.html > 29 SDT-NOC 354 http://www.ripe.net/db/state/maintainers/SDT-NOC.html > 30 AS1267-MNT 352 http://www.ripe.net/db/state/maintainers/AS1267-MNT.html > 31AS5378-MNT 345 http://www.ripe.net/db/state/maintainers/AS5378-MNT.html > 32 GLOBAL-MNT 343 http://www.ripe.net/db/state/maintainers/GLOBAL-MNT.html > 33 AS6678-MNT 339 http://www.ripe.net/db/state/maintainers/AS6678-MNT.html > 34 ITNET-MNT 334 http://www.ripe.net/db/state/maintainers/ITNET-MNT.html > 35 NACAMAR-POP 324 http://www.ripe.net/db/state/maintainers/NACAMAR-POP.html > 36 TDK-MNT 299http://www.ripe.net/db/state/maintainers/TDK-MNT.html > 37 DE-VOSS 298 http://www.ripe.net/db/state/maintainers/DE-VOSS.html > 38 IDNET-MNT 298 http://www.ripe.net/db/state/maintainers/IDNET-MNT.html > 39 AT-DOM-MNT 288 http://www.ripe.net/db/state/maintainers/AT-DOM-MNT.html > 40 KNIPP-NOC-MNT 259 http://www.ripe.net/db/state/maintainers/KNIPP-NOC-MNT.html > 41 IL-P 254 http://www.ripe.net/db/state/maintainers/IL-P.html > 42 FR-EASYNET 248 http://www.ripe.net/db/state/maintainers/FR-EASYNET.html > 43 RAK-NET 246 http://www.ripe.net/db/state/maintainers/RAK-NET.html > 44 INX-MNT 233 http://www.ripe.net/db/state/maintainers/INX-MNT.html > 45 MARIDAN-P 229 http://www.ripe.net/db/state/maintainers/MARIDAN-P.html > 46 GIGABELL-MNT 223 http://www.ripe.net/db/state/maintainers/GIGABELL-MNT.html > 47 EUROCONNECT 222 http://www.ripe.net/db/state/maintainers/EUROCONNECT.html > 48 AS2120-MNT 211 http://www.ripe.net/db/state/maintainers/AS2120-MNT.html > 49 AS1899-MNT 207 http://www.ripe.net/db/state/maintainers/AS1899-MNT.html > 50 IWAY-NOC 205 http://www.ripe.net/db/state/maintainers/IWAY-NOC.html > 51 AS5617-MNT 197 http://www.ripe.net/db/state/maintainers/AS5617-MNT.html > 52 AS3233-MNT 195 http://www.ripe.net/db/state/maintainers/AS3233-MNT.html > 53 IT-NIC 192 http://www.ripe.net/db/state/maintainers/IT-NIC.html > 54 AS2529-MNT 189 http://www.ripe.net/db/state/maintainers/AS2529-MNT.html > 55 NDH-P 187 http://www.ripe.net/db/state/maintainers/NDH-P.html > 56 NLNET-MNT 183 http://www.ripe.net/db/state/maintainers/NLNET-MNT.html > 57 EU-IBM-NIC-MNT2 181 http://www.ripe.net/db/state/maintainers/EU-IBM-NIC-MNT2.html > 58 FREENAME-NOC 179 http://www.ripe.net/db/state/maintainers/FREENAME-NOC.html > 59 IBGNET 179 http://www.ripe.net/db/state/maintainers/IBGNET.html > 60 OLEANE-NOC 175 http://www.ripe.net/db/state/maintainers/OLEANE-NOC.html > 61 ROM-MIKNET 158 http://www.ripe.net/db/state/maintainers/ROM-MIKNET.html > 62 AS5427-MNT 156 http://www.ripe.net/db/state/maintainers/AS5427-MNT.html > 63 TRMD-MNT 154 http://www.ripe.net/db/state/maintainers/TRMD-MNT.html > 64 SL-CUS-MNT 153 http://www.ripe.net/db/state/maintainers/SL-CUS-MNT.html > 65 EVOSYS-MNT 151 http://www.ripe.net/db/state/maintainers/EVOSYS-MNT.html > 66 MBT-MNT 150 http://www.ripe.net/db/state/maintainers/MBT-MNT.html > 67 AS1241-MNT 149 http://www.ripe.net/db/state/maintainers/AS1241-MNT.html > 68 AS5551-MNT 135 http://www.ripe.net/db/state/maintainers/AS5551-MNT.html > 69 AS2871-MNT 134 http://www.ripe.net/db/state/maintainers/AS2871-MNT.html > 70 NNCC 125 http://www.ripe.net/db/state/maintainers/NNCC.html > 71 NETCOLOGNE-MNT 124 http://www.ripe.net/db/state/maintainers/NETCOLOGNE-MNT.html > 72 OMNILINK-MNT 124 http://www.ripe.net/db/state/maintainers/OMNILINK-MNT.html > 73 ONE2ONE-MNT 121 http://www.ripe.net/db/state/maintainers/ONE2ONE-MNT.html > 74 WESPE-MNT 117 http://www.ripe.net/db/state/maintainers/WESPE-MNT.html > 75 IMAGINET-NOC-MNT 115 http://www.ripe.net/db/state/maintainers/IMAGINET-NOC-MNT.htm > 76 AS3292-MNT 112 http://www.ripe.net/db/state/maintainers/AS3292-MNT.html > 77 ROSNIIROS-MNT 108 http://www.ripe.net/db/state/maintainers/ROSNIIROS-MNT.html > 78 ISB-MNT 107 http://www.ripe.net/db/state/maintainers/ISB-MNT.html > 79 ECRC-MNT 103 http://www.ripe.net/db/state/maintainers/ECRC-MNT.html > 80 FO-DOMREG 100 http://www.ripe.net/db/state/maintainers/FO-DOMREG.html > 81 TELIANET-LIR 100 http://www.ripe.net/db/state/maintainers/TELIANET-LIR.html > 82 ISMA-MNT 98 http://www.ripe.net/db/state/maintainers/ISMA-MNT.html > 83 GARR-LIR 95 http://www.ripe.net/db/state/maintainers/GARR-LIR.html > 84 SEICOM-MNT 93 http://www.ripe.net/db/state/maintainers/SEICOM-MNT.html > 85 PROFI-MNT 92 http://www.ripe.net/db/state/maintainers/PROFI-MNT.html > 86 AS6721-MNT 87 http://www.ripe.net/db/state/maintainers/AS6721-MNT.html > 87 TINET-NOC 85 http://www.ripe.net/db/state/maintainers/TINET-NOC.html > 88 XNC-MNT 84 http://www.ripe.net/db/state/maintainers/XNC-MNT.html > 89 AS8875-MNT 82 http://www.ripe.net/db/state/maintainers/AS8875-MNT.html > 90 ISTLD-MNT 82 http://www.ripe.net/db/state/maintainers/ISTLD-MNT.html > 91 TPNET 80 http://www.ripe.net/db/state/maintainers/TPNET.html > 92 JIPS-NOSC 78 http://www.ripe.net/db/state/maintainers/JIPS-NOSC.html > 93 MDA-Z 78 http://www.ripe.net/db/state/maintainers/MDA-Z.html > 94 PRHO-GUARDIAN 78 http://www.ripe.net/db/state/maintainers/PRHO-GUARDIAN.html > 95 ISAR-NIC 77 http://www.ripe.net/db/state/maintainers/ISAR-NIC.html > 96 INETWIRE-MNT 76 http://www.ripe.net/db/state/maintainers/INETWIRE-MNT.html > 97 GLOBAL-ONE 74 http://www.ripe.net/db/state/maintainers/GLOBAL-ONE.html > 98 MAINT-AS3352 70 http://www.ripe.net/db/state/maintainers/MAINT-AS3352.html > 99 JO-YN14 67 http://www.ripe.net/db/state/maintainers/JO-YN14.html > 100 WEB4YOU-MNT 66 http://www.ripe.net/db/state/maintainers/WEB4YOU-MNT.html > Hank Nussbacher From joao at ripe.net Mon Sep 6 18:15:45 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Mon, 6 Sep 1999 18:15:45 +0200 Subject: Top 100 Maintainers List In-Reply-To: References: Message-ID: Hi, depends on what you consider wrong. Response time is definitely wrong. The system is, however, working. The system has on some occcasions, for the last two weeks, received messages at a rate that is faster than the system can handle. This is partly due to the fact that a number of huge messages (containing in the order of 10^4 objects) have been received and they request updates of objects of which there are a big number in the database. The current software hits severe scalability problems when this happens. We have during the last days, devoted a lot of attention to solving these problems by specifically hacking the software to optimize this type of updates. We have tuned the system parameters to the limit. We are currently in the process of trying out an update to the disk system (which to add to all of the above, has suffered an unusual amount of physical problems). We have also contacted the senders of the updates to try to have the messages split and give a chance to everyone else. We are looking at a front end for the database that will do some kind of batch queue handling enabling control over how resources are distributed to users, so that no single user can hog the machine. Also, this is impacting the efforts of the reimplementation project which is the ultimate solution for this problem. Hope this gives you a bit of an overview of the situation. I apologize for the incovenience this is generating for everyone but I assure you, we are doing our best to get this thing to work as fast as possible. Best regards, Joao Damas RIPE DB Group manager RIPE NCC At 17:52 +0200 6/9/99, Hank Nussbacher wrote: >On Mon, 6 Sep 1999, RIPE Database Administration wrote: > >Is something wrong with auto-dbm at ripe.net? I have not received any reply >from that id for the past 48 hours. > >-Hank From lmb at teuto.net Mon Sep 6 13:03:13 1999 From: lmb at teuto.net (Lars Marowsky-Bree) Date: Mon, 6 Sep 1999 13:03:13 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: ; from "Berislav Todorovic" on 1999-09-06T12:19:00 References: Message-ID: <19990906130313.H32504@pointer.teuto.de> On 1999-09-06T12:19:00, Berislav Todorovic said: > Therefore, a security-related RIPE WG might really be needed. Its aims > would be to: > > * enhance incident coordination among ISPs; > * ensure exchange of ideas and experiences in network and systems security; > * issue security-related recommendations and BCP documents; > * establish tighter relatioship between the ISPs and the CERTs. Very well summarized. This is a good starting point for a WG charta and I wholeheartedly agree. This complements the existing groups (which mostly deal with host security and LANs) and RIPE is definetely the right forum for this. We should be able to discuss and organize this at RIPE34. Sincerely, Lars Marowsky-Brie -- Lars Marowsky-Brie Network Management teuto.net Netzdienste GmbH - DPN Verbund-Partner From oppermann at pipeline.ch Tue Sep 7 15:10:49 1999 From: oppermann at pipeline.ch (Andre Oppermann) Date: Tue, 07 Sep 1999 15:10:49 +0200 Subject: Tracking stealth portscan/pepsi attacks References: <19990831132437.A16300@xlink.net> <19990901130902.A15938@nethammer.qad.org> <37CE4706.3B3D44D8@insnet.net> <19990902114412.S13951@Space.Net> <37CE556A.3B97A29E@insnet.net> Message-ID: <37D50ED9.2A9BA62@pipeline.ch> Leigh Porter wrote: > > "Gert Doering, Netmaster" wrote: > > > Hi, > > > > On Thu, Sep 02, 1999 at 10:44:39AM +0100, Leigh Porter wrote: > > > As a side note, does anybody use anything to prevent address spoofing in their > > > network? That would at prevent a lot of attacks completly and make tracing the > > > rest much easier. > > > > Sure we do. > > > > On our ingress interfaces to our customers, we have very strict access > > lists ("permit ip any / deny ip any any log"). > > How do you manage large BGP customers with lots of networks? > I would also be interested to know performance hits on the routers > for this. Last month I described the idea of an special prefix access list on de.comm.internet.routing that basically solves that problem. The syntax would look something like this: 'access-list 1000 permit bgp-neighbor 1.2.3.4 received-networks' 'access-list 1100 permit bgp-neighbor 1.2.3.4 announced-networks' It simply conscructs an automatic ip prefix access-list based on the prefixes received/announced to/from the BGP peer. This has the cute side effect that all ip filters can be done in one place; the bgp configuration. The 'permit received-networks' part looks pretty promising for an easy implementation because the router has to perform an bgp table lookup anyway for each incoming ip packet. It simply adds a compare to find the neighbor. The filtering on announced networks looks much more problematic to implement but it's not that important. Sure, this will eat some CPU but IMO not more than 10%. I've suggested this feature to cisco and they promised that they'll contact me tomorrow to discuss this further. As soon as I get cisco to think deeper about this I'll post here again with contacts so that you can voice your support too for this feature. -- Andre Oppermann CEO / Geschaeftsfuehrer Internet Business Solutions Ltd. (AG) Hardstrasse 235, 8005 Zurich, Switzerland Fon +41 1 277 75 75 / Fax +41 1 277 75 77 http://www.pipeline.ch ibs at pipeline.ch From Havard.Eidnes at runit.sintef.no Tue Sep 7 16:25:11 1999 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Tue, 07 Sep 1999 16:25:11 +0200 Subject: Tracking stealth portscan/pepsi attacks In-Reply-To: Your message of "Tue, 07 Sep 1999 15:10:49 +0200" <37D50ED9.2A9BA62@pipeline.ch> References: <37D50ED9.2A9BA62@pipeline.ch> Message-ID: <19990907162511D.he@runit.sintef.no> > Last month I described the idea of an special prefix access > list on de.comm.internet.routing that basically solves that > problem. > > The syntax would look something like this: > > 'access-list 1000 permit bgp-neighbor 1.2.3.4 received-networks' > 'access-list 1100 permit bgp-neighbor 1.2.3.4 announced-networks' > > It simply conscructs an automatic ip prefix access-list based > on the prefixes received/announced to/from the BGP peer. This > has the cute side effect that all ip filters can be done in one > place; the bgp configuration. Umm, how is this significantly different from doing RPF (Reverse Path Forwarding) checks for unicast packets, as I described earlier, and as already implemented by Cisco? If I understand what you're trying to do correctly, doing the "received-networks" would be to just turn on RPF checking on the incoming interface from the neighbor, while doing "announced- networks" will mean that you either have to make sure you have RPF checking on all your edges or that all interfaces on this particular customer access router has RPF checking turned on. > The 'permit received-networks' part looks pretty promising for > an easy implementation because the router has to perform an bgp > table lookup anyway for each incoming ip packet. Um, that's not quite correct. The router does a forwarding table lookup for the destination address in each packet when doing packet forwarding; the forwarding table is being built from (among other sources) the BGP routing database. Doing the RPF check for unicast packets adds a second forwarding table lookup for each packet (look up the source and see if the packet entered on an interface where we have a route pointing back out), so it does have a cost, but demanding CEF (as Cisco does) reduces that cost over the other potential alternatives. Regards, - H?vard From oppermann at pipeline.ch Tue Sep 7 17:02:56 1999 From: oppermann at pipeline.ch (Andre Oppermann) Date: Tue, 07 Sep 1999 17:02:56 +0200 Subject: Tracking stealth portscan/pepsi attacks References: <37D50ED9.2A9BA62@pipeline.ch> <19990907162511D.he@runit.sintef.no> Message-ID: <37D52920.B885349@pipeline.ch> Havard.Eidnes at runit.sintef.no wrote: > > > Last month I described the idea of an special prefix access > > list on de.comm.internet.routing that basically solves that > > problem. > > > > The syntax would look something like this: > > > > 'access-list 1000 permit bgp-neighbor 1.2.3.4 received-networks' > > 'access-list 1100 permit bgp-neighbor 1.2.3.4 announced-networks' > > > > It simply conscructs an automatic ip prefix access-list based > > on the prefixes received/announced to/from the BGP peer. This > > has the cute side effect that all ip filters can be done in one > > place; the bgp configuration. > > Umm, how is this significantly different from doing RPF (Reverse > Path Forwarding) checks for unicast packets, as I described > earlier, and as already implemented by Cisco? It allows asymetric routing. > If I understand what you're trying to do correctly, doing the > "received-networks" would be to just turn on RPF checking on the > incoming interface from the neighbor, while doing "announced- > networks" will mean that you either have to make sure you have > RPF checking on all your edges or that all interfaces on this > particular customer access router has RPF checking turned on. Well... What I imagine is an prefix based packet filter (no rule list). This would be as fast as the routing table lookup. Lets have a look what the router does with that feature: 1. ip packet comes enters through interface s0/0 2. ip packet source address gets checked against prefix filter. The prefix filter contains and allows only prefixes received from bgp neighbor 1.2.3.4 3. process the packet as usual > > The 'permit received-networks' part looks pretty promising for > > an easy implementation because the router has to perform an bgp > > table lookup anyway for each incoming ip packet. > > Um, that's not quite correct. The router does a forwarding table > lookup for the destination address in each packet when doing > packet forwarding; the forwarding table is being built from > (among other sources) the BGP routing database. Yes. > Doing the RPF check for unicast packets adds a second forwarding > table lookup for each packet (look up the source and see if the > packet entered on an interface where we have a route pointing > back out), so it does have a cost, but demanding CEF (as Cisco > does) reduces that cost over the other potential alternatives. The problem with RPF is that as doesn't work in environments with asymetric routing. -- Andre Oppermann CEO / Geschaeftsfuehrer Internet Business Solutions Ltd. (AG) Hardstrasse 235, 8005 Zurich, Switzerland Fon +41 1 277 75 75 / Fax +41 1 277 75 77 http://www.pipeline.ch ibs at pipeline.ch From ncc at ripe.net Wed Sep 8 17:38:09 1999 From: ncc at ripe.net (RIPE NCC Staff) Date: Wed, 08 Sep 1999 17:38:09 +0200 Subject: ICANN: Call for nominees to the Addres Council Message-ID: <199909081538.RAA01655@birch.ripe.net> Dear Colleagues, We are pleased to announce a call for nominations to the ICANN ASO committee. Please read this carefully as it is an important step in the process of furthering development in this area. In our effort to reach as many interested parties as possible we may unavoidably send you two copies. Please accept our apologies for this. ========= Call for Nominations for Members of the Address Council of ICANN - RIPE NCC Service Region Amsterdam, 8 September 1999 This is a call for nominations of individuals to serve as members of the Address Council, a body that is to be established under the authority of the Address Supporting Organisation (ASO) of ICANN. This document describes the process that will be followed in the selection of Address Council members. If you are interested in nominating an individual, or if you are interested in being nominated as a member of the Address Council, please read through the Memorandum of Understanding (MoU) and this document carefully. 1. The Address Supporting Organisation ----------------------------------------------------- The ASO will be created though a MoU that will be executed between the current Regional Internet Registries (RIRs) and ICANN. The latest version of this MoU is available under the ICANN and ASO current issues section on the RIPE NCC Web site at: http://www.ripe.net/info/ncc/icann.html Section 2(a) of the MoU provides a framework for the regional selection procedure of Address Council members. Due to additional time constraints set by the current ICANN board the schedule proposed in section 2(a) cannot be realised. Therefore in accordance with section 2(a)(v) a modified procedure will be followed to select the initial Address Council members with emphasis on openness and transparency. The RIPE NCC Association has chosen to make use of the existing open processes in their region to select Address Council members. The selection of the Address Council members will take place at the first following RIPE Meeting scheduled to take place from 21-24 September 1999 in Amsterdam, The Netherlands. In accordance with section 2(a)(v) the definition of the selection procedure will be part of the Local Internet Registry Working Group (Local IR WG) meeting scheduled for Wednesday, 22 September 1999 at 14:00 at the upcoming RIPE meeting. This working group has traditionally served as the RIPE NCC's IP address related policy making forum and is open to all interested parties. The actual selection will take place at the RIPE 34 Meeting - Plenary session to be held on Thursday, 23 September 1999 starting at 14:00. Further information about the upcoming RIPE Meeting can be found at: http://www.ripe.net/meetings/ripe/index.htmlripe-34/ 2. Address Council Nominations Process ------------------------------------------------------ Three individuals from the RIPE NCC Region will be selected to serve as initial members of the Address Council. The selection will be made from the set of individuals who have been nominated within this process. Any individual may be nominated within this process, with the exception of any staff member of any Regional Internet Registry. Self-nominations are permitted. Nominations are to be sent by email to: nominations at ripe.net The information included with the nomination is to be in English, and should include: Name of Nominee Organisation Email Address Postal Address Phone Number Motivation for Nomination All nominations are to be emailed to the above address on or before Sunday, 19 September 1999. All nominees will be contacted via email to confirm their willingness to serve as an Address Council member. If the nominee cannot be contacted via email then the nomination will not be confirmed. All confirmed nominations will be listed on the RIPE NCC Web site as soon as they are confirmed. Important Dates: 19 September 1999: deadline for Address Council nominations 21-24 September 1999: RIPE Meeting 34 - Amsterdam, The Netherlands Keith Mitchell, Chairman, RIPE NCC Executive Board Rob Blokzijl, Chairman, RIPE From ncc at ripe.net Wed Sep 8 18:43:07 1999 From: ncc at ripe.net (RIPE NCC Staff) Date: Wed, 08 Sep 1999 18:43:07 +0200 Subject: MoU based ASO proposal accepted by ICANN Message-ID: <199909081643.SAA10712@birch.ripe.net> [Apologies for duplicate mails] This is an update to our earlier posting regarding a proposal to form an Address Supporting Organisation (ASO) within the framework of the International Corporation for the Assignment of Names and Numbers (ICANN). RIPE NCC, together with the other Regional Internet Registries (RIR), ARIN and APNIC submitted this proposal for ICANN to consider at their August 26th Board meeting in Santiago, Chile. The RIPE NCC is pleased to report that ICANN has accepted this proposal. The resolutions approved at the recent ICANN Board meeting can be found at: http://www.icann.org/santiago/santiago-resolutions.htm The RIR Boards have worked to produce a draft Memorandum of Understanding that will form the ASO. This document can be found at: http://www.ripe.net/info/ncc/mou-draft.html In addition we need to progress with the selection of nominations for the Address Council. A formal call for nominations has been published outlining the process of the initial formation of the Address Council. The call for nominations can be found at: http://www.ripe.net/info/ncc/asonomin.html We would like thank you for your continued support in this process. Paul Rendek Communications Officer RIPE NCC From hph at sys.sol.no Fri Sep 10 15:54:58 1999 From: hph at sys.sol.no (hph at sys.sol.no) Date: Fri, 10 Sep 1999 15:54:58 +0200 Subject: RIPE 34 LIR WG Draft Agenda Message-ID: Dear Working Group Member ! I have put together a first draft of the agenda for the upcoming working group meeting. Please read it carefully and make suggestions for additions and changes. Remember: this is YOUR forum, please send me YOUR suggestions on what you want us to spend time on at the meeting in Amsterdam, Looking forward to meet you there, Hans Petter Holen LIR WG Chair ---------------------------------------------------- RIPE 34 - Local IR Working Group first draft Agenda 1. Admin scribe participant list charter mailinglists 2. Agenda 3. Introduction of the new Registration Services manager, Nurani Nimpuno. meet the RIPE NCC hostmasters 4. RIPE 33 minutes actions 5. Reports from the Registries RIPE APNIC 6. The RIPE community POLICY making process by Mirjam Discussion: is this well understood and 7. ICANN - ASO Current status, Further work Definition of the selection procedure for the address council selection 8. AOB From hph at sys.sol.no Fri Sep 10 16:04:22 1999 From: hph at sys.sol.no (hph at sys.sol.no) Date: Fri, 10 Sep 1999 16:04:22 +0200 Subject: RIPE 34 LIR WG Draft Agenda Message-ID: [ Moderator note: changed local-ir at ripe.net -> lir-wg at ripe.net ] Dear Working Group Member ! I have put together a first draft of the agenda for the upcoming working group meeting. Please read it carefully and make suggestions for additions and changes. Remember: this is YOUR forum, please send me YOUR suggestions on what you want us to spend time on at the meeting in Amsterdam, Looking forward to meet you there, Hans Petter Holen LIR WG Chair ---------------------------------------------------- RIPE 34 - Local IR Working Group first draft Agenda 1. Admin scribe participant list charter mailinglists 2. Agenda 3. Introduction of the new Registration Services manager, Nurani Nimpuno. meet the RIPE NCC hostmasters 4. RIPE 33 minutes actions 5. Reports from the Registries RIPE APNIC 6. The RIPE community POLICY making process by Mirjam Discussion: is this well understood and 7. ICANN - ASO Current status, Further work Definition of the selection procedure for the address council selection 8. AOB From support at waldonet.net.mt Fri Sep 10 17:11:32 1999 From: support at waldonet.net.mt (support at waldonet.net.mt) Date: Fri, 10 Sep 1999 15:11:32 GMT Subject: RIPE 34 LIR WG Draft Agenda [SPT1999091000000043] Message-ID: Dear lir-wg at ripe.net, This is an automated response from Support Pools . We received your message on 10/09/99 at 5:11:32 PM. We would like to offer our sincere thanks to you for writing to us. Your tracking number for this message is : SPT1999091000000043. Our staff are available to respond to messages during regular business hours, excluding holidays. Messages are normally answered within one business day. You should be receiving a personal response by e-mail from one of our staff shortly. In the event you need to contact us regarding your original message, please refer to the tracking number at the top of this message. This will help our staff locate and review your correspondence with us. Thanks once again for writing. You should hear from one of our staff shortly. Waldonet Ltd Telephone (Sales & Admin) 419100 Telephone (Customer Support) 419200 Fax: 419300 From jhma at EU.net Fri Sep 10 17:28:16 1999 From: jhma at EU.net (James Aldridge) Date: Fri, 10 Sep 1999 17:28:16 +0200 Subject: RIPE 34 LIR WG Draft Agenda In-Reply-To: Your message of "Fri, 10 Sep 1999 16:04:22 +0200." Message-ID: <199909101528.RAA22097@aegir.EU.net> hph at sys.sol.no wrote: > Remember: this is YOUR forum, please send me YOUR suggestions on what you > want us to spend time on at the meeting in Amsterdam, I think that it could be useful to start some discussion on whether an additional value for the inetnum "status" field would be useful. What I would like to see, and which would be useful for a large registry such as "eu.eunet" which I coordinate, is somethig like "LIR-ALLOCATED" which could be used to tag a block of addresses as being sub-allocated by a local registry for some purpose (e.g. identifying a block as being used for assignments by a particular local operation, PoP, etc.) but which wouldn't cause all the real assignments under that block to be flagged as overlaps or duplicates by the NCC's registry auditing processes. James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 625 5913 - ----- 24hr emergency number: +31 20 421 0865 From inaddr at ripe.net Mon Sep 13 15:12:43 1999 From: inaddr at ripe.net (RIPE NCC IN-ADDR. ARPA Role Account) Date: Mon, 13 Sep 1999 15:12:43 +0200 Subject: New RIPE NCC reverse delegation procedure Message-ID: <199909131312.PAA20799@birch.ripe.net> Dear Working Group, we intend to rewrite the software that we use to automate reverse delegation requests, with the (main) goals: - simplify/improve the request procedure - maximise automation to keep resource demands reasonable e.g. improving our internal system, including, for example, IPv6 automation - improve the maintainability of the software There are several issues which come up with regard to the request procedure. I've outlined some of our *intentions* below in the hope of soliciting feedback. ---> Requesters will only need to write to a single automatic mailbox , to request reverse delegation. Database update will take place automatically once all other checks are passed. + simplifies and speeds up procedure ---> If we attempt a zone tranfer to check that the contents of a zone are syntactically correct and consistent with other nameservers, and the transfer fails, we will not reject the request. We will check all of the data which can be queried without a transfer. + many zone administrators are very happy. - we cannot check some of the zone contents for problems. However, we think that the information we can collect without the transfers is sufficient to decide whether the delegation itself is well setup, even if it's contents are not. [Note: zone tranfers to our network will still be *required* to be enabled for reverse /16 zones, since we will continue to require that ns.ripe.net be included as a secondary for these zones.] ---> It will be mandatory that a registry ID is included in all requests for reverse delegation, as is currently the case for requests to . We will require that all requests come from an LIR receiving service (i.e. paying for services), and that the requester is one of the registry contact people/ contact role-account. + resource efficient. We only deal with people who are experienced in the reverse delegation procedure and aware of the RIPE NCC and RIPE DB procedures in general -> minimal time explaining procedure and general registry system concepts. Currently we spend much time dealing with inexperienced end-users who will set up only one or a few zones and therefore do not spend the time to become knowledgable concerning the procedures. + fair to paying members. We do not spend time guiding people who do not contribute to the costs. ---> We will only accept requests in the form of a RIPE DB domain object (as opposed to also accepting inetnum objects). + uniform update procedure for all types and sizes of zone, procedure becomes much clearer, confusion and doubt are banished. + removes possibility of 3-way inconsistency between domain objects in the RIPE DB, inetnum objects in the RIPE DB and the corresponding zone file delegations. + clear to users of DB in what type of object they need to look for contact info on the zone. + removes problem where errors in a single reverse zone of a corresponding large inetnum mean the whole inetnum has to be resubmitted, - for requests involving large numbers of zones lots of domain objects will be needed. We'll lessen this by making possible a shorthand domain object like this: domain: x-y.w.z.in-addr.arpa This will result in all reverse zones x-y being delegated (upon success), and x-y domain objects being entered in the database. This option will only be possible for corresponding address space which is occupied by a single inetnum object, to reduce the possibilty of misuse/mistakes. Thanks in advance for any input, Lee Wilmot RIPE NCC From alfredo at nexus.org Tue Sep 14 14:51:45 1999 From: alfredo at nexus.org (Alfredo E. Cotroneo) Date: Tue, 14 Sep 1999 14:51:45 +0200 Subject: RIPE handles delay Message-ID: <4.2.0.58.19990914143731.00a1cd60@mail2.nexus.org> Hi, For the last ten days or so we have noticed that replies for a new contact handle to auto-dbm at ripe.net is taking much more than the usual 2-5 minutes as it used to be in the good old times ;-) Although we request only a few handles per month, a relly from RIPE takes now 10-20 hrs or more in some cases, regardless of the time (day or night, week or week-end) when the request is sent out. I have heard of some kind of explanation related to SW/HW upgrades at RIPE and huge requests of handles being queued by some provider a few days ago, however, can someone at RIPE tell if the situation is going to be solved soon and when ? Unfortunately this is causing at least an additional 1+ day delay in the registration of new domains at the Italian NIC, as IT-NIC requests that a handle exists for each contact before the domain registration form is submitted. Of course any comment from IT-NIC on how they can modify their internal procedures to minimize such delays (i.e. by IT-NIC requesting a new handle to RIPE directly) is also welcome. Thanks. -- Alfredo E. Cotroneo PO Box 11028, 20110, Milano, Italy Phone: +39-335-214-614 (try first) / +39-02-266-6971 email: alfredo at nexus.org fax: +39-02-706-38151 From joao at ripe.net Tue Sep 14 15:03:42 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Tue, 14 Sep 1999 15:03:42 +0200 (CEST) Subject: RIPE handles delay In-Reply-To: <4.2.0.58.19990914143731.00a1cd60@mail2.nexus.org> Message-ID: Hi, we have been having a lot of trouble lately here at the NCC. Apart from some HW problems, that are now fixed, we are still receiving updates at a rate and in a combination that the DB can't presently handle in a fast way. All messages sent are queued and processed in turn. We are working on optimizing the software to handle these updates faster. Also we are going to deploy a queue control system to ensure a prompt response to updates more directly related to the RIPE DB intended purpose while still ensuring that others not so directly related will get processed. Currently we are processing the mails that were causing the problems with a lower priority to ensure an adequate service to the community. I will be presenting an in depth report on the situation next week at the RIPE meeting (DB wg). Shall the TLD wg also be interested in the some sort of presentation or overview I will be glad to present it. We have been reporting on the situation to this and other RIPE wgs and shall continue to do so. At this moment the situation is such that messages are being processed as in the good old days :-) Best regards, Joao Damas RIPE DB Group Manager RIPE NCC On Tue, 14 Sep 1999, Alfredo E. Cotroneo wrote: > Hi, > > For the last ten days or so we have noticed that replies for a new contact > handle to auto-dbm at ripe.net is taking much more than the usual 2-5 minutes > as it used to be in the good old times ;-) Although we request only a few > handles per month, a relly from RIPE takes now 10-20 hrs or more in some > cases, regardless of the time (day or night, week or week-end) when the > request is sent out. > > I have heard of some kind of explanation related to SW/HW upgrades at RIPE > and huge requests of handles being queued by some provider a few days ago, > however, can someone at RIPE tell if the situation is going to be solved > soon and when ? > > Unfortunately this is causing at least an additional 1+ day delay in the > registration of new domains at the Italian NIC, as IT-NIC requests that a > handle exists for each contact before the domain registration form is > submitted. Of course any comment from IT-NIC on how they can modify their > internal procedures to minimize such delays (i.e. by IT-NIC requesting a > new handle to RIPE directly) is also welcome. > > Thanks. > > > -- > Alfredo E. Cotroneo PO Box 11028, 20110, Milano, Italy > Phone: +39-335-214-614 (try first) / +39-02-266-6971 > email: alfredo at nexus.org fax: +39-02-706-38151 > > From leigh at insnet.net Tue Sep 14 15:53:17 1999 From: leigh at insnet.net (Leigh Porter) Date: Tue, 14 Sep 1999 14:53:17 +0100 Subject: RIPE handles delay References: <4.2.0.58.19990914143731.00a1cd60@mail2.nexus.org> Message-ID: <37DE534D.AD25284@insnet.net> "Alfredo E. Cotroneo" wrote: > Hi, > > For the last ten days or so we have noticed that replies for a new contact > handle to auto-dbm at ripe.net is taking much more than the usual 2-5 minutes > as it used to be in the good old times ;-) Although we request only a few > handles per month, a relly from RIPE takes now 10-20 hrs or more in some > cases, regardless of the time (day or night, week or week-end) when the > request is sent out. I also experianced longer-than-usual delays in submitting new objects of various types. -- Leigh From ruokonen at mail.teliafi.net Tue Sep 14 16:18:42 1999 From: ruokonen at mail.teliafi.net (Vesa Ruokonen) Date: Tue, 14 Sep 1999 17:18:42 +0300 (EEST) Subject: RIPE handles delay In-Reply-To: from "Joao Luis Silva Damas" at Sep 14, 99 03:03:42 pm Message-ID: <199909141418.RAA09646@mail.teliafi.net> > From: Joao Luis Silva Damas > Apart from some HW problems, that are now fixed, we are still receiving > updates at a rate and in a combination that the DB can't presently handle ... > All messages sent are queued and processed in turn. This together with recent comments about domain objects in RIPE DB has started to worry me too. Our operation depends on RIPE's ability to register IP address assignments. Based on recent statistics it seems like we are suffering from reasons NOT related to addresses at all. http://www.ripe.net/meetings/ripe/ripe-33/pres/db-update/sld008.html > Also we are going to deploy a queue control system to ensure a prompt > response to updates more directly related to the RIPE DB intended purpose > while still ensuring that others not so directly related will get > processed. This tactful comment probably means a turn to the right direction. But I wish it was said loudly and clearly, maybe even as a complete change in DB usage policy. We pay for address registration services, please take the domain (non-rev-dns-related) objects elsewhere. > We have been reporting on the situation to this and other RIPE wgs and Would it be possible to separate reverse DNS related domain objects from the big total of domain objects in RIPE DB report? > > handles per month, a relly from RIPE takes now 10-20 hrs or more in some > > cases, regardless of the time (day or night, week or week-end) when the ... > > Unfortunately this is causing at least an additional 1+ day delay in the > > registration of new domains at the Italian NIC, as IT-NIC requests that a > > handle exists for each contact before the domain registration form is -- Vesa Ruokonen - Internet Services, Telia Finland From woeber at cc.univie.ac.at Wed Sep 15 13:40:49 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 15 Sep 1999 13:40:49 MET-DST Subject: RIPE handles delay Message-ID: <009DE308.626BE8E2.1@cc.univie.ac.at> Dear Vesa! => response to updates more directly related to the RIPE DB intended purpose => while still ensuring that others not so directly related will get => processed. = =This tactful comment probably means a turn to the right direction. =But I wish it was said loudly and clearly, maybe even as a complete =change in DB usage policy. We pay for address registration services, =please take the domain (non-rev-dns-related) objects elsewhere. To statr with I'd like to assure you that we are (sometimes painfully) aware of the issue(s) you'r point fingers at. Quite a bit of things have been achived already to allow us to move in the right direction in due time: Technically: the NCC already has implemented the WG-approved refer: attribute to allow referrals to "remote" autoritative servers for domain: objects. This is already being use by (a few) TLD registries, others are working towards that end. Logistics: CENTR was formed within the framework of the RIPE NCC quite a while ago to deal with TLD activites (or DNS issues in general). CENTR has meanwhile been incoprorated as a legal entity of it's own, and moved office to the UK. RIPE discussions: we have already (recently) started to discuss (both informally amongst the WG chairs, as well as within the various WG meetings) the issues with co-locating different registries within a single database environment (i.e. the IP-Registry, Routing-Registry, DNS-Registry). These issues are (amongst others) . authority for data and responsibility for data quality . access patterns ie.e. (updates vs. consumers, privacy, copyright) . providing operational resources As an aside, you are correct in stating that the NCC's main objective rests with the IP-Address, including reverseDNS and Routing Registry activites. But, at the same time, the creation of and support for CENTR and the DNS-related activites was agreed by the RIPE community and there was (still is?) a contract in place between the NCC and CENTR to have CENTR contribute equitably to the NCC's operational costs. I'm looking forward to continue this thread of discussion (within the DB-WG framework or somewhere else) as well as to corrections and amendments by the RIPE community and WG chairs, and/or from NCC staff. Best regards, and thanks for bringing this up (again) for consideration! Wilfried Woeber DataBase WG chair. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________ From samc at UU.NET Thu Sep 16 17:00:41 1999 From: samc at UU.NET (Sam Critchley) Date: Thu, 16 Sep 1999 17:00:41 +0200 (MET DST) Subject: RIPE Hostmasters visiting LIRs Message-ID: Hello, Recently a few colleagues and I have been talking about the way we interact with the people in the RIPE NCC when dealing with customer assignments (and some other matters). One of the things we thought could be beneficial is if Hostmasters had more experience of the kind of issues we in the ISP community face on a day-to-day basis. We thought it might be a good idea if some of the Hostmasters were able to visit an ISP and see how they work, meet the people they deal with and perhaps work alongside them for a period of time. With this in mind we first thought of inviting individual people to come and visit us, or perhaps addressing the NCC asking if this were possible. However, we soon realised that this would have neutrality implications, and that it could be damaging both to the RIPE NCC reputation and to ours, and that for this reason it was unlikely to be accepted by them. In the last week or so I've been in touch with people in several other LIRs here in the Netherlands on an informal basis, and we all seem to agree that, were visits made to multiple registries by multiple members of the staff of the NCC, then this would have fewer neutrality implications. It seems like there are several registries who would be happy to offer help with this if it has a potential benefit for all LIRs. I realise that this has been discussed in various forums before, but feel personally that we are now able to remove many of the barriers which might prevent it happening. Do other LIRs feel that this could be beneficial to everyone in the RIPE community? What do RIPE NCC staff themselves think about it? What kind of restraints do people feel should be placed upon any such scheme? How should it be organised? Should it be discussed at a meeting? Looking forward to any comments on the lir-wg mailing-list, Best wishes, Sam From amar at telia.net Thu Sep 16 17:20:08 1999 From: amar at telia.net (Amar) Date: Thu, 16 Sep 1999 17:20:08 +0200 Subject: RIPE Hostmasters visiting LIRs References: Message-ID: <37E10AA8.1D627C0B@telia.net> Sam Critchley wrote: > Do other LIRs feel that this could be beneficial to everyone in the RIPE > community? What do RIPE NCC staff themselves think about it? What kind of > restraints do people feel should be placed upon any such scheme? How > should it be organised? Should it be discussed at a meeting? > > Looking forward to any comments on the lir-wg mailing-list, I think this is a extremly good idea. At the moment there has come a wast number of new LIR:s within the RIPE area. This suggestion should include both old LIR:s as the new one. It would benefit the way we work within the membership and build up a better understanding how everyone work as a LIR and as company/organization wich goal is to satisfy it's customers in the best possible way. I suggest that this should be a point on a upcoming meeting. >From there we should be able to create the way this should be done. Regards /Amar Andersson Telia Net From barak at netvision.net.il Thu Sep 16 18:21:25 1999 From: barak at netvision.net.il (Barak Engel) Date: Thu, 16 Sep 1999 18:21:25 +0200 Subject: RIPE Hostmasters visiting LIRs In-Reply-To: <37E10AA8.1D627C0B@telia.net> Message-ID: <000101bf005f$85e60280$de64cbc7@shitty.network.org.il> > I think this is a extremly good idea. I second that - it is an excellent idea! Sincerely, \'"'/ Barak Engel ( o o ) Netvision ---------------------ooOO-^-oOOo--------------------------- barak at netvision.net.il Network Expert BE-RIPE BE174 Phone/Fax: +972 48 560600#666/551132 Cell: +972 50 469 341 ----------------------------------------------------------- From amar at telia.net Thu Sep 16 17:58:26 1999 From: amar at telia.net (Amar) Date: Thu, 16 Sep 1999 17:58:26 +0200 Subject: [gigabell-technik] Re: RIPE Hostmasters visiting LIRs References: <37E10AA8.1D627C0B@telia.net> <19990916173448.A21648@darwin.gigabell.net> Message-ID: <37E113A2.D37D190C@telia.net> Jan Ahrent Czmok wrote: > what should be covered are the costs ? 50 / 50 for lir / ripe or > what else. You bring up an issue that we have to solve. And that is the finance of this. I think that most of the interested bigger LIR:s would be able to finance this on a, let's say, 50/50 basis. > i mean for bigger lirs it shall be no problem, but the smaller ones > may not have enough money to pay the hotel or travel costs for the > hostmaster. It is up to all the LIR:s that are interested to have a visit from a hostmaster to take an active roll in this suggestion. Noone should be forced ;-) But speaking for an ISP, i should evaluate the cost and see what i should gain from a visit. And i know it should be worth it. There is so many issues you would like to discuss with the RIPE staff, eye to eye. The meetings are a good forum, but sometimes you would like to show how that actual sitiuation is within your country or area. (One thing. This should not be a way for an big ISP to get a chance to do "lobbying" on his own turf. I am not afraid of this. But i would only like to state my opinion of this.) But those LIR:s that feel that they can not affford this is the main factor. I do not know how hard it should strain RIPE:s budget if we should do this: Eg: Size LIR/RIPE --------------------------------------------------- Large : 50/50 % Medium : 35/65 % Small : 20/80 % ( These numbers i just a suggestion ) The big LIR:s would "support" the smaller ones. But i am willing to do this as long that i can see that this will benefit the community as a whole. How much expences would RIPE:s finances be able to take without rising the memberfee for the LIR:s? If this would be a result of this, then i am sorry to say, would not get a consensus on a meeting. Regards /Amar Telia Net From netmaster at space.net Thu Sep 16 17:09:19 1999 From: netmaster at space.net (Gert Doering, Netmaster) Date: Thu, 16 Sep 1999 17:09:19 +0200 Subject: RIPE Hostmasters visiting LIRs In-Reply-To: ; from Sam Critchley on Thu, Sep 16, 1999 at 05:00:41PM +0200 References: Message-ID: <19990916170919.T13951@Space.Net> Hi, On Thu, Sep 16, 1999 at 05:00:41PM +0200, Sam Critchley wrote: > Do other LIRs feel that this could be beneficial to everyone in the RIPE > community? What do RIPE NCC staff themselves think about it? What kind of > restraints do people feel should be placed upon any such scheme? How > should it be organised? Should it be discussed at a meeting? I think it's a very good idea. Sometimes it is very frustrating to try to explain to RIPE hostmasters why something should be done in a certain way (because business demands it), and I imagine that it could be very helpful for them to see the "daily problems" of an ISP with their own eyes. Let's discuss it at the LIR-WG. Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From j.czmok at gigabell.net Thu Sep 16 17:34:48 1999 From: j.czmok at gigabell.net (Jan Ahrent Czmok) Date: Thu, 16 Sep 1999 17:34:48 +0200 Subject: [gigabell-technik] Re: RIPE Hostmasters visiting LIRs In-Reply-To: <37E10AA8.1D627C0B@telia.net> References: <37E10AA8.1D627C0B@telia.net> Message-ID: <19990916173448.A21648@darwin.gigabell.net> * Amar (amar at telia.net) [990916 17:19]: > > > Sam Critchley wrote: > > > Do other LIRs feel that this could be beneficial to everyone in the RIPE > > community? What do RIPE NCC staff themselves think about it? What kind of > > restraints do people feel should be placed upon any such scheme? How > > should it be organised? Should it be discussed at a meeting? > > > > Looking forward to any comments on the lir-wg mailing-list, > > I think this is a extremly good idea. At the moment there > has come a wast number of new LIR:s within the RIPE area. > This suggestion should include both old LIR:s as the new > one. It would benefit the way we work within the membership > and build up a better understanding how everyone work as > a LIR and as company/organization wich goal is to satisfy > it's customers in the best possible way. > > I suggest that this should be a point on a upcoming meeting. > >From there we should be able to create the way this should > be done. > Hi Sam! Hi Amar! Hi all! i also find it a good idea that Hostmasters shall visiting LIRs. It helps both sides, as the hostmasters see the lir view and problems and also the lir's can learn from the ripe. what should be covered are the costs ? 50 / 50 for lir / ripe or what else. i mean for bigger lirs it shall be no problem, but the smaller ones may not have enough money to pay the hotel or travel costs for the hostmaster. Jan From j.czmok at gigabell.net Thu Sep 16 18:10:43 1999 From: j.czmok at gigabell.net (Jan Ahrent Czmok) Date: Thu, 16 Sep 1999 18:10:43 +0200 Subject: [gigabell-technik] Re: RIPE Hostmasters visiting LIRs In-Reply-To: <37E113A2.D37D190C@telia.net> References: <37E10AA8.1D627C0B@telia.net> <19990916173448.A21648@darwin.gigabell.net> <37E113A2.D37D190C@telia.net> Message-ID: <19990916181043.A22089@darwin.gigabell.net> * Amar (amar at telia.net) [990916 17:58]: > > > Jan Ahrent Czmok wrote: > > > what should be covered are the costs ? 50 / 50 for lir / ripe or > > what else. > > You bring up an issue that we have to solve. And that is the > finance of this. I think that most of the interested bigger > LIR:s would be able to finance this on a, let's say, 50/50 basis. I agree completely. > (One thing. This should not be a way for an big ISP to get > a chance to do "lobbying" on his own turf. I am not afraid > of this. But i would only like to state my opinion of this.) > I think the hostmasters from ripe are very -straight- and i never see any lobbying.. > But those LIR:s that feel that they can not affford this is > the main factor. I do not know how hard it should strain RIPE:s > budget if we should do this: > > Eg: > > Size LIR/RIPE > --------------------------------------------------- > Large : 50/50 % > Medium : 35/65 % > Small : 20/80 % > I also have this idea in mind, but on the large and super national i would say 80/20 and medium 50/50 might be a better idea, as the most are in medium range and the bigger ones (such as we) shall support also the smaller ones. > ( These numbers i just a suggestion ) My numbers also.. > > The big LIR:s would "support" the smaller ones. But i am > willing to do this as long that i can see that this will > benefit the community as a whole. > Right. I think it could help the community as a whole and to fasten up many problems currently arising (e.g. long waiting queues) > How much expences would RIPE:s finances be able to take > without rising the memberfee for the LIR:s? > > If this would be a result of this, then i am sorry to > say, would not get a consensus on a meeting. > > Regards > > /Amar > > Telia Net > Jan From phk at critter.freebsd.dk Thu Sep 16 18:16:24 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 16 Sep 1999 18:16:24 +0200 Subject: [gigabell-technik] Re: RIPE Hostmasters visiting LIRs In-Reply-To: Your message of "Thu, 16 Sep 1999 17:58:26 +0200." <37E113A2.D37D190C@telia.net> Message-ID: <1663.937498584@critter.freebsd.dk> In message <37E113A2.D37D190C at telia.net>, Amar writes: >It is up to all the LIR:s that are interested to have a visit >from a hostmaster to take an active roll in this suggestion. I actually disagree. It is rather obvious from the various consistency reports that some LIR's are more in need of a visit than others... -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From leo.vegoda at level3.com Thu Sep 16 18:29:00 1999 From: leo.vegoda at level3.com (Leo Vegoda) Date: Thu, 16 Sep 1999 17:29 +0100 (BST) Subject: RIPE Hostmasters visiting LIRs In-Reply-To: Message-ID: On Thu, 16 Sep 1999 17:00:41 +0200 (MET DST), in , samc at UU.NET (Sam Critchley) wrote: > Recently a few colleagues and I have been talking about the way we > interact with the people in the RIPE NCC when dealing with customer > assignments (and some other matters). One of the things we thought > could > be beneficial is if Hostmasters had more experience of the kind of > issues > we in the ISP community face on a day-to-day basis. [...] > Do other LIRs feel that this could be beneficial to everyone in the > RIPE > community? What do RIPE NCC staff themselves think about it? What > kind of > restraints do people feel should be placed upon any such scheme? How > should it be organised? Should it be discussed at a meeting? I feel this could only benefit LIRs and RIPE NCC. It would be nice to see local visits on a fairly regular basis so we all get to know the work the other half is doing. Regards, -- leo vegoda level (3) communications, london, uk PGP Key ID: 0xCC00E1AA PGP Fingerprint: 8B72 E9C8 AA9D D615 EE6E EA45 370C 0801 CC00 E1AA From woeber at cc.univie.ac.at Thu Sep 16 18:35:35 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 16 Sep 1999 18:35:35 MET-DST Subject: New RIPE NCC reverse delegation procedure Message-ID: <009DE3FA.BA85AFF2.19@cc.univie.ac.at> Hi Lee! >---> It will be mandatory that a registry ID is included in all > requests for reverse delegation, as is currently the case for requests > to . We will require that all requests come from > an LIR receiving service (i.e. paying for services), and > that the requester is one of the registry contact people/ > contact role-account. > > + resource efficient. We only deal with people who are experienced > in the reverse delegation procedure and aware of the RIPE NCC > and RIPE DB procedures in general -> minimal time explaining > procedure and general registry system concepts. Currently > we spend much time dealing with inexperienced end-users who will > set up only one or a few zones and therefore do not spend the > time to become knowledgable concerning the procedures. > > + fair to paying members. We do not spend time guiding people who > do not contribute to the costs. My 1st reaction: this requires a bit more thinking - the people (individuals) running the address assignment business are not necessarily the same persons which deal with DNS. Maybe they should, or the DNs folks should be added to the LIR contacts just for that purpose, but this requires a reality check and procedure review, I suppose? - between the lines, also, this states that users of address space obtained from LIRs which have been closed for one reason or another cannot get RevDNS services set up and/or changed - unless you provide some loopholes. I don't have an opinion about good/bad, it's just an observation. > - for requests involving large numbers of zones lots of > domain objects will be needed. We'll lessen this by > making possible a shorthand domain object like this: > > domain: x-y.w.z.in-addr.arpa > > This will result in all reverse zones x-y being delegated > (upon success), and x-y domain objects being entered in > the database. This option will only be possible for > corresponding address space which is occupied by a single > inetnum object, to reduce the possibilty of misuse/mistakes. Uhh, ohh, this might be a non-starter (the single inetnum object, not the idea in itself). I like the intent, but again this requires a review of other procedures (or customs) in some places. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________ From AbbeyS at alphabusiness.co.uk Thu Sep 16 18:38:12 1999 From: AbbeyS at alphabusiness.co.uk (Abbey Shasore) Date: Thu, 16 Sep 1999 17:38:12 +0100 Subject: RIPE Hostmasters visiting LIRs Message-ID: Hi Chaps, Now come along...it is *great* idea for RIPE to get to know what we do and how we do it. However, I am far from convinced that this is the way to do it! Of course there will be lobbying, of course there will be LIRs that will make an impression, and of course there is a real risk of compromising RIPE neutrality. Also, how would this be funded? Ok for the big(ger) guys, but how about us less big guys? Personally, I would like to have you guys get to know us better and so on - but I am not sure we can afford it! More thought required me thinks... Abbey Shasore A4U Net - Alpha Internet -----Original Message----- From: Sam Critchley [mailto:samc at UU.NET] Sent: 16 September 1999 16:01 To: lir-wg at ripe.net Subject: RIPE Hostmasters visiting LIRs Hello, Recently a few colleagues and I have been talking about the way we interact with the people in the RIPE NCC when dealing with customer assignments (and some other matters). One of the things we thought could be beneficial is if Hostmasters had more experience of the kind of issues we in the ISP community face on a day-to-day basis. We thought it might be a good idea if some of the Hostmasters were able to visit an ISP and see how they work, meet the people they deal with and perhaps work alongside them for a period of time. With this in mind we first thought of inviting individual people to come and visit us, or perhaps addressing the NCC asking if this were possible. However, we soon realised that this would have neutrality implications, and that it could be damaging both to the RIPE NCC reputation and to ours, and that for this reason it was unlikely to be accepted by them. In the last week or so I've been in touch with people in several other LIRs here in the Netherlands on an informal basis, and we all seem to agree that, were visits made to multiple registries by multiple members of the staff of the NCC, then this would have fewer neutrality implications. It seems like there are several registries who would be happy to offer help with this if it has a potential benefit for all LIRs. I realise that this has been discussed in various forums before, but feel personally that we are now able to remove many of the barriers which might prevent it happening. Do other LIRs feel that this could be beneficial to everyone in the RIPE community? What do RIPE NCC staff themselves think about it? What kind of restraints do people feel should be placed upon any such scheme? How should it be organised? Should it be discussed at a meeting? Looking forward to any comments on the lir-wg mailing-list, Best wishes, Sam From amar at telia.net Thu Sep 16 18:37:50 1999 From: amar at telia.net (Amar) Date: Thu, 16 Sep 1999 18:37:50 +0200 Subject: [gigabell-technik] Re: RIPE Hostmasters visiting LIRs References: <1663.937498584@critter.freebsd.dk> Message-ID: <37E11CDE.62530B5B@telia.net> Poul-Henning Kamp skrev: > > In message <37E113A2.D37D190C at telia.net>, Amar writes: > I actually disagree. It is rather obvious from the various > consistency reports that some LIR's are more in need of a > visit than others... The numbers suggested have the pontential to create a sitiuation where the hostmasters would be able to visit those LIR:s that have a problem with consistency. But you bring up a point here. We have to ask us what the actual outcome of a visit should be: - Is it a visit from RIPE to solve the consistency? or - Is it a way to make the members and RIPE work more closely togheter, and by that bring up a better understanding between the LIR:s and RIPE? And by that also be able to solve the problems that maybe have led to the sitiuation where we today have consistency as a result? I see it as a way to get in contact with the "hard-to-reach" LIR:s that actually do a lot of registrations today. But they can of some reason not be able/afford to attend a RIPE meeting. Both of the actual cost and the loss of workpower as a person attending a meeting would result in. Regards /Amar Telia Net From phk at critter.freebsd.dk Thu Sep 16 18:48:12 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 16 Sep 1999 18:48:12 +0200 Subject: [gigabell-technik] Re: RIPE Hostmasters visiting LIRs In-Reply-To: Your message of "Thu, 16 Sep 1999 18:37:50 +0200." <37E11CDE.62530B5B@telia.net> Message-ID: <1824.937500492@critter.freebsd.dk> In message <37E11CDE.62530B5B at telia.net>, Amar writes: >Poul-Henning Kamp skrev: >> >> In message <37E113A2.D37D190C at telia.net>, Amar writes: > >> I actually disagree. It is rather obvious from the various >> consistency reports that some LIR's are more in need of a >> visit than others... > >The numbers suggested have the pontential to create a >sitiuation where the hostmasters would be able to visit >those LIR:s that have a problem with consistency. > >But you bring up a point here. Well, my point was not quite one of those you present, it was more along the lines: Wouldn't it be a more profitable use of RIPEs funds to visit the provably needy LIRs ? even at a 50/50 funding split, this is going to drain a lot of resources from RIPE, so we might as well try to get some tangible benefits from it. Of course we could also try to add a new policy which says that if a LIR after three warnings from RIPE havn't gotten their act together they get a RIPE visit, and the full bill for that visit (the "RIPE-MIB": RIPE-Men In Black :-) -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From woeber at cc.univie.ac.at Thu Sep 16 19:58:58 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 16 Sep 1999 19:58:58 MET-DST Subject: RIPE Hostmasters visiting LIRs Message-ID: <009DE406.60B9E6B2.2@cc.univie.ac.at> >Of course we could also try to add a new policy which says that >if a LIR after three warnings from RIPE havn't gotten their >act together they get a RIPE visit, and the full bill for >that visit (the "RIPE-MIB": RIPE-Men In Black :-) Yeah, you fail 3 times to answer a phone call within 30 seconds on Sunday afternoon, and voila, you've got the tax hounds on your neck :-) :-) :-) Reality check, gentlemen! From my point of view there is milage in persuing this idea, with the boundary condition that the goal of this whole exercise is to improve the mutual understanding and information flow between the LIRs and RIR's representatives (i mean: strategically, not for a *particular* LIR or particular HM (or a very small set of both)!). Paying visits to each other is maybe *one* way of achieving that goal. There might be others, quite as well. Let's hear the NCC's point of view on this general idea. Then let's try to sort out the particular goals, boundary conditions, and - eventually - the funding issues. How's that sound? My 2 Groschen (0.02 ATS = 0.00145346 EUR) for X-NCC-RegID: at.aconet Wilfried. From amar at telia.net Thu Sep 16 20:53:33 1999 From: amar at telia.net (Amar) Date: Thu, 16 Sep 1999 20:53:33 +0200 Subject: [gigabell-technik] Re: RIPE Hostmasters visiting LIRs References: <1824.937500492@critter.freebsd.dk> Message-ID: <37E13CAD.50A05793@telia.net> Poul-Henning Kamp wrote: > Well, my point was not quite one of those you present, it was > more along the lines: > > Wouldn't it be a more profitable use of RIPEs funds to visit the > provably needy LIRs ? If this is a way to help "needy" LIRs in the best way i am note sure about. But it could be a part of a bigger activity from RIPE. But there will allways be some LIRs that doesn't want to finance this type of activities with LIRs that need help from RIPE. I this suggestion from RIPE more a way from RIPE to get to know the LIRs and the sitiuation that they actually face every day. I am sure that there is some LIRs that need help, but i am not sure if this is the right way to solve this problem. > even at a 50/50 funding split, this is going to drain a lot of > resources from RIPE, so we might as well try to get some > tangible benefits from it. True. Thats why we need some figures of how the present finance of RIPE will be able to handle the costs. This input can only be give by RIPE itself. > Of course we could also try to add a new policy which says that > if a LIR after three warnings from RIPE havn't gotten their > act together they get a RIPE visit, and the full bill for > that visit (the "RIPE-MIB": RIPE-Men In Black :-) 1984 ;-) I do not think that RIPE need to do this. And it is allready stated in some sentence in RIPE-170 section 4.4. /Amar From jhma at EU.net Thu Sep 16 21:26:26 1999 From: jhma at EU.net (James Aldridge) Date: Thu, 16 Sep 1999 21:26:26 +0200 Subject: RIPE 34 LIR WG Draft Agenda In-Reply-To: Your message of "Fri, 10 Sep 1999 17:28:16 +0200." <199909101528.RAA22097@aegir.EU.net> Message-ID: <199909161926.VAA14169@aegir.EU.net> On 10th September I wrote: > I think that it could be useful to start some discussion on whether an > additional value for the inetnum "status" field would be useful. > > What I would like to see, and which would be useful for a large registry such > as "eu.eunet" which I coordinate, is somethig like "LIR-ALLOCATED" which could > be used to tag a block of addresses as being sub-allocated by a local registry > for some purpose (e.g. identifying a block as being used for assignments by a > particular local operation, PoP, etc.) but which wouldn't cause all the real > assignments under that block to be flagged as overlaps or duplicates by the > NCC's registry auditing processes. I've seen no comments on this so maybe I need to explain a bit more why I think that a LIR-ALLOCATED value in the status field would be useful: ---------- "Status: LIR-ALLOCATED" Considered Useful ========================================= For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher-lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s). An example: inetnum: 10.1.0.0 - 10.1.255.255 netname: ZZ-REGY-19990916 descr: REGY Allocation country: EU ... status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT ... inetnum: 10.1.0.0 - 10.1.31.255 netname: ZZZ-REGY-ALLOC descr: REGY - Local assignments in ZZZ country: ZZ ... status: LIR-ALLOCATED PA mnt-by: REGY-MNT mnt-lower: REGY-ZZZ-MNT ... inetnum: 10.1.0.0 - 10.1.0.63 netname: CUSTOMER-XYZ-NET descr: Customer XYZ in ZZZ country: ZZ ... status: ASSIGNED PA mnt-by: REGY-ZZZ-MNT ... ---------- Any comments? James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 625 5913 - ----- 24hr emergency number: +31 20 421 0865 From BERI at etf.bg.ac.yu Thu Sep 16 22:44:00 1999 From: BERI at etf.bg.ac.yu (Berislav Todorovic) Date: Thu, 16 Sep 1999 21:44 +0100 Subject: COMMENT: "status: LIR-ALLOCATED" Message-ID: <15155D475400187D@etf.bg.ac.yu> Hello, I'd back the proposal for the "status: LIR-ALLOCATED" attribute, with the possibility to restrict the use of that status to the international LIRs only (or allocations higher or equal to /16) - to avoid possible problems and abuses from small LIRs - intentional or unintentional. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI at etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3218-350 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' -------------------------------------------------------------------- From j.czmok at gigabell.net Thu Sep 16 21:38:52 1999 From: j.czmok at gigabell.net (Jan Ahrent Czmok) Date: Thu, 16 Sep 1999 21:38:52 +0200 Subject: [gigabell-technik] Re: RIPE 34 LIR WG Draft Agenda In-Reply-To: <199909161926.VAA14169@aegir.EU.net> References: <199909101528.RAA22097@aegir.EU.net> <199909161926.VAA14169@aegir.EU.net> Message-ID: <19990916213852.A23343@darwin.gigabell.net> > Any comments? > > James Only one short: Would be nice if it will be implemented as fast as possible. It might help us in some situation, and other companies are also benefitting of this proposal. Jan From hank at att.net.il Thu Sep 16 21:52:11 1999 From: hank at att.net.il (Hank Nussbacher) Date: Thu, 16 Sep 1999 21:52:11 +0200 (IST) Subject: RIPE Hostmasters visiting LIRs In-Reply-To: Message-ID: On Thu, 16 Sep 1999, Abbey Shasore wrote: Please read ripe-154: RIPE NCC Local IR Training Policies The proper thing is for new LIRs to attend these workshops: http://www.ripe.net/cgi-bin/courselist.pl.cgi What should be required is that part of these workshops have time allocated for the LIRs to introduce themselves to the hostmasters and explain anything specific that they do differently. The LIR list at: http://www.ripe.net/lir/registries/indices/data/index.html is 208K in size! How many LIRs are there - 1000? How long would it take for the RIPE hostmasters to visit ALL of them? The logistics of having the hostmasters taking a traveling tour of Europe, Africa and the Middle East just doesn't make any sense. This should be handled during the training course that all LIRs should have to attend. -Hank > Hi Chaps, > > Now come along...it is *great* idea for RIPE to get to know what we do and > how we do it. However, I am far from convinced that this is the way to do > it! > > Of course there will be lobbying, of course there will be LIRs that will > make an impression, and of course there is a real risk of compromising RIPE > neutrality. > > Also, how would this be funded? Ok for the big(ger) guys, but how about us > less big guys? Personally, I would like to have you guys get to know us > better and so on - but I am not sure we can afford it! > > More thought required me thinks... > > Abbey Shasore > A4U Net - Alpha Internet > > -----Original Message----- > From: Sam Critchley [mailto:samc at UU.NET] > Sent: 16 September 1999 16:01 > To: lir-wg at ripe.net > Subject: RIPE Hostmasters visiting LIRs > > > > > Hello, > > Recently a few colleagues and I have been talking about the way we > interact with the people in the RIPE NCC when dealing with customer > assignments (and some other matters). One of the things we thought could > bebeneficial is if Hostmasters had more experience of the kind of issues > we in the ISP community face on a day-to-day basis. > > We thought it might be a good idea if some of the Hostmasters were able to > visit an ISP and see how they work, meet the peoplethey deal with and > perhaps work alongside them for a period of time. With this in mind we > first thought of inviting individual people to come and visit us, or > perhaps addressing the NCC asking if this were possible. However, we soon > realised that this would have neutrality implications, and that it could > be damaging both to the RIPE NCC reputation and to ours, and that for > this reason it was unlikely to be accepted by them. > > In the last week or so I've been in touch with people in several other > LIRs here in the Netherlands on an informal basis, and we all seem to > agree that, were visits made to multiple registries by multiple members of > the staff of the NCC, then this would have fewer neutrality implications. > It seems like there are several registries who would be happy to offer > help with this if it has a potential benefit for all LIRs. I realise that > this has been discussed in various forums before, but feel personally that > we are now able to remove many of the barriers which might prevent it > happening. > > Do other LIRs feel that this could be beneficial to everyone in the RIPE > community? What do RIPE NCC staff themselves think about it? What kind of > restraints do people feel should be placed upon any such scheme? How > should it be organised? Should it be discussed at a meeting? > > > Looking forward to any comments on the lir-wg mailing-list, > > > Best wishes, > > > > Sam > > > > > > > Hank Nussbacher From phk at critter.freebsd.dk Fri Sep 17 00:40:27 1999 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Fri, 17 Sep 1999 00:40:27 +0200 Subject: RIPE 34 LIR WG Draft Agenda In-Reply-To: Your message of "Thu, 16 Sep 1999 21:26:26 +0200." <199909161926.VAA14169@aegir.EU.net> Message-ID: <2753.937521627@critter.freebsd.dk> > "Status: LIR-ALLOCATED" Considered Useful > ========================================= Sounds useful, as long as it's only effect is adding nodes to the maintainer tree. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! From amar at telia.net Fri Sep 17 10:35:44 1999 From: amar at telia.net (Amar) Date: Fri, 17 Sep 1999 10:35:44 +0200 Subject: RIPE Hostmasters visiting LIRs References: Message-ID: <37E1FD60.E624709F@telia.net> Hank Nussbacher skrev: > > On Thu, 16 Sep 1999, Abbey Shasore wrote: > > Please read ripe-154: > RIPE NCC Local IR Training Policies > > The proper thing is for new LIRs to attend these workshops: > http://www.ripe.net/cgi-bin/courselist.pl.cgi > > What should be required is that part of these workshops > have time allocated for the LIRs to introduce themselves > to the hostmasters and explain anything specific that > they do differently. I fully agree with you on this. But i see the suggestion more like a way for RIPE to get an understanding of the actual day-to-day work a LIR has. And it could be hard to explain during a meeting or a training course. I visit would show this more clearly. > The LIR list at: > http://www.ripe.net/lir/registries/indices/data/index.html > is 208K in size! How many LIRs are there - 1000? How > long would it take for the RIPE hostmasters to visit ALL > of them? This list has formly exploded in the last month. But the suggestion , as i saw it, is not based on that RIPE should visit everyone on this list. > The logistics of having the hostmasters taking a traveling > tour of Europe, Africa and the Middle East just doesn't > make any sense. This should be handled during the training > course that all LIRs should have to attend. This suggestion could be based on the LIRs that are willing to share the cost for RIPE to perform a visit to them. It would not be forced on anyone. Just give the chance for those who wish to discuss "LIR problems" on the home turf. But i think that alla the postings point on one important thing: The financing. If we could solve this without increasing the cost for all the LIRs, and do this within RIPEs budget, then this could be supported by many. Regards /Amar Telia Net From jhma at EU.net Fri Sep 17 11:51:43 1999 From: jhma at EU.net (James Aldridge) Date: Fri, 17 Sep 1999 11:51:43 +0200 Subject: RIPE 34 LIR WG Draft Agenda In-Reply-To: Your message of "Fri, 17 Sep 1999 00:40:27 +0200." <2753.937521627@critter.freebsd.dk> Message-ID: <199909170951.LAA16387@aegir.EU.net> Poul-Henning Kamp wrote: > > > "Status: LIR-ALLOCATED" Considered Useful > > ========================================= > > Sounds useful, as long as it's only effect is adding nodes to > the maintainer tree. I see its main use as adding nodes to the maintainer tree and also as a way of documenting use of address space without actually making an assignment. Without specific "ASSIGNED" objects below a "LIR-ALLOCATED" object the address space would still be treated as unassigned as if the new object wasn't there at all. James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 625 5913 - ----- 24hr emergency number: +31 20 421 0865 From inaddr at ripe.net Fri Sep 17 14:15:51 1999 From: inaddr at ripe.net (RIPE NCC IN-ADDR. ARPA Role Account) Date: Fri, 17 Sep 1999 14:15:51 +0200 Subject: New RIPE NCC reverse delegation procedure In-Reply-To: Your message of Thu, 16 Sep 1999 18:35:35 +0700. <009DE3FA.BA85AFF2.19@cc.univie.ac.at> References: <009DE3FA.BA85AFF2.19@cc.univie.ac.at> Message-ID: <199909171215.OAA03246@birch.ripe.net> Good afternoon Wilfried, and thanks for your comments. * >---> It will be mandatory that a registry ID is included in all * > requests for reverse delegation, as is currently the case for * requests * > to . We will require that all requests co * me from * > an LIR receiving service (i.e. paying for services), and * > that the requester is one of the registry contact people/ * > contact role-account. * > * > + resource efficient. We only deal with people who are experie * nced * > in the reverse delegation procedure and aware of the RIPE NC * C * > and RIPE DB procedures in general -> minimal time explaining * > procedure and general registry system concepts. Currently * > we spend much time dealing with inexperienced end-users who * will * > set up only one or a few zones and therefore do not spend th * e * > time to become knowledgable concerning the procedures. * > * > + fair to paying members. We do not spend time guiding people * who * > do not contribute to the costs. * * My 1st reaction: this requires a bit more thinking * * - the people (individuals) running the address assignment business * are not necessarily the same persons which deal with DNS. Maybe they * should, or the DNs folks should be added to the LIR contacts just for * that purpose, but this requires a reality check and procedure review, * I suppose? That's one of the problems. The DNS people often don't know all of the RIPE NCC's P&P's (policies and procedures) when they are not also fulfilling the role of LIR contacts, and we spend quite a while trying to explain everything with lots of mutual frustration. The idea is only to make sure that the same people, whoever it might be, are always the ones making the requests. As you suggest, the DNS people could register as contacts with the RIPE NCC, though perhaps with a slightly different status to the address registration staff, after taking some time to familiarise themselves with the basics of the address registration P&P's. Please note that we already have had a similar (LIR contacts only) setup for AS number requests for quite a while. These are most often for customers of a registry, but the registry makes the actual request. In any case, Mirjam will bring this up in the LIR WG at the RIPE Meeting next week for discussion. * - between the lines, also, this states that users of address space * obtained from LIRs which have been closed for one reason or another * cannot get RevDNS services set up and/or changed - unless you provide * some loopholes. * I don't have an opinion about good/bad, it's just an observation The intention is that end-users whose LIR is not open for whatever reason, would approach another LIR which -was- open. The reason being that in these cases the end-users are otherwise forced to attempt to make requests themselves, a source of frustration and resource burning for both the RIPE NCC and the end-users (do you remember what it's like reading the documentation from scratch ?). In addition, those end-users are receiving services which are being paid for by the open registries. * > - for requests involving large numbers of zones lots of * > domain objects will be needed. We'll lessen this by * > making possible a shorthand domain object like this: * > * > domain: x-y.w.z.in-addr.arpa * > * > This will result in all reverse zones x-y being delegated * > (upon success), and x-y domain objects being entered in * > the database. This option will only be possible for * > corresponding address space which is occupied by a single * > inetnum object, to reduce the possibilty of misuse/mistakes. * * Uhh, ohh, this might be a non-starter (the single inetnum object, * not * the idea in itself). I like the intent, but again this requires a * review * of other procedures (or customs) in some places. Could you explain or give examples of why this would have ramifications for other procedures in place ? Is your concern non-uniformity of notation, in the sense that people would be tempted to also send such shorthand notations to the database software, for example ? Lee From joao at ripe.net Fri Sep 17 16:13:19 1999 From: joao at ripe.net (Joao Luis Silva Damas) Date: Fri, 17 Sep 1999 16:13:19 +0200 Subject: We think it may be interesting... Message-ID: Hi, we have just made available some more operational information online for your convenience. Please see http://www.ripe.net/db/mrtg/whois.html Hope you find it useful. It uses the great mrtg tool. Best regards, Joao Damas RIPE DB Group manager RIPE NCC From hank at att.net.il Sat Sep 18 19:34:02 1999 From: hank at att.net.il (Hank Nussbacher) Date: Sat, 18 Sep 1999 19:34:02 +0200 (IST) Subject: We think it may be interesting... In-Reply-To: Message-ID: On Fri, 17 Sep 1999, Joao Luis Silva Damas wrote: Very nice! Much appreciated. Keep up the excellent work. -Hank > Hi, > > we have just made available some more operational information online for > your convenience. > > Please see http://www.ripe.net/db/mrtg/whois.html > > Hope you find it useful. > > It uses the great mrtg tool. > > Best regards, > Joao Damas > RIPE DB Group manager > RIPE NCC > Hank Nussbacher From woeber at cc.univie.ac.at Mon Sep 20 11:42:41 1999 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 20 Sep 1999 11:42:41 MET-DST Subject: RIPE 34 LIR WG Draft Agenda Message-ID: <009DE6E5.B57FFAE2.10@cc.univie.ac.at> Hi James, => > "Status: LIR-ALLOCATED" Considered Useful => > ========================================= => => Sounds useful, as long as it's only effect is adding nodes to => the maintainer tree. = =I see its main use as adding nodes to the maintainer tree and also as a way of =documenting use of address space without actually making an assignment. I was using a similar approach/technique for a while to document *revoked* address assignments in the RIPE-DB. My reasoning was that the whole block of addresses being ALLOCATED by the RIR to a particular LIR is *by definition* ALLOCATED Px, unless it is ASSIGNED Px at any particular point in time. From my point of view, any address space from that block *not* being explicitely listed in an inetnum: object with status: ASSIGNED Px, has to be treated as ALLOCATED Px. >Without specific "ASSIGNED" objects below a "LIR-ALLOCATED" object the address >space would still be treated as unassigned as if the new object wasn't there >at all. Exactly. However I was forced (and only partly convinced!) by the hostmasters and Paula C. to stop using that approach. If I recall correctly, there is some interaction with (undocumented?) hostmaster tools/procedures getting things mixed up. (I also mangaged to mix up a human hostmaster...) I understand that more up-to-date SW releases even preclude anyone but the NCC staff from using status: ALLOCTED xx. I don't think this is/was the right direction to go, but that's as it stands right now - to my knowledge. Do we want to re-visit that in either LIR or DB later this week? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________ From ripe-dbm at ripe.net Wed Sep 22 11:50:22 1999 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Wed, 22 Sep 1999 11:50:22 +0200 Subject: Top 100 maintainers list Message-ID: <199909220950.LAA28853@birch.ripe.net> Dear list members, This is biweekly report on inconsistent objects in the RIPE whois database. The first 100 maintainers are listed as a table below sorted according to number of their inconsistent objects in the database. The rest of the maintainers which have inconsistent objects can be found at http://www.ripe.net/db/state/mntnerreport1.html You can find further information about the Consistency Project at http://www.ripe.net/db/state/ Regards, RIPE NCC Database Group =============================================================== Maintainer no of name inconsistent objects 1 NL-DOMREG 51932 http://www.ripe.net/db/state/maintainers/NL-DOMREG.html 2 DENIC-P 32961 http://www.ripe.net/db/state/maintainers/DENIC-P.html 3 XLINK-MNT 28267 http://www.ripe.net/db/state/maintainers/XLINK-MNT.html 4 DK-DOMREG 19720 http://www.ripe.net/db/state/maintainers/DK-DOMREG.html 5 FR-NIC-MNT 2907 http://www.ripe.net/db/state/maintainers/FR-NIC-MNT.html 6 ROKA-P 2549 http://www.ripe.net/db/state/maintainers/ROKA-P.html 7 DTAG-NIC 2020 http://www.ripe.net/db/state/maintainers/DTAG-NIC.html 8 SCHLUND-P 1544 http://www.ripe.net/db/state/maintainers/SCHLUND-P.html 9 AS1849-MNT 1512 http://www.ripe.net/db/state/maintainers/AS1849-MNT.html 10 ECORE-NET 1354 http://www.ripe.net/db/state/maintainers/ECORE-NET.html 11 BO-DOMREG 1341 http://www.ripe.net/db/state/maintainers/BO-DOMREG.html 12 NACAMAR-NOC 1321 http://www.ripe.net/db/state/maintainers/NACAMAR-NOC.html 13 DENIC-N 1068 http://www.ripe.net/db/state/maintainers/DENIC-N.html 14 WWW-MNT 1032 http://www.ripe.net/db/state/maintainers/WWW-MNT.html 15 AS1717-MNT 751 http://www.ripe.net/db/state/maintainers/AS1717-MNT.html 16 SEKTORNET-MNT 539 http://www.ripe.net/db/state/maintainers/SEKTORNET-MNT.html 17 DKNET-MNT 492 http://www.ripe.net/db/state/maintainers/DKNET-MNT.html 18 CSL-MNT 490 http://www.ripe.net/db/state/maintainers/CSL-MNT.html 19 DFN-NTFY 483 http://www.ripe.net/db/state/maintainers/DFN-NTFY.html 20 PSINET-UK-SYSADMIN 465 http://www.ripe.net/db/state/maintainers/PSINET-UK-SYSADMIN.h 21 INTERNET-NOC 446 http://www.ripe.net/db/state/maintainers/INTERNET-NOC.html 22 SKYNETBE-MNT 441 http://www.ripe.net/db/state/maintainers/SKYNETBE-MNT.html 23 NACAMAR-RES 418 http://www.ripe.net/db/state/maintainers/NACAMAR-RES.html 24 ITNET-MNT 398 http://www.ripe.net/db/state/maintainers/ITNET-MNT.html 25 HIGHSPEED-DOM 390 http://www.ripe.net/db/state/maintainers/HIGHSPEED-DOM.html 26 RAIN-TRANSPAC 390 http://www.ripe.net/db/state/maintainers/RAIN-TRANSPAC.html 27 DIGITALWEB-MNT 379 http://www.ripe.net/db/state/maintainers/DIGITALWEB-MNT.html 28 SDT-NOC 366 http://www.ripe.net/db/state/maintainers/SDT-NOC.html 29 AS5378-MNT 362 http://www.ripe.net/db/state/maintainers/AS5378-MNT.html 30 GLOBAL-MNT 362 http://www.ripe.net/db/state/maintainers/GLOBAL-MNT.html 31 AS1267-MNT 351 http://www.ripe.net/db/state/maintainers/AS1267-MNT.html 32 NACAMAR-POP 340 http://www.ripe.net/db/state/maintainers/NACAMAR-POP.html 33 AS6678-MNT 338 http://www.ripe.net/db/state/maintainers/AS6678-MNT.html 34 IDNET-MNT 311 http://www.ripe.net/db/state/maintainers/IDNET-MNT.html 35 TDK-MNT 306 http://www.ripe.net/db/state/maintainers/TDK-MNT.html 36 DE-VOSS 293 http://www.ripe.net/db/state/maintainers/DE-VOSS.html 37 KNIPP-NOC-MNT 253 http://www.ripe.net/db/state/maintainers/KNIPP-NOC-MNT.html 38 IL-P 251 http://www.ripe.net/db/state/maintainers/IL-P.html 39 FR-EASYNET 247 http://www.ripe.net/db/state/maintainers/FR-EASYNET.html 40 INX-MNT 242 http://www.ripe.net/db/state/maintainers/INX-MNT.html 41 GIGABELL-MNT 237 http://www.ripe.net/db/state/maintainers/GIGABELL-MNT.html 42 MARIDAN-P 229 http://www.ripe.net/db/state/maintainers/MARIDAN-P.html 43 AT-DOM-MNT 222 http://www.ripe.net/db/state/maintainers/AT-DOM-MNT.html 44 DK-NIC 221 http://www.ripe.net/db/state/maintainers/DK-NIC.html 45 EUROCONNECT 221 http://www.ripe.net/db/state/maintainers/EUROCONNECT.html 46 RAK-NET 220 http://www.ripe.net/db/state/maintainers/RAK-NET.html 47 IMAGINET-NOC-MNT 213 http://www.ripe.net/db/state/maintainers/IMAGINET-NOC-MNT.htm 48 AS2120-MNT 211 http://www.ripe.net/db/state/maintainers/AS2120-MNT.html 49 DREIMARK49-MNT 206 http://www.ripe.net/db/state/maintainers/DREIMARK49-MNT.html 50 AS1899-MNT 205 http://www.ripe.net/db/state/maintainers/AS1899-MNT.html 51 IWAY-NOC 205 http://www.ripe.net/db/state/maintainers/IWAY-NOC.html 52 AS3233-MNT 204 http://www.ripe.net/db/state/maintainers/AS3233-MNT.html 53 FREENAME-NOC 204 http://www.ripe.net/db/state/maintainers/FREENAME-NOC.html 54 AS5617-MNT 203 http://www.ripe.net/db/state/maintainers/AS5617-MNT.html 55 AS2529-MNT 197 http://www.ripe.net/db/state/maintainers/AS2529-MNT.html 56 NDH-P 195 http://www.ripe.net/db/state/maintainers/NDH-P.html 57 IBGNET 190 http://www.ripe.net/db/state/maintainers/IBGNET.html 58 IT-NIC 185 http://www.ripe.net/db/state/maintainers/IT-NIC.html 59 NLNET-MNT 182 http://www.ripe.net/db/state/maintainers/NLNET-MNT.html 60 AS5427-MNT 162 http://www.ripe.net/db/state/maintainers/AS5427-MNT.html 61 SL-CUS-MNT 158 http://www.ripe.net/db/state/maintainers/SL-CUS-MNT.html 62 EU-IBM-NIC-MNT2 157 http://www.ripe.net/db/state/maintainers/EU-IBM-NIC-MNT2.html 63 MBT-MNT 157 http://www.ripe.net/db/state/maintainers/MBT-MNT.html 64 AS1241-MNT 154 http://www.ripe.net/db/state/maintainers/AS1241-MNT.html 65 ROM-MIKNET 152 http://www.ripe.net/db/state/maintainers/ROM-MIKNET.html 66 TRMD-MNT 150 http://www.ripe.net/db/state/maintainers/TRMD-MNT.html 67 WESPE-MNT 150 http://www.ripe.net/db/state/maintainers/WESPE-MNT.html 68 AS5551-MNT 137 http://www.ripe.net/db/state/maintainers/AS5551-MNT.html 69 ONE2ONE-MNT 130 http://www.ripe.net/db/state/maintainers/ONE2ONE-MNT.html 70 ABCAG-MNT 127 http://www.ripe.net/db/state/maintainers/ABCAG-MNT.html 71 NETCOLOGNE-MNT 126 http://www.ripe.net/db/state/maintainers/NETCOLOGNE-MNT.html 72 OMNILINK-MNT 125 http://www.ripe.net/db/state/maintainers/OMNILINK-MNT.html 73 AS2871-MNT 124 http://www.ripe.net/db/state/maintainers/AS2871-MNT.html 74 NNCC 124 http://www.ripe.net/db/state/maintainers/NNCC.html 75 NETTUNO 116 http://www.ripe.net/db/state/maintainers/NETTUNO.html 76 AS3292-MNT 111 http://www.ripe.net/db/state/maintainers/AS3292-MNT.html 77 EVOSYS-MNT 111 http://www.ripe.net/db/state/maintainers/EVOSYS-MNT.html 78 ISB-MNT 107 http://www.ripe.net/db/state/maintainers/ISB-MNT.html 79 ISMA-MNT 106 http://www.ripe.net/db/state/maintainers/ISMA-MNT.html 80 ROSNIIROS-MNT 106 http://www.ripe.net/db/state/maintainers/ROSNIIROS-MNT.html 81 OLEANE-NOC 101 http://www.ripe.net/db/state/maintainers/OLEANE-NOC.html 82 AS6721-MNT 97 http://www.ripe.net/db/state/maintainers/AS6721-MNT.html 83 TELIANET-LIR 96 http://www.ripe.net/db/state/maintainers/TELIANET-LIR.html 84 PRHO-GUARDIAN 94 http://www.ripe.net/db/state/maintainers/PRHO-GUARDIAN.html 85 SEICOM-MNT 92 http://www.ripe.net/db/state/maintainers/SEICOM-MNT.html 86 MDA-Z 89 http://www.ripe.net/db/state/maintainers/MDA-Z.html 87 ISTLD-MNT 88 http://www.ripe.net/db/state/maintainers/ISTLD-MNT.html 88 AS8875-MNT 85 http://www.ripe.net/db/state/maintainers/AS8875-MNT.html 89 XNC-MNT 85 http://www.ripe.net/db/state/maintainers/XNC-MNT.html 90 TINET-NOC 84 http://www.ripe.net/db/state/maintainers/TINET-NOC.html 91 PROFI-MNT 82 http://www.ripe.net/db/state/maintainers/PROFI-MNT.html 92 GARR-LIR 80 http://www.ripe.net/db/state/maintainers/GARR-LIR.html 93 TPNET 80 http://www.ripe.net/db/state/maintainers/TPNET.html 94 JIPS-NOSC 78 http://www.ripe.net/db/state/maintainers/JIPS-NOSC.html 95 ICMS-NOC-MAINTAINER 77 http://www.ripe.net/db/state/maintainers/ICMS-NOC-MAINTAINER. 96 INETWIRE-MNT 76 http://www.ripe.net/db/state/maintainers/INETWIRE-MNT.html 97 MAINT-AS3352 75 http://www.ripe.net/db/state/maintainers/MAINT-AS3352.html 98 GLOBAL-ONE 74 http://www.ripe.net/db/state/maintainers/GLOBAL-ONE.html 99 ODN-MNT 74 http://www.ripe.net/db/state/maintainers/ODN-MNT.html 100 WEB4YOU-MNT 69 http://www.ripe.net/db/state/maintainers/WEB4YOU-MNT.html From ncc at ripe.net Thu Sep 30 18:25:07 1999 From: ncc at ripe.net (RIPE NCC Staff) Date: Thu, 30 Sep 1999 18:25:07 +0200 Subject: Announcement of the Address Council members - RIPE NCC Service Region Message-ID: <199909301625.SAA10884@birch.ripe.net> Members of the Address Council of ICANN - RIPE NCC Service Region During the 34th RIPE Meeting in Amsterdam on 23 September 1999 three Members of the ICANN ASO Address Council were selected as suggested by the call for nominations of 8th September. The duties of the ICANN Address Council are mainly threefold: First, to advise the Board of ICANN on matters referred to the Address Council by the ICANN Board. Secondly to oversee the existing regional processes for development of global policies relating to distribution and registration of Internet address space, identifiers used in Internet inter-domain routing, and the part of the DNS name space which is derived from the Internet address space and the inter-domain routing identifiers. The third being to appoint Directors to the ICANN Board of Directors in accordance with the By-laws of ICANN. The selection procedure was discussed in the LIR-WG, the open forum for policy issues in RIPE. The selection was performed during the RIPE Plenary meeting. As a pure consensus based selection is highly improbable, the final selection was performed by a secret ballot. The result of this ballot was confirmed by consensus support form the audience. There was also consensus that the three selected candidates should themselves establish their terms. To the best of our knowledge this selection has been in accordance with the principles described in the draft MoU (http://www.ripe.net/info/ncc/mou-draft.html) The selected individuals are: Sabine Jaume, RENATER for a one year period Hans Petter Holen, SOL System for a two year period Wilfried Woeber, Vienna University for a three year period We wish them success and look forward to co-operating with them. Rob Blokzijl Keith Mitchell RIPE chair RIPE NCC chair