- connect-wg - mailman.ripe.net

My response to Ronald Guilmette
by Elad Cohen 17 Apr '20

17 Apr '20

Hello Everyone, Please forgive me for not writing an official response in first set of Ronald's online madness months ago, I was out of hospital after full anesthesia and it took me months to get back to myself. Ronald is misery person with nothing and with no one in his life, the only joy that he have in his life - is for him to serve as the front person of the illegal anonymous organization "The Spamhaus Project". Here is a presentation that "The Spamhaus Project" wrote on themselves (in the following link) and according to it Spamhaus is an illegal anonymous organization - they receive a massive amount of illegally obtained privacy data of internet users from internet companies and internet organizations on a regular basis - and then they share it in illegal way (without any warranty) with law enforcement agencies. https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Vio… Ronald doesn't deny himself being part of "The Spamhaus Project", not only that - but his old friend Hank Nussbacher is also part of the illegal anonymous organization "The Spamhaus Project", Hank reminds me Judas Iscariot - Hank obviously have other interests - it is very sad to see a person at the age of Hank acting like a little child. All the few reports that were made were made by reporters which are connected to "The Spamhaus Project" and that are part of "The Spamhaus Project" - not only that, the source of the media reports is a person in "The Spamhaus Project" which is the owner of that illegal twitter account: https://twitter.com/underthebreach , that person is a criminal according to his own words in his own twitter account - and that person is also a master of cyber influence operations (just like what Coconut Guilmette and Cheerleader Nussbacher are doing here, to influence public opinion without any single proof) - and the owner of that twitter account is also an employee of the israeli-based company GeoEdge which financially benefit from that media report because they are a direct competitor of the company using the exact same netblock, so now I'm explaining to you that that root of this all fake story is just business competition, and in addition Coconut Guilmette also attacked the Israeli-based company Divinetworks in Nanog (Coconut Guilmette searched an unreasonable way why they received a specific grant from a global world organization and also defamed them) - so here is why he did it - the Israeli-based company Divinetworks is also a direct competitor of the Israeli-based company GeoEdge - that their employee is a criminal and the owner of the illegal twitter account https://twitter.com/underthebreach and also the "source" for the fake few media reports. In the following link you can see how a high manager in GeoEdge is highly proud in how customers attracted to him after the "low value" of competitors, if only the world would knew how that company does business. https://imgur.com/7DF1NSP That company GeoEdge is not only a criminal company in the way that they do business (because their criminal employee in "The Spamhaus Project" is the one pumped Coconut Guilmette proof-less ideas), but that company is also a criminal in the way that they are tax-evading since 2005 (they are registered in Cyprus with fake-single-owner abroad while they have more actual hidden owners in Israel that didn't pay any tax for their income since 2005, and one of the registered owners is using an international fake name and he is a professional money-laundering person, not only for that Israeli company). They (Coconut Guilmette, Cheerleader Nussbacher and their mob friends at "The Spamhaus Project") are very very afraid of me releasing all the information that I found out on the illegal anonymous organization "The Spamhaus Project" - and that is the only reason that they are attacking me personally in such way, they are trying to ruin my good name - but they didn't succeed and they will not succeed - because anyone that knows me and anyone that will personally know me - will know what they are trying to do and that what they are writing is 100% false. All the personal attack against me - is only because I dared to stood up against "The Spamhaus Project" which is intimidating and hurting many businesses online, and I would and will do it again and again and again, I'm not the kind of a misery bendover jew like Hank that will sell his values and his being for a title, a group acceptance or a few cents. Coconut Guilmette, is not only a sick person, in body and mind, but also a racist and an antisemitic, you can see in the following links his stereotypical mindset: https://imgur.com/AcmgwEX (Coconut Guilmette opinion on all Dutch people as a whole - "Dutch are any more inclined toward cybercrime") https://imgur.com/WUZvdNJ (Coconut Guilmette opinion on all Colombian Network Operators usage of the internet as a whole - "Undoubtedly drug smuggling over HTTP") https://imgur.com/a/1ULfVEC (Coconut Guilmette opinion on the City of Chicago including all of its citizens as a whole - "American city most known for its high ideals and consistantly ethical behavior, Chicago") https://imgur.com/AQCmZlk (Coconut Guilmette identified as racist in Nanog) https://imgur.com/a/Rzrbxkz (Coconut Guilmette identified as antisemitic in Nanog) Besides the above links, Coconut Guilmette is specifically calling me with two words and here he is quoting Shakespeare: https://imgur.com/AcmgwEX , the two words that Coconut Guilmette is calling me are being used in Shakespeare litrature to identify jews in an antisemitic way, Coconut Guilmette is an antisemitic, I'm very sorry to write it but Ripe is not a decisive organization towards racism or antisemitism, the Tone in Ripe management and in Ripe board and in this working group co-chairs, is a very narrow tone that only reflect the good of the people in their positions, Ripe board & management are not taking any actions for Ripe to be a multi-culture multi-national unpolitical organization that it needs to be with the tolerance to anyone and with the decisive intolerance to racism or antisemitism. The encouragement of Cheerleader Nussbacher is even worst because Cheerleader Nussbacher is encouraging someone which is a racist and an antisemitic. Hank, how more self-hating jew can you be ? to support such person only to be part of an illegal anonymous organization ? to support racism ? to support antisemitism ? And to the rest of the community, anyone that wrote to this person - "nice story, but you could say it in other words" - you are a lowlife as Hank is, you don't treat a racist or an antisemitic person with tolerance, period. Ripe is a RIR which is spread over 3 continents over many countries, Ripe members are different from each other by all means, I would expect Ripe community not to tolerate racism in any way and when Ripe members see it - to stand up - like I dared to stand up against "The Spamhaus Project". Ron, seeing a person at your age that knows to get attention only by using racism and antisemitism is sad, but seeing the lowlife Judas Iscariot cheerleading your mental illness is sadder. Here are only some of the real identities of the people behind "The Spamhaus Project": "Rob Shultz" - Rob McEwen (https://www.invaluement.com/) "Thomas Morrison" - Daniel R. Thomas (https://personal.cis.strath.ac.uk/d.thomas/) "Pete Dawes" - Ildiko Pete (https://www.cl.cam.ac.uk/~ip358/) "Vincent Hanna" - Vincent Schonau of Open-Xchange (https://www.linkedin.com/in/vincentschonau/) "Milly Fawcett" - Kelly Molloy of FarSight Security (https://www.linkedin.com/in/kelly-molloy-b886442/) Among others Commericial companies behind "The Spamhaus Project": ThreatSTOP FarSight Security Fastly Cymru Among others Keep on playing with me Coconut Guilmette and Cheerleader Nussbacher and I guarantee to you that the full list will be written here, you can hurt me as much as you please - I am not boneless and will not fold like Hank "Judas Iscariot" Nussbacher. The only reason that Coconut Guilmette returned to life in this thread - is because I wrote two days ago the real identity of "Rob Shultz" (which is Rob McEwen of https://www.invaluement.com/ ) to the co-chairs of this working group with CC to Ripe Board and to Ripe Management, I asked for the initial post of lies of Coconut Guilmette to be removed and I showed to them the relation of one of the current co-chairs of that working group to the illegal anonymous organization "The Spamhaus Project" which the poster Coconut Guilmette is related to it too. (also in the past there was a co-chair of that working group which is part of "The Spamhaus Project", Richard D G Cox, as you can see in his presentation that I linked to it above) That is the only reason (that I revealed that "Rob Shultz" from "The Spamhaus Project" is Rob McEwen) that Coconut Guilmette and Boneless Nussbacher are personally attacking me, not only that - but soon you will also see a new fake media report about me from the same reporter that used the criminal https://twitter.com/underthebreach as his source - all of it (like it was then and like they are trying to do now) - is to maneuver the subject of who are the real people behind "The Spamhaus Project" and to which internet companies and internet organizations they are connected to. "The Spamhaus Project" is an illegal anonymous organization and an unregulated organization, by being unregulated it is abused by the some of the members of it for making money, without any supervision, for example the criminal which is the owner of the illegal twitter account https://twitter.com/underthebreach that did what it did only that GeoEdge will earn a few more cents, such as Laura Atkins from WordToTheWise which is selling a Spamhaus listing removal service (https://wordtothewise.com), such as Vincent Schonau (AKA "Vincent Hanna" of "The Spamhaus Project") from Open-Xchange, a company that Spamhaus are attacking its competitors, and there are many more Spamhaus members that are using Spamhaus for their financial benefits. "The Spamhaus Project" - by being unregulated and unsupervised - is also being used as tool to attack business competitors, this is something that should wake up each and every member of the internet community. Hank, why do you let Coconut Guilmette to do the hard work for you (of defaming me) ? because you know that he have nothing in his life and a lawsuit against him will not result any financial aid ? why are you abusing his mental illness ? you know that he is not fine, why don't you help him like a good old friend ? Go ahead and write what Ron is writing so I will be able to sue you locally in Israel (I'm willing to pay you 100,000 NIS if you are right in a single thing that you wrote or that you will write against me, are you willing to do the same ? are you willing to put your money where your words are? or are you boneless that can only exploit the state of your old friend? ) I respect Ripe NCC and Respect all the members of Ripe Anti-Abuse Working Group. (P.S.: you can recognize now any member of "The Spamhaus Project" that will jump now, if he will attack me or support Ron, you can just ask him a simple question - "show us a single proof" - and you will see that no proof will be displayed, because all of it is part of an illegal "cyber influence operation" by "The Spamhaus Project" pumped by the criminal https://twitter.com/underthebreach) Respectfully, Elad

1 0

how to approach some IX resources
by Eric Andrei Băleanu | InterLAN 02 Apr '20

02 Apr '20

Hello, It seems like these days we have more time to discuss. We would like to have some input from the community about your approach regarding some IX resources. Backup ports: commonly the ISP has an aditional router connected to the backup port, in a switch other than the one where the main port is connected, with an additional configuration (another pair of IPv4/v6 adresses). Question: Do you permit balanced traffic between the main port and the backup port? Or the backup port is allowed to be use only when the main port is down? Aggregated ports: The ISP has N x 1G or N x 10G ports connected to IXP platform, same switch, LACP config. Question: Do you treat aggregated ports as "one" port? E.g. 2 x 1G ports are one 2G port? Or 2 x 10G ports are one 20G port? Please share your experiences, keep safe and stay healthy. Regards, Eric Andrei Băleanu InterLAN Internet Exchange 8 Cezar Bolliac Street, Bucharest 030912, 3rd District Phone: +40 31 710 2428 Mobile: +40 733 999 069 E-mail: eric.baleanu(a)interlan.ro <mailto:eric.baleanu@interlan.ro> www.interlan.ro <http://www.interlan.ro/> www.ronog.ro <http://www.ronog.ro/>

1 0

virtual session at RIPE 80
by Florence Lavroff 27 Mar '20

27 Mar '20

Dear friends of the Connect-WG, As you may all know by now, RIPE 80 will be a virtual meeting. While we are still working out the logistics of it with our fellow RIPE chairs, we'd like to get your feedback on what topics you'd like to discuss under what format and how long this virtual session should ideally take. We consider maintaining our 1.5 hour slot for the moment, unless you propose otherwise. We'd also like to suggest as a main topic for the working group a discussion session around the impact of covid-19 on traffic, including but not restricted to the role of IXPs during the crisis. Feel free to let us know your thoughts, Stay safe, healthy and wash your hands, Best regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Infrastructure Acquisition and Interconnect / Google EMEA

4 3

New on RIPE Labs: Down the Black Hole: Dismantling Operational Practices of BGP Blackholing at IXPs
by Mirjam Kuehne 07 Dec '19

07 Dec '19

Dear colleagues, For those who missed Marcin Nawrocki's presentation at RIPE 79, the summary of this research is now available on RIPE Labs: Down the Black Hole: Dismantling Operational Practices of BGP Blackholing at IXPs https://labs.ripe.net/Members/marcin_nawrocki/down-the-black-hole-dismantli… Kind regards, Mirjam Kühne RIPE NCC

2 1

Fwd: Re: BEREC consultation: contribution
by Steve Nash 13 Nov '19

13 Nov '19

I have only partially absorbed all aspects of the BEREC document and EU Article61, but my impression is of some important missing elements. In particular, I have not noticed references to co-habitation of multiple NTP in one customer site. The subject of resilience seems missing. BEREC has given us a simple model on which to comment, with three levels of NTP. Rather than defining what an NTP must always be, I prefer to consider what a customer needs from the NTP regardless of its logical location. Given that we are RIPE, and given the absence of any bidirectional Public Data Communication Network other than the Internet, I focus my comments accordingly. Summary Whatever the point of delivery of the Network connection, there must be clear signalling of whether or not the provision of Network connection is functional. For Internet Access the NTP must indicate the status of its connection to the Internet. The form of the indication is considered next for each of the BEREC logical Termination Points. *BEREC connection point C:* (Where the NTP has a routing function or NAT, IP aware) The NTP must indicate via its customer port, using IETF standard routing protocol, what connections it is offering /{list of minimum customer selectable protocols?}/. It must withdraw those routing announcements as quickly as the standard allows in the event that its peer router in the network becomes unavailable. *BEREC connection point B:* (Where the connection is provided at a modem port, Ethernet or WiFi) The network must provide signalling of its status to the user. The user must be provided with: * visibility of the adjacent router(s) by routing protocol announcements from the operators router(s). The list of offered routing protocols being a required part of the service description. * the IP address delegated by the operator for the CPE, manually or by DHCP. * the permanence of the IP address delegation (Static or Dynamic) * the IP address of the adjacent router(s) in the provider's network, to enable security filtering *BEREC connection point A:* (Where the connection is by wired, optical or wireless Ethernet) The Network must offer DHCP for the customer's delegated address, and the address of the available Network router. The Network may offer IP routing protocols, as for connection point B. The physical Signal must be withdrawn at the physical layer when the Network is otherwise unable to communicate loss of routes ( for comparison consider removal of dial tone). *Other Requirements:* 1/ In cases B and C, user-configuration of the characteristics of the user port must be supported. Including Local MAC address, Local IP address, Local default router, Local routing protocol, as applicable. 2/ It must be contractually clear whether an Internet Connection service at an NTP is fully open, or in some way restricted.A fully open Internet Connection will have a public IP address capable of end to end communication with any other public Internet address on the same version of IP. This would facilitate the customer in supporting an Internet Server, if they so choose. Restrictions that make the connection less than a fully open Internet connection must be disclosed in the documentation of the connection service, and include: * Network Address Translation, either in the network (CGN) or on supplied NTP. * Blocking of access to some Internet addresses (as has sometimes been the case for open DNS resolvers). 3/ Power Supply resilience for network devices becomes increasing important. Consideration should be given to regulation of common low power battery backup supply connection for all NTP. Rationale Most homes in the EU have more than one Network by which to access the Internet, commonly one fixed and one or more mobile. The NTP of each Network must allow for the existence of others and must enable the customer to program decisions about which Network to use. Automated resilience of Internet connectivity becomes increasingly important as: * home working becomes more prevalent * critical devices such as medical appliances and alarm systems are connected in the home via the Internet Therefore resilience for Internet connectivity must be considered in regulation with respect to both Network selection and power supply resilience, as follows. *Network selection:* On the PSTN the existence of Dial-tone has been the indication of availability at the NTP. A home can easily have more than one PSTN NTP, and more than one fixed line connection to the Internet in addition to mobile. Therefore, customer owned equipment must have the opportunity to be able to directly determine, in an automated fashion, whether or not connectivity via each Internet Connection Provider is functional. Methods are dependent on the chosen logical Network Termination Point and are proposed in the Summary above. *Power supply resilience:* Logical termination equipment (e.g. modem) may be required for some physical access media. If power is not supplied from the network then the customer's domestic supply may be used. In the latter case the regulator must give consideration to backup supply standardisation. The proliferation of individual AC to DC power converters and the need for Inverters to get back to AC supply levels from battery backup is not energy efficient. Standardisation of low power DC supply to NTP devices would reduce electrical wastage and could reduce the number of manufactured components required where devices are permanently powered with DC. Steve Nash Writing my personal opinions, with the Sponsorship of NETSCOUT. On 10/10/2019 17:52, Marco Hogewoning wrote: > Dear colleagues, > > Earlier this week, BEREC (Body of European Regulators for Electronic Communications) announced a public consultation on their draft guidelines for interpreting the “network termination point (NTP)”. These guidelines have been designed in accordance with Article 61(7) of the European Electronic Communications Code to provide national regulatory authorities (NRAs) with guidance on how to interpret the EU directives and implement them in their national legislation. > > This consultation is open to the public. While the RIPE NCC has no particular position on this topic, we think it is important for the community to consider the impact of these guidelines. They could impact not only our members’ operations, but the RIPE NCC’s engagement strategy on a number of topics such as IPv6 and IoT security. > > We invite the Connect Working Group to discuss the proposed guidelines and, should it reach a rough consensus as determined by the chairs, the RIPE NCC is willing to submit that opinion as a response on behalf of the RIPE community. As we see pros and cons to either alternative, failure to reach consensus will mean we will not respond to this consultation on behalf of the RIPE community, but would instead encourage individual members to provide their own responses. > > I’ll provide a brief description of the problem space and the potential impact below, but I recommend reading the draft guidelines as they are posted on the BEREC website: > https://berec.europa.eu/eng/document_register/subject_matter/berec/regulato… > > Please note that while BEREC’s deadline is 21 November, we would need a few days to process and file the formal response and we kindly request the working group to respect close of business on 15 November as its internal deadline to reach consensus. > > Key Issues > > One of the key questions laid out in the document is whether or not the CPE or modem is part of the NTP. EU Regulation 2015/2120 states with regard to Internet access services in article 3(1): > >> “End-users shall have the right to access and distribute information and content, use and provide applications and services, and use terminal equipment of their choice […]” > The 2016 BEREC Guidelines on net neutrality rules (paragraphs 26 and 27) provide further guidance on the implementation and state: > >> “In considering whether end-users may use the terminal equipment of their choice, NRAs should assess whether an ISP provides equipment for its subscribers and restricts the end-users’ ability to replace that equipment with their own equipment, i.e. whether it provides ‘obligatory equipment’. >> >> Moreover, NRAs should consider whether there is an objective technological necessity for the obligatory equipment to be considered as part of the ISP network. If there is not, and if the choice of terminal equipment is limited, the practice would be in conflict with the Regulation.” > Not only is this subject to national definitions and implementations, it also allows for exceptions under “objective technological necessity”. Among other things, the draft guidelines go into a lot of detail with regards to the consequence of the different options that exist. > > As explained above, the RIPE NCC has no immediate position on which option is the better alternative. However, it could impact our engagement strategy in the longer term. > > There are roughly two alternative options: the modem or CPE is “obligatory” and as such will be supplied and maintained by the access provider as part of their network, or the end-user is allowed or even required to source their own equipment, which needs to be compatible with the network. > > The two different options would impact, for example, the RIPE NCC’s focus when it comes to IPv6 adoption. Although we have seen successful deployments under both scenarios, it is either the ISP that is in control and has to make the choice (which of course often means our members are deciding), or we need to somehow create awareness among end-users and engage more with manufacturers, importers and retailers to adopt equipment that supports IPv6. > > We also imagine that such a choice would impact the scale and, more importantly, the speed of IPv6 adoption. > > We also expect that if the prevailing choice would be to allow the end-user to select their own equipment, there will be an increased demand for strict standards and profiles to ensure interoperability. While the draft guidelines recognise that the CPE market is both competitive and innovative, we expect these discussions to lean towards additional certification requirements to ensure interoperability. > > In light of the current discussions about IoT security, especially in household appliances, we also see a big focus on the CPE as providing some security-related services. Several of these systems, such as SPIN and MUD/FUD, have been presented to the community. Again, a more scattered landscape where users select their own devices might make it challenging for these technologies to reach a sustainable level of adoption. > > More generally, we can expect that greater freedom of choice in selecting devices would come with some additional security challenges, where the increased variety could also lead to an increase in the variety of attack vectors and vulnerabilities. Also, as the CPE would no longer be in the ISP’s domain, we would lose the ability to quickly roll out patches and would instead have to trust the end-user or manufacturer to install updates in a timely fashion. > > Again, this is something where we would expect further discussion with regards to regulatory measures and (mandatory) certification to ensure minimum requirements are met and to protect the consumer. > > In either case, we trust the NRAs and the market to make an informed decision on the most appropriate approach and are happy to bring the RIPE community’s opinion forward to this consultation. Regardless of the outcome, we will continue to monitor these discussions and adjust our engagement strategy accordingly, both towards policymakers as well as the various market participants and, where necessary, the end-users. > > Regards, > > Marco Hogewoning > External Relations, RIPE NCC > > > _______________________________________________ > connect-wg mailing list > connect-wg(a)ripe.net > https://lists.ripe.net/mailman/listinfo/connect-wg -- Steve(a)nashfamily.me.uk is now my personal email address.

4 5

FW: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)
by Erik Bais 17 Oct '19

17 Oct '19

Dear Connect WG, As co-chair of the Address Policy WG, I would like to inform you at the following AP-WG proposal by Remco van Mook to adjust the default allocation size for IXP space. The discussion will be on a AP-WG mailing list and I would suggest to the Connect WG to provide your experience and input on this idea. This will have an impact on your business/operation .. we need to receive your view and insight. Regards Erik Bais On behalf of the AP-WG Chair collective On 15/10/2019, 14:43, "address-policy-wg on behalf of Marco Schmidt" <address-policy-wg-bounces(a)ripe.net on behalf of mschmidt(a)ripe.net> wrote: Dear colleagues, A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" is now available for discussion. This proposal aims to change the default IXP assignment size from a /24 to a needs-based model, with a /27 as a minimum. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-07 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 13 November 2019. Regards, Marco Schmidt Policy Officer RIPE NCC

1 0

BEREC consultation: Identification of the network termination point
by Marco Hogewoning 16 Oct '19

16 Oct '19

Dear colleagues, Earlier this week, BEREC (Body of European Regulators for Electronic Communications) announced a public consultation on their draft guidelines for interpreting the “network termination point (NTP)”. These guidelines have been designed in accordance with Article 61(7) of the European Electronic Communications Code to provide national regulatory authorities (NRAs) with guidance on how to interpret the EU directives and implement them in their national legislation. This consultation is open to the public. While the RIPE NCC has no particular position on this topic, we think it is important for the community to consider the impact of these guidelines. They could impact not only our members’ operations, but the RIPE NCC’s engagement strategy on a number of topics such as IPv6 and IoT security. We invite the Connect Working Group to discuss the proposed guidelines and, should it reach a rough consensus as determined by the chairs, the RIPE NCC is willing to submit that opinion as a response on behalf of the RIPE community. As we see pros and cons to either alternative, failure to reach consensus will mean we will not respond to this consultation on behalf of the RIPE community, but would instead encourage individual members to provide their own responses. I’ll provide a brief description of the problem space and the potential impact below, but I recommend reading the draft guidelines as they are posted on the BEREC website: https://berec.europa.eu/eng/document_register/subject_matter/berec/regulato… Please note that while BEREC’s deadline is 21 November, we would need a few days to process and file the formal response and we kindly request the working group to respect close of business on 15 November as its internal deadline to reach consensus. Key Issues One of the key questions laid out in the document is whether or not the CPE or modem is part of the NTP. EU Regulation 2015/2120 states with regard to Internet access services in article 3(1): > “End-users shall have the right to access and distribute information and content, use and provide applications and services, and use terminal equipment of their choice […]” The 2016 BEREC Guidelines on net neutrality rules (paragraphs 26 and 27) provide further guidance on the implementation and state: > “In considering whether end-users may use the terminal equipment of their choice, NRAs should assess whether an ISP provides equipment for its subscribers and restricts the end-users’ ability to replace that equipment with their own equipment, i.e. whether it provides ‘obligatory equipment’. > > Moreover, NRAs should consider whether there is an objective technological necessity for the obligatory equipment to be considered as part of the ISP network. If there is not, and if the choice of terminal equipment is limited, the practice would be in conflict with the Regulation.” Not only is this subject to national definitions and implementations, it also allows for exceptions under “objective technological necessity”. Among other things, the draft guidelines go into a lot of detail with regards to the consequence of the different options that exist. As explained above, the RIPE NCC has no immediate position on which option is the better alternative. However, it could impact our engagement strategy in the longer term. There are roughly two alternative options: the modem or CPE is “obligatory” and as such will be supplied and maintained by the access provider as part of their network, or the end-user is allowed or even required to source their own equipment, which needs to be compatible with the network. The two different options would impact, for example, the RIPE NCC’s focus when it comes to IPv6 adoption. Although we have seen successful deployments under both scenarios, it is either the ISP that is in control and has to make the choice (which of course often means our members are deciding), or we need to somehow create awareness among end-users and engage more with manufacturers, importers and retailers to adopt equipment that supports IPv6. We also imagine that such a choice would impact the scale and, more importantly, the speed of IPv6 adoption. We also expect that if the prevailing choice would be to allow the end-user to select their own equipment, there will be an increased demand for strict standards and profiles to ensure interoperability. While the draft guidelines recognise that the CPE market is both competitive and innovative, we expect these discussions to lean towards additional certification requirements to ensure interoperability. In light of the current discussions about IoT security, especially in household appliances, we also see a big focus on the CPE as providing some security-related services. Several of these systems, such as SPIN and MUD/FUD, have been presented to the community. Again, a more scattered landscape where users select their own devices might make it challenging for these technologies to reach a sustainable level of adoption. More generally, we can expect that greater freedom of choice in selecting devices would come with some additional security challenges, where the increased variety could also lead to an increase in the variety of attack vectors and vulnerabilities. Also, as the CPE would no longer be in the ISP’s domain, we would lose the ability to quickly roll out patches and would instead have to trust the end-user or manufacturer to install updates in a timely fashion. Again, this is something where we would expect further discussion with regards to regulatory measures and (mandatory) certification to ensure minimum requirements are met and to protect the consumer. In either case, we trust the NRAs and the market to make an informed decision on the most appropriate approach and are happy to bring the RIPE community’s opinion forward to this consultation. Regardless of the outcome, we will continue to monitor these discussions and adjust our engagement strategy accordingly, both towards policymakers as well as the various market participants and, where necessary, the end-users. Regards, Marco Hogewoning External Relations, RIPE NCC

3 2

Minutes from RIPE 78
by remco van mook 10 Oct '19

10 Oct '19

Dear all, In order to prevent another red-face moment, please find below the draft minutes from the previous meeting. I trust you will read them all carefully so we can sign off on them during our next meeting! Kind regards Remco Co-chair of Connect-WG Connect Working Group RIPE 78 22 May 2019, 11:00-12:30 WG co-Chairs: Remco van Mook, Florence Lavroff, Willem van Gullik Scribe: Rumy Spratley-Kanis 1. Opening (Welcome, scribe appointment, agenda, proposed session format) The presentation is available at: https://ripe78.ripe.net/archives/video/50/ Florence asked attendees what businesses they worked in; this was measured by a show of hands and is as follows in descending order: - IXP - ISP - Content - Enterprise - Educational network 2. The Elusive Internet Flattening: 10 Years of IXP Growth Ignacio Castro, Queen Mary University of London The presentation is available at: https://ripe78.ripe.net/archives/video/51/ Nina Bargisen (Netflix) asked if, with IXP, Ignacio meant public peering. He confirmed that he collected public peerings from the peering DB. Nina said it makes some of the conclusions confusing because when there is a big flow in an IXP, it is moved to private interconnections. These peerings should be included to assess if the Internet is getting flatter because of Internet exchanges. All operators do private interconnections, so it would be useful to adjust the methods and include these. Nina asked Ignacio to study each of the CDNs and how they route their clients because not all the CDNs do it the same way. Ignacio agreed with the comments about private peering but he felt constrained due to having to look at historical data, which doesn’t include changes in redirection strategies. Martin Levy (Cloudflare) pointed out that the graph on slide 27 doesn't tell the full story. The divergence is partly a business model of the different players and is not a reflection of the IXPs in any way. While the graph is correct, it doesn’t tell whether we are better connected today than 15 years ago. He added that the graph by itself wasn’t flattering for Internet exchanges; even if they are the saving grace for how the internet works today. He asked whether Ignacio could share any data that wasn't based on IXP data. Ignacio empathised with Martin's comment, then explained that it was very difficult to find data with the limitations that were in place. He agreed that looking at redundancy multihoming would be an extra metric that would be interesting to review. In the end, he tried to look at two relatively simple metrics that are comparable over time and easy to convey. Martin commended him on his study. Andrew Sullivan (ISOC) mentioned that he was troubled by the last discussion. The numbers and graphs seemed to contradict the work done by IXPs. This may lead to an incorrect conclusion that IXPs are not worth the investment – he did not believe this. He encouraged Ignacio to find additional numbers to show a complete picture. Ignacio mentioned that his original plan for this work was “should I build an IXP?” His intent was not to say IXPs don’t matter, his message was, that in the specific metrics he looked at, the impact was as expected, particularly with regards to path length. The impact of transit dependence was clear. Blake Willis (Zayo / iBrowse / L33) added to Nina's point about private interconnects (PNIs) saying it would be interesting if Ignacio could dig into his data and analyse when a path moved from an IXP to a PNI. This could be a way to analyse where the bigger flows are. 3. RPKI at Route Servers Follow Up Nick Hilliard, INEX The presentation is available at: https://ripe78.ripe.net/archives/video/53/ Marja Jan Matejka (CZ.NIC), a developer of Bird, mentioned that in Bird Version 2, there is a special feature called Custom Route Attribute. This feature allows you to name and use your route attribute instead of these defined contents. He suggested that this would be much faster. He asked why they weren’t doing both RPKI and IRR DB? Nick replied they do both, but they start with RPKI filtering. If it fails the RPKI validation, it will drop the prefix, and if it’s unknown, it will pass through the IRR DB. However, the ASN check has to be evaluated first, so it’s IRR DB AS check, followed by RPKI validation, followed by regular IRR DB validation if it’s RPKI unknown. A participant asked whether they also do comparison evaluations against, for instance, FRR. Nick replied that they hadn’t tried FRR because there hadn’t been a huge amount of code changes for the route server code paths in FRR. Also, there were scaling problems with Quagga. There are other issues with FRR it being more difficult to do atomic config changes and updates, and the FRR will need a little bit more work before they can use it. Aris Lambrianidis from AMSIX asked whether they had a change of heart with regards to implementing RPKI in the EU route servers. Nick said this was a good question – and for them, this was more a policy issue rather than a technical issue. They were previously sceptical about RPKI implementation because when seen from a very high level, it creates a single point of failure. If compromised, for example, at an RIR, a red button could be pressed to disable a particular prefix or set of prefixes. Before, the BGP inter-domain ecosystem was based on a peer-to-peer system with filtering arrangements between organisations, whereas now there is a top-down thing which is controlled by the RIRs. He added there had been an increase in the amount of BGP hijacking that is difficult to deal with unless you implement a tool like RPKI. Like any policy decision, it’s a balance between not implementing something that could potentially cause problems, and implementing something that could fix a problem you already have. In the last few years, RPKI has seen various changes at a policy level. There is now jurisprudence about how courts interact with organisations like the RIPE NCC about deregistering prefixes, and there is much clearer understanding from a legal point of view. So, they looked at all the issues from a technical and a policy angle and concluded that RPKI was a good way to go. Randy Bush (Internet Initiative Japan) mentioned that RPKI is a database and this means RPKI based origin validation. He added that while it will help, it is not a magic bullet. Nick confirmed and agreed with Randy. He added that if hijacks and misconfigurations were easy to solve, they would have been solved years ago. RPKI makes it more difficult to make bigger mistakes. 4. BGP Filtering on AS15169 Using IRR and Other Data Arturo Servin, Google The presentation is available at: https://ripe78.ripe.net/archives/video/56/ Ruediger Volk (Deutsche Telecom) asked why they are not considering to mark the regular RPKI evaluation early on, as marking and reporting what looks invalid would be a good idea and helpful from the beginning. Arturo replied that he and Chris have considered it and will be further discussed. Ruediger asked why they were considering RPKI as a source only for invalidating IRR data. Why not include the RPKI ROA data sets as an additional quality source of route information? Arturo replied that they will when they are ready to use it. Ruediger mentioned that if they don’t have the tools, he has them. Arturo added that RPKI only has the origin, and they need more, but they will not use one signal, they need more signals to make it reliable. Ruediger said that Arturo was only talking about acceptance, it would be nice to have a slide with what they are publishing, as authoritative information from their peers. Arturo said that his presentation was short, but they are fixing all their internal systems to ensure that data in the IRR is correct and that what is in there, is exactly what they want to announce. They are also working on publishing their ROAs. This will happen in the next quarter, along with a lot of other parts that need fixing. Ruediger replied that it would be nice to have a summary at some point. Arturo said that they have also joined MANRS. To show their commitment to fixing this problem and be part of the solution rather than just the problem, they are working with ISOC to make MANRS more successful. Cleaning up and filtering is something Google wants to do and is committed to, and so they are in the process, but it will take some time. Magnus, a remote chat participant, asked if they could open their IRR software. Arturo said they don’t have an IRR software, but they do have some tools that they use to parse the information. Chris Morrow, Arturo’s colleague from Google, replied that he had written some IRR parsing software, available on GitHub, it still needs work, but once finished, it could be used to parse the data and create filters. They will spend more time on that. Randy Bush commented on the slide “How do I peer with AS15169?” He asked if that included the transitive closure. If Randy, a BGP speaker, were not their peer, but a customer of their peer, would they accept his prefix from their peer if his prefix did not have an IRR Object? Arturo replied that they wouldn’t because there wouldn’t be any authorisation in place. Paul Hoogsteder, a remote chat participant, asked if Arturo could explain what is meant with “follow the AS/arrow maintainer”? Arturo replied that in the IRR, you have the maintainer, the AS-SET and the ASN object. They check the ASN object and check if it is an ASN they peer with. But they need to know all the routing information, which is in the AS-SET. So if someone peers with them and doesn’t put the ASN-SET in the ISP.google.com, one of the ways they find the AS-SET that has all the ASNs or all the information related to that ASN is by going to the peering DB to check the ASN-SET. Brian Dickson (GoDaddy) asked if a BGP speaker with their own AS, peering with Google directly and has RPKI but no IRR object or AS path, would Google not accept routes from them? Arturo confirmed that for now, they wouldn’t. He added that NTT has a way to export from RPKI to IRR’s, but they hadn’t decided if they were going to use it. This will be discussed. Brian asked if AS cone were to get formalized and adopted, would they use it? Plus RPKI? Arturo replied that he wasn’t sure you can put AS cone in the RPKI. All they know is that the prefix as an origin. Brian clarified AS cone if it does go into the RPKI. Arturo replied that if that were the case, including AS PA, then maybe they would adopt it. An anonymous remote chat participant asked if they were doing filtering before this, and based on what information? Arturo replied that they didn’t do any filtering, they just had the prefix, the number of prefixes – Chris will answer: Chris Morrow (Google) added that they were doing less filtering, not none. 5. Connect Update Florence Lavroff The presentation is available at: https://ripe78.ripe.net/archives/video/57/ There were no questions or comments. 6. Euro-IX Update Bijal Sanghani, Euro-IX The presentation is available at: https://ripe78.ripe.net/archives/video/58/ There were no questions or comments. 7. IXPDB and Tools Jesse Sowell, The Bush School of Government and Public Service, Texas A&M University The presentation is available at: https://ripe78.ripe.net/archives/video/59/ There were no questions or comments. 8. Offline Discussion There was no discussion 9. Closure

1 0

Working Group agenda, RIPE 79
by Florence Lavroff 02 Oct '19

02 Oct '19

Dear friends of the Connect WG, RIPE 79 is around the corner. Here is the agenda for our next Working Group session on Wednesday, October 16th from 11:00 to 12:30 : 1 Opening (Welcome, scribe appointment, agenda, proposed session format) 2 Raci #1 - Dismantling Operational Practices of BGP Blackholing at IXPs, Marcin Nawrocki, Freie Universitaet Berlin - 10 min 3 Raci #2 - Keeping state election infrastructure safe: How Cloudflare and local IXP connectivity helped a small country in Europe, Vladislav Bidikov, Faculty of Computer Science and Engineering / IXP.mk - 10 min 4 IX-API: An API for Automating Interconnection, Thomas King, DECIX - 15 min 5 IPv6 adoption on Internet Exchanges, Susan Forney, Hurricane Electric - 15 min 6 Euro-IX update - Bijal Sanghani, Euro-IX - 3 min 7 Connect update - Florence Lavroff - 3 min 8 Offline discussion 9 Closure See you in Rotterdam ! Best regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Infrastructure Acquisition and Interconnect / Google EMEA

1 0

Call for presentations at RIPE 79
by Will van Gulik 11 Sep '19

11 Sep '19

Dear friends of the Connect WG, We are a bit more than a month away from RIPE 79, that will take place in Rotterdam, the Netherlands, from October 14th to 18th 2019. Our next Connect-WG session is scheduled for Wednesday, October 16th from 11 AMto 12.30 in the main room. If there is any topic you are interested to present during the session, please let us know ! Thanks, Kind regards, Florence, Remco and Will Connect-WG co-chairs

1 0