From mark at pine.nl Wed Jul 5 22:52:52 2000 From: mark at pine.nl (Mark Lastdrager) Date: Wed, 5 Jul 2000 22:52:52 +0200 (MET DST) Subject: a few matters about security and consistency Message-ID: Hi, There are two matters I want to discuss, which are related from my point of view. Yesterday, ons of our hosts was attacked (Denial of Service). The attacker was using the DNS DOS described in http://www.ciac.org/ciac/bulletins/j-063.shtml (AUSCERT AL-1999.004) for this. The used attack in short: Small DNS queries are sent from the attacker to each of the DNS servers. These queries contain the spoofed IP address of the target. The DNS servers respond to the small query with a large response. These responses are routed to the target, causing link congestion and possible denial of Internet connectivity. This morning, we took our tcpdump logs of the attacks, and built a script which queried the Ripe database for the admins of the abused ('man-in-the-middle') networks. We got almost 900 unique email adresses out of this, to whom we sent a clear email describing what happened and asking for any logs or other usable information to find out who the attacker is. We we astonished how many people reacted with usefull information, we are still investigating right now. It pointed out we were not the only one attacked, it now looks like the attacker (or attackers ofcourse) is abusing most of the 194.x network to amplify the DNS requests pointing at a lot of Dutch hosts and even some in the USA. Ok, that was the scary part ;-) If you operate 1 or more DNS servers, please read the AUSCERT document and apply the workarounds they mention there (only allow your nameserver(s) to answer to queries from trusted hosts and/or zones you are authoritive for). If will really help from people abusing your network and filling up your pipe(s). Matter 1: What scared me was the great amount of bounced mail we got back from the 900 mails we sent. I think at least 10% did not exist. Besides that we got a lot of replies like 'hey don't bother me, I don't work there anymore'. Why doesn't RIPE test periodically if email adresses still work? Matter 2: Like I said, we got a lot of useful replies and they all more or less contained the same information. People had full, non-working internet links for days because of the attacks and were very happy that we pointed them to the 'Auscert workaround' because now they've closed their DNS'es the traffic (and business!) goes back to normal. Because of the info we got, we are -while I write this- trying to trace back to the origin of the spoofed packets. I think it would be very helpful if there was a mailinglist where European operators could discuss this kind of incidents, like the USA people do at the Securityfocus mailinglist (http://www.securityfocus.com/templates/archive.pike?list=75). I think the introduction at http://www.securityfocus.com/forums/incidents/intro.html would describe the use of such a list very well. Incidents like this DOS which affect a lot of European networks could be stopped much quicker, and if you can contact your fellow operators you don't have to waste expensive time trying to track down those stupid scriptkids (believe me.. it takes a lot of time ;-)). Ofcourse things like virii, talk about used exploits etc. are on-topic and interesting too. Like I said: time is money, so we set up the list euro-incidents at security.nl already. Anybody can subscribe at http://www.security.nl/mailman/listinfo/euro-incidents. Thanks for your time, Mark Lastdrager Pine Internet -- email: mark at lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl Today's excuse: We only support a 28000 bps connection. From Daniel.Karrenberg at ripe.net Thu Jul 6 08:23:03 2000 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 06 Jul 2000 08:23:03 +0200 Subject: a few matters about security and consistency In-Reply-To: Message-ID: <4.3.2.7.2.20000706081632.00cdcb00@localhost.ripe.net> At 10:52 PM 7/5/00, Mark Lastdrager wrote: >Matter 1: > >What scared me was the great amount of bounced mail we got back from the >900 mails we sent. I think at least 10% did not exist. Besides that we got >a lot of replies like 'hey don't bother me, I don't work there >anymore'. Why doesn't RIPE test periodically if email adresses still work? This idea has come up before. It boils down to whether the RIPE NCC members want to commit the resources necessary to do this properly. Looking at it carefully one discovers quickly that this would require a lot of humanpower for the followup actions necessary. Remember that we cannot just change or delete data in the database. Thus we would have to follow up any problems with someone who can. While much of this could be automated, still a great deal of it would require humam (naturally intelligent) intervention. All of this can be done if there are enough members who want this and are willing to pay the price. Daniel PS: As to the other matters I think that a functioning European CERT is what is needed here. From mark at pine.nl Thu Jul 6 10:11:26 2000 From: mark at pine.nl (Mark Lastdrager) Date: Thu, 6 Jul 2000 10:11:26 +0200 (MET DST) Subject: a few matters about security and consistency In-Reply-To: <4.3.2.7.2.20000706081632.00cdcb00@localhost.ripe.net> Message-ID: At Thu, 6 Jul 2000, Daniel Karrenberg wrote: >PS: As to the other matters I think that a functioning European CERT is >what is needed here. Partially agree with that. History has learned that CERTs not always respond as quick as we all want to, and besides that I think people with a business to protect are more eager to help eachother. Mark Lastdrager Pine Internet -- email: mark at lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl Today's excuse: Feature was not beta tested From Alessandro.Pelosi at swisscom-italy.com Thu Jul 6 10:23:47 2000 From: Alessandro.Pelosi at swisscom-italy.com (Alessandro.Pelosi at swisscom-italy.com) Date: Thu, 6 Jul 2000 10:23:47 +0200 Subject: R: a few matters about security and consistency Message-ID: We experienced the same problem... one of our customers was attacked properly in this way.... the only way to stop it was to add an iproute on our gateway royter that thashed in the null0 all the traffic directed to the victim server, and then renumber the other services. -----Messaggio originale----- Da: Mark Lastdrager [mailto:mark at pine.nl] Inviato: mercoled? 5 luglio 2000 22.53 A: lir-wg at ripe.net Cc: cert at pine.nl Oggetto: a few matters about security and consistency Hi, There are two matters I want to discuss, which are related from my point of view. Yesterday, ons of our hosts was attacked (Denial of Service). The attacker was using the DNS DOS described in http://www.ciac.org/ciac/bulletins/j-063.shtml (AUSCERT AL-1999.004) for this. The used attack in short: Small DNS queries are sent from the attacker to each of the DNS servers. These queries contain the spoofed IP address of the target. The DNS servers respond to the small query with a large response. These responses are routed to the target, causing link congestion and possible denial of Internet connectivity. This morning, we took our tcpdump logs of the attacks, and built a script which queried the Ripe database for the admins of the abused ('man-in-the-middle') networks. We got almost 900 unique email adresses out of this, to whom we sent a clear email describing what happened and asking for any logs or other usable information to find out who the attacker is. We we astonished how many people reacted with usefull information, we are still investigating right now. It pointed out we were not the only one attacked, it now looks like the attacker (or attackers ofcourse) is abusing most of the 194.x network to amplify the DNS requests pointing at a lot of Dutch hosts and even some in the USA. Ok, that was the scary part ;-) If you operate 1 or more DNS servers, please read the AUSCERT document and apply the workarounds they mention there (only allow your nameserver(s) to answer to queries from trusted hosts and/or zones you are authoritive for). If will really help from people abusing your network and filling up your pipe(s). Matter 1: What scared me was the great amount of bounced mail we got back from the 900 mails we sent. I think at least 10% did not exist. Besides that we got a lot of replies like 'hey don't bother me, I don't work there anymore'. Why doesn't RIPE test periodically if email adresses still work? Matter 2: Like I said, we got a lot of useful replies and they all more or less contained the same information. People had full, non-working internet links for days because of the attacks and were very happy that we pointed them to the 'Auscert workaround' because now they've closed their DNS'es the traffic (and business!) goes back to normal. Because of the info we got, we are -while I write this- trying to trace back to the origin of the spoofed packets. I think it would be very helpful if there was a mailinglist where European operators could discuss this kind of incidents, like the USA people do at the Securityfocus mailinglist (http://www.securityfocus.com/templates/archive.pike?list=75). I think the introduction at http://www.securityfocus.com/forums/incidents/intro.html would describe the use of such a list very well. Incidents like this DOS which affect a lot of European networks could be stopped much quicker, and if you can contact your fellow operators you don't have to waste expensive time trying to track down those stupid scriptkids (believe me.. it takes a lot of time ;-)). Ofcourse things like virii, talk about used exploits etc. are on-topic and interesting too. Like I said: time is money, so we set up the list euro-incidents at security.nl already. Anybody can subscribe at http://www.security.nl/mailman/listinfo/euro-incidents. Thanks for your time, Mark Lastdrager Pine Internet -- email: mark at lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl Today's excuse: We only support a 28000 bps connection. From Havard.Eidnes at runit.sintef.no Thu Jul 6 10:53:05 2000 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Thu, 06 Jul 2000 10:53:05 +0200 Subject: a few matters about security and consistency In-Reply-To: Your message of "Wed, 5 Jul 2000 22:52:52 +0200 (MET DST)" References: Message-ID: <20000706105305R.he@runit.sintef.no> Hi, I'll follow up on one of your points, and partly echo what Daniel Karrenberg said in his reply: > What scared me was the great amount of bounced mail we got back > from the 900 mails we sent. I think at least 10% did not > exist. Besides that we got a lot of replies like 'hey don't > bother me, I don't work there anymore'. Why doesn't RIPE test > periodically if email adresses still work? 10%? That's better than I had feared... It's possible you meant "RIPE NCC" when you said "RIPE". If so, that is probably because it's not the RIPE NCC which maintains the data in the RIPE database, and they have a long-standing policy of not modifying the real data in the database (IMHO a wise decision). So, doing the checks would make it necessary to hunt down who to contact about the contents of the database objects, something which can be troublesome for objects which are not marked with "mnt-by". Regards, - H?vard From leigh at insnet.net Thu Jul 6 12:41:17 2000 From: leigh at insnet.net (Leigh Porter) Date: Thu, 06 Jul 2000 11:41:17 +0100 Subject: R: a few matters about security and consistency References: Message-ID: <3964624D.453501A@insnet.net> Alessandro.Pelosi at swisscom-italy.com wrote: Was this recently? I saw attacks such as these a couple of years ago and again a little more recently. You could help it by using Cisco CAR and shaping incoming DNS queries down to something lowish at your borders, i.e. slightly higher than would ever be seen usually. If a client off your network has a problem getting a response, they should switch to a secondary on another network/subnet and eventually get a response. Out of interest, abut hor many queries per second did you folks see? Thanks, Leigh Porter Internet Network Services > > We experienced the same problem... one of our customers was attacked > properly in this way.... > the only way to stop it was to add an iproute on our gateway router that > thashed in the null0 all the traffic directed to the victim server, and then > renumber the other services. > > -----Messaggio originale----- > Da: Mark Lastdrager [mailto:mark at pine.nl] > Inviato: mercoledl 5 luglio 2000 22.53 > A: lir-wg at ripe.net > Cc: cert at pine.nl > Oggetto: a few matters about security and consistency > > Hi, > > There are two matters I want to discuss, which are related from my point > of view. > > Yesterday, ons of our hosts was attacked (Denial of Service). The attacker > was using the DNS DOS described in > http://www.ciac.org/ciac/bulletins/j-063.shtml (AUSCERT AL-1999.004) for > this. > > The used attack in short: Small DNS queries are sent from the attacker > to each of the DNS servers. These queries contain the spoofed IP address > of the target. The DNS servers respond to the small query with a large > response. These responses are routed to the target, causing link > congestion and possible denial of Internet connectivity. > > This morning, we took our tcpdump logs of the attacks, and built a script > which queried the Ripe database for the admins of the abused > ('man-in-the-middle') networks. We got almost 900 unique email adresses > out of this, to whom we sent a clear email describing what happened and > asking for any logs or other usable information to find out who the > attacker is. We we astonished how many people reacted with usefull > information, we are still investigating right now. > > It pointed out we were not the only one attacked, it now looks like the > attacker (or attackers ofcourse) is abusing most of the 194.x network to > amplify the DNS requests pointing at a lot of Dutch hosts and even some > in the USA. > > Ok, that was the scary part ;-) If you operate 1 or more DNS servers, > please read the AUSCERT document and apply the workarounds they mention > there (only allow your nameserver(s) to answer to queries from trusted > hosts and/or zones you are authoritive for). If will really help from > people abusing your network and filling up your pipe(s). > > Matter 1: > > What scared me was the great amount of bounced mail we got back from the > 900 mails we sent. I think at least 10% did not exist. Besides that we got > a lot of replies like 'hey don't bother me, I don't work there > anymore'. Why doesn't RIPE test periodically if email adresses still work? > > Matter 2: > > Like I said, we got a lot of useful replies and they all more or less > contained the same information. People had full, non-working internet > links for days because of the attacks and were very happy that we pointed > them to the 'Auscert workaround' because now they've closed their DNS'es > the traffic (and business!) goes back to normal. Because of the info we > got, we are -while I write this- trying to trace back to the origin of the > spoofed packets. > > I think it would be very helpful if there was a mailinglist where European > operators could discuss this kind of incidents, like the USA people do at > the Securityfocus mailinglist > (http://www.securityfocus.com/templates/archive.pike?list=75). I think the > introduction at http://www.securityfocus.com/forums/incidents/intro.html > would describe the use of such a list very well. Incidents like this DOS > which affect a lot of European networks could be stopped much quicker, and > if you can contact your fellow operators you don't have to waste expensive > time trying to track down those stupid scriptkids (believe me.. it takes a > lot of time ;-)). Ofcourse things like virii, talk about used exploits > etc. are on-topic and interesting too. > > Like I said: time is money, so we set up the list > euro-incidents at security.nl already. Anybody can subscribe at > http://www.security.nl/mailman/listinfo/euro-incidents. > > Thanks for your time, > > Mark Lastdrager > Pine Internet > > -- > email: mark at lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 > http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 > PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl > Today's excuse: We only support a 28000 bps connection. From ariek at kpnqwest.net Thu Jul 6 10:32:40 2000 From: ariek at kpnqwest.net (Arie Kuipers) Date: Thu, 06 Jul 2000 10:32:40 +0200 Subject: R: a few matters about security and consistency References: Message-ID: <39644427.ECCED947@kpnqwest.net> Please discuss this somewhere else :-) Alessandro.Pelosi at swisscom-italy.com wrote: > We experienced the same problem... one of our customers was attacked > properly in this way.... > the only way to stop it was to add an iproute on our gateway royter that > thashed in the null0 all the traffic directed to the victim server, and then > renumber the other services. > > -----Messaggio originale----- > Da: Mark Lastdrager [mailto:mark at pine.nl] > Inviato: mercoledl 5 luglio 2000 22.53 > A: lir-wg at ripe.net > Cc: cert at pine.nl > Oggetto: a few matters about security and consistency > > Hi, > > There are two matters I want to discuss, which are related from my point > of view. > > Yesterday, ons of our hosts was attacked (Denial of Service). The attacker > was using the DNS DOS described in > http://www.ciac.org/ciac/bulletins/j-063.shtml (AUSCERT AL-1999.004) for > this. > > The used attack in short: Small DNS queries are sent from the attacker > to each of the DNS servers. These queries contain the spoofed IP address > of the target. The DNS servers respond to the small query with a large > response. These responses are routed to the target, causing link > congestion and possible denial of Internet connectivity. > > This morning, we took our tcpdump logs of the attacks, and built a script > which queried the Ripe database for the admins of the abused > ('man-in-the-middle') networks. We got almost 900 unique email adresses > out of this, to whom we sent a clear email describing what happened and > asking for any logs or other usable information to find out who the > attacker is. We we astonished how many people reacted with usefull > information, we are still investigating right now. > > It pointed out we were not the only one attacked, it now looks like the > attacker (or attackers ofcourse) is abusing most of the 194.x network to > amplify the DNS requests pointing at a lot of Dutch hosts and even some > in the USA. > > Ok, that was the scary part ;-) If you operate 1 or more DNS servers, > please read the AUSCERT document and apply the workarounds they mention > there (only allow your nameserver(s) to answer to queries from trusted > hosts and/or zones you are authoritive for). If will really help from > people abusing your network and filling up your pipe(s). > > Matter 1: > > What scared me was the great amount of bounced mail we got back from the > 900 mails we sent. I think at least 10% did not exist. Besides that we got > a lot of replies like 'hey don't bother me, I don't work there > anymore'. Why doesn't RIPE test periodically if email adresses still work? > > Matter 2: > > Like I said, we got a lot of useful replies and they all more or less > contained the same information. People had full, non-working internet > links for days because of the attacks and were very happy that we pointed > them to the 'Auscert workaround' because now they've closed their DNS'es > the traffic (and business!) goes back to normal. Because of the info we > got, we are -while I write this- trying to trace back to the origin of the > spoofed packets. > > I think it would be very helpful if there was a mailinglist where European > operators could discuss this kind of incidents, like the USA people do at > the Securityfocus mailinglist > (http://www.securityfocus.com/templates/archive.pike?list=75). I think the > introduction at http://www.securityfocus.com/forums/incidents/intro.html > would describe the use of such a list very well. Incidents like this DOS > which affect a lot of European networks could be stopped much quicker, and > if you can contact your fellow operators you don't have to waste expensive > time trying to track down those stupid scriptkids (believe me.. it takes a > lot of time ;-)). Ofcourse things like virii, talk about used exploits > etc. are on-topic and interesting too. > > Like I said: time is money, so we set up the list > euro-incidents at security.nl already. Anybody can subscribe at > http://www.security.nl/mailman/listinfo/euro-incidents. > > Thanks for your time, > > Mark Lastdrager > Pine Internet > > -- > email: mark at lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 > http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 > PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl > Today's excuse: We only support a 28000 bps connection. -- __ ----- / ___ ___ / ) ___ ___ ____ ---- /___/ /___/ / / / / | / /___/ /___ / --- / \ / / / (__ \ |/\/ /___ ___/ / -- Arie Kuipers, IP Engineer -- KPNQwest N.V. - IP NOC (formerly EUnet) -- Singel 540, 1017 AZ Amsterdam, NL -- Phone: +31 (0)20 4210865; Fax: +31 (0)20 6224657 -- Email: ariek at kpnqwest.net From mark at pine.nl Thu Jul 6 11:43:25 2000 From: mark at pine.nl (Mark Lastdrager) Date: Thu, 6 Jul 2000 11:43:25 +0200 (MET DST) Subject: R: a few matters about security and consistency In-Reply-To: <39644427.ECCED947@kpnqwest.net> Message-ID: At Thu, 6 Jul 2000, owner-lir-wg at ripe.net wrote: >Please discuss this somewhere else :-) Yes.. if you want to continue the discussion about the recent attacks (which would be appreciated), please join the euro-incidents list at http://www.security.nl/mailman/listinfo/euro-incidents as it's off-topic on this list I guess ;-) Mark Lastdrager Pine Internet -- email: mark at lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl Today's excuse: We're upgrading /dev/null From phk at critter.freebsd.dk Thu Jul 6 13:07:44 2000 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 06 Jul 2000 13:07:44 +0200 Subject: a few matters about security and consistency In-Reply-To: Your message of "Thu, 06 Jul 2000 10:11:26 +0200." Message-ID: <585.962881664@critter.freebsd.dk> In message , Mark Lastdrag er writes: >At Thu, 6 Jul 2000, Daniel Karrenberg wrote: > >>PS: As to the other matters I think that a functioning European CERT is >>what is needed here. > >Partially agree with that. History has learned that CERTs not always >respond as quick as we all want to, and besides that I think people with a >business to protect are more eager to help eachother. I think we need a NANOG more than a CERT. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From Daniel.Karrenberg at ripe.net Thu Jul 6 14:23:07 2000 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 06 Jul 2000 14:23:07 +0200 Subject: a few matters about security and consistency In-Reply-To: <585.962881664@critter.freebsd.dk> References: Message-ID: <4.3.2.7.2.20000706142134.00d02a80@localhost.ripe.net> At 01:07 PM 7/6/00, Poul-Henning Kamp wrote: >I think we need a NANOG more than a CERT. I thought we had RIPE for that. What does NANOG do that you need and RIPE does not do? A mailing list with a high S/N ratio ? Seriously: RIPE or the RIPE NCC should be doing what you need. Tell us. Daniel From netmaster at space.net Thu Jul 6 14:03:47 2000 From: netmaster at space.net (Gert Doering, Netmaster) Date: Thu, 6 Jul 2000 14:03:47 +0200 Subject: a few matters about security and consistency In-Reply-To: <585.962881664@critter.freebsd.dk>; from phk@critter.freebsd.dk on Thu, Jul 06, 2000 at 01:07:44PM +0200 References: <585.962881664@critter.freebsd.dk> Message-ID: <20000706140347.I11768@Space.Net> Hi, On Thu, Jul 06, 2000 at 01:07:44PM +0200, Poul-Henning Kamp wrote: > I think we need a NANOG more than a CERT. Agreed! 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 Torsten.Blum at ecrc.de Thu Jul 6 14:22:09 2000 From: Torsten.Blum at ecrc.de (Torsten Blum) Date: Thu, 6 Jul 2000 14:22:09 +0200 (CEST) Subject: a few matters about security and consistency In-Reply-To: <585.962881664@critter.freebsd.dk> from Poul-Henning Kamp at "Jul 6, 2000 01:07:44 pm" Message-ID: <200007061222.OAA18539@turon.ecrc.de> Poul-Henning Kamp wrote: > I think we need a NANOG more than a CERT. I definately agree. What about ENOG ? ;) -tb -- Torsten Blum, Network Engineer Tel: +49.89.92699.0 Cable & Wireless ECRC GmbH Fax: +49.89.92699.225 Arabellastr. 17 E-Mail: tblum at ecrc.de D-81925 Munich, Germany From phk at critter.freebsd.dk Thu Jul 6 14:38:26 2000 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 06 Jul 2000 14:38:26 +0200 Subject: a few matters about security and consistency In-Reply-To: Your message of "Thu, 06 Jul 2000 14:22:09 +0200." <200007061222.OAA18539@turon.ecrc.de> Message-ID: <1145.962887106@critter.freebsd.dk> In message <200007061222.OAA18539 at turon.ecrc.de>, Torsten Blum writes: >Poul-Henning Kamp wrote: > >> I think we need a NANOG more than a CERT. > >I definately agree. >What about ENOG ? ;) Who's the first to find the best expansion of the acronym EGGNOG ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From stephenb at uk.uu.net Thu Jul 6 15:51:23 2000 From: stephenb at uk.uu.net (Stephen Burley) Date: Thu, 06 Jul 2000 13:51:23 +0000 Subject: a few matters about security and consistency References: <200007061222.OAA18539@turon.ecrc.de> Message-ID: <39648EDA.E920FF01@uk.uu.net> Torsten Blum wrote: > Poul-Henning Kamp wrote: > > > I think we need a NANOG more than a CERT. > > I definately agree. > What about ENOG ? ;) Or even better EGGNOG! ;) Sorry could not resist. But i totally agree with Daniel RIPE/RIPE NCC should be the equivalent org in Europe. > > > -tb > -- > Torsten Blum, Network Engineer Tel: +49.89.92699.0 > Cable & Wireless ECRC GmbH Fax: +49.89.92699.225 > Arabellastr. 17 E-Mail: tblum at ecrc.de > D-81925 Munich, Germany -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life Stephenb at uk.uu.net if you're stupid and willing to wait" ------------------------------------------------------------------------ From Daniel.Karrenberg at ripe.net Thu Jul 6 15:17:48 2000 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 06 Jul 2000 15:17:48 +0200 Subject: a few matters about security and consistency In-Reply-To: <20000706144710.J11768@Space.Net> References: <4.3.2.7.2.20000706142134.00d02a80@localhost.ripe.net> <585.962881664@critter.freebsd.dk> <4.3.2.7.2.20000706142134.00d02a80@localhost.ripe.net> Message-ID: <4.3.2.7.2.20000706151321.00cdee50@localhost.ripe.net> At 02:47 PM 7/6/00, Gert Doering, Netmaster wrote: >Hi, > >On Thu, Jul 06, 2000 at 02:23:07PM +0200, Daniel Karrenberg wrote: >> At 01:07 PM 7/6/00, Poul-Henning Kamp wrote: >> >> >I think we need a NANOG more than a CERT. >> >> I thought we had RIPE for that. What does NANOG do that you need and >> RIPE does not do? A mailing list with a high S/N ratio ? > >Hmmm, there is no real "Network OPerators" list at RIPE, afaik. By >that I mean, technical discussion about BGP issues, router configuration >issues, ongoing attacks, etc. - local-ir etc. is more for less technical >issues (as I see it). The list is there: ripe-op at ripe.net. It has not been used for some time and not even received any SPAM lately. Look at http://www.ripe.net/ripe/mail-archives/ripe-op/index.html for some historical jewels! Maybe time to revive that list? Daniel >I wouldn't object to having that list hosted at the RIPE NCC, though :-) > >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 sp at DK.net Thu Jul 6 15:21:01 2000 From: sp at DK.net (Soren Petersen) Date: Thu, 6 Jul 2000 15:21:01 +0200 (MET DST) Subject: a few matters about security and consistency In-Reply-To: <1145.962887106@critter.freebsd.dk> Message-ID: European General Groans Network Operations Group European Gigabit Gurus Network Operations Group - Soren On Thu, 6 Jul 2000, Poul-Henning Kamp wrote: > In message <200007061222.OAA18539 at turon.ecrc.de>, Torsten Blum writes: > >Poul-Henning Kamp wrote: > > > >> I think we need a NANOG more than a CERT. > > > >I definately agree. > >What about ENOG ? ;) > > Who's the first to find the best expansion of the acronym EGGNOG ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > ----------------------------------------------------------------------- - sp at DK.net - Backbone Manager @ Tele Danmark Internet - +45 35279000 - ----------------------------------------------------------------------- From netmaster at space.net Thu Jul 6 14:47:10 2000 From: netmaster at space.net (Gert Doering, Netmaster) Date: Thu, 6 Jul 2000 14:47:10 +0200 Subject: a few matters about security and consistency In-Reply-To: <4.3.2.7.2.20000706142134.00d02a80@localhost.ripe.net>; from Daniel.Karrenberg@ripe.net on Thu, Jul 06, 2000 at 02:23:07PM +0200 References: <585.962881664@critter.freebsd.dk> <4.3.2.7.2.20000706142134.00d02a80@localhost.ripe.net> Message-ID: <20000706144710.J11768@Space.Net> Hi, On Thu, Jul 06, 2000 at 02:23:07PM +0200, Daniel Karrenberg wrote: > At 01:07 PM 7/6/00, Poul-Henning Kamp wrote: > > >I think we need a NANOG more than a CERT. > > I thought we had RIPE for that. What does NANOG do that you need and > RIPE does not do? A mailing list with a high S/N ratio ? Hmmm, there is no real "Network OPerators" list at RIPE, afaik. By that I mean, technical discussion about BGP issues, router configuration issues, ongoing attacks, etc. - local-ir etc. is more for less technical issues (as I see it). I wouldn't object to having that list hosted at the RIPE NCC, though :-) 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 marck at rinet.ru Thu Jul 6 15:57:11 2000 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu, 6 Jul 2000 17:57:11 +0400 (MSD) Subject: a few matters about security and consistency In-Reply-To: <1145.962887106@critter.freebsd.dk> Message-ID: On Thu, 6 Jul 2000, Poul-Henning Kamp wrote: PK> Who's the first to find the best expansion of the acronym EGGNOG ? European Giant Gang? ;-))) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From adrian.pauling at bt.com Thu Jul 6 16:21:54 2000 From: adrian.pauling at bt.com (adrian.pauling at bt.com) Date: Thu, 6 Jul 2000 15:21:54 +0100 Subject: a few matters about security and consistency Message-ID: <27EDC2145E42D211AD9600606DD5EC1D07ED0C90@mbrpb1nt02.mww.bt.com> Dear All, Issue 1 is of interest to anyone involved with RIPE database. It must be in the RIPE communities interest to keep data as up to date and accurate as possible. Auditing is a resource hungry task and a pain in the asynchronous port, but is necessary to maintain and improve the quality of the data within the database. Is it acceptable for RIPE database to periodically, say once a year, to contact via e-mail each person and role object? The objective would be to ensure the person / role object are up to date. If there was no response, perhaps within a 4 week period, any associated maintainer object could be used to identify other people who could up date the records. If there is no maintainer, then a RIPE Hostmaster maintainer or notify attribute could be added to the record - and mark the record as out of date as appropriate . This would be a small overhead to everyone who is on the RIPE database that would ensure and improve the integrity of data within the database, for a piece of work on the database. From below, there is a possibility of up to 10 % of records on the database being inaccurate. That can not be an acceptable situation. Issue 2 is beyond the direct scope of the LIR-WG. However, I recollect that at RIPE 35 there was a suggestion of adding a new database record to the RIPE database, to clearly identify those networks which had a CERT team - has any progress been made? Regards, Adrian F Pauling :-)NEL2C Internet Protocol Manager acd Information Systems Engineering Technical Architecture AFP1-RIPE / AFP-ARIN / AFP25-InterNIC * adrian.pauling at bt.com * +44 19 2685 1992 / +44 78 0290 4877 British Telecommunications plc Registered Office 81 Newgate Street London EC1A 7AJ Registered in England no 1800000 > -----Original Message----- > From: Mark Lastdrager [SMTP:mark at pine.nl] > Sent: 05 July 2000 21:53 > To: lir-wg at ripe.net > Cc: cert at pine.nl > Subject: a few matters about security and consistency > > Hi, > > There are two matters I want to discuss, which are related from my point > of view. > > Yesterday, ons of our hosts was attacked (Denial of Service). The attacker > was using the DNS DOS described in > http://www.ciac.org/ciac/bulletins/j-063.shtml (AUSCERT AL-1999.004) for > this. > > The used attack in short: Small DNS queries are sent from the attacker > to each of the DNS servers. These queries contain the spoofed IP address > of the target. The DNS servers respond to the small query with a large > response. These responses are routed to the target, causing link > congestion and possible denial of Internet connectivity. > > This morning, we took our tcpdump logs of the attacks, and built a script > which queried the Ripe database for the admins of the abused > ('man-in-the-middle') networks. We got almost 900 unique email adresses > out of this, to whom we sent a clear email describing what happened and > asking for any logs or other usable information to find out who the > attacker is. We we astonished how many people reacted with usefull > information, we are still investigating right now. > > It pointed out we were not the only one attacked, it now looks like the > attacker (or attackers ofcourse) is abusing most of the 194.x network to > amplify the DNS requests pointing at a lot of Dutch hosts and even some > in the USA. > > Ok, that was the scary part ;-) If you operate 1 or more DNS servers, > please read the AUSCERT document and apply the workarounds they mention > there (only allow your nameserver(s) to answer to queries from trusted > hosts and/or zones you are authoritive for). If will really help from > people abusing your network and filling up your pipe(s). > > Matter 1: > > What scared me was the great amount of bounced mail we got back from the > 900 mails we sent. I think at least 10% did not exist. Besides that we got > a lot of replies like 'hey don't bother me, I don't work there > anymore'. Why doesn't RIPE test periodically if email adresses still work? > > > Matter 2: > > Like I said, we got a lot of useful replies and they all more or less > contained the same information. People had full, non-working internet > links for days because of the attacks and were very happy that we pointed > them to the 'Auscert workaround' because now they've closed their DNS'es > the traffic (and business!) goes back to normal. Because of the info we > got, we are -while I write this- trying to trace back to the origin of the > spoofed packets. > > I think it would be very helpful if there was a mailinglist where European > operators could discuss this kind of incidents, like the USA people do at > the Securityfocus mailinglist > (http://www.securityfocus.com/templates/archive.pike?list=75). I think the > introduction at http://www.securityfocus.com/forums/incidents/intro.html > would describe the use of such a list very well. Incidents like this DOS > which affect a lot of European networks could be stopped much quicker, and > if you can contact your fellow operators you don't have to waste expensive > time trying to track down those stupid scriptkids (believe me.. it takes a > lot of time ;-)). Ofcourse things like virii, talk about used exploits > etc. are on-topic and interesting too. > > Like I said: time is money, so we set up the list > euro-incidents at security.nl already. Anybody can subscribe at > http://www.security.nl/mailman/listinfo/euro-incidents. > > Thanks for your time, > > Mark Lastdrager > Pine Internet > > -- > email: mark at lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 > http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 > PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl > Today's excuse: We only support a 28000 bps connection. > > > > > From leigh at insnet.net Thu Jul 6 19:30:41 2000 From: leigh at insnet.net (Leigh Porter) Date: Thu, 06 Jul 2000 18:30:41 +0100 Subject: a few matters about security and consistency References: <585.962881664@critter.freebsd.dk> Message-ID: <3964C241.40A54FFC@insnet.net> Poul-Henning Kamp wrote: > I think we need a NANOG more than a CERT. I thought that was what RIPE was for? The NANOG list is used to discuss all manor of ops/engineering matters, is there a similar RIPE list? YEah NANOG gets busy sometimes and full of crud, but it's nice to have a list where you can do that kind of thing. -- Leigh Porter INS From phk at critter.freebsd.dk Thu Jul 6 21:23:39 2000 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 06 Jul 2000 21:23:39 +0200 Subject: a few matters about security and consistency In-Reply-To: Your message of "Thu, 06 Jul 2000 14:23:07 +0200." <4.3.2.7.2.20000706142134.00d02a80@localhost.ripe.net> Message-ID: <2574.962911419@critter.freebsd.dk> In message <4.3.2.7.2.20000706142134.00d02a80 at localhost.ripe.net>, Daniel Karre nberg writes: >At 01:07 PM 7/6/00, Poul-Henning Kamp wrote: > >>I think we need a NANOG more than a CERT. > >I thought we had RIPE for that. What does NANOG do that you need and >RIPE does not do? A mailing list with a high S/N ratio ? > >Seriously: RIPE or the RIPE NCC should be doing what you need. >Tell us. I think the main issues facing us are DoS attacks, portscans and outages, so I think a mailing list dedicated to abnormal operational issues would be a good idea. It will require a concensus about the exact charter but that can probably be found. It would also be nice if we had a field in the database which made it possible to lookup the email+phone of the person to contact for cert/abuse issues by IP number. As it is now the database is less useful than simply mailing abuse at domain, root at domain and cert at domain. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From lir-mod at ripe.net Fri Jul 7 13:50:26 2000 From: lir-mod at ripe.net (NCC local-ir list Moderator) Date: Fri, 07 Jul 2000 13:50:26 +0200 Subject: Duplicate mails Message-ID: <200007071150.NAA02485@birch.ripe.net> Dear subscribers, Please notice that we are experiencing some strange mail behaviour at the moment. The previous mail from Mr Henning Brauer seems to have been re-sent to the lists in error. We are not sure of the cause yet. Before replying to what may seem like an old thread, please check the sent date. We will endeavour to prevent any more of these mails leaking through. Regards, John Crain Head of Internal Services From hph at online.no Fri Jul 14 14:22:07 2000 From: hph at online.no (Hans Petter Holen) Date: Fri, 14 Jul 2000 14:22:07 +0200 Subject: a few matters about security and consistency References: <585.962881664@critter.freebsd.dk> <4.3.2.7.2.20000706142134.00d02a80@localhost.ripe.net> <20000706144710.J11768@Space.Net> Message-ID: <006e01bfed8e$22c46b20$bae6fea9@a.sol.no> > On Thu, Jul 06, 2000 at 02:23:07PM +0200, Daniel Karrenberg wrote: > > At 01:07 PM 7/6/00, Poul-Henning Kamp wrote: > > > > >I think we need a NANOG more than a CERT. > > > > I thought we had RIPE for that. What does NANOG do that you need and > > RIPE does not do? A mailing list with a high S/N ratio ? > > Hmmm, there is no real "Network OPerators" list at RIPE, afaik. By > that I mean, technical discussion about BGP issues, router configuration > issues, ongoing attacks, etc. - local-ir etc. is more for less technical > issues (as I see it). What about EOF - European Operators Forum ? The European Operators Forum deals with the operational issues of networks in Europe, such as new backbones and Internet Exchange Points. -hph From nigel.titley at level3.com Fri Jul 14 14:31:34 2000 From: nigel.titley at level3.com (Nigel Titley) Date: Fri, 14 Jul 2000 13:31:34 +0100 Subject: a few matters about security and consistency In-Reply-To: Message from "Hans Petter Holen" of "Fri, 14 Jul 2000 14:22:07 +0200." <006e01bfed8e$22c46b20$bae6fea9@a.sol.no> Message-ID: > > On Thu, Jul 06, 2000 at 02:23:07PM +0200, Daniel Karrenberg wrote: > > > At 01:07 PM 7/6/00, Poul-Henning Kamp wrote: > > > > > > >I think we need a NANOG more than a CERT. > > > > > > I thought we had RIPE for that. What does NANOG do that you need and > > > RIPE does not do? A mailing list with a high S/N ratio ? > > > > Hmmm, there is no real "Network OPerators" list at RIPE, afaik. By > > that I mean, technical discussion about BGP issues, router configuration > > issues, ongoing attacks, etc. - local-ir etc. is more for less technical > > issues (as I see it). > > What about EOF - European Operators Forum ? > > The European Operators Forum deals with the operational issues of networks > in Europe, such as new backbones and Internet Exchange Points. Good point. In fact EOF was created as the European equivalent of NANOG. Nigel -- Tel: +44 171 864 4450 Fax: +44 171 864 4488 Well I'm disenchanted too. We're all disenchanted (James Thurber) From mcortes at ripe.net Wed Jul 26 15:17:13 2000 From: mcortes at ripe.net (Monica Cortes) Date: Wed, 26 Jul 2000 15:17:13 +0200 Subject: scheduled downtime of RIPE NCC network Message-ID: <200007261317.PAA24407@x26.ripe.net> Dear Colleagues, Due to an upgrade of our network infrastructure, the external services the RIPE NCC provides will be unavailable for about 10 minutes. The downtime is scheduled for next Thursday 27th of July between 19:30 and 20:00. If you have any questions, please reply to ops at ripe.net. Regards, --Monica Cortes From nurani at ripe.net Thu Jul 27 18:34:53 2000 From: nurani at ripe.net (Nurani Nimpuno) Date: Thu, 27 Jul 2000 18:34:53 +0200 Subject: REMINDER: RIPE NCC ADDRESS POLICY CHANGE Message-ID: <200007271634.SAA20179@x7.ripe.net> POLICY CHANGE REMINDER ====================== During the RIPE 36 meeting in Budapest (16-19 May 2000) the LIR working group agreed upon the following policy change: AS OF THE 1ST OF AUGUST 2000, THE RIPE NCC WILL LOWER THE MINIMUM ALLOCATION SIZE FROM A /19 TO A /20. Allocations of the size /20, will initially be issued from CIDR block 217/8. If you use prefix based filtering in your routers, please note this change. The Minimum Allocation Size does not constrain requests for address space that can justify larger blocks of addresses. For further information regarding sizes of allocations made by the RIPE NCC, please refer to the following RIPE document: ripe-211 - "Size of smallest allocations in CIDR blocks allocated by the RIPE NCC". http://www.ripe.net/ripe/docs/ripe-211.html Best regards, Nurani Nimpuno Registration Services Manager RIPE NCC From hph at online.no Fri Jul 28 21:12:33 2000 From: hph at online.no (Hans Petter Holen) Date: Fri, 28 Jul 2000 21:12:33 +0200 Subject: Draft minutes v1 LIR-36 Message-ID: <000101bff98a$6149e8e0$43f5fea9@hph> Many thanks to Eamonn for preparing theese minutes basd on his own and Mirjams notes. My only contribution to theese has been to delay them for a coulple months. My appologies for that. Please send your comments and additions to me, and I will incorporate them in the final minutes. Yours, Hans Petter Holen Chair LIR-WG ---- Minute taker - Eamonn McGuinness (RIPE NCC Hostmaster) AGENDA 1. Admin -scribe, participant list, charter, mailinglists 2. Agenda 3. RIPE 35 - minutes - actions 4. Reports from the Registries - RIPE NCC - APNIC - ARIN - ICANN - Status of the Latin and Afrinic 5. ICANN AC Upcoming Election 6. Status of ICANN Ad Hoc Group 7. IP addresses to GPRS infrastructure 8. Microallocations in the ARIN region 9. Minimum Allocation 10. Name-based webhosting 11. AW's for registry's infrastructure (eg. headends) 12. ripe-174 RIPE NCC Conflict Arbitration Procedure 12. Interim report from the ICANN ad Hoc group -------------------------- 3. Action list from RIPE-35 : Action Owner Status Description 35.1 Chair Publish policy document 35.2 Chair Publish election procedure 35.3 WG Subscribe lir-wg 35.4 NCC PGP Key exchange procedure 35.5 NCC Implement PGP for hostmaster mail 35.6 NCC Make db checking tool available for self audit 35.7 Chair Task Force on addresses to GPRS infrastructure 4. Report from the RIPE NCC - Nurani Nimpuno http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/ Some points in the presentation : - Asused public released ftp://ftp.ripe.net/tools/asused-public-0.1b.tar.gz - AS# checker released http://www.ripe.net/cgi-bin/web147cgi - New FAQ http://www.ripe.net/ripencc/faq/index.html - Hiring Technical Advisor for the Hostmasters IPv6 - 17 sub-TLAs allocated - 8 ranges reverse delegated QUESTIONS HPH: wait queue 7 days at the moment, when will it be down again to 2 days? Next week or one week before the next RIPE Mtg? Joao: unfortunately not next week. We have hired more staff, who have to be trained. We're also looking into tools and processes, haven't started changing things yet, want to analyse it carefully before. Trying to have a staffing level that allows us to address variations in work load. WW: did not participate in discussion on mailing list. Might have a bit more relaxed view, knows more about the background of the NCC. Would like the community to achieve (not just the NCC) to improve the information flow. We as a group could have done better in spotting the fact that the problem was growing, could have saved a few months when the review process would have started earlier. Start discussing: what is acceptable delay time, what can be done to improve and keep it. Joao mentioned 2 days turn around time as acceptable, not sure anymore if this view is shared by the community, used to be acceptable in the past, maybe not anymore. We all suffer from the problem that we only see our point of view, NCC only sees their point of view, he as academic LIR doesn't know the view of commercial LIRs etc. Proposes to set up a review process to review boundary conditions and what the process should be. What's number of e-mails in the wait queue, how many requests, how much resources, are there peaks etc (some of this is already on the web now). Having this information available would allow the LIRs to have a tool to adjust their expectations. Not sure if throwing more and more resources is the solutions. Maybe adjusting rules may be more effective. Barbara: suggestions: like to see easier way of communicating when filling out a request form (like a help desk), not about specific requests, but just simple questions with filling in form etc. (more administrative questions). We've being turned away by the RIPE NCC secretaries and have to wait up to 2 weeks for an answer to a simple question. Alternatively have separate queues for requests and for these kind of questions. Also would like to see percentage of request sizes. Then we figure out what a good comprise between efficiency and proper management of the IP address space. Nurani: agrees with suggestions about improving the information flow. Trying to answer simple questions fast. Will provide these kind of statistics. Juergen: agrees with WW but has an additional comment. Looking at Assignment Windows of the already experienced LIR, Every time NCC decreases the AW the work load increases. Nurani: agrees that NCC must be more proactive with increasing AW. Ask the LIRs also to approach the NCC when they feel it should be raised. However, must find a good balance with management of IP space. Easier to rule out mistakes at the start than correcting it later. Eamonn: people are moving fast in this business, experienced staff leaves and leave knowledge gap at the LIR. Some LIRs even ask to decrease AW, for instance because they don't find the time to train staff internally. Yes, decreasing AW increases work load, but asks people to keep the above point also into account when discussing this. Juergen: surprised that we do not have a new policy draft for the IPv6 policy document. This is unsatisfying. Joao: we want a global policy draft, there have been various discussions about that, there seems to be disagreement about one particular point in the policy, this is the only thing outstanding. HPH: trying to summarise, most concrete suggestion was to set up a group to look into information flow and processes, will meet during the coffee break t set up a charter. - APNIC Report - Anne Lord http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/ 75% of members were not using all their /19 (80% ?) after a year. Proposal to reduce AW to /20. Met with agreement. Implemented 3 months from March. IPv6 12 allocations. Over half were 6Bone members. - ARIN Report http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/ IPv6 6 requests, 4 blocks allocated. Harvad: some of us have address space that predates the establishment of the RIRs, that means that ARIN is currently responsible for maintaining the DB data and the reverse delegation. How can we interact with you ? Richard: modification template on web. There is activity underway to distribute the records to the region the network is located. Q: Isn't there a process to do this easier ? A: Yes, a smoother procedure will be introduced later in the year. Juergen: all RIRs report about their address utilisation, it is however difficult to gain an overview over the global IPv4 utilisation. WW: just want to make sure that whatever is developed for the distribution also works for the emerging RIRs. What are you going to do to inform the parties effected by this. Will this be an administrative issues, a DB issue, a policy issue and where will it discussed? Richard: this has not been discussed yet, maybe good idea to set up a dedicated list for that. Nothing has been done yet, obviously we'll do everything to inform the community. - ICANN Report - Louis Touton http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/ Very quick, skipped most slides. Slides looked like the ones used by Andrew McLaughlan in Feb. - IPv6 (will be important very soon, increased demand on IPv4 due to new technology, this will increase demand for Ipv6 very quickly) - General mix of global versus regional address policy (in IPv4 big goal is aggregation deserves some re-assimilation certainly with Ipv6, because the scarcity is gone). - Emerging RIRs QUESTION: Randy: if the purpose of spinning was internationalisation is it still true that the Doc has to approve all changes in ccTLDs? [eamonn - Did he not ask] "Does the US Department of Commerce still have authority to make changes to ICANN ?" Louis: Yes, all changes in the root zone requires formal approval by the DoC until everything is set up fully. Community needs to gain confidence. - Report about emerging RIRs. AfriNIC Meeting Report - Mirjam Kuehne http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/ Andrew Brooks from South Africa is coming Thursday to speak more about this meeting at the Plenary. QUESTIONS: WW: What is the function of the listeners ? Louis: When the RIR gets established it will have 3 seats on the AC, in the meantime they will just listen as anyone in the public can listen. - LacNIC - Joao Luis Silva Damas Sao Paulo meeting this week (i think). - Task Force met at the break. (see HPH slides) Participants: Daniele Bovio, Joao Damas, Juergen Rauschenbach, Sabine, WW, HPH (others added later). They set a Goal; To improve NCC Services to its membership. Anyone else wants to participate, speak with the Chair. 5. ICANN AC Upcoming Election (see HPH slide) 6. Status of ICANN Ad Hoc Group HPH presented some slides prepared by Raimundo Beca who is on the Ad Hoc Editorial group. No report yet (probably at Yokohama ICANN Meeting). 7. IP address space for GPRS Infrastructure - Kim Fullbrook Working party setup after RIPE-35. There was a number of presentations covering GPRS, UMTS and the bridge to the Internet. Task force setup. They met in London 2 weeks ago. GPRS Operators asked for their address requirements from their GPRS networks. Not all were at that advanced stage. The question of public unique address space for this was proven. Estimates for address need for infrastructure came to : ~400 GSM providers x ~2000 IP addresses for GPRS n/w's = 800K. QUESTIONS: Randy: What kind of a uniformed address policy is needed in order for roaming to work ? Kim: Requirement is that they all use unique address space. Hph: Do we have consensus that public addresses are needed ? Randy: what is the difference with GPRS with respects to other new technologies ? Answer: Nothing is different, thats the point. Anders Roos: the main reason is that we have about 400 members in the GSM association, a lot of them will request for address space. In order to reduce work for all parties, they try to establish a common policy and procedure. WW: grateful for the work and the effort done to achieve this. Very acceptable solution found. Just as a clarification, what was presented might be new policy for the GSM operators, but is not viewed as new address allocation policy. CONCLUDED - SOLVED 8. Microallocations in the ARIN region - Cathy Wittbrodt ARIN has been received requests for small amounts of PI address space. ARIN Advisory Council did some research and found that most people would not have a problem as long as important infrastructure is defined clearly. TLD server, RIRs and ICANN should be added to the list of 'critical infrastructure'. Randy: Why is it necessary to have a unique special infrastructure defined ? There was for instance special /24s reserved/assigned for the root NSes. None of them are using them, because they don't need to. Dfk: Shares Randys view. What he thinks wants to be achieved, is notification mechanism (a registry where network addresses can be registered and ISPs can decide to route that or not). Then you don't need to decide what is routable ? Addresses are made portable by the fact that ISPs decide to route them, not made portable by the ISPs to assign special addresses. Suggests to register the addresses they already use rather than assigning them special addresses. Randy: What worries them is that parts of the Internet are fixed that aren't broken. The reason that the root NSes didn't use the special addresses is that they were already part of existing networks and are connected to the Internet, and they aren't being filtered out by others. Also the ccTLD servers are connected currently and they have secondaries. 9. Minimum Allocation Proposal from the RIPE NCC - Nurani Nimpuno Question to the community; Should we lower minimum allocation from a /19 to a to /20 ? http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/ Stats show over 2 years ~60% of /19 allocations were not used (to 80%). We would have saved ~200 /19s if we allocated /20s 2 years ago. Concerned from the community was to have proper notification of where the /20s will be allocated from so filters can be adjusted. Anne: APNIC will be not be starting with a fresh /8. We need to fill up some of the old blocks first. Randy: appreciates that and suggests to use certain ranges in a /8 and publish that. DFK: suggests to have in a machine readable format what the minimum allocation of this particular /8 for all RIRs. Richard: ARIN have stats for 1 year progress of using /20 allocations. Some organisations that received the contiguous /20 chose not to aggregate their two /20s into one /19. Randy: nothing he can do about that, but the routing registry can be used for that. In ARIN's one year experience with that policy how many of the organisations came back for an additional allocations ? Richard: 198 organisations received a /20. Initially 37 out those came back for an additional /20 within 1 year (less than 20%). Hesitant to free up those other /20s because that wouldn't be contiguous with another /20 (for another organisations) - tradeoffs to be made. DFK formulates the conclusion: start allocating /20 from 1.8.2000 and identify blocks concerned by 15.07.2000. These blocks should be as long as possible but not smaller than a/10. NCC also has plenty of space left in 213/8 & 62/8. NCC will allocate from 62/8 as normal. NCC will keep aggregation in mind but cannot guarantee it. 10. Name-based Web Hosting - Joao Luis Silva Damas Question to the floor; Is it reasonable to make all new requests compliant to http 1.1 ? ARIN makes it mandatory with some constraints. APNIC strongly discourages 1.0 WW: Do you have any estimate of the amount of address space that would be saved assuming one allows for exceptions. What do you think is the potential gain ? I usually do not like a solution that requires a list of exceptions to the default. Joao: address space saved is not as significant as with the change of minimum allocation change. Don't know the exact number. Randy: e-commerce requires an address per page. This is common practice now. Louis: What would be the burden on the NCC to enforce the policy change ? A: Is not that big a deal really, but NCC has the duty to review policies when there are alternatives out there to conserve address space. Security is still an issue, thats why 1.0 is still used. WW: uses the example of policies for dial up and now a large proportion of these users are moving to always-on access and get a fixed address anyway. It would not be worth changing the policy if we only safe a small amount of addresses but would have to review all kinds of exceptions. Anne: isn't there work in the IETF to upgrade http to allow name based hosting with SSL and e-commerce? Randy: yes, but it will take a long time until this will be deployed. Bill: in previous types of discussion when the general concept of LIRs/RIRs etc came out, the question was raised if the address delegation policies ???? If such a policy would be implemented he would want to have it temporary first. Bill: it is the RIRs duty to use appropriate diligence on protecting Internet resources. Randy agrees and thinks that the dial up policies had more a social effect in that the RIRs were watching. Maybe the web hosting issues will have a similar effect. He believes that people care about the right thing if they can do it. Rob believes that there will be a growing list of exceptions and it will be awkward for the NCC to check all this. Consensus is that the policies remains the way it is but that the NCC strongly recommends to do the right thing if possible. 11. AW's for registry's infrastructure (eg. headends) - Cathy Wittbrodt This was not really understood by the group. Some registries will only make address assignments that the NCC consider are part of their infrastructure. For example, cable operators. An AW is no use to them because no matter what the size AW they receive, any requests will still be above it and therefore it forces them to send in ALL requests to the NCC. Cathy thinks this is unfair to these type of LIRs and wants the policy changed to allow an AW to be given to its headends for example. Just some way so that they will not have to send in EVERY request, even when they are competent. This should be added to task force. There are many other providers out there who have the same problem as Cathy's "friend". Randy suggests to write this up and send it to the mailing list, because people might not clearly understand how that network is set up. Why is this different than ISPs with individual POPs ? They also only have one AW. 12. ripe-174 RIPE NCC Conflict Arbitration Procedure There has been a request to the RIPE NCC for the arbiters specified by RIPE-174 due to a dispute between two LIRs over address space. The RNA executive board have not until now created a pool of arbitrators. The reasoning between RIPE 174 was described to the audience and a call for nominations was put to the audience. Suggestions were to be sent to Axel Pawlik to be passed on to the RNA board. AOB Joao showed workload from Hm's per size of request. Could not really discuss it as there was a power failure. Joao was asked to put this and other stats on the web. From hph at online.no Fri Jul 28 21:16:19 2000 From: hph at online.no (Hans Petter Holen) Date: Fri, 28 Jul 2000 21:16:19 +0200 Subject: Open actions LIR-WG 36 Message-ID: <000201bff98a$6c73e180$43f5fea9@hph> 35.1 Chair Publish policy document 35.2 Chair publish election procedure 35.4 NCC PGP Key exchange procedure 35.5 NCC Implement PGP for hm 36.1 Chair Form 17th of May Task Force 36.2 KF/NCC Implement the recommended GPRS policy 36.3 NCC Publish address block allocation sizes by 0615 36.4 NCC Lower minimum allocation size from /19 to /20 not before 0801 36.5 Chair Assignment window applied on infrastructure 36.6 AP Collect arbitrators 36.7 NCC Keep lir-wg updated on pre RIR address space changes From hph at online.no Fri Jul 28 21:20:30 2000 From: hph at online.no (Hans Petter Holen) Date: Fri, 28 Jul 2000 21:20:30 +0200 Subject: Draft Agenda LIR-WG 37 Message-ID: <000401bff98a$722e4020$43f5fea9@hph> 1. Admin scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters 4. RIPE 35 minutes actions 5. Reports from the Registries RIPE NCC APNIC ARIN ICANN Status of the Latin and AFRI NiCs 6. Report from the address council 7. Presentations of candidates for the AC election 8. Status of the ICANN ad Hoc group 9. Report from the 17th of may Task Force 11. AOB.