- anti-abuse-wg - mailman.ripe.net

survey on BGP prefix hijacking
by Alberto Dainotti 25 Apr '17

25 Apr '17

Dear anti-abuse working group, BGP prefix hijacking remains a problem for Internet routing, despite the (partial) use of RPKI or detection services. We would like to hear your opinions on BGP prefix hijacking (concerns, existing defenses, needs, etc.) that would help us research new defense mechanisms both for its detection and mitigation. Please help us by answering this short (< 10min, 21 questions) and anonymous survey. Survey URL: http://tinyurl.com/hijack-survey <http://tinyurl.com/hijack-survey> *** The survey *** This survey is part of a joint research effort by CAIDA (www.caida.org <http://www.caida.org/>) and the ICS-FORTH (www.ics.forth.gr <http://www.ics.forth.gr/>) research institute, to study (a) operator awareness of BGP prefix hijacking attacks/incidents, (b) presently used defenses against BGP prefix hijacking, (c) the willingness to adopt new defense mechanisms, and (d) reasons that may hinder the deployment of BGP prefix hijacking defenses. We expect the findings of this survey to increase the understanding of existing BGP hijacking defenses and the needs of network operators, as well as help us design and implement new defense mechanisms that we will present to the operator and scientific communities. A summary of the aggregate results will be published as a part of an article/conference paper. Thank you in advance, and we look forward to your responses! Alberto (CAIDA) and Pavlos (ICS-FORTH)

1 0

Proposal for fixing "abuse-c:"
by denis walker 18 Apr '17

18 Apr '17

Colleagues I have just sent a proposal to the DB-WG for fixing the issues with "abuse-c:". If you are not subscribed to the DB-WG you can find the proposal:https://www.ripe.net/ripe/mail/archives/db-wg/2017-April/005520.ht… cheers denis co-chair DB-WG

1 0

Re: [anti-abuse-wg] anti-abuse-wg Digest, Vol 65, Issue 2
by Marilson 18 Apr '17

18 Apr '17

Hi Prince Olaf Thank you so much for taking the time to send me so much information about the potential of governments. As a layman in this subject, this information helped me better to assess the real effects of a policy proposal anti-shutdown which provides for punishment. So I must agree with your point of view: "i don't think this method will have 'sufficient impact' to 'make them think twice'..." Sorry for not posting your text which were banned by the RIPE censors. It is an old habit of the colonizing lords. One day they will learn to live with the contradictory, by hook or by crook. Although I do not agree with your truth about spam, I must respect the way you expose your truth without hypocrisy, without subterfuge, with honesty. I can not say the same about your detractors in this group. Marilson From: anti-abuse-wg-request(a)ripe.net Sent: Sunday, April 16, 2017 7:00 AM To: anti-abuse-wg(a)ripe.net Subject: anti-abuse-wg Digest, Vol 65, Issue 2 Send anti-abuse-wg mailing list submissions to anti-abuse-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/anti-abuse-wg or, via email, send a message with subject or body 'help' to anti-abuse-wg-request(a)ripe.net You can reach the person managing the list at anti-abuse-wg-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of anti-abuse-wg digest..." Today's Topics: 1. About introduction of punishments in AFRINIC's policy (Marilson) ---------------------------------------------------------------------- Message: 1 Date: Sat, 15 Apr 2017 19:37:18 -0300 From: "Marilson" <marilson.mapa(a)gmail.com> To: <anti-abuse-wg(a)ripe.net> Subject: [anti-abuse-wg] About introduction of punishments in AFRINIC's policy Message-ID: <CC24BC5A92B14DF59394BDA9F957A7AE@xPC> Content-Type: text/plain; charset="iso-8859-1" Abuse: shut down Internet access for political reasons Abuse authorship: autocratic governments Objective: punishment The RIPE policy list commented and it is under discussion on AFRINIC a policy proposal anti-shutdown which provides for punishment. https://afrinic.net/en/community/policy-development/policy-proposals/2061-a… https://www.theregister.co.uk/2017/04/12/no_ip_addresses_for_countries/ On the ARIN Public Policy Mailing List, a member commented: >Doesn't seem like the most workable policy to my novice eyes. >Is it really a good idea to convert RIRs into the internet police? >if we think it is a good idea, who decides what's a proper case for implementation? That is what I wrote there: To my novice eyes, but tired and disappointed, I find it rather appropriate that the entity responsible for the management and allocation of IP address blocks adopt punitive measures against those who interfere in the free internet or in the inappropriate use of those services. Who decides? The evidence. And the Internet community seems to be the only one capable of putting punitive measures into practice. No matter who we are or what we do, commitment to democracy should always be part of our activities. The owners of these resources is the population of the planet. RIRs manage these resources on behalf of this population and should effectively manage without omitting and transferring that responsibility to governments or to their ISP customers. I say this because, just as there are autocratic governments, there are bad ISPs who arrogantly refuse to punish clients with illicit activities even in the face of evidence. And in the face of these bad providers, governments, without exception, turn a blind eye. They are more concerned about employment within their territory even at the expense of the population being the victim of spammers and scammers. This situation explains and does not justify the 420 billion spam and scam per day (Cisco). Never so few done so much harm to so many. No more shutdowns. No more denying access to information and knowledge. No more bad ISPs. Even with Trump! Marilson

1 0

About introduction of punishments in AFRINIC's policy
by Marilson 16 Apr '17

16 Apr '17

Abuse: shut down Internet access for political reasons Abuse authorship: autocratic governments Objective: punishment The RIPE policy list commented and it is under discussion on AFRINIC a policy proposal anti-shutdown which provides for punishment. https://afrinic.net/en/community/policy-development/policy-proposals/2061-a… https://www.theregister.co.uk/2017/04/12/no_ip_addresses_for_countries/ On the ARIN Public Policy Mailing List, a member commented: >Doesn't seem like the most workable policy to my novice eyes. >Is it really a good idea to convert RIRs into the internet police? >if we think it is a good idea, who decides what's a proper case for implementation? That is what I wrote there: To my novice eyes, but tired and disappointed, I find it rather appropriate that the entity responsible for the management and allocation of IP address blocks adopt punitive measures against those who interfere in the free internet or in the inappropriate use of those services. Who decides? The evidence. And the Internet community seems to be the only one capable of putting punitive measures into practice. No matter who we are or what we do, commitment to democracy should always be part of our activities. The owners of these resources is the population of the planet. RIRs manage these resources on behalf of this population and should effectively manage without omitting and transferring that responsibility to governments or to their ISP customers. I say this because, just as there are autocratic governments, there are bad ISPs who arrogantly refuse to punish clients with illicit activities even in the face of evidence. And in the face of these bad providers, governments, without exception, turn a blind eye. They are more concerned about employment within their territory even at the expense of the population being the victim of spammers and scammers. This situation explains and does not justify the 420 billion spam and scam per day (Cisco). Never so few done so much harm to so many. No more shutdowns. No more denying access to information and knowledge. No more bad ISPs. Even with Trump! Marilson

1 0

Re: [anti-abuse-wg] Abuse: ipv6 and spam
by Richard Clayton 13 Apr '17

13 Apr '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message , ox <andre(a)ox.co.za> writes >I am currently drafting a document regarding accepting email on ipv6 I am happy to argue that being able to obtain an IPv4 address for an MTA is a "clue test" and that failure to have that clue is a plausible reason for rejecting email from a sender... this is not Politically Correct but it's going to be a very effective heuristic for some years to come. [this doesn't apply to end users submitting email to a "smart host", but you authenticate them, so the issues are different] >On White Lists, the process is not as clear or obvious as one may >think as firstly the address space has 2(128) addresses, sec issues >( https://tools.ietf.org/html/rfc5782) etc etc etc you might like to look at M3AAWG's suggestions (essentially they suggest that /64s are the initial granularity of choice) <https://www.m3aawg.org/sites/default/files/document/M3AAWG_Inbound_IPv6 _Policy_Issues-2014-09.pdf> what will go wrong with this approach is that a major site could decide that they want all of their (100s of millions) of users to accrue their own reputation and so they use a unique IPv6 address for each user... >The actual listing entries, sure, we already have a few hundred >good/known ipv6 email servers, but how do admins go about adding >themselves to the white list? > >Obviously it has to be free, open, fair and anyone has to be able to >add themselves. that's not obvious at all -- reputation providers can and will have their own rules for setting the reputation of IPs. If their decisions are wise (and their pricing is acceptable) then people will flock to use their product. >which has given rise >to an idea that all servers (people providing services / providers of >services as opposed to users of) - should have their own, separate >resource listing... what you need to be able to do is to determine whether two IPv6 addresses are controlled by the same person (so that allocating a single reputation to a range of IPv6 addresses makes complete sense). For that you need to know the "cut point" ... what allocation unit is being used by the entity that handed out the IPv6 addresses. constructing a free/open directory of that information would be useful (before we all have to buy it from a commercial vendor) - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBWO9/kju8z1Kouez7EQK9SQCcCd1tG8InFx144G2M0IP1jjqNsqAAoMNC SHHEW9eLteAdA2qSEALuTu6z =Ifr6 -----END PGP SIGNATURE-----

1 0

Abuse: ipv6 and spam
by ox 13 Apr '17

13 Apr '17

Hello Everyone, I am currently drafting a document regarding accepting email on ipv6 and building our white list database (it will eventually be either six.ascams.com or sixwhite.ascams.com) Ref: https://tools.ietf.org/html/draft-tzink-ipv6mail-whitelist-01 The actual practical implementation is so simple and easy:, simply use it in reverse of a blacklist, score all incoming ipv6 emails +1000 and if listed on six.ascams.com -1000 (and if listed with whitelist.example.com -1000 - etc etc) Defining the actual processes for white listing itself, is not as easy as it may seem... Black list: for example superblock.ascams.com: First time de-listing (takes anywhere from 24 hours to 7 days) Second time de-listing (takes anywhere from 7 days to 3 weeks) Third time listing is a semi permanent block (discussed in public) Fourth time listing is permanent, even if the ipv4 resource re-allocated On White Lists, the process is not as clear or obvious as one may think as firstly the address space has 2(128) addresses, sec issues ( https://tools.ietf.org/html/rfc5782) etc etc etc But, notwithstanding that, the actual listing & de listing is also, reasonably simple: For example: the same process as blacklists, if multiple users file complaints, the ipv6 entry is revoked, re-instated, etc etc and this is where I am at now. The actual listing entries, sure, we already have a few hundred good/known ipv6 email servers, but how do admins go about adding themselves to the white list? Obviously it has to be free, open, fair and anyone has to be able to add themselves. But, it is the actual adding, bots, trust and other issues that is still challenging. (and, yes, I have read BITAG (bitaq) etc as well as all the other copious amounts of drivel, diatribe and POV out there) One idea is for admins to go through manual verification process, for which volunteers would be required, Another idea is that In the TXT answer, for white listing, the email address of the ipv6 abuse@ is to be published and for the entire database to be available (like the RIPE whois) - which has given rise to an idea that all servers (people providing services / providers of services as opposed to users of) - should have their own, separate resource listing... There are of course many other ideas as well, but the reason for my post is: Do you have any value, comment or idea you could add to this? thanks! Andre

1 0

"abuse-c:" - a question....
by ripedenis＠yahoo.co.uk 31 Mar '17

31 Mar '17

Colleagues [Apologies if you receive duplicate versions of this email but my interaction with the RIPE NCC mailing lists is getting worse. Three attempts with gmail, yahoo and xs4all email accounts all failed to post this to the DB-WG so lets discuss it here...] I would like to ask the community a question that looks at a wider picture than the "abuse-c:" attribute itself. Depending on how people react to this question, it may impact the chosen path to solving the issue with documenting abuse contact details in the RIPE Database. The current implementation for "abuse-c:" documents the default contact details for who handles abuse issues within an organisation that holds resources. If the email address is invalid or there is no response to a complaint sent to that address it is clear who the organisation is and there are other contacts related to this organisation. Sometimes a resource holder delegates some responsibility for the management of (one or more of) their resource(s) to another person/organisation. This may be just the abuse handling. With the current database semantics it is not always possible to create a separate ORGANISATION object to document this responsibility. This issue has been described as 'How to reference the email address for the abuse reports for this resource?'. The simple version of my question is 'Is it enough to only know the email address and an un-validated postal address for the abuse handler?'. An email address can be 'anyone(a)anybody.com'. This tells you nothing about 'anyone' or 'anybody'. It is a one directional channel to throw something down that may end in a black hole. If nothing happens, who was supposed to have this responsibility? Not everyone who uses this abuse contact information understands the RIPE Database structure, the resource hierarchy or the contractual responsibilities of the related parties. They may have searched online for who to complain to, got this email address and got no response. How do you take further action against an email address? What I am working round to is explaining why the "abuse-c:" was designed the way it is. Where responsibility for handling abuse was delegated to another party (separate organisation or another internal department) we wanted to maintain a closely coupled link between the resource listing a contact and an organisation responsible or accountable for abuse handling. As it turned out this created the need for repetitive data in some cases and not being able to record the right details in some other cases. The simplest solution that has been discussed in the past is to allow the "abuse-c:" attribute in resource objects. This does create some resource and data management issues. But these can be solved by providing resource managers with the right software tools. Now we get to the in depth version of my question. Do we need to maintain that close coupling in the database between who is responsible or accountable for handling abuse for a resource and their correct and validated (by the resource holder) contact details? If the answer to this question is a simple 'no' then we can easily add "abuse-c:" attributes anywhere pointing to an email address and provide the resource managers with tools to maintain the data....job done. If the answer is anything other than a simple 'no' and we believe abuse information consumers without an in depth knowledge of the database or industry need to easily understand 'who' claims to be behind an email address then we may need a more complex solution. I hope this makes sense and look forward to comments and questions. cheers denis co-chair DB-WG

4 5

Re: [anti-abuse-wg] "abuse-c:" - a question....with no answers?
by Hal ponton 31 Mar '17

31 Mar '17

Sorry didn't cc in the list, Regards, Hal > Hal ponton <mailto:hal@buzcom.net> > 31 March 2017 at 09:53 > Andre, > > The issue I see with two contacts (emergency and standard) is that > everyone will email the emergency contact. > > I fully agree that the response required for 1 spam email vs 10000 > emails is vastly different, however, if someone wants a response they > will email the account they think they'd get the fastest / best > response from. It's just human nature. > > Whilst at first non-emergency complaints will be ignored, it will get > to a "boy who cried wolf" situation where the amount of non-emergency > emails vastly outweighs the emergency emails. To the point where the > organisation will just treat the emergency mailbox the same as the > current abuse mailbox. > > You would need some disincentive to email the emergency mailbox. Like > on a train where if you pull the emergency handle without there being > an emergency you get a fine. I'm not advocating a fine here, just > something similar to try and regulate emails coming into the emergency > mailbox. > > > >

2 1

Report of AS203496 (LLC AB-Telecom) to halt announcement of IPv4 block 168.197.120.0/23 (Operbes, S.A. de C.V. - MX-OSCV9-LACNIC)
by Jose Damian Cantu Davila 16 Mar '17

16 Mar '17

Hi, I apologize in advance if this is the wrong forum Im Damian Cantu, analyst at IAR Mexico, which is the National Internet Registry for Mexico. We find out that LLC AB-Telecom´s AS203496 started announcing in november 4th of 2016 the IPv4 block 168.197.120.0/23 which belongs to an ISP located in our region -LACNIC, the Latin American and Caribbean Internet Addresses Registry-. https://stat.ripe.net/168.197.120.0%2F23#tabId=at-a-glance The IPv4 block 168.197.120.0/23 belongs to Operbes, S.A. de C.V. (MX-OSCV9-LACNIC) which has a Legal contract with us. http://lacnic.net/cgi-bin/lacnic/whois?lg=EN&query=168.197.120/22&stkey=220… We need that LLC AB-Telecom´s AS203496 halt any further announcement of the IPv4 block since it is affecting our clients network operation. I had reported to their abuse info but haven´t had any response. Im wondering if someone in this forum can put me in contact with their tech-staff. Thanks in advance for your help, And I apologize if it's the wrong forum to post. Best regards. [damian cantu] ________________________________ Este mensaje contiene información confidencial y se entiende dirigido y para uso exclusivo del destinatario. Si recibes este mensaje y no eres el destinatario por favor elimínalo, ya que difundir, revelar, copiar o tomar cualquier acción basada en el contenido está estrictamente prohibido. Network Information Center México, S.C., ubicado en Ave. Eugenio Garza Sada 427 L4-6 Col. Altavista, Monterrey, México, C.P. 64840 recaba tus datos personales necesarios para: la prestación, estudio, análisis y mejora del servicio, la realización de comunicaciones y notificaciones; la transferencia y publicación en los casos aplicables; el cumplimiento de la relación existente; así como para la prevención o denuncia en la comisión de ilícitos. Si eres colaborador o candidato a colaborador de NIC México, tus datos serán utilizados para: la creación y administración de tu perfil como profesionista; el otorgamiento de herramientas de trabajo; la realización de estudios; el otorgamiento de programas y beneficios para mejorar tu desarrollo profesional; la gestión y administración de servicios de pago y/o nómina; así como para contacto y/o notificaciones. Si participas en promociones o en estudios podrás dejar de participar. Para mayor información revisa el Aviso de Privacidad<http://www.nicmexico.mx/static/docs/Aviso_de_Privacidad.pdf>. This message contains confidential information and is intended only for the individual named. If you are not the named addressee please delete it, since the dissemination, distribuition, copy or taking any action in reliance on the contents is strictly prohibited. Network Information Center Mexico, S.C., located on Av. Eugenio Garza Sada 427 Col. Altavista L4-6, Monterrey, Mexico, CP 64840 collects your personal data which is necessary to: provide, research, analyze and improve the service; send communications and notices; transfer and publish your personal data when applicable; fulfill the existing relationship; prevent or inform in the commission of unlawful acts or events. If the data is processed in your quality of candidate or collaborator of NIC Mexico, the purpose of treatment is to: create and manage your profile as a professional; provide you with working tools; conduct studies; grant benefits and programs to enhance your professional development; manage and administrate payment services and/or payroll; as well as to contact you. If you participate in promotions or surveys you may stop or quit your participation at any time. For more information read the Privacy Note<http://www.nicmexico.mx/static/docs/Aviso_de_Privacidad.pdf>.

2 1

Draft Agenda - AA-WG RIPE74
by Brian Nisbet 13 Mar '17

13 Mar '17

Colleagues, Here is the draft agenda for RIPE 74. The WG meeting is to take place at 11:00CEST on Thursday 11th May. As you can see, there is still some space on the agenda, so if you would like to present, propose or discuss something in Budapest, please let Tobias or myself know. A. Administrative Matters * Welcome * Scribe, Jabber, Stenography * Microphone Etiquette * Approve Minutes from RIPE 73 * Finalise agenda B. Update * B1. Recent List Discussion? * B2. C. Policies - * C1. D. Interactions - * D1. Working Groups - DB & Implementation of "abuse-c" * D2. E. Presentation - * E1. Network & Information Security Directive, Nathalie Falot, NCSC-NL X. A.O.B. Z. Agenda for RIPE 75

1 0