2010-09 New Policy Proposal (Frequent Update Request)
Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-09.html We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 7 December 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC
What happens if: * A named maintainer for a assigned subnet is not a LIR in their own right? * There is a typo in an email address and it bounces? * A small LIR with only one maintainer (or even just a PERSON object) is unable to respond, say for instance they had a car accident or something? Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Ltd M: 07795 840385 jamie.stallwood@imerja.com NIC: uk.imerja.JS7259-RIPE -----Original Message----- From: anti-abuse-wg-admin@ripe.net [mailto:anti-abuse-wg-admin@ripe.net] On Behalf Of Emilio Madaio Sent: 09 November 2010 14:50 To: policy-announce@ripe.net Cc: anti-abuse-wg@ripe.net Subject: [anti-abuse-wg] 2010-09 New Policy Proposal (Frequent Update Request) Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-09.html We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 7 December 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC -- Imerja Limited Tel: 0870 8611488 | Fax: 0870 8611489 | 24x7 ISOC: 0870 8611490 | Web: www.imerja.com Registered Office: Paragon House, Paragon Business Park, Chorley New Road, Horwich, Bolton BL6 6HG Registered in England and Wales No. 5180119 VAT Registered No. 845 0647 22 ISO Registered Firm No. GB2001527 This email is confidential and intended solely for the person or organisation to which it is addressed. It may contain privileged and confidential information. If you are not the intended recipient(s) you should not use, copy, distribute or take any action or reliance on it, since to do so is strictly prohibited and may be unlawful. If you have received this transmission in error please notify the sender immediately by email reply and delete it from your system. E-mail messages are not secure and attachments could contain software viruses which may damage your system. Whilst every reasonable precaution has been taken to minimise this risk, Imerja Limited cannot accept any liability for any damage sustained as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. Any views or opinions expressed in this e-mail are solely those of the author and do not represent those of Imerja Limited unless otherwise stated.
Le 09/11/2010 16:03, Jamie Stallwood a écrit :
What happens if:
* A named maintainer for a assigned subnet is not a LIR in their own right? * There is a typo in an email address and it bounces? Well, mail delivery status are easy to check :)
* A small LIR with only one maintainer (or even just a PERSON object) is unable to respond, say for instance they had a car accident or something?
As it is a function abuses normaly point in best case scenario to a ticketing system where mail should be archived & then dispatched to a person, but where anyone could take over the historic in case something happens. It also permits auditing... Ticketing system are usually linked to best practices such as evaluating urgency/importance of mails before dispatching them to different teams, and these systems scale & are easy to install so even one single person could use it without any noticeable drawbacks & some interests (such as easily handing over some of the tickets when the load grows). And since support is a well documented function of the enterprise and its tools are pretty easy to use ... there should be no worries. -- Julien Tayon
-----Original Message----- From: anti-abuse-wg-admin@ripe.net [mailto:anti-abuse-wg- admin@ripe.net] On Behalf Of Emilio Madaio Sent: Tuesday, November 09, 2010 4:50 PM To: policy-announce@ripe.net Cc: anti-abuse-wg@ripe.net
A new RIPE Policy Proposal has been made and is now available for discussion.
You can find the full proposal at:
http://ripe.net/ripe/policies/proposals/2010-09.html
We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 7 December 2010.
Under “Arguments supporting the proposal”, the argument “More people will use the LIR Portal” is listed. I wonder why increased admin workload and increased system load would be advantages. Under “Arguments opposing the proposal”, the proposal states that no disadvantages are foreseen. That view seems rather disconnected. Did we not already have a discussion where at least one representative of a large LIR indicated that clicking ”OK” for a zillion objects every 12 months would constitute a major burden? -- Thor Kottelin http://www.anta.net/
already have a discussion where at least one representative of a large LIR indicated that clicking ”OK” for a zillion objects every 12 months would constitute a major burden?
We're not a very large LIR, but we still have ~4,500 objects with our maintainers. We update objects when our contact details change. If a proposal similar to this is to go through, I'd like to be able to click a button that performs an ack for all objects with our maintainer. Rob
Am 09.11.2010 15:50 schrieb Emilio Madaio:
A new RIPE Policy Proposal has been made and is now available for discussion.
many times I was annoyed about obviously wrong data in the ripe/arin/* databases. validating data about an ipblock owner makes sense... +1 -- Andreas Schulze Internetdienste | P532 DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info @datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender) Dipl.-Kfm. Michael Leistenschneider Jörg Rabe v. Pappenheim Dipl.-Vw. Eckhard Schwarzer Vorsitzender des Aufsichtsrates: Reinhard Verholen
Hello, I recall when ARIN was discussing automatically marking non-responsive contacts in their database, a concern did come up. The concern was that address hijackers would have an excellent pre-filtered list of networks that are likely to be poorly maintained. A spammer could: 1. Download the latest list of non-responsive object owners. 2. Download the latest list of inetnum in the RIPE Database. 3. Extract out the network ranges with non-responsive object owners. 4. Find those network ranges that also happen to be missing from BGP. 5. Advertise those ranges. 6. Send spam from those ranges. 7. Profit! Since the spammer knows that the mail for these ranges don't work, she can be pretty sure that it will take a while for the good guys to figure out what is going on. By that time she's sipping cocktails on the beach. I am not opposed to having regular checks of contact information. I am not even opposed to providing a public view of the "quality" of contact information, as proposed in 2010-09. However, perhaps a better way forward would be to make this something handled in the context of the RIPE NCC/LIR relationship. Keeping in mind that these are people who have been contacted via the LIR Portal and e-mail, they need to be encouraged to care a bit. There are several ways this could be done: * Changing the contact information on the maintainers to the contact for the LIR, along with an appropriate message explaining it (I think the LIR contact information is corrected at least often enough to send an annual invoice) * Require checking of maintainer information before receiving future RIPE NCC registration services (this will probably be less important post-IPv4 runout... what services do I need after I get my IPv6 /32 block!?!) * Adding a penalty in the annual membership fees if maintainer information is not confirmed (I suppose this could be named a "Good Quality Discount" instead, but that amounts to the same thing) * Revoking the resources from the LIR The problem here, as always, is that LIRs set the policies, and I think they are unlikely to approve a policy that can be used against them. I doubt the RIPE NCC actually wants to enforce this kind of stuff either! -- Shane
In the ARIN region we attempted to safe guard against the list being missued, by making the data available only to entities who have qualified to obtain bulk whois data from ARIN. In order to obtain bulk whois data, you must sign an agreement with ARIN and meet certain qualifications: https://www.arin.net/resources/services/poc_validation_readme.html Ideally, the data would be used for good and not evil -- that service providers would check against the list before permitting a prefix to be announced. --Heather On Wed, Nov 10, 2010 at 8:18 AM, Shane Kerr <shane@time-travellers.org> wrote:
Hello,
I recall when ARIN was discussing automatically marking non-responsive contacts in their database, a concern did come up. The concern was that address hijackers would have an excellent pre-filtered list of networks that are likely to be poorly maintained.
A spammer could:
1. Download the latest list of non-responsive object owners. 2. Download the latest list of inetnum in the RIPE Database. 3. Extract out the network ranges with non-responsive object owners. 4. Find those network ranges that also happen to be missing from BGP. 5. Advertise those ranges. 6. Send spam from those ranges. 7. Profit!
Since the spammer knows that the mail for these ranges don't work, she can be pretty sure that it will take a while for the good guys to figure out what is going on. By that time she's sipping cocktails on the beach.
I am not opposed to having regular checks of contact information. I am not even opposed to providing a public view of the "quality" of contact information, as proposed in 2010-09.
However, perhaps a better way forward would be to make this something handled in the context of the RIPE NCC/LIR relationship.
Keeping in mind that these are people who have been contacted via the LIR Portal and e-mail, they need to be encouraged to care a bit. There are several ways this could be done:
* Changing the contact information on the maintainers to the contact for the LIR, along with an appropriate message explaining it (I think the LIR contact information is corrected at least often enough to send an annual invoice) * Require checking of maintainer information before receiving future RIPE NCC registration services (this will probably be less important post-IPv4 runout... what services do I need after I get my IPv6 /32 block!?!) * Adding a penalty in the annual membership fees if maintainer information is not confirmed (I suppose this could be named a "Good Quality Discount" instead, but that amounts to the same thing) * Revoking the resources from the LIR
The problem here, as always, is that LIRs set the policies, and I think they are unlikely to approve a policy that can be used against them. I doubt the RIPE NCC actually wants to enforce this kind of stuff either!
-- Shane
participants (8)
-
Andreas Schulze -
Emilio Madaio -
Heather Schiller -
Jamie Stallwood -
julien tayon -
Rob Evans -
Shane Kerr -
Thor Kottelin