- lir-wg - mailman.ripe.net

X-NCC RegID: UK.BTENT - Enterprise Registry Address Assignment Po licy
by adrian.pauling＠bt.com 01 Aug '00

01 Aug '00

Dear Hostmasters / LIRwg, I seek clarification on policy with respect to Enterprise Registry assignments, and have two fundamental areas for debate. Area 1: Enterprise vs. ISP LIR Assignment for non-ISP LIR Revenue Generation As an Enterprise Registry, should we be assigning IP addresses to Web Server Farms, which are part of the owning Corporate but not part of the ISP operation (ISP LIR, not the associated Enterprise LIR) ? At the IP level, web hosting server farm group are not revenue generating for the ISP operation, and they do not resell IP services as they only host web pages. They are revenue generating for the Corporate though. I believe they're paying commercial public rates to the ISP operation for their Internet connection. Initially the ISP LIR rejected an assignment request as the web hosting operation seems to be from the Corporate. Hence, they're requesting an assignment from the Enterprise LIR. The reverseDNS for the Enterprise is operated independently of the ISP operation. Should an Enterprise Registry assign the addresses? Area 2: Enterprise vs. ISP LIR Assignments for Corporate Pilots and Trials As the Enterprise LIR, we are often asked to assign addresses for pilots & trials of new technologies from teams within the Corporate Group. Such pilots and trials often become commercial revenue generating upon successful completion. At this stage the Enterprise address space ends up on a commercial service. Should the commercial service re-address upon successful completion ( causing operational costs and product launch difficulties ) using assignments from the ISP LIR? Do we transfer IP assignments from Enterprise LIR to ISP LIR registries? Regards, Adrian F Pauling :-)NEL2C Internet Protocol Manager acd Information Systems Engineering AFP1-RIPE / AFP-ARIN / AFP25-InterNIC * adrian.pauling(a)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

1 0

Open actions LIR-WG 36
by Hans Petter Holen 28 Jul '00

28 Jul '00

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

1 0

Draft minutes v1 LIR-36
by Hans Petter Holen 28 Jul '00

28 Jul '00

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 <not done yet> 35.2 Chair Publish election procedure <not done yet> 35.3 WG Subscribe lir-wg <ongoing> 35.4 NCC PGP Key exchange procedure <ongoing ?> 35.5 NCC Implement PGP for hostmaster mail <ongoing ?> 35.6 NCC Make db checking tool available for self audit <DONE, see mailing list> 35.7 Chair Task Force on addresses to GPRS infrastructure <DONE, results at EOF and later in WG> 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.

1 0

REMINDER: RIPE NCC ADDRESS POLICY CHANGE
by Nurani Nimpuno 27 Jul '00

27 Jul '00

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

1 0

scheduled downtime of RIPE NCC network
by Monica Cortes 26 Jul '00

26 Jul '00

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(a)ripe.net. Regards, --Monica Cortes

1 0

Re: a few matters about security and consistency
by Nigel Titley 14 Jul '00

14 Jul '00

> > 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)

1 0

a few matters about security and consistency
by Mark Lastdrager 14 Jul '00

14 Jul '00

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(a)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(a)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.

11 16

Duplicate mails
by NCC local-ir list Moderator 07 Jul '00

07 Jul '00

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

1 0

RE: a few matters about security and consistency
by adrian.pauling＠bt.com 06 Jul '00

06 Jul '00

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(a)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@pine.nl] > Sent: 05 July 2000 21:53 > To: lir-wg(a)ripe.net > Cc: cert(a)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(a)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(a)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. > > > > >

1 0

R: a few matters about security and consistency
by Alessandro.Pelosi＠swisscom-italy.com 06 Jul '00

06 Jul '00

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@pine.nl] Inviato: mercoledì 5 luglio 2000 22.53 A: lir-wg(a)ripe.net Cc: cert(a)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(a)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(a)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.

4 3