2 pm
Opening plenary:
RIPE 92.
MIRJAM KUHNE: This is great, lights go off, exciting, room is filling up, yeah, welcome. Please find a seat, we still have a minute or so before we start. Still enough seats over here, in the middle.
Still more people coming in. I assume we have people online, I think there are a number of online participants. We have great registration numbers this time, this is a very attractive place for people to come to. So yeah, please find a seat and we can start this meeting.
My name is Mirjam Kuhne, I am chair of the RIPE community and I would like to welcome you here to the RIPE 92 meeting in Edinburgh, I want to say a few welcoming words and happened it over. You can see already the number of registrations, they are over 1,000, which is very unusual, I mean not unusual but it's a great number, high number, I think the last time we had a high number was Rotterdam, Berlin, and not everybody is here yet but these are the registration numbers so on site over seven hundred online, over three hundred from 59 different countries. Which is amazing and also we have a lot of newcomers here and also before I for get to mention, we have three local hubs this time, one in Poland again, one in Turkey and one in Sofia in Bulgaria which will be where the next RIPE meeting will take place, we have groups of people joining us from there.
Yeah, this is actually the second time we are in Edinburgh, last team we were here, in 1998, and it was a new chair chosen for the then LIR working group the local internet registry working group and that new chair was called Hans Petter Holen he took over and the LIR group split up into two, became the address space and NCC services working group, there was a new working group created, anti‑spam working green was create in bra at RIPE 91 and I found in the minutes an interesting discussion about I think it was version 3 of the buy laws of IANA, a time under this newly created organisation called ICANN, that had just started IANA of course was close to the RIPE community, we had lots of feedback and comments on the new draft buy laws of IANA, that's something the RIPE community looked into. There on the right‑hand side you see the beautifully designed slides the RIPE NCC shared at the time and they were really struggling with the additional workload and apologizing to the RIPE community during meetings so many people are still around we have a lot you have new people here, it's great, it's always fun to look back, actually I forgot one thing, it reminds me now because the first, it was also the first meeting of Anna Wilson, and she's right there, she's my Vice Chair and I should have introduced her at the beginning, apologies, and of course she'll be here during the week, you will see her.
We have a RIPE code of conduct so please treat teach other with respect and make sure you feel safe and included and welcome and if you feel somehow in our, you want to report something or you feel unsure about it, it doesn't always have to end in an official report or investigation, there are a number of people here from the RIPE Code of Conduct team, whoever is here, I don't know if you can just quickly wave, people can see there a number of Code of Conduct team members here in the room, you see them on the screen there and there are posters outside. Don't hesitate to talk to them about anything you want to report.
We have the RIPE Programme Committee members here who are responsible for the programme of the plenary today, tomorrow and on Friday and they will take over after I am done with my first part here and then we have a number of RIPE working groups responsible for the programme later in the week of all the working groups and there are a number of working group chairs selections going on, I think I have them son the slide here shall the Programme Committee is looking for new candidates there, two seats and the nominations deadline is tomorrow afternoon and then also after that please remember to vote and you will hear more about this, we'll give you lots of reminders of that. Also a number of working groups are looking for co‑chairs and I would stress the IoT working group is still looking for a candidate, if you are interested in becoming a chair of a group that's dealing with internet of things, devices and you know how they fit in the network, please come talk to me to or one of the current co‑chairs.
And we also are going to have a more generic discussion on community working group chair selection procedures in the community plenary, you might have seen a mail sent to the RIPE list by Sasha yesterday.
This is the meeting plan. It's usually confined. It's on the back of your badge there. There are a number of QR codes, one leads you to the Meeting Plan, you can click on the individual sessions and then you find the agendas for that particular slot.
It's pretty much the same layout as we had last time. I want to point out to two BoF sessions here, Birds of a Feather sessions, one today is organised by a number of IETF participants from IETF leadership, IAB, ISG, other IETF participants are here and they are running a BoF to see how we continue to collaborate and make sure we have the right communication channels between network operators and there's another BoF on Thursday called Practical AI and what impacts and benefits could be there for network operations and engineering.
Also again as usual, we have a Diversity in Tech, or DEI session on Tuesday. This time, the theme is I want to break free and it's talking a little bit about challenges in the workplace, work space and what equity and inclusion means there in practice, it's open to everybody, come join us, it's usually a really inspiring session I find, and that's Tuesday evening.
And the new thing I want to point out to you, you might have heard of this RACI fellowship programme, the RIPE NCC allows academics and researchers and students to come to the RIPE meeting under the RIPE academic collaboration initiative and most of them are here and to present and various sessions, those who don't present might have a poster outside, you can talk to them and also we trying something new this time, it's like the whole point of this initiative is to get operators and researchers together and make sure there's research that's useful for operations and researchers kind of know, have the right feedback from network operators that their research topics are relevant so we have some white boards out there next to the Meet&Greet area and if you have any ideas during the week, I would love to have somebody look into this particular dataset or work on some, you know, whatever would be useful to you as an operator, write it down there if you have an idea, write it down on and Thursday we'll have a meet up session together with where everybody who has written down an idea can come together and see if you can find a match, if you find a researcher who wants to work on your project. So we'll be piloting this time and continue to facilitate that collaboration between research and operations.
And then, of course, you have social events again, lots of opportunities to hang out and work together and have fun together and today is the welcome reception here and Tuesday we have the networking event, also on Tuesday we have a board game session, we had that also last time, it was quite a success, and on Thursday you have the dinner. You can find this information on the dinner and also within one of the QR codes on the badge.
Last but not least, I would like to thank all the sponsors, we couldn't do it without the local host, Hilco, who has done a lot of work to make sure we have a smooth meeting here, the RIPE NCC of course, a diamond sponsor, and a lot of staff resources went that this meeting. We have a AWS, platinum sponsor, IPv4 global sponsoring the social, a number of silver sponsors, Meta, InterLIR, AmSix, IXPO, Verisign, Linx, Net UK and Lonap is sponsoring the arista, and Internet Society as the bronze sponsor and Connectivity Sponsor is Commsworld. I would like to give a round of applause to all the support sons sponsors.
(APPLAUSE.)
I am pleased to see a range of sponsors for this event. And the, I don't think the timer works but I am almost done.
Yeah, I couldn't leave you here without actually mentioning all the conflicts and wars that are going on in the world and especially also in the RIPE region and in the RIPE NCC service region and I am really proud of this community, we have come together to do work together to collaborate here during the week in Edinburgh, despite of the conflicts and wars going on around the region and I hope you are having a good and collaborative week and at the same time I would like to also express my sympathies to those who couldn't come here this time because they are affected one way or another by the war or conflicts in their country.
So for that, I wish you a productive and collaborative and fun week and I would like to actually introduce you to our next speaker that's the Lord Provost of Edinburgh who would like to give you some welcoming words and I am really proud we have our functionary here to welcome our community to your city to so please. (APPLAUSE.)
LORD PROVOST OF EDINBURGH: Thanks very much, good afternoon everybody, and can I offer you all very warmest of welcomes here to the Edinburgh international conference centre here in our ancient global capital, Edinburgh and for those who are in the hubs or were unable to make it, can I just urge you to come and visit and experience Edinburgh in person when you are able to do so, we are sorry you are not here with us in person just now but we hope you will be able to come back at some point soon.
Those of you who are here have come to a capital which is thriving on many levels as a global city, we have got a strong diaspora of ethnic and other groups can connections with every every continent, and 12 long established twinning and partnership arrangements, connections with the euro cities network of 140 cities and 39 countries, the world cities forum involving 37 other capitals globally and more than 30 missions and consults from other countries. The cities are UNESCO world heritage cities and we are also the very first UNESCO international city of literature. So our city recognises, it respects and it celebrates linguistic and cultural diversity, indeed we are a multicultural and interfaith community and that contributes to our unity, our cohesion and the richness of our locality, it's what makes Edinburgh such a wonderful diverse rich place to live in or to visit.
So, modern Edinburgh is internationally known as a welcoming place, an inclusive place and a peaceful place which both respects and embraces different traditional cultures and faiths and provides a place of sang re for those who need it.
Recently receiving a number of accolades, it basically sums up saying Edinburgh is a wonderful city, it's a top 20 European destination, a top ten public transport provider, a top ten international destination for higher studies, the safest city in the UK, the most productive city outside London, the UK's most digital city, the best city in the UK to raise a family, the best city to live and work and the happiest city in the UK and one of the top five happiest holiday destinations. So you get the message.
(APPLAUSE.)
Now, you will know better than I do but I understand that the RIPE meeting is one of Europe's oldest running gatherings of network operators since 1989 and it's been connecting the people and organisations who make the internet run. RIPE meetings I understand are built around open discussion, collaboration and bottom up community driven co‑ordination. The community play as really important role in supporting a globally interoperable secure and resilient internet. Now of course the internet's continuing stability depends not only on infrastructure but also very crucially on the relationships and trusted co‑operation between the people who attend these events and internet has evolved through trust, shared standards across borders and sectors.
Communities like RIPE help maintain the shared norms and coordinated processes that allow the internet to function globally, they also continue to strengthen trust through co‑operation, dialogue and shared responsibility and one of the key reasons for Edinburgh's continuing success is access to great communications with both enterprises and homes enjoying an extensive 5G coverage provided by major UK networks next with widespread availability, you will probably find it fails when you go out but it does average 150 megabits per second.
Ready access to high quality and speedy internet has become a cornerstone for the way the city's large local, national and international business community operates, with high and growing use of 5G and additionally many sectors are turning to third party apps for ordering and for deliveries, technology making it ever easier for customers to get efficient access to goods and services.
So collaboration, be it across network providers or across geographic and cultural boundaries are, in the contemporary world, absolutely essential for growing economies and vital for economic sustainability and progress and gathers like this help to galvanise those involved in both managing and developing our access to the internet and to realise the wider and perhaps as yet undiscovered benefits, help to go push the boundaries of what is possible and achievable.
Just an example was the recent world first robotics stroke surgery performed by experts from a distance of over 4,000 miles with only 120 millisecond lag. Absolutely fantastic, the potential is absolutely amazing, and if we can achieve that by working together, who knows what else deeper and meaningful co‑operations can generate, it's an open question and one that I am sure you will be engaging with over the next few days.
So I hope that you have a fantastic experience over the next few days, in an old Scots phrase "Haste ye back", which means come back soon, and we'll be delighted to welcome you for a longer stay.
Before I close, you may know that Scotland has two national drinks, I understand you may be doing a whiskey experience, that's one of our national drinks, and the other national drink, I noticed some cans of it upstairs, is Iron Brew, which is a fizzy drink, one of them rots your liver and the other one rots your teeth. So I hope that you enjoy yourself despite the damage that being in Edinburgh might cause your health.
But can I thank each of you for your commitment and the valuable contributions you will be making through this key conference, your professionalism, your dedication, your ideas and your solutions are what gatherings like this makes them so impactful and forward looking. So I wish you all, whether here in person, on line or on local hub areas, a really fantastic conference and I look forward to hearing any key product coming from your deliberation that is we need to take on board as a city. Thanks very much indeed
(APPLAUSE.)
MIRJAM KUHNE: Thank you very much for those welcoming, this warm welcoming words, I'd like to ask Linda Shannon who is representative of our local host to also say a few words.
LINDA SHANNON: Thanks Mirjam and thanks to the Right Honourable Lord Provost, I have to say I feel a bit bare standing here following your bling, I wish I had worn more jewellery. But speaking of the dress codes, there's still time to hire kilts, I believe the Code of Conduct Committee cleared it in the end, it certainly echoed the Lord Provost's words, we are delighted to welcome you here to Bono Scotland, Edinburgh has long been a city of ideas shaped by the Scottish enlightenment and by generations of engineers, scientists and innovators. It's a place associated with open exchange, international collaboration and practical problem solving, though very much in line with the important work you do every day, the spirit of the RIPE community.
It's been over ten years since a RIPE meeting I believe was last held in the UK, there's been a few changes since then but we are glad to see that people and packets are still routing successfully across the channel.
We really appreciate your presence and hope you have a fantastic week. It's lovely to see so many clients and partners and friends in the crowd, I think many of you are already familiar with Hilco Global and our intellectual property, digital assets and IPv4 global business units, for those who aren't and just to briefly recap, Hilco Global is a diversified financial services firm backed by the Orex Corporation, we help clients maximise value and improve performance across the business lifecycle, we deliver professional services and capital solutions aI don't say all asset classes, we have more than eight hundred employees operating across all continents, including from our Scottish office.
Within that, IPv4.global operates a leading brokerage helping folks to buy, sell, lease, manage and raise finance against IP address resources, together with our experts provision, formerly 6Connect team, we are proud to provide world class DDA and Anycast solutions as well as network advisory services, including around the deployment of IPv6, we have recently expanded our UDP and international team, many of whom are here this week and really look forward to chatting with you.
We have attended and supported RIPE meetings for many years, this one is especially meaningful for us, it's an absolute real honour to be embraced and trusted the community and a privilege to serve as your local host, we hope you have a wonderful week in a wonderful city, the best we have just heard. I say that from Glasgow as well.
But yes, it looks to be a week set full of productive discussion and with plenty of time to socialise as well, you know Hilco despite the risks to our liver, we do love whiskey as much as we love cider, classless entertain main routing letters, so we hope that you join us for a wee random at some point, perhaps balanced out with tomorrow morning's run or Friday afternoon's walk up Arthur's Seat that we have organised in addition to the main social programme.
So yeah, if there's anything we can do for you this week, please let us know. We'd love for you to stop by the stand and say hello or arrange a time to meet with the team, thanks again, it's just an absolutely real privilege to welcome you here and hope you enjoy the week.
(APPLAUSE.)
MIRJAM KUHNE: Thanks, Linda. And now last but certainly not least I would like to welcome Hans Petter Holen, the managing director of the RIPE NCC and our diamond sponsor to say a few welcoming words.
HANS PETTER HOLEN: Thank you very much Mirjam and yes, I am Hans Petter Holen and as you saw from one of Mirjam's slides, I was apointed chair of one of the working groups here in RIPE last time we were in Edinburgh so I have been with the community for quite a while, contributing as a community member, as always of you are doing. And then six years ago I took the position as managing director of the RIPE NCC. To guide this organisation forward.
So the RIPE community was a group of people that met in 1989 to hold some meetings to solve all problems or challenges with the internet in Europe, now we are at meeting 92, we still have work to be done. It's a community, it's open to all to exchange informations. The internet providers may be competitors but need to collaborate for the internet to work, so that's what we are providing here in the RIPE community to bring you together. At some point the RIPE community figured out we need a secretariat to organise for us, so they set up the RIPE NCC in 1992, it's a membership organisation run by RIPE NCC staff and executive board, elected by members and provides services to services to members an to the community and implement policies set I the community. So it's not the RIPE NCC that decides on the policy, it's you, the community, that decides on that and we implement them.
And we are dependent on the community for all of our services and especially in today's world where we see increasing security issues, having volunteers in the community doing research and challenging our security and reporting security vulnerabilities to us is a vital part of our security operations, as you will hear about in later talks today.
Logistics, if you are connected remotely, you already figured out we are using Meetecho to see this, to participate in this event but you can also use that if you are in the room because then you can see the chat, you can raise your hand and so on. So please book mark your unique log in link and use it for all sessions and you need it for polls, you can do Q&As there and you can connect with audio and video when the session chairs give you the possibility to speak.
And we also have live transcript, and that's not AI generated, it's real intelligence generated from our stenographer sitting at the front here, so please be nice to them!
The sessions are recorded and published on the RIPE 92 website. Audio video queue, I already mentioned, you can see the icons here for that. Request the floor to ask questions directly, click the mic or camera to get into the queue and state your name and affiliation out loud, your affiliation means not who you speak on behalf of as a community member, we assume you speak on behalf of yourself but we would like to know who your affiliated with so that we understand where you come from.
Questions and answers you can type them in the Q&A window and you can also have informal chats with the group and individuals participants in the chat but if you want to ask a question, please use the Q&A and I already said transcripts and stenography, that's also available in Meetecho.
Badge is important, please wear it at the site, there is security at the entrance so we are kind of only that open of course anybody can register and come in but we would like to make sure that only the ones registered present at the event, you need it at social events, so please bring it there as well. If you haven't connected to the wi‑fi yet, the wifi password is at the back and there's some QR codes you can scan for Meeting Plan, social events, parallel events and for emergencies.
And then gracefully mentioning our sponsors, Hilco Global, AWS, IPv4 Global and, as mentioned, RIPE NCC picks up a large part of the bill for this as well.
We have an official photographer here. If you do not want to be photographed, please ask for a yellow lanyard and then the photographer will do their best to avoid photographing you. Please respect your fellow attendees choice of lanyards, if you take pictures, don't take pictures of people are yellow lanyards. So please keep out for our eye out for the official photographer if you want your picture taken.
Meeting organisations team for all RIPE 92 related, feel free to reach out, we have a tech team on site, please if you are speaking please talk to them well in advance to test your presentation, to to make sure that everything works. We have an NCC support desk where you can get help from the member services and registry staff, we are doing on sign assisted registry checks, you can do that here. And please speak to RIPE NCC staff working in your areas of interest. I think we are sixty staff here, that's like a third of staff here because we want to engage and interact with all of you.
You can also register and take RIPE NCC academy certification, if you are taking the training source courses you but want the certification you can do the exam here or participate in user testing.
So, there is also a General Meeting, the formal body governing the RIPE NCC here, you need to be a member, you need to be registered to get into that on Wednesday.
And it will take place at 4 o'clock on Wednesday, 20th May and it's both online and in person. Registered members can collect entry stickers at the GM help desk from Tuesday onward, once they have received their email invitation, members can also register to vote, via the LIR portal and the voting is open from Wednesday until Friday morning, if you are not here in the room, you have the opportunity to vote while you are awake during Thursday.
Members can also, yeah, I just said that. The GM help desk is open from Tuesday until Thursday from nine until five. I mentioned user testing, it's really important to improve the user experience, we have developed prototypes and things that we want to test out on real users so please contact Fallon and an ton ella in order to sit down and test out some of the ideas we have to improve the user interfaces and the cool thing about using formal methods for this is that we are not looking at what you are saying you want, we are looking at what you actually do when you see the user interface to make it simpler and better to use.
And with that, I am really eager to hear the latest security research which kind of scares me a bit because it's security research on the RIPE NCC services but I really appreciate the work that's being done there by community members so looking forward to that, thank you.
(APPLAUSE.)
MIRJAM KUHNE: Thank you. Thank you, Hans Petter and this ends the welcoming part of the plenary, of the opening plenary and I would like to hand over over to the Programme Committee to chair the next part of the session.
MASSIMILIANO STUCCI: Good afternoon everyone. I am Max and Jan is reaching over here slowly, come on Jan! We would like to begin this session by repeating a few things that were told in the opening, first of all we are having EC elections this week, so watch out for the candidates or talk to one of us from the Programme Committee, which I would like, would you like to stand up for a moment, Programme Committee members. You can see them standing up. The gentlemen and the ladies. Yes. And talk to us if you are interested in maybe running for the elections, there are two seats available, actually one of them is mine. So it's my, it's the end of my second term here. And with this said, I would like to introduce Sasha Romijn who is here and she'll talk to us about some findings she made.
SASHA ROMIJN: Awesome. So, if you have ever within to a security training, they may have told you not to open suspicious links. However this does not look like a suspicious link, especially if you are familiar with RIPE Atlas and yet this was enough to take over your RPKI configuration using vulnerabilities that I found over the last year.
So my name is Sasha Romijn, I am an independent developer, I do a lot of things around routing standard infrastructure, you might know me from project like IRRD and IR explorer, I have a lot of other interests and I am not a professional security research; I just like to poke at things and see what happens.
And my favourite html tag is the marquee, it remind me of older time in the internet marquee has horrible usability but it still works in modern browsers because I saw this is a real browser and I actually like the marquee tag so much that I put it every place that will let me such as my name server investigation version, the RIPE database or from my own address space, I have put it in every field in DNS that I can edit, TLS certificate, the RIPE database and any field it will let me enter text. Loramesh radio names, DHCP host names, anything that will let me enter a free text.
And typically it's evolved over the years, I do something like this, there's some visual enhancements here, there's some prove that I can execute Javascript which is important later, some emojis and Unicodes and a tracking pixel IX figure out who is loading the content so I can track them down and help them fix it and this has been quite effective.
Typically you see a plot in standard look ups and IP resources info, a website like this one, there's many like it which shows the XSS in Javascript, my visual enhancements to the site, there's four or five injections here, my web server header, I think there's more a better website has become so poly rendered it's become hard to read, making not just a random IP checker websites also here the art app look up that hurricane electric was running a little more so here because RDAP only renders the address, but that's free text also, you can put whatever you want in there. RDAP is also on ARIN.net, this one, these are fixed and here you can see also, I intentionally actually don't close the marquee tag, you can have a double marquee, which looks even better and it's not just injecting a little, it's a little design enhancement, it's actually executing Javascript, I found by accident you can put the entire website inside a marquee sometimes, there's double one in here somewhere also. This was mesh tasks I can note names but don't worry, not everything is broken because as I learned when I was learning about the internet, RFC 1035, host names will be letters, ditches and darns and that does not allow HTML. This is looking at a pure even CDN and we are going to run a traceroute to a /24 I recent re got and see what it does with that.
That's unfortunate. And as I hover over it, you can see that. I do empathise because when I wrote my first Looking Glass, it showed vulnerability which is worse than this, in my defence, I was 14, and I fixed it within ten minutes, whereas when I told this CDN about this, they said there's no proof of concept, we must refuse your report so this one is still live, it hasn't been fixed. They refused to report, I said that means I published and they never replied again.
But I mean it's not just the ECD N, it's other organisations that you may be aware of. Also fixed. This one was fixed quite quickly. This one was a bit tricky because this is a bit of a, a lot of DNS code doesn't like this host name, they don't like spaces or present sees, I haven't been able to figure out who is filtering these but HTML is really weird, you can use back particulars and slashes, you can see the syntax highlighting completely fills on this, you can actually ping this as a host on Mac OS, on some Linux hosts, I haven't been able to ping it and that's valid for confirmed reverse DNS. Now that is funny to me, can we actually do something with it or is it just entertaining yes because this kind of injection often leads to cross site scripting so my Javascript I planted runs in the context of that website's domain which means if they are used visited, they will take my Javascript as being authoritative, it will provide access to cookies and other requests that is potentially very bad. It's also a very cold attack like 20 years, there are many places where it's fixed, there are many mitigations but it is still a common one. So instead of just doing some art stack enhancements, let's take up some hosting accounts, I found two European hosters and they ran WHMCS, a common web hosting management platform and they ran it on the same domain as a TLS tracking tool and RIPE database tracking tool and didn't escape these two, once I planned Javascript on their main domain I was able to do that's correct I had full Javascript excuse that gave access to this admin portal, once you are there, there's nothing else protecting the user from taking actions on behalf of the user.
Which includes in this portal for example adding admin users with no other confirmation or notification to the original users and I found some others that were, that had other less serious but still serious vulnerable ends points, this is one of them which had also the server, the HTTP service in the bottom also, TLS certificates and of course if you did this in a real attack, you probably wouldn't make it quite so loud, it's not obvious, I just do it because it's more fun but you can make this appear entirely subtle.
This is OpenWrt, some may be familiar, popular OpenSource router, I actually ran it on one of my axis points that went out of support, on the left a browser that we presume is still legitimate of this device and on the right is a few of of my terminals trying to compromise it, I am trying to get route access to this device, I currently cannot because my key hasn't been added. So what I do is start an axis point with a special name, then we have to treat a legitimate admin into opening their wireless scan page. And a few seconds later, execution pay load has been pulled, route key installed and also firewall opened because OpenWrt rendered wi‑fi assist and escaped once you have Javascript, my Javascript running in their admin page, the admin page of the device you can scroll all the API end points the user does with the web interface, send a little ping back, whatever you want. A little tricky that SSIDs are quite short, I did two SSIDs that build on top of each other, I tried to this also on a Fritz box and high her particulars and they didn't have any issues, I don't have any other hardware so I don't know.
So it's not just a little visual marquee. There were multiple hosts I found it compromised much of their admin portals, sometimes persistent permanent access to a user account, with a single link to their hoster's domain, persist route on scan page if you are in radio range and if you work for Lumen, we should talk this week.
One day, I am debug the reverse own for my IPv6 range in RIPE state and I am hit by a blue mark, it's not quite as artistic as my more recent work and I had actually forgotten how it happened and I planted this myself, this was the DNS zone master integration in the old RIPE state UI showing my version of the name server including excuse and I actually found over time a number of them modern RIPE state, oh that's not ‑‑ that's unfortunate. We didn't test this!
Anyway through the blue flickering which is not part of my work, you can you can see accessSthrough the name server records of my domain, then there was also a RIPE Atlas NSID returns debugging filterses you can return along with your queries and finally a bit more subtle bottom right TLS record in RIPE Atlas, this was my favourite because it was one click only, the others you had to open something, this one is single click, Javascript execution on RIPE.net, in four different ways, DNS version NSrecord labels and DNS NSID and TLS examiner. That's pretty cool, now you can steal atlas credits except no one cares, you could mess with measurements which wouldn't be great but it's not a huge deal. What is the RPKI dashboard, but that's a separate thing. So can we actually reach that as well. Well, when we talk about RPKI insecurity, we often talk about the standards that are underneath it, how relying parties validate their ROAs, hardware security multitudes at the RIPE NCC to store the route key, they have a certificate practice statement, there's a lot of paperwork around this as well and a lot of that, that is all very solid work and also to be clear, RPKI is good, you should drop invalid routes. But from my perspective, looking at it as an attacker, it's a website. It's a website, it has log ins, people click on buttons and then RPKI configs change. So it's not entirely a website,QL API, common API formats and basically you take a graph permutation which can remove ROAs, adds some ROAs, post stats to a particular end point and include your authentication cookie, this is how it works, this is entirely fine, there's no problem here, just a normal way to build a website. The vulnerability here was that you could do this from any host under RIPE.next, once you combine it with the SS I found, put this request in TLS certificate, I opened it, this is my address ranges, I would open it if I am looking into any RIPE NCC and all my ROAs are placed, network invalid, you don't have to replace it with network zero you can support hijacking as well.
And the closest example we have seen of someone actually doing this was 2024 when someone took over span I can't say account, they didn't do it very well, they didn't go for maximum effect, it took a day for full recovery, and but this was also a lot louder but it doesn't end to suggest with RPKI also because the same vulnerability worked for RIPE database, so any ripe.network host, you could submit a new which is subject and replace the contents and authenticate, ask any user locked in while opening that link, RIPE database is interesting, it's a lot louder and slower, it sends notifications to most of us, RPKI also does from the RPKI dashboard but they are trivial to disable, I can't avoid notifications but interesting is that you can make it much harder to recover because if you compromise a RIPE database maintainer access, you can take over the entire object, you can remove access for the original maintainer, this is all recoverable, the RIPE NCC will eventually guess this all fixed but it will take time, where is for RPKI, you just log in and update it your is he, you can't remove the original person's access.
How does this all escalate so badly from one improperly rendered TLS certificate into all these other services. It is because the RIPE NCC uses a single SSL cookie, it's not actually a lasting crowd I think that token authenticates any action in any RIPE NCC service and you get one by logging into any RIPE NCC service, you leave a comment on RIPE Labs, the website has just given you a token to update your RPKI config. So any dashboard request from Atlas from the RPKI dashboard meets all criteria for this cookie, if you have one, if I you are likely to have like I did to upload these slides, it authenticates the changes on behalf of you. A little side step from most what I am covering here, I was thinking like what is this cookie. Because the cookie means it's sent with any HTTPS request to RIPE.net, who things happen under that domain, what about the meeting wi‑fi or all RIPE NCC Atlas anchors because until last year, anyone with control of any those of those could request a valid certificate, you trick someone into visiting your anchor host in their browser, they will, they will submit their RIPE NCC cookie, this was a lot worse. Because once we have a stolen instructions cookie, we don't have to middle with doing specific requests that we have sufficient access to, once you have the khaki, you have access to anything on behalf of the user, including silently adding admin users to the LIR and other fun things like that so persistent you can also do. This is a little risky design that's mitigated by tightening CA, you cancel request TLS certificates for the hosts any more, fun fact a bug bounty policy of the RIPE NCC, while writing someone realised these hosts were not run by the RIPE NCC but while at the same time probably in a different process, different person, they did end up in cookie scope.
Essentially this is the same thing over and over, there's some low sensitivity tools, some debugging software software and it's trust some protocol implementation or assumptions around protocol, so the protocol specifically or its conventions and it's included in the same trust scope as something that is very sensitive, I do encourage you to have a look at what these things look like in your stack.
I found about 30 of these type of vulnerabilities so some are catastrophic, some minor, reporting all of it is a lot of work, I never did this before at this scale, fastest fix was 50 minutes on a Saturday even.
A lot of it goes well, some of it goes poorly. Often within less than two days, like Hurricane Electric and ARIN I showed, less than two days there was a fix. The RIPE NCC vulnerabilities were not as smooth. I will start again, all vulnerabilities are fixed and also the staff who work with me always acted in good faith and their best effort and my impression was more of under resourcing rather than issues with anyone that I actually worked with, there's an upward trend with things I reported later in how well and how fast things were handled. We had some sign in day fixes also and the bug bounty paid me 4300 but the RIPE database took 13 months to fix and was fixed incorrectly twice, one time there was even a public announcement saying a vulnerability had been fixed, serious enough for a security release and the type of vulnerability but it had not been fixed, which I found by going back to my original port, taking my proof of concept and running it again and finding it hadn't been figured, two days later we had the real fix, it took 30 messages across five channels, I heard nothing for four months and public statements by the RIPE NCC other than the ones just before me on this stage are incomplete or incorrect or there are none yet. They have said there will be a lapse post coming so I am very eager to read that and also see what reflections the NCC has made on the technical aspects but also the disclosure process and how they handled this kind of thing so that both the NCC and ourselves as a community can learn from these things and look forward to how things can go smoother in the future. I also want to specifically highlight bug bounty programmes, they know less than you by now, they don't understand RPKI, they have never heard of this, RIPE NCC users integrity, I have to file through it to qualify for a bounty, this is not my job, I do prefer to try to qualify for a bounty where I can and so I have to do it through them but it's a struggle every time, if you say I can manipulate RPKI, they completely pass them by.
Loumen forces everybody through bug crowd, there's no other human contact, they didn't understand the most basics and refused to reply further and earlier I searched through G core so these bug bounding programmes a risk in getting things reported to you and something to be aware of, whether that is the only way and what expertise these programmes have.
Finally I want to highlight that injection is also a thing that happens a lot in context, this was my attempt at the HTTP host name injection, didn't find anything really cool with that, this is from my MikroTik who has no problem with this, I don't know if this is legal per protocol but it's not a vulnerability in this platform. However it's also in the web version, it renders this just fine, entirely probably escaped with the emoji in the DRPhost name, this is safe, this device is fine, if an SNMP reader and takes it data and renders it now that's still where you might have a problem.
So also this can basically stack even through devices that you trust. Even so I don't even know if this is allowed in the host names but it works.
So all of this was basically me just being curious if I could put HTML in weird places, I did not expect this level of compromise from it, it's been fun, I have a little backlog of blogs to write. But this is definitely the coolest I have found so far.
My lessons, my tips would be be very careful in trusting strange computers to in whatever they might implement of the protocol, whether they might follow it, also because you don't know whether you are enforced those and whether they do that right.
Don't trust strange computers, whatever the protocol, whether they follow and it not just a protocol but the conventions and assumptions we have around it and make sure I can actually report something if I found something so I don't have to put your name on a slide.
For web applications specifically, something that's not work something how fast it he will collated sometimes. So think carefully about what is the trust scope of those applications, if you have something sensitive, who else is in that cookie scope, what other applications run on the server, how far does it get, what do you need to compromise to get to this critical service, content security policy is a cool header, it would have stopped me every time, RIPE Atlas now has it, and they are working on it for RIPE state. And finally reauthentication an notification for critical actions I found missing every time, if someone adds an AI keep, you have to mail those users because doing it silently makes it a lot worse and if you have to reenter your password, if you have a new admin user, this, none of this would work.
I dare say there are lots more to this than I have been able to cover here, please read the full write ups on my website, if you are interested in knowing more and also I have more things to come, so thank you very much and remember, do not trust strange computers.
(APPLAUSE.)
JAN ZORZ: Thank you Sasha, this was nice. OK, there are questions, I didn't doubt.
SPEAKER: Good afternoon everybody, I am from the RIPE NCC, so actually first of all, I am going to start with a big thank you because the value that Sasha brought was exactly actually this change of vulnerabilities, otherwise we would not have found, so helping us realise the impact of compromising different servers with different physicality like RIPE Atlas and how it can impact RPKI was very insightful and helps had the development teams realise how things can get interconnected and the impact of decision made over time, thank you, we really appreciate the work, I think what really also makes the difference for us because you also pulled out the bug bound programme is the domain knowledge, it's very different having A researcher that will stop when they find that excess versus actually someone really taking the time to invest and understand how things are interconnected and how they impact. So I would say keep them coming because for us this is a very impactful way to understand what needs to be fixed but also highlight what is the potential impact of such security vulnerability, when we need to adjust our road map to fix things quickly but also really plan for bigger architectural changes that take time among a lot of other things.
I will also say absolutely that there has been a reflection moments for us on how do we also communicate with the researchers, how do we keep researchers involved and informed, while we try to do co‑ordination as a security team across development development teams because you sign this case how many teams were involved but also impacted. So thank you again and please indeeds there will be a RIPE Labs article describing also our experience, the reflections, but also what it means to really do a coordinated disclosure together with a researcher. Thank you.
JAN ZORZ: In the interests of time, I am cutting the queue. Can you be faster please.
AUDIENCE SPEAKER: Two things,, thank you very much for doing this, it's amazing work, I love when the RIPE community works with the NCC, second thing are you suggesting that we should increase the RIPE member shit so the RIPE NCC would be less under staff to address security issues faster and secondly, as far as the problem with the kind of the external programmes like integrity, the problem coming from experience is very frequently they have a wide breadth of scope they address and do the initial triage, if the person doing that triage lacks the context or the industry understanding, things can get missed, that happens all the time and it sucks when it happens. The easiest way to fix it is find someone from the security team directly and harass them until they fix the problem that you are trying to fix. Which I assume with the 30 messages you did, I really appreciate that. Thank you.
SASHA ROMIJN: On the membership fee, I think that's for the GM and not for me, I have no opinion on this at all.
AUDIENCE SPEAKER: Hi, sort of pontificating on the whole bug bounty thing, I never found one managed by a third party to be any good, I also find the stuff is genuinely really difficult in that you are flooded with huge amounts of nonsense vulnerabilities, or at least very border line nonsense vulnerabilities and it's very hard to, if I have an issue with quantifying my vulnerabilities, a third party has very little chance of doing it, it's worth keeping in mind because I have been on both sides of the argument now and it's just really hard.
SASHA ROMIJN: Y I have heard this too, I have not been on the other side myself, I have found, I sent integrity of a video of me taking over a session and clicking over and they said oh but have you proven there's a confidentiality issue here because I don't see personally identifying information and I was like I don't think you watched anything I sent and also yes, so I think it both happens like outsourcing them to deal with the flood of poor reports is a problem and I don't have the complete answer to it either.
SPEAKER: A lot of the reports are also somewhat malicious, I get three or four a day from relatively sketchy email addresses asking for for a pay out for the fact that my site doesn't have a HTTPS vulnerability.
SPEAKER: I do recommend HTS, I noted also with some organisations, they did the opposite, I thought it was out of scope, I mailed them and they said oh, yeah, it's a cool vulnerability, can you report it anyway so we can give you money so it can go well. But yeah, it's a continuing struggle in security reporting for both sides I think.
JAN ZORZ: OK. Thank you Sasha.
(APPLAUSE.)
MARIA MATEJKA: Good afternoon again. I have taken a photo today, today morning, I almost stomped on this pretty snail but it was also, it's also kind of how the ASPA specification comes forward.
So first what actually is the ASPA. Most of you probably know what the route region authorisation which authorises the end of the AS path and now we want to authorise all the rest.
So we look at the path by parts and check whether each path makes sense. And the principle is that every sin ton news systems lines the list of their providers which means if I have a bunch of providers, I make a list of them, I sign the list and I publish it, it's all done through the RIPE portal, I have never seen the portal open because I don't have a log in there but it doesn't matter, those who know it know where it is.
And I am not going to deep dive there.
But there are quite some misconceptions. ASPA is not authorisation of the whole AS path at once, it's authorisation only of the parts of the AS path it's not going to tell you the AS path is perfectly developed, it's only telling you it's plausible. And if it's invalid, it's telling you somebody is telling you that it is not a plausible path and you should probably drop the route but it doesn't mean that if it's sad valid, you should accept it with no questions asked.
It also is not an authorisation. Whether there was two ASes inside the path may actually be neighbours, you may have a provider in your list, which is actually not your neighbour but you are planning to have it. You are planning to update your network but it's not now. It means it only says which route is not plausible. It doesn't say anything about authenticity, it doesn't tell you whether this route actually did what's in there, whether the path actually was created by faithful creation, by faithful moving, announcing the route. No. It only says that this AS path may be plausible. It doesn't tell you anything and it may be your direct peer who created the path completely from scratch and who faked it and last but not least, it's not a replacement for BCP SEC that nobody has implemented in production probably but maybe if somebody wants a real authenticity check, we should go for the BCP SEC but it has its own draw backs like the performance issues, so we are now stuck with ASPA.
But this misconceptions are kind of running around, I have jumped into one of these as well. So yeah. Some years ago I was asked well the ASPA is looking quite well. So we should do it. So when I was flying to NANOG in San Diego, it was an eleven hour flight, I sat on the plane, opened a laptop and I coded it, and I code it had wrong.
And nobody realised. So it was in the bird code base for like a year and a half. And my wrong assumption was this one. I was expecting that the ASPA says whether two AS neighbours which are side by side in the AS path, whether they actually may be neighbours. But I was reading the draft several times. I was very convinced that it is the case and I was not the only one who was reading the draft. Actually nobody on the BIRD team, not even this BIRD noticed that this was a very vigilant bird, it was looking all around, it has a nice vantage point, but no, not even this bird found out that I was getting it wrong.
But that was the validation. Then you have to load the records into the router, so nice, let's load the data, there's an under draft, and other colleague Kata took the draft and implemented it thoroughly and she implemented it well and she implemented this. There is ‑‑ this is the PDU, the message which sends the autonomous systems it sends the land and there's the provider AS count and there's the customer AS and provider ASes, everything is OK but then we tested it against the RDR and they didn't send us, they didn't send us the provider AS count, it was zero.
We looked at it and said well, that looks fishy. And then looked at it again and said well, there are two bytes which are zero and there are two bytes they are serve as a provider AS count which can be done by the land, why why are there four bites more than needed. So then we asked at the list and this was already quite late because the ASPA is here for years and we asked about the AS count and I don't know whether I wrote or Kata wrote this into the mailing list so we asked whether it's a good idea or not and we got an answer that we are too late.
So we asked what is going to happen then and then there are other people pointing out other issues. And other people and more people and we induced an IETF last call refraction for a document which was about to become an RFC. So now we have the draft back. So we still have the draft back. And we are debating it more and more.
And then some time later, I met sir RAM in Dublin and I asked him a little clarification question because I was not sure about one thing in side of the validation algorithm and Syram was completely confused by my question, which led to finding out that I actually don't understand ASPA validation and not only that, that the implementation is actually wrong.
Click. So just a month later, I wrote a bunch of suggestions, we should improve the text. So that it's not so easy to miss things. But while the conversation with the draft authors, has been quite hard and it's becoming quite a common thing in IETF that people are writing the drafts very scientifically. I don't know how many of you remember the university courses where sometimes the lecturer goes a definition, a theorem and a proof. And this is the cycle. And this is what some people want to have in the RFCs. And if there are two things which are redundant, why should we have two paragraphs saying almost the same from two different angles. Why? There's no reason, it's redundant, remove one of those.
Yes, remove one of those. Make the developers confused. So just a quick ASPA remember, what it's actually about. ‑‑ ASPA refresher) the thing is the provider which you have signed in your list is allowed to pop great your routes to anybody else, you are authorising your provider to send your routes to anybody.
And unless you signed that provider, it's expected that they shouldn't propagate your routes to anybody. It's also expected that every AS provides a list of providers and it completely builds on the principle of ramps. Every route goes first up from you to your providers for some amount of hops. Then it goes down to customers. It never goes back up. And it never hops laterally to somebody who is speed peering with you but not behaving as a provider, not jumping more than one peer.
Basically this is what this drawn inside the draft. The route should go up and should go down.
If this doesn't happen in your case, then your, how to say it, then your relationship with the peer is complicated and you probably should consider them a provider.
Which makes things easier.
You can also see that there is the receiving and very fine ton Ms system which is not included in the whole ramp, which is going to bring problems later. But the main thing is we are trying to find an up ramp inside the AS path and we are trying to find a down ramp and we are trying to cover the whole path by these ramps so that it goes from that one to K and then from the L to M down. And we explain that either the L and K are the same, or they are neighbours. So the validation algorithm asks whether there is an up ramp and possibly down ramp covering the whole path. While the ramp is calculated in such a way that I will go back if it works, yes, we ask whether the ‑‑ we ask whether the AS 1 has actually signed the AS 2 which is not here. Then whether the AS 2 has signed the record for AS 3 and so on and so forth. We don't ask anything about AS(K) and we don't ask anything about AS(L) but we ask that one after, whether they signed the predecessor and so on and so forth up to the AS number N, which should have signed AS number and minus 1.
We are asking only for one way of signatures and if somebody here like L happened to sign L plus one, we don't care. If L plus one provider of L, if will is also a provider of L plus one, there can be a mute all providers because for example they are too large and in some location they are, one it is Freud provider of another and in another location,s switched, request not so validation algorithm assessed, if you can cover the whole path with a, test it with signed records, then it's valid. Then there is the unknown. Which is unknown for many people. Let's assume that everybody who has not signed anything approves actually all providers.
If this operation adding the best possible records makes the route valid, then it's unknown. If it's not possible to rectify it, then it's invalid. The thing is if we have what ‑‑ if we have this L and K, they can have anything, they can be lateral peers, they can zine zero mean these are transits, we are not looking at them either, we are just ignoring them because they are at the end of the path.
And then there's the problem with excluding your local ASN, you look at what arrives at your external BGP from your peer, check the local role which is another RFC, another method and you say well the path looks OK and the last hop looks OK, let's fold it together and say it's a valid route.
Which brings me to the back up link risk. Sets say you are a small ISP and you are signing your provider list. And you walk over those providers and you forget that there is a link which is doing a back up in case everything other fails and you omit this provider from your list. You just forget, it happens. Or you make a typo. In their ASN. That happens. And you don't find out. Because you are sending a path stuffed export, you send a route which is never ever going to propagate anywhere so you don't expect that route to appear anywhere.
And it doesn't. But then your main link fails, the back up routes become best. And for the back up provider, it's OK. The role is OK, the ASPA path contains one one single AS, it's you, and one AS path is always valid because there is no relationship, it's always, it's just the end. And all the clients of the back up provider say OK, that's fine but if the back up provider sends it to another provider or their peer, they suddenly finds out well, this is invalid. You are getting invalids, not at your neighbour, you are getting invalids at the neighbour's neighbour. In case everybody checks ASPA, if not, you are getting this on the other end of the world.
This is some Schema I sketched in the aeroplane yesterday. Basically I forget to include my back up provider so that my link between me and my back up provider is now considered peering and the back up provider has only authorised to send the route to their customers, if they send it to peer, it looks like a leak, it looks like a misconfiguration on their side. And it makes your network unreachable from weird places.
So I sent another email. What about prepending my own ASN before actually doing the check? And the draft authors told me quite plainly, this is a performance issue. It's going to make the AS path longer. We should not do this.
So in the end I was, there was quite, there was quite a push and quite some conversations about this, it ended up becoming another draft which may hopefully unblock the process but these discussions were going forward and backwards for quite a while. So now we are in 2026 and it's still a draft because, well, it still has the draft parameters.
There's a short interlude. There are three major software engineering programmes, the first of them is cache invalidation, the second of them is off by one. The third problem is naming things.
Because nobody knows how to name things. And the fourth one is cache invalidation. (Laughter)
And I would ask you which one of those was in BIRD's ASPA this time. Let's return to ASPA.
We got a message the downstream validation in BIRD is yet again wrong. And after confirming this which took quite a while actually, we were off by one. If you remember the Schema of up ramp and down ramp, we were not counting properly whether these two top points are nearby or whether they are the same and we only accepted those which were the same. Oh, no. This was off by one.
So what to do now. On your side is study how it works. I promise I pinky promise it's almost done. It's not going to change much. Please sign your own ASPA just to prevent valids but please deploy things like checking whether all of your BGP sessions are actually covered by the ASPA, if you don't do that, you get an invalid route on the other side of the world until people deploy ASPA checks. And deploy ASPA checks and check, it may show you some nasty things, some funny things. Yeah, this is who is speaking, I am working for CZ‑NIC. There's a block of contacts which is actually available on the website in the presentation. And that's it.
(APPLAUSE.)
MASSIMILIANO STUCCI: Do we have any questions for Maria. I see people walk towards the mic, OK.
SPEAKER: Hi, I have one side remark to that, also don't forget that all the layer free IXP out reaches are transit providers, like Swiss IX.
MARIA MATEJKA: Yes, this is one option, the other option is to convince your transit IXPs that they are actually behaving transparently and dropping their AS from the ASPA but this is something which has to be decided inside the IXP.
SPEAKER: We'll go to the other side here.
SPEAKER: Job Schneider; I am I guess one of the people that your launching your complaints about customer service being a little bit slow about. And I agree with much of your analysis in that the ASPA technology is a bit insidious in its complexity, within the one hand it's easy to explain to people, filling your providers and are good to go and your router will doing the magic and I think we managed successfully to put a lot of the complexity into the router which Maria means that you and I have to suck it up! In our respective BGP stacks but I think that the lived experience through the deployment of route rich invalidation as we went through that 2019, 2020, has caught the community at large a lot about like oh cool, there are risk conditions to consider, there are minute details that must be unambiguous even when the world's top lawyers look at this and it is that learning experience that I think makes the ASPA project a very much measure eight times, nine times, cut twice because the cost of getting this wrong or shipping a specification that's not the absolute best that we can do is pre‑then /TKUS and given that RPKI has a lot of impact on today's routing, I think it is really sort of a one shot chance that we have to get this deployed and we cannot go back to the drawing board if we discover problems in the field and in this adventure like one of the things that IETF learned is that implementations are a requirement for successful RFC publications and your work in BIRD and ours in open BGP D and others is inst men toll at that time success of ASPA and the fact that you recognise oh, this was a little bit different than I thought it was or oh, the text is unclear, it's tremendously helpful in navigating what is a complicated feature that we are adding to the stack, so thank you for your analysis, I think there are more contributing factors, you are being very graceful in holding back some of the criticism that would also be justified to express. And in your final statement that we are close, I agree. We are close, we only need to add to shut down message to RTR and then we are done. But.
MARIA MATEJKA: Just the last patch.
SPEAKER: One for thing.
MARIA MATEJKA: One more fix. Yeah I I agree, it's basically getting it right, the best ones.
SPEAKER: Thank you very much for fixing Spa in BIRD because we need to in meeting ASPA in BIRD path which I am not sure whether it's the right thing to do, however I can just tell you that right now we are dropping 937 IPv4 route and 772 IPv6 routes out of 500 different paths so for no complaints, I also wonder for everybody else, if you see something that doesn't look right, talk to me please. Not to British transport police.
Sander Steffan: One of the reasons I haven't created ASPA records yet is so if I am peering with somebody on AmSix for example and they have customers of customers of customers, so I don't have an up ramp, I just is a down ramp, what am I break.
MARIA MATEJKA: If you have no transit at all .
SANDER STEFFANN: I do but not for this particular...
MARIA MATEJKA: Then I will jump back to that... it's quite a long one. It's completely OK to have one of the ramps, in this case the up ramp, it's completely OK to have it at one, you are becoming this one, then you are sending the route to the peer and then the peer is sending it to their customers and the thing you are, if you go and sign your ASPA being here meaning you have some providers above you, all others will know that the route you have sent to them must only be sent through their customers and nowhere else. Which means they can't send it to their peers for example and that traffic has to go through the transit.
SANDER STEFFANN: Perfect. Thank you.
MASSIMILIANO STUCCI: OK. We have a question?
SPEAKER: Hello, yes, OK, we have three actually, the first one is Alexander says ASPA cold water and the question is is there anything that makes you happy with ASPA.
MARIA MATEJKA: I will defer this for later.
SPEAKER: OK, then we have Matthias, a comment not question, in addition to better writing, proper and complete test cases would help.
MARIA MATEJKA: There is actually a funny power point presentation which includes a bunch of unit tests and if I wasn't a total idiot and implemented these tests after suggesting them for in BIRD we wouldn't have the off by one. Because I suggested those tests, created them, then I put only half of them into BIRD, forgetting that there is another half, then took them, put them into the presentation that became half official document and after that some other people found out that if they implement the rest of the tests, they actually reproduce the bug.
SPEAKER: OK and third one, Lucas rose, you said as a to do, sign your ASPA. If I were to do that and haven't heard of ASPA before, where would I start, is there any documentation you would recommend.
MARIA MATEJKA: I would expect the RIPE NCC has some documents but I have no idea, maybe that's a question for different people. I am just implementing the RFCs and sending things on the mailing lists.
JAN ZORZ: OK, thank you.
MAX STUCCI: I would say there was a nice presentation at the previous meeting how to go and create your ASPAs, I would suggest you check that one and it's relatively easy, time why are one quick comment.
SPEAKER: One quick comment. Come to the routing working group because I believe there is a number of super interesting ‑‑ Oh and more advertisements, IETF Hackathon, but routing working group is I think the next ASPA topic coverage.
MAX STUCCI: Perfect, let's see. We are five minutes over time so thank you Maria. Thank you very much. (APPLAUSE.)
This concludes our session and I see you later after the break.
[Coffee break].