- db-wg - mailman.ripe.net

Re: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01
by h.lu＠anytimechinese.com 08 Mar '16

08 Mar '16

Hi I fail to understand how spammer are legal in certain country has to do with my reasoning or logic. The argument is about if there is managing position for community to take, my answer is no, we are not law enforcement and we only do book keeping, we don't tell people what to do, if they want to be good guy, great, if they don't care about spam or any abuse so to say, ok, it's their call. Making things mandatory with no real enforcing power are just not working. So make logic simple to understand, if the abuse is serious as crime, you don't need abuse c to get the right person(law enforcement has much better way than ripe db), if it is not serious as crime, if the op cares, with or without abuse c they will have their abuse contact there, and will deal with it. For ops don't care, with or without abuse c, they still don't care. So you can put up an extra line ask people to fill, but I don't think it makes much difference. > On 4 Mar 2016, at 20:00, Jeffrey Race <jrace(a)post.harvard.edu> wrote: > > Dear Lu, > > Your reasoning fails the logic test because you do not cognize the mismatch > between the operation of "law to enforce things" and the spammer business > model. The loss to no single victim rises above the threshold to initiate > either criminal or civil proceedings. The spammers organize their business > model in this way expecting most people to have your attitude. > > This is clearly explained in > > <http://www.jeffreyrace.com/nugget/spam_05.pdf> > > Kind regards, > > Dr. Jeffrey Race, President > Cambridge Electronics Laboratories > 20 Chester Street, Somerville MA 02144-3005 > Tel +1 617 629-2805 Fax +1 617 623-1882 > > Avoid spinal damage from computer use! > Read "Cripples by Thirty?" > > <http://www.camblab.com/nugget/nugget.htm> > > --Original Message Text--- > From: Lu Heng > Date: Fri, 4 Mar 2016 14:20:28 +1300 > > Hi there: > > I think the whole notion about we are managing the internet though the policy are not correct. > > > We are not managing the internet, we are book keeping really. > > > Denis, your argument standing on a group that if we do not manage the internet, the gov will step > in and do it for us, but that is largely untrue. > > > The Gov are managing it now as we speak, they have something called law to enforce things, they > really don't need bother to go though policy here to block content they dislike, bust people they > think are bad, find people are responsible, if there is a seriou crime going on, with or without > abuse-c, gov will find them or not---abuse c does not change the outcome. > > > Take China for example, A 500 m user can not access Facebook, tell me they go though any sort of > APNIC policy to do that, same goes for some countries inA Middle East. > > > So my last point is. If you like their gov job, you can apply one, don't try to push community here > to do gov's job. > > > On Friday 4 March 2016, denis <ripedenis(a)yahoo.co.uk> wrote: > Hi Peter > > OK lets cut to the bottom line. Does anyone NOT agree with these points: > > -Internet abuse (in it's various forms) is considered both a nuisance and a danger by the publicA > -Politicians will jump onto any band wagon that has popular public support and enhances their > careers > -Responsible internet resource management includes receiving and handling abuse complaints related > to the networks you manage > > If we all supported these points, especially the last one, then in an ideal world all network > managers would be happy to provide abuse contact details and would take action on complaints > received. > > Unfortunately we don't live in that ideal world. The fact that so many experienced technical > internet people are opposing this policy worries me. So many of you are fixating on this point > about 'mandatory', 'enforcing', 'justifying'. If everyone agreed with point 3 above then you would > all be willing to do this voluntarily anyway. So what difference does it make to those of you who > do this anyway if it is mandatory? > > But we know some people simply can't be bothered to handle abuse complaints and we also know some > people make money by providing services to the abusers. There is no point pretending this does not > happen. If there is a lot of money to be made some people will want a slice of it. That is why this > has to be mandatory. > > When abuse-c was first introduced it was made clear that this was the first step of a process. The > intention was for all IP addresses within the RIPE region to have one common way of documenting an > abuse contact that can be accessed programatically. It was also made clear that this first step had > nothing to do with whether anyone responds to reports sent to that contact. Because it was and > still is clear that some people don't want to publicise any abuse contact details it had to be and > still has to be mandatory. If you enter data into the RIPE Database you are required to ensure it > is correct. Dealing with whether anyone responds to the reports sent to this contact is a separate > issue and should not cloud the discussion on the abuse-c information in the RIPE Database. Neither > should the technical implementation of the abuse-c attribute. > > I know there are policies about policies for legacy resources. Personally I think that is crazy. > All IP addresses are technically the same no matter how or when you acquired it. Abuse can come > from any one of them. > > I don't know why we are making the policy side so complicated. The principle is simple. If you > manage IP addresses in the public domain, from where abuse can be generated, responsible management > requires you to provide abuse contact details!!! > > cheers > denis > > On 03/03/2016 23:30, Peter Koch wrote: > On Thu, Mar 03, 2016 at 11:46:45AM +0100, denis wrote: > > In these days of political interest in how the internet is 'managed' the > RIRs need to do more than 'just maintain an accurate registry'. The > > > indeed. The community should be careful to maintain and improve the > credibility and legitimacy of its policy development process. > ``Extra constitutional'' activity (imposing "abuse" handling procedures > camouflaged as syntax changes to database objects) and retroactive > changes to policy without an exceptional justification both aren't > helpful. > > 2016-01 claims "Better data quality", which is not backed with arguments. > 2016-01 claims "More accurate data for abuse contact", which is not > A A A A A supported by arguments or evidence/precedent. > > internet is a crucial part of modern life. Abuse is considered to be a > serious problem. What you are saying is that you don't give a dam about > abuse and are not interested in being part of the management of abuse. > > > The alleged correctness of data does not imply a "right to response" (cf ripe-563), > and rightfully so.A Therefore the claims that refusal to add abuse-c > would imply refusal to deal with abuse reports are pointless, since > the sheer presence of the attribute does not imply anything, either. > > Also, I have not heard RA¬diger (or anyone else) claim they would not > want to even add abuse-c - it's making this policy mandatory what is > being contested.A ripe-639 re-establishes the 'special role' of > legacy resources as exempt from policy changes: > > A A A A Any existing or future RIPE policy referring to resources shall not apply > A A A A to legacy resources unless the policy explicitly includes legacy resources in its > scope. > > Now, if that was simply a matter of a boilerplate in any future policy > (xxx shall also apply to legacy resources), this clause would not make > the slightest sense.A Consequently, a special consideration is needed. > 2016-01 simply refers to inconsistency (obviously a simple consequence > of ripe-639 and thus not exceptional) and "better data quality" - without > justification.A No indication is given of any harm caused by legacy > resources currently not subject to ripe-563.A ripe-563/ripe-639 > do not preclude use of abuse-c for legacy resources, either. > > All in all, I understand the motivation behind 2016-01, but the reasoning > is far too poor to justify proceeding with the proposal. > > -Peter > > > > > > > > -- > -- > Kind regards. > Lu > > > > > > >

9 19

Re: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01
by h.lu＠anytimechinese.com 05 Mar '16

05 Mar '16

Hi guys: I think I really should make myself clear here. (Sorry for sending 3 mails in a row as I just realise people are taking to me one by one) I do not against abuse c or support it, I just don't think it will make much difference. That's all I have to say about abuse c. However, I do against the idea "if we not managing the internet the gov will step in and take over". The last thing I would want the community is doing the gov's managing job for them. So that's what my last email about. > On 5 Mar 2016, at 08:32, andre(a)ox.co.za wrote: > > On Fri, 4 Mar 2016 17:55:16 +0000 > Michele Neylon - Blacknight <michele(a)blacknight.com> wrote: > <snip> >> >> We are not managing the internet, we are book keeping really. > [...] > > If you are correct (and imho you are) > > the whole point of book keeping is to have accurate data and records > > so, pick your poison. All POV leads to exactly the same thing: the ncc > needs accurate abuse-c as much as any of the other data.

1 0

Re: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal
by Marilson 04 Mar '16

04 Mar '16

Hello I am also impressed and concerned with the old, inopportune and improper posture of the gentlemen Randy Bush and Gert Doering. Denis, it is gratifying to hear someone concerned about the future of the Internet and with the exponential increase in the abuse. Greed, not wanting to plagiarize Gordon Gekko, reigns absolute and moves the wheels of the global economy. The agenda is: cheat as much as you can, just try not to get caught. HSBC and Volkswagen are the portrait of this posture unethical where the end, profit, justifies the means. You all have the opportunity to do the right thing. How do you want to be remembered? Or you start a remediation process of such abuses or will be done by rulers (governments) pressured by the world's population. Thanks Marilson

3 2

Cleanup work for "abuse-mailbox:" in certain ORGANISATION objects, following policy 2011-06
by Tim Bruijnzeels 04 Mar '16

04 Mar '16

Dear working group, As you know, the RIPE NCC completed the work for the 2011-06 policy on 15 February, and "abuse-c:" is now added to all organisations that hold resources allocated or assigned by the RIPE NCC. Going forward we propose to: - Remove "abuse-mailbox:" for all ORGANISATION objects that *have* "abuse-c:" in a one-off operation - Introduce a business rule to prevent adding "abuse-mailbox:" to ORGANISATION objects, urging people to use "abuse-c:" instead Please note that the proposal above does not force anyone to use "abuse-c:", it just enforces that "abuse-c:" is used instead of "abuse-mailbox:". Having both attributes on an ORGANISATION object is extremely confusing, and currently updating "abuse-mailbox:" does not work in the LIR Portal organisation object editor. We therefore believe that the cleanup is needed, and we hope that this will not be controversial. We would like to ask the working group for the mandate to do the cleanup proposed above. Originally the intent was to clean up "abuse-mailbox:" on all objects (except in abuse-c roles) and possibly IRT objects. However, we are fully aware that more controversy exists here. There is a lot of discussion about whether "abuse-c:" can be mandatory for organisations holding legacy resources (2016-01). Questions are being raised about the data model. We are following these discussions with interest and we believe that this part of the originally proposed cleanup should be put on hold until we have a more clear direction from those discussions. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

2 1

Re: [db-wg] [anti-abuse-wg] objection to RIPE policy proposal 2016-01
by Gert Doering 03 Mar '16

03 Mar '16

Hi, On Thu, Mar 03, 2016 at 12:56:05PM +0200, andre(a)ox.co.za wrote: > it is actually very simple: > > any rigorously correct resource allocation registry data must > include accurate abuse records. No. It needs to contain accurate records of who has been delegated responsibility for that (admin-c / org). abuse-c is a way to ease finding the *right* contacts instead of always having to write paper mail to the company CEO - and that makes sense, but it's a convenience to operators (as is tech-c), and in no means required for the function as registry. Which might conincide with the fact that the paperwork you sign when opening a LIR has no field for abuse-c... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

4 4

[training] RIPE NCC Training Courses April-June 2016
by Training Services 29 Feb '16

29 Feb '16

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Budapest, Tirana, Manchester, Lisbon, Bologna, Munich, Tallinn, Moscow, Vienna, Valletta, Reykjavik. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - Basic IPv6 Training Course - DNSSEC Training Course - 2 days Advanced IPv6 Training Course - 2 days BGP Operations and Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

RIPE DB services downtime
by Thiago da Cruz Pereira 19 Feb '16

19 Feb '16

Dear working group, Later today, we’re going to restart our servers to apply a patch. A short downtime to updates is expected and queries will not be affected. Kind regards, Thiago da Cruz Software Engineer - Ripe Database Team

1 1

RIPE NCC to set abuse-c for remaining organisation with ASNs or other resources allocated or assigned by the RIPE NCC
by Tim Bruijnzeels 19 Feb '16

19 Feb '16

Dear working groups, As you know all organisations that have internet number resources allocated or assigned by the RIPE NCC need to have an abuse-c attribute according to policy 2011-06. The following implementation plan was communicated for this policy: https://labs.ripe.net/Members/kranjbar/implementation-details-of-policy-201… Phase 1 of this plan was completed in December 2013, setting up abuse-c for then existing LIRs. Phase 2 of this plan was completed for organisations holding sponsored PI resources in November 2014. However, since then LIRs and end-users have been responsible for ensuring that an abuse-c exists for their organisation. In practice it has proven difficult to enforce this, since abuse-c is not a mandatory attribute in the RIPE DB schema, and as a result new cases where organisations do not have an abuse contact have been created. There is an important change in the implementation we would like to do – based on our experiences thus far – which would like the community's mandate on. We propose to use the end-user organisation's email address instead of the sponsoring LIR email address. We believe there are valid reasons for this change, but of course if this suggested change is controversial we would encourage discussing it in the anti-abuse working group. Ideally, we need to have a decision on this by early January so that we can prepare the work. 1) Prevent NEW cases We want to ensure that no new cases will be created as follows: = Since 1 March, the new member application form already provides much better integration with the RIPE Database - because of this an abuse contact is now created whenever a new LIR is activated - it can be modified the LIR, e.g. using web-updates, but not removed = We are currently adapting the new create organisation webupdates form to include abuse-c by default allowing the user to: - reference an existing abuse-c role object, or - enter an email address to create an abuse-c role for the organisation (using the same maintainer) = We are also adapting the edit organisation webupdates form to always suggest adding an abuse-c contact if it's not present = We plan to extend the new request forms: - check that an end-user organisation has abuse-c before it can be used - if not, refer to the edit form for the organisation where it will be easy to add reference an existing abuse contact, or create a new object 2) Resolve remaining EXISTING cases Originally the idea for phase 2 was to use the sponsoring LIR's email address in case the end-user organisation was unresponsive to requests to set their own abuse contact. However, since then policy 2012-08 has been implemented and nowadays the sponsoring LIR, and its abuse contact, can be found through the sponsoring-org attribute. Also, the RIPE NCC found that using the sponsoring organisation's email address leads to a number of issues: - end-users have no incentive to set their own abuse-c, rather then letting abuse questions go to their sponsor, so the majority remains unresponsive - in case an end-user has resources from more than one sponsor it is ambiguous which sponsor's email should be used - many LIRs were unpleasantly surprised by finding their email address in the abuse-c of the organisation they sponsor - in case LIRs no longer wish to sponsor resources, or when they are returned, existing references to their email in the end-user abuse-c are not cleaned up We would therefore like to propose a change to the implementation plan when addressing the remaining cases. Today, in case no abuse contact is set, users of the database will resort to using the organisation's default email. Therefore, adding a dedicated abuse-c role object using this email address, doesn't cause any noticeable new effects on organisations. It may well be the correct email address to use for an organisation, and no action would be required. However, it *enables* an organisation to use a different email address for abuse questions if appropriate. We would like to email remaining LIRs, and end-user organisations and sponsoring LIRs on Monday 1 February, giving them until Monday 15 February to set their abuse contact. We realise that this means we would have another delay, but we believe that it would be unwise to do this change over the end of year holiday period, and to ensure that we can give proper support to questions we want to avoid doing this at the same time as the start of the year invoicing. Please let us know what you think. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

9 14

Question about RIPE Database
by Ricardo Cukier 15 Feb '16

15 Feb '16

Hi. I am using the following FTP files to identify IPs per Country: ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest ftp://ftp.apnic.net/pub/stats/apnic/delegated-apnic-latest ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-latest ftp://ftp.apnic.net/pub/stats/iana/delegated-iana-latest While doing some searchs on the web, I found a few IP Addresses that are not included in those files, for example, 2.190.0.0 however, when i searched on the Web Database (see attached screenshot), it was found as an IRAN subnet and assigned by RIPENCC. Why I am unable to see this subnet in the files? Am I doing the download of the incorrect files? Can someone please help me to identify whats the best process to get the correct list of IPs/subnets per country? -- Best Regards, Ricardo Cukier

2 1

Proposal to limit the use of the RIPE-NCC-RPSL-MNT on mnt-by
by Tim Bruijnzeels 11 Feb '16

11 Feb '16

Dear working group, There is an open action point on us regarding the use of the RIPE-NCC-RPSL-MNT maintainer: https://www.ripe.net/ripe/mail/archives/db-wg/2015-May/004626.html > I'd like to ask RIPE NCC to provide the group with an implementation > plan and a timeline on how to prevent the RIPE-NCC-RPSL-MNT mntner from > being used to authenticate updates to an object after the object has > been created. We also ask that the RIPE NCC look into cleaning up > existing references to RIPE-NCC-RPSL-MNT and tell us their plan. Note that there is an ongoing an important parallel discussion about the authorisation of out-of-region IRR objects in general. But this is specifically about the use of 'RIPE-NCC-RPSL-MNT' on "mnt-by:". As long as we do have RIPE-NCC-RPSL-MNT, there are things we can improve and we want to propose the following to working group: 1) implement a business rule to prevent that this maintainer is used as 'mnt-by' Submitting an object that includes 'mnt-by: RIPE-NCC-RPSL-MNT' would result in a hard error, with a message like: "The RIPE-NCC-RPSL-MNT is used to authorise the creation of out-of-region aut-num and route(6) objects, but may not be used as 'mnt-by'" This is fairly trivial to implement, provided of course that the working group agrees to this. 2) remove the maintainer from existing objects There are roughly 2000 objects that are maintained by 'RIPE-NCC-RPSL-MNT' only, and about 10000 objects that are maintained by 'RIPE-NCC-RPSL-MNT' and at least one other maintainer. In the first case we propose to lock the object, i.e. set 'mnt-by: RIPE-NCC-LOCKED-MNT', and send out a custom notification to any contacts on the object explaining that the object has been locked to prevent a hijack of the object, and that ripe-dbm(a)ripe.net can be contacted to unlock the object. In the second case we propose to leave the remaining maintainer and send out a custom notification informing contacts on the object that the "RIPE-NCC-RPSL-MNT" has been removed to prevent a hijack of the object, and listing which maintainer(s) remain. Technically this is not difficult either, but it can result in a lot of questions. Therefore we prefer to do this in batches to make sure that we can process possible follow up requests to ripe-dbm(a)ripe.net properly. For reference we used a similar approach when dealing with locking the old MD5 passwords earlier this year. Provided that the working group agrees with this, we expect this can be done in the space of a few weeks after the business rule is implemented. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group

9 14