November 2019 - members-discuss

RIPE DB T&C violation by brokers
by Sergey Myasoedov 09 Jan '20

09 Jan '20

Dear RIPE NCC, members, I would like to raise an issue of misuse of the RIPE Database by the brokers. I've reported different issues to RIPE NCC, but every time I receive a reassurance that appropriate measures will be taken. I am pretty sure that broker agreements and LIR contracts should be reviewed for every case of misuse of the RIPE NCC. But this specific broker - Supplity - is still sending spam using the RIPE DB contacts and nothing has happened to them. So I would like to collect more data, whether someone else has reported their spam to NCC. And finally to ask a question why nothing is happened to their broker status. Thank you. -- Kind regards, Sergey Myasoedov

26 32

BLACK FRIDAY IPv4 transfer
by José Manuel Giner 03 Dec '19

03 Dec '19

Hello, we're interested to buy (full-transfer) a /22, If anybody is interested to sell us with a special price, please contact me with the proposal details. Thanks. -- José Manuel Giner https://ginernet.com

35 42

Re: [members-discuss] [LIR] Re: Fwd: Re: RIPE DB T&C violation by brokers
by Schnabeltier 28 Nov '19

28 Nov '19

1 0

Resource Certification (RPKI) alerts for...
by Carlos Friaças 18 Nov '19

18 Nov '19

Hi, I suspect some of you have also received something similar to this recently: ----- There are alerts about BGP announcements with your certified address space for pt.rccn in the Resource Certification (RPKI) service. These are BGP announcements with your certified address space that have the status Unknown. You should create a ROA for each authorised announcement to make them Valid: AS Number Prefix AS<redacted> 2000::/12 (...) ----- I didn't see the same message repeated 24h after this one, so i hope this huge fumble is now solved. Proper filters are also needed in the IPv6 world -- please don't forget about that :-)) Cheers, Carlos

4 3

An ISP offers to announce our prefix. Is that normal?
by Bernd Naumann 13 Nov '19

13 Nov '19

Hi, I have a question about the validly of an option provided by our ISP. Back story: We will move one of your office uplinks in germany next year to an other provider. They offered us various options how it could be implemented. In my personal option one option sounds technical crazier then the other, even that it is "enterprise". The management involved raised concern when the ISP noticed that if we wanna use "just BGP" we will loose any SLA for L3 services. With no doubt I see managements point but now it comes: Then the ISP offered us to announce _our_ prefix for us, from their ASN, and here I lost trust, and stopped the planning for now to get either confirmation or an other red flag. - Is this even "allowed" or recommend by RIPE policies or BCPs? - Wouldn't that be at least looks like a/an BGP hijacking (attempt)? Because I have not seen / read about that implementation anywhere... - Just in case this is ok-ish, how would I setup the ROA with RPKI so that it would be come valid? An other but related question: Regarding the "No SLA" thing: Could someone point me on how other ISPs handle this or what would be "industrial standard". I highly doubt the reasoning, that just because the customer is using his own gear that the ISP will get way with any disturbance of their service... Naive me thought that it would be like in your data center installations: You get transit v4 and v6 networks from the provider, configure BGP and are done. Yes this does not prevent a customer to mis-configure things but in this case we would just get a default route and announcing one or more prefixes. I hardly see any pitfalls here. Thanks in advise and for your time, Best, Bernd

6 9

Re: [members-discuss] An ISP offers to announce our prefix. Is that normal?
by Bernd Naumann 12 Nov '19

12 Nov '19

Hi Matthias, But that's the point, we can and would prefer to maintain our own gear. I'm just find it curious that the provider states, that in this case we would get no L3 SLA. And regarding "someone else announces our prefix": I just never heard of it that this is common. That's why I'm asking. With this provider, or at this location we have not yet BGP in place. To recap: Announcing "someone else" prefix is OK, and the ROA can be signed. As I have not seen this in the RPKI FAQ: can I also sign i.e. the aggregate ROA prefix, one time from our ASN and one time from the providers ASN? And things are still valid? In this case I would not see a reason not to do it that way. Bernd On 12.11.19 12:50, Matthias Brumm | tkrz Stadtwerke GmbH wrote: > Hi! > > We have done simlar things, if the customer does not want to maintain his own router or has no knowledge in this. Could you please explain, why there is such a problem? If you have an ASN and there are BGP sessions in place, announcing your prefix, you just change one session for the other. > > Regards, Mit freundlichen Grüßen, > > > Hi, > > I have a question about the validly of an option provided by our ISP. > > Back story: We will move one of your office uplinks in germany next year to an other provider. They offered us various options how it could be implemented. In my personal option one option sounds technical crazier then the other, even that it is "enterprise". > > The management involved raised concern when the ISP noticed that if we wanna use "just BGP" we will loose any SLA for L3 services. With no doubt I see managements point but now it comes: > > Then the ISP offered us to announce _our_ prefix for us, from their ASN, and here I lost trust, and stopped the planning for now to get either confirmation or an other red flag. > > - Is this even "allowed" or recommend by RIPE policies or BCPs? > - Wouldn't that be at least looks like a/an BGP hijacking (attempt)? > Because I have not seen / read about that implementation anywhere... > - Just in case this is ok-ish, how would I setup the ROA with RPKI so that it would be come valid? > > > An other but related question: Regarding the "No SLA" thing: > Could someone point me on how other ISPs handle this or what would be > "industrial standard". I highly doubt the reasoning, that just because > the customer is using his own gear that the ISP will get way with any > disturbance of their service... > > Naive me thought that it would be like in your data center > installations: You get transit v4 and v6 networks from the provider, > configure BGP and are done. Yes this does not prevent a customer to > mis-configure things but in this case we would just get a default route > and announcing one or more prefixes. I hardly see any pitfalls here. > > Thanks in advise and for your time, > Best, > Bernd

3 3

Re: [members-discuss] An ISP offers to announce our prefix. Is that normal?
by Bothe, Jason 12 Nov '19

12 Nov '19

HI Michael, we do have a quite large relationship with them but it seems the issue is with their sister org, HKT which is behind the PCCW. I have submitted tickets, completed forms and all I get is its 'in progress'. It's been months. J~ On 11/12/19, 7:13 AM, "Michael Boehme" <mboehme(a)webdiscount.net> wrote: Jason, do you have any contractional relationship with PCCW so you could officially insert a ticket and ask them to remove it? They´re not supposed to do so if origin in RIRs databases points to your AS number. We do have ip transit from them in Hong Kong so we could try to see if this helps Thanks Michael Mit freundlichen Grüßen Michael Böhme KOMPETENZ VERBINDET. WEBDISCOUNT GmbH & Co. KG Robert-Bosch-Straße 20 48153 Münster, Deutschland Fon +49 251 263930-0 Fax +49 251 263930-49 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.webdiscount.net&d=D… Sitz der Kommanditgesellschaft: Münster Amtsgericht Münster HRA 8897 USt.ID: DE 815 197 935 Persönlich haftende Gesellschafterin: WEBDISCOUNT Verwaltungs GmbH Sitz der GmbH: Münster Amtsgericht Münster HRB 12721 Geschäftsführer: Michael Böhme -----Ursprüngliche Nachricht----- Von: members-discuss <members-discuss-bounces(a)ripe.net> Im Auftrag von Bothe, Jason Gesendet: Dienstag, 12. November 2019 14:08 An: Job Snijders <job(a)ntt.net>; Bernd Naumann <bena(a)spreadshirt.net> Cc: members-discuss(a)ripe.net Betreff: Re: [members-discuss] An ISP offers to announce our prefix. Is that normal? If anyone could tell me how to get an ISP to 'un-announce' prefixes on your behalf I will buy them dinner. I have two prefixes of mine that PCCW won't to take down and at this point I have better chances of convincing Donald Trump to resign than I do getting PCCW to remove them from their announcements. J~ On 11/12/19, 6:48 AM, "members-discuss on behalf of Job Snijders" <members-discuss-bounces(a)ripe.net on behalf of job(a)ntt.net> wrote: Dear Bernd, Good questions, thanks for bringing them up, this topic indeed doesn't receive much attention. I can't comment on the specifics of your case in regard to SLA and what the best choices are for your organisation, but I can share one small data point. On Tue, Nov 12, 2019 at 12:16:53PM +0100, Bernd Naumann wrote: > Then the ISP offered us to announce _our_ prefix for us, from their > ASN, and here I lost trust, and stopped the planning for now to get > either confirmation or an other red flag. This actually is a common practise! Speaking from NTT's perspective we see that customer's used to run BGP in the past, but no longer have interest in maintaining that infrastructure and switch to a "Direct Internet Access" (DIA) product which usually is statically routing the IP space and perhaps using a first-hop redundancy protocol. In such cases the customers request NTT to announce the space on their behalf - which we can do provided that a RPKI ROA and IRR route object are created to demonstrate to the world that we in fact are allowed to originate the prefix. > - Is this even "allowed" or recommend by RIPE policies or BCPs? yes, this is allowed; and if it adequately addresses the challenges you are trying to solve for your organisation I'd say it is even 'recommended' ;-) - the real answer is "it depends". > - Wouldn't that be at least looks like a/an BGP hijacking (attempt)? it would not look like a BGP hijack if RPKI ROAs / IRR "route:/route6:" objects are created in the appropriate places authorising the ASN that originates the prefix. > - Just in case this is ok-ish, how would I setup the ROA with RPKI so that > it would be come valid? You'd go to the RIPE web portal, and create a RPKI ROA like you'd normally do, but instead of inputting your own ASN you input the ASN of the provider that will announce the space on your behalf. You create/have multiple ROAs covering the same prefix but with different Origin ASNs co-exist - this allows you to make-before-break in transitions such as you might be going through at this moment. A variant of the scenario you describe is "BYOIP" in context of the cloud providers. The analogy is that instead of routing your IP space to your office, some cloud providers offer to announce your IP space and route it to your virtual datacenter: https://urldefense.proofpoint.com/v2/url?u=https-3A__aws.amazon.com_vpc_faq… https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.cloudflare.… https://urldefense.proofpoint.com/v2/url?u=https-3A__cloud.ibm.com_docs_tut… https://urldefense.proofpoint.com/v2/url?u=https-3A__www.zdnet.com_article_… https://urldefense.proofpoint.com/v2/url?u=https-3A__ideas.digitalocean.com… . Your IP resources are yours*, and you are free to authorize anyone to route them on your behalf on the public internet. Kind regards, Job * not meaning to start debate about ownership, just wanted to emphasize that whether you do your own BGP or have someone do it on your behalf is the same. _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman… Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman… **************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any device. **************************************************************** _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman… Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman…

1 0

Ausente por vacaciones
by jg.mondejar＠airenetworks.es 12 Nov '19

12 Nov '19

Gracias por ponerse en contacto con Aire Networks. Le informamos que esta cuenta de correo: jg.mondejar(a)airenetworks.es; no será atendida hasta el próximo 13 de Noviembre. Por favor, utilice la siguiente cuenta de correo para contactar con nosotros: ingenieriadered(a)airenetworks.es. Saludos cordiales, Thank you for contacting with Aire Networks. We inform you that this email account: jg.mondejar(a)airenetworks.es; won't be answered till 13th of November. Please, use this email account to contact us: ingenieriadered(a)airenetworks.es. Best Regards,

1 0