- members-discuss - mailman.ripe.net

Re: [members-discuss] Billing scheme
by Tobias Weinfeld 09 Jan '19

09 Jan '19

Dear colleagues, the removement of the ability of a quarterly or half-annually billing scheme is in my opinion a bad move. Unfortunately I have no data prior to 1998, but at least since this year it was already possible for LIRs to choose from a quarterly, half-annually or annually charging scheme. It simplified and still simplifies the process for newcomers to become LIR. Altough the fees were higher than today we break here with a tradition that lasted more than 20 years (!). This change will decrease the amount of reminders, yes, but it also will decrease the amount of newcomers, small companies or even technical interested natural persons which plan to become LIR at RIPE. Furthermore the last subnets of the IPv4 pool, which is already quite scarce, won't go anymore to many newcomers, it will possibly go more to companies which already have enough means to buy IPv4 from the market. Those who have more financial opportunities can easily create multiple LIR accounts because they anyway pay annually as usual, so those who are affected are newcomers and small companies. I am strict against this change. It was an important simplification and I see no real reason for removing it after more than 20 years because in a few years when the pool is exhausted also the aforementioned heavy burden will be extenuated. Especially when it comes to IPv6 the next years it should be easily possible for newcomers to become LIR; because it is and should be a membership and not an investment. I also want to criticize that this was announced on a Friday, three days before Christmas, only about one month (now two months) the invoices for Q1/Y2019 will be sent and after expiration of the termination deadline of 15th December 2018. In my opinion, RIPE NCC is one of the fairest and liberal RIR - but that change isn't fair, it is more than astonishing.

2 1

Re: [members-discuss] billing problem on multiple lir accounts.
by Azer Karyagdy 08 Jan '19

08 Jan '19

Hello, Please note that depend from country it should be yearly payment + local taxes. For Russia it is now 20% VAT. And this VAT, depend from way of how business was registered in tax ministry may not to be returned. This might crash new small business or at least make their expenses to be unacceptable. With last terms about aquistion and join businesses it is also make hard way to get our from business. This may increase percent of died RIPE LIR's because beginners could not transfer their ip's could not sell it to another company or join with someone who can support their customers within 2 (or even 3 years). So RIPE will need sent invoices to collectors or get back ip's from such LIR's without any payments. RIPE can say why beginners do not use good business plan but remember that many new business die within first few years. Best Regards Azer ----- Исходное сообщение ----- > * Alexander Buzaev <buzaev.weecomi(a)ukr.net> [2019-01-08 08:22]: > > Dear Sebastian, > > I am not happy with this decision. This is too large a one-time > > fee. Especially for our country. > > Hi Alexander, > > that might be, but you're not "many members". As for a too large > one-time fee, the paragraph adressed this: > > The Executive Board supported the implementation of an enhanced > billing cycle and instructs the RIPE NCC Management to implement a > yearly billing process, including payment options for members with > cash flow limitations. > > You should ask the RIPE NCC what the available payment options are in > your case. > > Regards > > Sebastian > > _______________________________________________ > members-discuss mailing list > members-discuss(a)ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: > https://lists.ripe.net/mailman/options/members-discuss/azer%40karyagdy.com >

2 2

M&A procedure
by IPLab 19 Dec '18

19 Dec '18

6 6

Policy violation
by Marco Schmidt 18 Dec '18

18 Dec '18

Dear Aleksey and all, We would like to clarify the situation because the policy refers to transfers between RIPE NCC members and not transfers between the LIR accounts that members might hold. A member may hold multiple LIR accounts. Regarding the section that you refer to in the procedure, please see the mail that was sent to the NCC Announce mailing list in October: https://www.ripe.net/ripe/mail/archives/ncc-announce/2018-October/001286.ht… This message explains how the RIPE NCC processes transfers of IPv4 address space or 16-bit ASNs due to a merger, acquisition or any other change in business structure. We hope this clarifies that no policy violation has taken place. A merger or acquisition is possible at any time and must take place following the processes outlined in the email. Kind regards, Marco Schmidt Policy Officer RIPE NCC

2 1

Change of conditions
by Aleksey Bulgakov 17 Dec '18

17 Dec '18

Dear all. I would like to ask you one question. If one company open account in June 2018, but respected executive board decides to implement restrictions in September - should the company to apply this restrictions? I mean the document https://www.ripe.net/publications/docs/ripe-709#transfer35 -- ---------- Best regards, Alexey Bulgakov

9 9

Re: [members-discuss] [exec-board] Change of conditions
by Rob Golding 17 Dec '18

17 Dec '18

> Curious about the statement that Companies House don't maintain records > of M&A activity. Surely they maintain a record of the controlling interest for > all UK companies They do, however whilst for most companies that's "correct" at least once a year (we hope), in the majority of M&As there are no changes at companies house as the original "org" is no longer required/wanted - Directors/owners/shareholders details do get updated where they want to continue that "brand" but that's sub-10% of company acquisitions, the bulk of M&A activity in the LTD space (rather than PLC space) is "asset" rather than "share" based [with about 1/3rd being where the liquidators sell off the assets , or goodwill/brand or whatever] So the statement is correct in general terms, that nothing appears at companies house As to whether you can "infer" it (as some of us do when regular buyers take over companies we're following) ... > If it is on record that A is now a PSC with >50% voting/equity of B then an > acquisition has taken place No it means A has 50% of the equity, that’s very different to an acquisition, although can be indicative of takeover - the ability to vote on a resolution and the running of a company are very different things > and if B and C notify their PSCs are the same then > a merger between B & C has taken place. It means nothing of the sort. Being listed as the same PSC on multiple companies absolutely does not mean in any way they have merged. IP Cortex own corporate structure being a good example of why this doesn’t mean what you're saying - 2 separate legal entities despite same PSCs/Shareholders - not Merged, not Acquired, just "similarly owned" > My understanding is that for many things RIPE want a (virtual) piece of paper > that certifies X is true, rather than a process for verifying in a public database > that X is true I think the idea of formalising what can be used where public-database doesn't contain the data is good overall, but exactly how you do that I am not sure - I can see lots of ways to not do it effectively though :) Rob --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

Re.: Policy violation
by FreeData 14 Dec '18

14 Dec '18

1 0

Policy violation
by Николай Давыденко 14 Dec '18

14 Dec '18

1 0

Policy violation
by FreeData 14 Dec '18

14 Dec '18

1 0

Policy violation
by FreeData 14 Dec '18

14 Dec '18

1 0

Re: [members-discuss] billing problem on multiple lir accounts.
by ripe-member-discuss+lr＠c2play.de 12 Dec '18

12 Dec '18

1 0

Re: [members-discuss] Our AS is in a macro that we don't authorize.
by Erik Bais 10 Dec '18

10 Dec '18

I have to agree with Karl. I also have some AS-SETS in the RIPEDB that we use for RPSL stuff that we feed into a routeserver of an IXP for instance.. with whom we don't want to peer with .. it works as an exclude list. The list isn't used for providing transit or telling others that they can find them in our AS cone ... so doing authorisations on them or other stuff would break things in our case.. Depending of the usage, it will give a different result. Regards, Erik Bais On 05/11/2018, 07:49, "members-discuss on behalf of Kaiser, Karl" <members-discuss-bounces(a)ripe.net on behalf of karl.kaiser(a)upc.at> wrote: Hi, I do understand your concerns, but: also your AS number shows up in someone elses AS-SET is does not mean any traffic being routed anywhere. This is mainly a documentational and a possible security issue (also no harm seems to be done by now). AS24748 seem to have 106 Peers - far away from the "thousands". The macro: AS24748:AS-THINX contains about every single active AS-Number i know of (at least the first 10 of 15 that came into my mind were in there). So there guy's built a fancy and completely useless macro - maybe they shouldn't consider their upstream to be their customers. Anyhow - forget about them or try to make them clean up their mess - but I don't think this mailinglist might be able to help you any further. Kind regards Karl ________________________________________ Von: members-discuss [members-discuss-bounces(a)ripe.net]" im Auftrag von "José Manuel Giner [jm(a)ginernet.com] Gesendet: Freitag, 02. November 2018 10:27 An: members-discuss(a)ripe.net Betreff: Re: [members-discuss] Our AS is in a macro that we don't authorize. I want my traffic routed where I want it. I'm not a member of that IX and if you're routing traffic through this IX, it's being a latency problem (my servers are a far away from that IX, +60 ms) and possibly a hijaking security problem. On 01/11/2018 10:13, Tapio Haapala wrote: > Why you want remove your AS from IX routing list? You want that your > prefixes does not get routed to some part of internet? Correct if I am > wrong but for me that looks more like that at least someone (atman) do > filtering even for tier1 operators and at least in theory it should be > good thing. > > > On 30.10.2018 16:27, José Manuel Giner wrote: >> Hi, we checked that our AS is present in the macro: AS24748:AS-THINX >> (they have thousands of AS in their macro) >> >> After contacting atman.pl who is responsible for this macro, they tell me: >> >>> It appears that AS59432 is contained in one of our customers AS-SETs and >>> it is automatically added to our AS-SET AS24748:AS-THINX >>> >>> As soon as they remove AS59432, it will disappear from AS24748:AS-THINX >> >> We have asked him how we can find out who that customer is. But their >> answer doesn't give us any information. >> >>> Please be kindly informed that our macros are being built automatically >>> according to our customers` macros. If your AS happens to be removed >>> from whichever of our customer`s macros, ours is to be changed >> accordingly. >> >> We are concerned about this situation and do not know how to proceed. >> >> Thank you for your help! >> > > -- José Manuel Giner http://ginernet.com _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/karl.kaiser%40upc.at Information gemäß § 14 Unternehmensgesetzbuch: T-Mobile Austria GmbH, Firmensitz: Wien, Geschäftsanschrift Rennweg 97-99, 1030 Wien, Firmenbuchnummer: FN 171112 k, Handelsgericht Wien. _______________________________________________ members-discuss mailing list members-discuss(a)ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/erik%40bais.name

1 0

Re: [members-discuss] LIR???s billing issues with RIPE NCC, need support
by Bunea TELECOM 06 Dec '18

06 Dec '18

Can you please show me a successful implementation of NAT in a medium sized datacenter? I am quite curious. Also, how about companies that have a dormant /8 which they don’t even announce ? I think you should be angry over them, for having millions of IPv4 unused, and not over us, who have a few thousands. I think they are the ones you refer to as stealing the future of other companies, right ? — Petru Bunea / CEO suport(a)bunea.eu <mailto:suport@bunea.eu> / +40752481282 <tel:+40752481282> Bunea TELECOM / DATACENTER / APP DEVELOPMENT http://www.bunea.eu <http://www.bunea.eu/> / +40745495495 <tel:+40745495495> > On 4 Dec 2018, at 15:50, Lutz Donnerhacke <L.Donnerhacke(a)iks-service.de> wrote: > > You can’t avoid NAT, because there are not enough IPv4’s for everybody. > You can’t change this, because the IPv4 pool is limited by technical standards. > So you either implement NAT or move to IPv6. The best advice is to do both. > > Faking LIRs for RIPE in order to grab legacy IP space is stealing the future of other companies. > > Von: Bunea TELECOM <suport(a)bunea.eu <mailto:suport@bunea.eu>> > Gesendet: Dienstag, 4. Dezember 2018 14:16 > An: Lutz Donnerhacke <L.Donnerhacke(a)iks-service.de <mailto:L.Donnerhacke@iks-service.de>> > Cc: members-discuss(a)ripe.net <mailto:members-discuss@ripe.net> > Betreff: Re: [members-discuss] LIR???s billing issues with RIPE NCC, need support > > Hello Lutz, > > Perhaps you should also offer some advice for us, we run a datacenter and we are very curious how we can evolve without having to open up multiple LIR accounts? > I don’t think NAT is a solution, so I am waiting for your answer. > > Thanks > — > > > <image001.jpg> > > > > > Petru Bunea / CEO > suport(a)bunea.eu <mailto:suport@bunea.eu> / +40752481282 <tel:+40752481282> > Bunea TELECOM / DATACENTER / APP DEVELOPMENT > http://www.bunea.eu <http://www.bunea.eu/> / +40745495495 <tel:+40745495495> > > > On 4 Dec 2018, at 14:50, Lutz Donnerhacke <L.Donnerhacke(a)iks-service.de <mailto:L.Donnerhacke@iks-service.de>> wrote: > > Because I need more addresses to offer to my customers. Purchasing > addresses from open market is risky. Thats why I open new LIRs. > > You are doing it wrong. > > Please learn how to operate an ISP in modern times. > Two hints: > - https://lutz.donnerhacke.de/eng/content/search?SearchText=NAT <https://lutz.donnerhacke.de/eng/content/search?SearchText=NAT> (use deepl.com <http://deepl.com/>) > - https://tools.ietf.org/html/rfc6540 <https://tools.ietf.org/html/rfc6540> > > But please stop wasting tight resources by incompetence. > And please stop stealing resources from others by tricking RIPE policies. > > Please note, that your message is enough to reclaim the illegal obtained resources back by RIPE NCC. That's one of the activities we pay them for. > _______________________________________________ > members-discuss mailing list > members-discuss(a)ripe.net <mailto:members-discuss@ripe.net> > https://lists.ripe.net/mailman/listinfo/members-discuss <https://lists.ripe.net/mailman/listinfo/members-discuss> > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/suport%40bunea.eu <https://lists.ripe.net/mailman/options/members-discuss/suport%40bunea.eu> >

3 2

Re: [members-discuss] LIR???s billing issues with RIPE NCC, need support
by support 05 Dec '18

05 Dec '18

Ist very good what you are writing there Lutz.The reality is another thing, especially about IPv6.We are using both well, but we are a company located in Kenya.Kenya dont use IPv6 which means that when we dont work with both (IPv4 and IPv6) our Sites will not be available worldwide, especially in Kenya. This dont mean right now that I support lower prices and lower transfer time.Who opens a LIR have to accept the rules, otherwise dont think even to open one!Have a nice day guys. Christian Lutzner Vhost Meremeta LTDVon meinem Samsung Galaxy Smartphone gesendet.

3 3

Two mailing lists?
by LeBar, Russell J 05 Dec '18

05 Dec '18

Any chance we could split this list into two -- one for the business, billing, contracts, etc. side of things and another for technical side of things? -- Russ ________________________________ CONFIDENTIALITY NOTICE: This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may contain confidential and privileged information protected by law. If you received this e-mail in error, any review, use, dissemination, distribution, or copying of the e-mail is strictly prohibited. Please notify the sender immediately by return e-mail and delete all copies from your system.

2 1

Re: [members-discuss] LIR???s billing issues with RIPE NCC, need support
by ivaylo 04 Dec '18

04 Dec '18

Hello, everybody The problems with overing IPV4 space will become more and more actual with time, and I think this come from unfair RIPE charging scheme. As far as I'am familiar Current charging allows some lirs to have huge number of unused resources and others to think how to get needed resources, and everybody pay same amount of money. Also this scheme create space for speculators to get easy money from internet companies. By me fair will be this scheme: Registration fee: no matter as RIPE decide 2k euro seems not little, but it is acceptable. Annual fee: 350 euro (or second variant 1400 euro as it is now) Every LIR (old and new) get one /24 IPV4 and one ASN for these 350 EURO (or one /22 IPV4 and 1 ASN) same as it is now, just for smaller organizations/companies which want to become LIR small fees and less resources will be provided. If a company or organization needs more IPV4 space the annual fee to be bigger, for every /24 +350 euro. If a company have more than one /19 fee to be +400 euro for every /24 after first /19 All LIR to LIR permanent resource transfer to be disabled. So if you need resources only ripe can provide them to you. I beliave this way LIRs who have a lot of blocked unused IPV4 resources will return them to RIPE and they will be available for those who need them. Also speculators will be eliminated. And not last, RIPE will collect more moneys and will do what it have to do - to control the resources. Maybe somewhere back in time something similar was discussed but can somebody explain me why it is not accepted or rejected or not liked ? Ivaylo Josifov Varteh LTD Varna, Bulgaria On Tue, 4 Dec 2018, ripe-member-discuss+lr(a)c2play.de wrote: > @Dmitry: > RIPE NCC does not earn quick money, it is a non-profit organisation and not > a self-service shop. > > @Lutz Donnerhacke: > I'm not sure what you mean, but it is allowed for a single company to create > multiple LIR accounts and so get multiple IPv4 /22 at the end of the day. > That is absolutely conform to RIPE policy. > > > ____________________________________________________________________________ > From: Dmitry Vorozhtsov <dvorozhtsov(a)gmail.com> > Sent: Tuesday, 4. Dec 2018 ? 12:09 CET +0100 > To: members-discuss(a)ripe.net > > Subject: Re: [members-discuss] LIR???s billing issues with RIPE NCC, need > support > > You are wrong. All my addresses are assigned and working. You may ask - why > do I open LIRs again and again? > > Because I need more addresses to offer to my customers. Purchasing addresses > from open market is risky. Thats why I open new LIRs. > > RIPE earns quick money in this case, not me. > > > Regards, Dmitry. > > 04.12.2018 19:41, Paolo Prandini ?????: > > I was worried so much about this discussion starting again! > > I suppose a lot of people is interested in it, as far as I can > understand > is a > > matter of quick money by buying and reselling the last IPv4 blocks, > and > RIPE is > > NOT making this easy enough for some people. Then there are legitimate > > claims, but the rules were so easy to understand, 1k IPs for new LIRs, > > that there is always someone trying to bend them to make some more money. > > Anyway it is the way it goes, the world moves where it finds the money, > > I suppose it is a corollary of finding the minimum of potential energy. > > But I am not interested in this discussion, it goes on and on and on > > since more than a year, I am unsubscribing to the list. Thanks anybody > > who contributed. > > Paolo > > > > Il 04/12/2018 11:25, ripe-member-discuss+lr(a)c2play.de ha scritto: > >> > Sebastian Wiesinger sebastian.wiesinger at noris.net [Tue Dec 4 >> > 08:53:56 CET 2018] > >> > The RIPE NCC fees are anually. As a convenience *to you* you can also > >> > pay them quarterly (we don't). This has been discussed multiple times. > >> > >> > Regards > >> > >> > Sebastian > >> > >> That is, in the light of the matter of this discussion, not quite >> > correct. Yes, the fees are annual - but they are charged on a pro >> rata > basis, so for example, LIRs don't pay a full annual fee of >> ?1,400 when > they become LIR in the last quarter of 2018. They only >> pay for the last > quarter of 2018. > >> > >> What the starter of the discussion criticizes is that LIRs not only >> > have to pay member fees retroactively, they also have to pay it when >> those > LIRs are not involved in the transfer at all. > >> > >> To be honest, I think that RIPE NCC is a very fair RIR, if not the >> > fairest. But I also admit that this rule is quite confusing: To >> prevent > impatient people from creating a LIR in the last quarter of a >> year, then > transfering the resource(s) and closing the LIR to make >> fast money, we > already have a rule which states that scarce resources >> cannot be > transfered within the first 24 months after the resource >> was allocated. > >> > >> There may be also other reasons for companies to create multiple LIRs >> > than making fast money. Many people do legitime business. Also in the >> > earlier days of RIPE NCC some companies had multiple LIRs. > >> > >> With that said, I don't think the way how fees are charged for such >> > transfers is consistent, it is quite confusing. On the other hand >> RIPE NCC > has a legitime interest to prevent people from making fast >> money; but here > we already have an effective rule: The 24 months >> restriction. > >> > >> So the question is: What is the reason for this rule if you think we >> > need it to be kept? > >> > >> > >> ------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ---------------------------------------------------------------------------- > ----- >> > >> *From:*Dave Benwell <dave(a)it-communicationsltd.co.uk >> > </email/new/1/dave%40it-communicationsltd.co.uk>> > >> *Sent:*Tuesday, 4. Dec 2018 ? 10:39 CET +0100 > >> *To:*Sebastian Wiesinger <sebastian.wiesinger(a)noris.net >> > </email/new/1/sebastian.wiesinger%40noris.net>> > >> members-discuss(a)ripe.net </email/new/1/members-discuss%40ripe.net> > >> > >> *Subject:*Re: [members-discuss] LIR?s billing issues with RIPE NCC, >> > need support > >> > >> Additional accounts are normally setup to get more IP Space > >> > >> -----Original Message----- > >> From: members-discuss [mailto:members-discuss-bounces@ripe.net] On >> > Behalf Of Sebastian Wiesinger > >> Sent: 04 December 2018 07:54 > >> To: members-discuss(a)ripe.net > >> Subject: Re: [members-discuss] LIR?s billing issues with RIPE NCC, >> need > support > >> > >> * Juri <hostmaster(a)ntx.ru> [2018-12-04 08:09]: > >> > I suggest RIPE NCC do correct accounting for each LIR for the time >> > > this LIR instance exists. If LIR has annual billing - then RIPE NCC >> > > should use it. If LIR selected quarterly billing - RIPE NCC show >> use. > > But RIPE NCC should not overcharge LIRs for the time they >> didn't give > > any services for LIR instance. > >> > >> The RIPE NCC fees are anually. As a convenience *to you* you can also >> > pay them quarterly (we don't). This has been discussed multiple times. > >> > >> Regards > >> > >> Sebastian > >> > >> _______________________________________________ > >> members-discuss mailing list > >> members-discuss(a)ripe.net > >> https://lists.ripe.net/mailman/listinfo/members-discuss > >> Unsubscribe: >> > https://lists.ripe.net/mailman/options/members-discuss/dave%40it-communic > ationsltd.co.uk > >> > >> _______________________________________________ > >> members-discuss mailing list > >> members-discuss(a)ripe.net > >> https://lists.ripe.net/mailman/listinfo/members-discuss > >> Unsubscribe: >> > https://lists.ripe.net/mailman/options/members-discuss/ripe-member-discus > s%2Blr%40c2play.de > >> > >> _______________________________________________ > >> members-discuss mailing list > >> members-discuss(a)ripe.net > >> https://lists.ripe.net/mailman/listinfo/members-discuss > >> Unsubscribe: >> > https://lists.ripe.net/mailman/options/members-discuss/prandini%40spe.net > > > > > > > > _______________________________________________ > > members-discuss mailing list > > members-discuss(a)ripe.net > > https://lists.ripe.net/mailman/listinfo/members-discuss > > Unsubscribe: > > https://lists.ripe.net/mailman/options/members-discuss/dvorozhtsov%40gmail > .com > > > _______________________________________________ > members-discuss mailing list > members-discuss(a)ripe.net > https://lists.ripe.net/mailman/listinfo/members-discuss > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-mem > ber-discuss%2Blr%40c2play.de >

1 0

Re: [members-discuss] LIR’s billing issues with RIPE NCC, need support
by ripe-member-discuss+lr＠c2play.de 04 Dec '18

04 Dec '18

6 5

Re: [members-discuss] LIR???s billing issues with RIPE NCC, need support
by ripe-member-discuss+lr＠c2play.de 04 Dec '18

04 Dec '18

2 1

Re: [members-discuss] LIR???s billing issues with RIPE NCC, need support
by Lutz Donnerhacke 04 Dec '18

04 Dec '18

> Because I need more addresses to offer to my customers. Purchasing > addresses from open market is risky. Thats why I open new LIRs. You are doing it wrong. Please learn how to operate an ISP in modern times. Two hints: - https://lutz.donnerhacke.de/eng/content/search?SearchText=NAT (use deepl.com) - https://tools.ietf.org/html/rfc6540 But please stop wasting tight resources by incompetence. And please stop stealing resources from others by tricking RIPE policies. Please note, that your message is enough to reclaim the illegal obtained resources back by RIPE NCC. That's one of the activities we pay them for.

3 2

Our AS is in a macro that we don't authorize.
by José Manuel Giner 02 Nov '18

02 Nov '18

Hi, we checked that our AS is present in the macro: AS24748:AS-THINX (they have thousands of AS in their macro) After contacting atman.pl who is responsible for this macro, they tell me: > It appears that AS59432 is contained in one of our customers AS-SETs and > it is automatically added to our AS-SET AS24748:AS-THINX > > As soon as they remove AS59432, it will disappear from AS24748:AS-THINX We have asked him how we can find out who that customer is. But their answer doesn't give us any information. > Please be kindly informed that our macros are being built automatically > according to our customers` macros. If your AS happens to be removed > from whichever of our customer`s macros, ours is to be changed accordingly. We are concerned about this situation and do not know how to proceed. Thank you for your help! -- José Manuel Giner http://ginernet.com

6 7

[ncc-announce] [news] Transfers Due to Change in Business Structure and Between LIR Accounts of One Member
by Фри Дата 29 Oct '18

29 Oct '18

1 0

Out of office email
by Cedric R 02 Aug '18

02 Aug '18

Hello, When i send a message to this mailing list, i receive some Out of office from a bunch of members. Can you avoid to use out of office on mailbox used for mailing list (maybe use separate mailbox). Thanks Cédric Rossius

2 1

Re: [members-discuss] Effective countermeasures against BGP hijacking
by Alex Band 02 Aug '18

02 Aug '18

Hi Dominic, > On 1 Aug 2018, at 16:43, Dominic Schallert <ds(a)schallert.com> wrote: > > Signed PGP part > Hi Cedric, > >> Am 01.08.2018 um 15:45 schrieb Cedric R <ml(a)servperso.com>: >> >> Hello, >> I think it's not a bad idea but the real solution remain RPKI. >> If transit operator like HE or L3 start to reject INVALID RPKI and some riskly network start to sign theyr route (and it's pretty simple with RIR tools) we can clear a part of the problem quickly. >> I don't talk about reject unsigned route, but only invalid signed. > > I absolutely agree with you. Personally I believe, for making progress with technology, we will always need some innovators and big players which are able and willing to create a certain amount of pressure on the market. If the big transit providers or networks like Google, Amazon, etc. would agree about a certain date after which they will reject all invalid RPKI, I guess we would see some spike in RPKI adoption VERY quickly. Similiar thing just happening with HTTPS/TLS and their flagging of http:// as insecure in their latest Chrome builds. Same story around three years ago with Google's call for mobile-first and responsiveness. Concerning BGP, unfortunately I do not expect the any of the big ones to take this step anywhere soon, as it would also dramatically impact their own availability and revenue. So what other options do we have then? After events like the MyEtherWallet BGP hijack, these big corporations you mention are certainly not ignoring RPKI. The feedback I’ve been getting from the industry is not so much the willingness to adopt RPKI but rather the lack of mature, well maintained and easy to use tooling to deploy and maintain it. The hosted systems that the RIRs offer are fine for basic management, but if you’re an enterprise with address space in multiple RIR regions or you are an LIR with a large amount of customers you manage routing for, clicking around in (multiple) RIR web interfaces gets old really fast. The same goes for relying party software to validate RPKI data; how many mature implementations are available? To use your own example, large scale deployment of HTTPS was only possible after Let’s Encrypt provided a practical and affordable way for everyone to have a certificate. The same can happen with RPKI... Cheers, Alex Band NLnet Labs @alexander_band https://nlnetlabs.nl > > >> Also AS blacklisting can be quickly spoofed. >> What append if someone use hijacked ASN behind it's legit ASN to announce hijacked prefix (not every filters drop that). > > To be honest, that’s an issue I haven't thought about yet but you are absolutely right. > The only feasible solution here would be strict IRRDB filtering on autnum/as-set. > > Best Regards > Dominic > > >> Best Regards >> Cedric Rossius >> >> Le 01-08-18 à 11:59, Dominic Schallert a écrit : >>> Dear colleagues, >>> >>> I’m sure some of you have read about this recent incident; https://bgpstream.com/event/144058 . Nowadays we’re talking about transport security, https-per-default, etc. but the most fundamental parts of the internet such as BGP, are basically broken from a security perspective. While RPKI/ROA/ROV could fix most of the current security-related struggles, their deployment currently competes somewhat with IPv6 - or even worse - and therefore won’t be a practical solution in the forseeable future. Strict IRRDB and route object filtering is complicated (or almost impossible) as well. >>> >>> So I’m wondering, why can't we just have an automated blacklist like RBL's for mailservers, where all AS'es detected for hijacking prefixes are automatically blacklisted, similiar to Team Cymru's fullbogons feed? The list combined with some scripting could then be used for realtime AS-path filtering at border routers. Delisting of blacklisted ASNs should happen only after a pre-defined amount of time (eg. 14 days) or after paying a fee to a charity/non-profit and providing a statement on the issue which is publicy released. The idea is to hurt those who can’t get their stuff - especially prefix filtering - together. >>> >>> I still remember the days where everyone complained about RBLs, nowadays almost every mailserver setup relies on them. Sometimes extreme problems require extrem solutions. >>> >>> Mit besten Grüßen >>> Kind Regards >>> >>> Dominic Schallert, BA >>> >>> >>> <logo_email.png> >>> >>> >>> schallert.com e.U. | Hauptstraße 35b, 6800 Feldkirch, Austria >>> >>> FN: 440372g | UID: ATU66209211 | Gerichtsstand: Feldkirch >>> >>> Tel.: +43 680 146 1947 | Fax: +43 134 242 642 616 >>> >>> www.schallert.com | office(a)schallert.com >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> members-discuss mailing list >>> >>> members-discuss(a)ripe.net >>> https://lists.ripe.net/mailman/listinfo/members-discuss >>> >>> Unsubscribe: >>> https://lists.ripe.net/mailman/options/members-discuss/ml%40servperso.com >> > > >

2 1

Re: [members-discuss] Effective countermeasures against BGP hijacking
by Cedric R 01 Aug '18

01 Aug '18

Anyone to start an internet secure day ? ;) Maybe it's a good way to kickstart that change Le 01-08-18 à 16:43, Dominic Schallert a écrit : > Hi Cedric, > >> Am 01.08.2018 um 15:45 schrieb Cedric R <ml(a)servperso.com >> <mailto:ml@servperso.com>>: >> >> Hello, >> I think it's not a bad idea but the real solution remain RPKI. >> If transit operator like HE or L3 start to reject INVALID RPKI and >> some riskly network start to sign theyr route (and it's pretty simple >> with RIR tools) we can clear a part of the problem quickly. >> I don't talk about reject unsigned route, but only invalid signed. > > I absolutely agree with you. Personally I believe, for making progress > with technology, we will always need some innovators and big players > which are able and willing to create a certain amount of pressure on > the market. If the big transit providers or networks like Google, > Amazon, etc. would agree about a certain date after which they will > reject all invalid RPKI, I guess we would see some spike in RPKI > adoption VERY quickly. Similiar thing just happening with HTTPS/TLS > and their flagging of http:// as insecure in their latest Chrome > builds. Same story around three years ago with Google's call for > mobile-first and responsiveness. Concerning BGP, unfortunately I do > not expect the any of the big ones to take this step anywhere soon, as > it would also dramatically impact their own availability and revenue. > So what other options do we have then? > > >> Also AS blacklisting can be quickly spoofed. >> What append if someone use hijacked ASN behind it's legit ASN to >> announce hijacked prefix (not every filters drop that). > > To be honest, that’s an issue I haven't thought about yet but you are > absolutely right. > The only feasible solution here would be strict IRRDB filtering on > autnum/as-set. > > Best Regards > Dominic > > >> Best Regards >> Cedric Rossius >> >> Le 01-08-18 à 11:59, Dominic Schallert a écrit : >>> Dear colleagues, >>> >>> I’m sure some of you have read about this recent incident; >>> https://bgpstream.com/event/144058 . Nowadays we’re talking about >>> transport security, https-per-default, etc. but the most fundamental >>> parts of the internet such as BGP, are basically broken from a >>> security perspective. While RPKI/ROA/ROV could fix most of the >>> current security-related struggles, their deployment currently >>> competes somewhat with IPv6 - or even worse - and therefore won’t be >>> a practical solution in the forseeable future. Strict IRRDB and >>> route object filtering is complicated (or almost impossible) as well. >>> >>> So I’m wondering, why can't we just have an automated blacklist like >>> RBL's for mailservers, where all AS'es detected for hijacking >>> prefixes are automatically blacklisted, similiar to Team Cymru's >>> fullbogons feed? The list combined with some scripting could then be >>> used for realtime AS-path filtering at border routers. Delisting of >>> blacklisted ASNs should happen only after a pre-defined amount of >>> time (eg. 14 days) or after paying a fee to a charity/non-profit and >>> providing a statement on the issue which is publicy released. The >>> idea is to hurt those who can’t get their stuff - especially prefix >>> filtering - together. >>> >>> I still remember the days where everyone complained about RBLs, >>> nowadays almost every mailserver setup relies on them. Sometimes >>> extreme problems require extrem solutions. >>> >>> Mit besten Grüßen >>> Kind Regards >>> >>> Dominic Schallert, BA >>> >>> >>> <logo_email.png> >>> >>> >>> *schallert.com e.U.* | Hauptstraße 35b, 6800 Feldkirch, Austria >>> FN: 440372g | UID: ATU66209211 | Gerichtsstand: Feldkirch >>> Tel.: +43 680 146 1947 | Fax: +43 134 242 642 616 >>> >>> www.schallert.com <http://www.schallert.com/> | office(a)schallert.com >>> <mailto:office@schallert.com> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> members-discuss mailing list >>> members-discuss(a)ripe.net >>> https://lists.ripe.net/mailman/listinfo/members-discuss >>> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/ml%40ser… >> >> >

1 0

Re: [members-discuss] Effective countermeasures against BGP hijacking
by Dominic Schallert 01 Aug '18

01 Aug '18

Hi Cedric, > Am 01.08.2018 um 15:45 schrieb Cedric R <ml(a)servperso.com <mailto:ml@servperso.com>>: > > Hello, > I think it's not a bad idea but the real solution remain RPKI. > If transit operator like HE or L3 start to reject INVALID RPKI and some riskly network start to sign theyr route (and it's pretty simple with RIR tools) we can clear a part of the problem quickly. > I don't talk about reject unsigned route, but only invalid signed. I absolutely agree with you. Personally I believe, for making progress with technology, we will always need some innovators and big players which are able and willing to create a certain amount of pressure on the market. If the big transit providers or networks like Google, Amazon, etc. would agree about a certain date after which they will reject all invalid RPKI, I guess we would see some spike in RPKI adoption VERY quickly. Similiar thing just happening with HTTPS/TLS and their flagging of http:// as insecure in their latest Chrome builds. Same story around three years ago with Google's call for mobile-first and responsiveness. Concerning BGP, unfortunately I do not expect the any of the big ones to take this step anywhere soon, as it would also dramatically impact their own availability and revenue. So what other options do we have then? > Also AS blacklisting can be quickly spoofed. > What append if someone use hijacked ASN behind it's legit ASN to announce hijacked prefix (not every filters drop that). To be honest, that’s an issue I haven't thought about yet but you are absolutely right. The only feasible solution here would be strict IRRDB filtering on autnum/as-set. Best Regards Dominic > Best Regards > Cedric Rossius > > Le 01-08-18 à 11:59, Dominic Schallert a écrit : >> Dear colleagues, >> >> I’m sure some of you have read about this recent incident; https://bgpstream.com/event/144058 <https://bgpstream.com/event/144058> . Nowadays we’re talking about transport security, https-per-default, etc. but the most fundamental parts of the internet such as BGP, are basically broken from a security perspective. While RPKI/ROA/ROV could fix most of the current security-related struggles, their deployment currently competes somewhat with IPv6 - or even worse - and therefore won’t be a practical solution in the forseeable future. Strict IRRDB and route object filtering is complicated (or almost impossible) as well. >> >> So I’m wondering, why can't we just have an automated blacklist like RBL's for mailservers, where all AS'es detected for hijacking prefixes are automatically blacklisted, similiar to Team Cymru's fullbogons feed? The list combined with some scripting could then be used for realtime AS-path filtering at border routers. Delisting of blacklisted ASNs should happen only after a pre-defined amount of time (eg. 14 days) or after paying a fee to a charity/non-profit and providing a statement on the issue which is publicy released. The idea is to hurt those who can’t get their stuff - especially prefix filtering - together. >> >> I still remember the days where everyone complained about RBLs, nowadays almost every mailserver setup relies on them. Sometimes extreme problems require extrem solutions. >> >> Mit besten Grüßen >> Kind Regards >> >> Dominic Schallert, BA >> >> >> <logo_email.png> >> >> >> schallert.com e.U. | Hauptstraße 35b, 6800 Feldkirch, Austria >> >> FN: 440372g | UID: ATU66209211 | Gerichtsstand: Feldkirch >> >> Tel.: +43 680 146 1947 | Fax: +43 134 242 642 616 >> >> www.schallert.com <http://www.schallert.com/> | office(a)schallert.com <mailto:office@schallert.com> >> >> >> >> >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss(a)ripe.net <mailto:members-discuss@ripe.net> >> https://lists.ripe.net/mailman/listinfo/members-discuss <https://lists.ripe.net/mailman/listinfo/members-discuss> >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ml%40servperso.com <https://lists.ripe.net/mailman/options/members-discuss/ml%40servperso.com> >

1 0