November 2011 - members-discuss

Executive Board Activity Since the RIPE NCC General Meeting
by Nigel Titley 22 Dec '11

22 Dec '11

Dear all, We would like to give you an update on the thoughts and decisions of the RIPE NCC Executive Board since the RIPE 63 Meeting and RIPE NCC General Meeting three weeks ago. On Friday, 18 November, the Executive Board met for a teleconference to review the events and discussions that took place during that very busy week. First of all, we were all very pleased by the opportunity to meet so many of our members; we appreciate the lively discussions and see them as a sign that the RIPE NCC membership is very much alive and kicking. Thank you all for your contributions, whether they took place here on the mailing list or at the microphones in Vienna. The main business we conducted during our Board meeting revolved around the Charging Scheme, Budget and Activity Plan for 2012, as you would probably expect. As the proposed Charging Scheme did not find sufficient support, we will use the 2011 Charging Scheme for 2012. Because the 2011 Charging Scheme does not explicitly say that legacy space resources will have no impact on membership fees, the Board has decided to formally waive fees for legacy space resources for the coming year. With a view towards a sustainable and member-supported Charging Scheme, the Board would like to call for a small task force of RIPE NCC members and RIPE NCC staff to work together with Executive Board members on models for such a new Charging Scheme. Axel will work with his staff on a draft charter for this task force. Further to comments made during the General Meeting, we asked Axel to ensure a better alignment between the Activity Plan and Budget structures. On the Budget, having examined our options in order to reduce the effects on the services we offer to members, we have made a reduction in costs of approximately 2%, mainly in the areas of Travel, RIPE meeting organisation and Training efficiency: especially as these were highlighted as suitable areas for economies by the membership. On the income for 2012, we are are now expecting a slight surplus because new members and holders of independent resources will remain a strong source of income. The membership also voted to have the RIPE NCC continue with development of Resource Certification (RPKI) including route object authorisations (ROAs). However the Board recognises that a number of concerns were raised about certification and will ensure that those concerns are taken into account as development goes ahead. You can find the minutes of the Executive Board teleconference at: https://www.ripe.net/lir-services/ncc/executive-board/minutes/draft-minutes… If you have any further questions or comments, please do not hesitate to contact us at <exec-board(a)ripe.net>. Kind regards, Nigel Titley Chairman, Executive Board

4 5

IDAQ joins an exclusive club
by Nigel Titley 30 Nov '11

30 Nov '11

I see that IDAQ has joined PrivateLayer in the exclusive club of those members who have subscribed their ticket robots to the RIPE member-discuss list. Welcome to the IDAQ-ticket robot, and congratulations on achieving sentience. We will look forward to your contributions to the discussion list with interest. Nigel (waiting in Moscow airport for my flight back to strike-hit Heathrow)

1 0

What to do
by Comunicaciones ACOTELSA 24 Nov '11

24 Nov '11

Hi all. We have detected a DoS from IP of APNIC, from China. Are there a procedure to inform APNIC or RIPE about the problem or the only way is inform to the WHOIS contact? Thanks in advance. Saludos... =========================================== Luis Ángel Lozano Aparicio Comunicaciones y Seguridad Grupo Acotel e-mail: comunicaciones(a)acotelsa.com ------------------------------------------ Tlf: 983 440274 - 902 194273 Fax:983 548220 Oficina 201 - Edificio Galileo, módulo Rojo Parque Tecnológico de Boecillo 47151 Boecillo (Valladolid) - España =========================================== Protección de Datos: ACOTELSA le informa de que los datos facilitados por Ud. y utilizados para el envío de esta comunicación serán objeto de tratamiento automatizado o no en nuestros ficheros, con la finalidad de gestionar la agenda de contactos de nuestra empresa y para el envío de comunicaciones profesionales por cualquier medio electrónico o no. Vd. podrá en cualquier momento ejercer el derecho de acceso, rectificación, cancelación y oposición en los términos establecidos en la Ley Orgánica 15/1999. El responsable del tratamiento es ACOTELSA, con domicilio en Ronda de Poniente, 3 bajo, 28760 Tres Cantos, Madrid. Confidencialidad El contenido de esta comunicación, así como el de toda la documentación anexa, es confidencial y va dirigido únicamente al destinatario del mismo. En el supuesto de que usted no fuera el destinatario, le solicitamos que nos lo indique y no comunique su contenido a terceros, procediendo a su destrucción. Gracias. Confidenciality The content of this communication and any attached information is confidential and exclusively for the use of the addressee. If you are not the addressee, we ask you to notify to the sender and do not pass its content to another person, and please be sure you destroy it. Thank you.

8 8

Re: [members-discuss] What to do
by sslavov＠blizoo.bg 22 Nov '11

22 Nov '11

Contact the Persons in the WHOIS database, your UPLINK Provider AND BLOCK IP RANGE. Best regards. Stoyan > > RIPE, APNIC or any of the other RIRs only handle administrative issues > wrt the allocation and distribution of IP addresses, AS numbers etc. > They have no "power" over the network of any ISP. > > You should contact the persons in the WHOIS, and at the same time, you > should contact your upstream provider and ask them if they can see where > the DOS originates and if they can perhaps block it for you. > > Do remember that IP packets can be spoofed, the source address of the > DOS packets may say "this originated from 243.1.2.3" but perhaps it is a > completely different network that is sending you the packets - your > upstream provider might be able to pinpoint the actual source. > > Mike. > > On 22-11-11 4:41 PM, Comunicaciones ACOTELSA wrote: >> Hi all. >> >> We have detected a DoS from IP of APNIC, from China. >> >> Are there a procedure to inform APNIC or RIPE about the problem or the >> only >> way is inform to the WHOIS contact? >> >> Thanks in advance. >> >> >> Saludos... >> >> =========================================== >> Luis Ángel Lozano Aparicio >> Comunicaciones y Seguridad >> Grupo Acotel >> e-mail: comunicaciones(a)acotelsa.com >> ------------------------------------------ >> Tlf: 983 440274 - 902 194273 Fax:983 548220 >> Oficina 201 - Edificio Galileo, módulo Rojo >> Parque Tecnológico de Boecillo >> 47151 Boecillo (Valladolid) - España >> =========================================== >> >> >> >> >> >> Protección de Datos: ACOTELSA le informa de que los datos facilitados >> por Ud. y utilizados para el envío de esta comunicación serán objeto de >> tratamiento automatizado o no en nuestros ficheros, con la finalidad de >> gestionar la agenda de contactos de nuestra empresa y para el envío de >> comunicaciones profesionales por cualquier medio electrónico o no. Vd. >> podrá en cualquier momento ejercer el derecho de acceso, rectificación, >> cancelación y oposición en los términos establecidos en la Ley Orgánica >> 15/1999. El responsable del tratamiento es ACOTELSA, con domicilio en >> Ronda de Poniente, 3 bajo, 28760 Tres Cantos, Madrid. >> >> Confidencialidad El contenido de esta comunicación, así como el de toda >> la documentación anexa, es confidencial y va dirigido únicamente al >> destinatario del mismo. En el supuesto de que usted no fuera el >> destinatario, le solicitamos que nos lo indique y no comunique su >> contenido a terceros, procediendo a su destrucción. Gracias. >> >> Confidenciality The content of this communication and any attached >> information is confidential and exclusively for the use of the >> addressee. If you are not the addressee, we ask you to notify to the >> sender and do not pass its content to another person, and please be sure >> you destroy it. Thank you. >> >> >> >> ---- >> If you don't want to receive emails from the RIPE NCC members-discuss >> mailing list, please log in to your LIR Portal account and go to the >> general page: >> https://lirportal.ripe.net/general/view >> >> Click on "Edit my LIR details", under "Subscribed Mailing Lists". From >> here, you can add or remove addresses. >> > > ---- > If you don't want to receive emails from the RIPE NCC members-discuss > mailing list, please log in to your LIR Portal account and go to the > general page: > https://lirportal.ripe.net/general/view > > Click on "Edit my LIR details", under "Subscribed Mailing Lists". From > here, you can add or remove addresses. >

1 0

Re: [members-discuss] Update on police order of 8 November
by Brandon Butterworth 16 Nov '11

16 Nov '11

> Please keep in mind, I'm not a laywer Likewise but it appears to be totally unnecessary action that establishes precedent for other more intrusive requests later > - These punishable facts are an immediate threat to the Dutch public order. Seems quite unlikely that there will be public disorder as a result of malware, at least to the extent freezing registry entries would prevent. > o The suspects in the US investigation will transfer the control of > the relevant registrations of a couple specific IP ranges in the > public register. > o The suspects in the US investigations will alter the > relevant registration(s) of a specific set of IP ranges in the > public register, unless specifically approved by the FBI of the > US attorney's office for the Southern District of New York. Why would that matter as long as they made an evidence record of what it was at this time. There's lots of things the suspects may do during the course of an investigation, like just live their normal lives. brandon

1 0

Update on police order of 8 November
by Axel Pawlik 16 Nov '11

16 Nov '11

Dear all, In the interest of transparency, I'd like to update you on the Dutch police order issued to the RIPE NCC on 8 November 2011 to temporarily lock a registration of four IP address blocks in the RIPE Registry until 22 March 2012. As mentioned earlier, we are working on full disclosure of the background documents. You can read a copy of the police order here: https://www.ripe.net/lir-services/member-support/police-order-8-november-20… We will update you if and when any other publishable materials become available. We have received independent legal advice and are in discussion with the appropriate authorities. We intend to pursue this matter further in Dutch court to establish a precedent so that we are certain of our rights regarding such orders. The RIPE NCC is committed to acting in the best interest of its membership and we will continue to inform you and the Internet community on this matter as it progresses. I'd also like to take this opportunity to clarify that we have not withdrawn, removed or reclaimed the address blocks in question. kind regards, Axel

2 2

NCC acting on registrations pursuant to "police order"?
by Sascha Luck 14 Nov '11

14 Nov '11

All, in the recent discussion on RPKI, it was stated by the NCC that it would not act on resource registrations (and, by extension, certificates and ROAs) without a valid Dutch court order. According to: http://www.ripe.net/internet-coordination/news/about-ripe-ncc-and-ripe/ripe… ther NCC has blocked changes to registered resources pursuant to "an order from Dutch police". Now, I'm not overly familiar with the Dutch legal system but in ours, a court order is different from a "police order". Considering the implications for, in particular, RPKI; could someone from the NCC confirm that this was, in fact, on foot of a court order? Alternatively, is a "police order" something equivalent, eg an order that must be followed on pain of legal sanction?` Regards, Sascha Luck

11 12

Re: [members-discuss] [#22756] Re: FW: NCC acting on registrations pursuant to "police order"?
by Sven Olaf Kamphuis 12 Nov '11

12 Nov '11

Security expert Ronald Prince of forensic firm Fox-IT across all Macworld speculated that this action may be related to the rolling up of the DNS gang. "De DNS-servers draaiden op bepaalde ip-adressen. Nu zijn die vervangen door servers van de politie zelf." "The DNS servers were running on certain IP addresses. Now those servers replaced by the police themselves." ah so-called "security expert" and well known sockpuppet of the amerifags, ronald prins, is at it again... when he's not too busy persecuting the international souvereign military order of internet knights that is anonymous, he's always to be found to make some foolish statements in the press. The rolled malware gang has four million PCs worldwide able to infect. This is done through rogue DNS servers. NO -THIS IS DONE THROUGH MICROSOFT WINDOWS-, go and arrest bill gates for selling utter crap that doesn't belong on a network in the first place, and not fixing it on purpose although code is much easier to fix than to maintain a dictionary of search strings for 'known' virus code that exploits it. Prince says that the RIPE-blocking by the Dutch police can ensure that the infected computers keep their connection. Only is it not the rogue machines, but the police servers. " And that solves the problem ... how exactly... the next virus will show up and microsoft continue keep sell crap and isn't even being blamed by this rather pro-american so-called "security" expert. i'd say, flash the god damn biosses with an advertisement that gets them to the mac store, or force install ubuntu if you're already taking over a botnet anyway :P the dutch police gets paid by dutch taxpayers to protect dutch/european interests, not those of mickeysoft or the usa, or to run after people that exploit bugs (probably purposely) not fixed by microsoft to keep their "anti virus industry" buddies in business. i'd say, this whole thing is EASILY solved by a forced update of windows, on THEIR side of the ocean, i see no need to waste further european tax money on whatever that god damn ex-colony of amsterdam wants. (and while we're at the subject, why on earth do we let them sell that crap in our stores ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven(a)cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Fri, 11 Nov 2011, support(a)privatelayer.com wrote: > Dear Valued Private Layer Customer, > > > Our tech support department has received your message in good order and we have assigned a ticket number to your request. > > The ticket number assigned is: 22756. We are reviewing your ticket and will reply to it shortly. > > > Best Regards, > > Private Layer INC > Tech Support Department > support(a)privatelayer.com >

1 0

Re: [members-discuss] FW: NCC acting on registrations pursuant to "police order"?
by Erik Bais 11 Nov '11

11 Nov '11

Hi Brandon, >>> 1 Each Party shall adopt such legislative and other measures as >>> may be necessary to enable its competent authorities to order or >>> similarly obtain the expeditious preservation of specified computer >>> data > >It's just preservation, it doesn't say prevention of new data creation (you'd have to preserve that too) >It would just be a limitation of the RIPE systems if they have to lock an account to ensure retention of data, they could implement other means to provide a preserved data trail while leaving the account active. Your statement might be true and is also the problem with international ratification of Treaties and the underlying national implementation into the law. In this case, the question would be, what was the actual request from the Police, in order to get some more detail on it. If a preservation of information would have been enough or if a freeze of an account would be required. An online copy of the actual request from the KLPD in that case would be nice, where the personal details can be removed with black marker to protect the innocence etc. (blah blah .. ;-) ) I can only imagine that the operational system of RIPE would not have been designed to comply with anything like a Data retention act in mind. (Off-topic: Which in the Netherlands is still on 12 months btw.) So was the locking of the accounts towards the RIPE systems or freezing of the subnets, was it about the LIR portal, the associated maintainer passwd, or something else, like preventing them from doing changes to rev. dns. ? Or was it about avoiding transfers or changes in the Whois DB ? And instead of dealing with all the fuzz of the above, RIPE NCC might have taken the route of ... disable the accounts and wait ... Which is a perfectly good action imho as it would freeze the evidence present and the people involved would only notice it when they would actually need to make changes. Questions .. questions .. And only a few that know. Erik

3 2

Re: [members-discuss] FW: NCC acting on registrations pursuant to "police order"?
by Brandon Butterworth 11 Nov '11

11 Nov '11

>> 1 Each Party shall adopt such legislative and other measures as >> may be necessary to enable its competent authorities to order or >> similarly obtain the expeditious preservation of specified computer >> data It's just preservation, it doesn't say prevention of new data creation (you'd have to preserve that too) It would just be a limitation of the RIPE systems if they have to lock an account to ensure retention of data, they could implement other means to provide a preserved data trail while leaving the account active. brandon

1 0