Plenary session
.
RIPE 82
.
17 May 2021
.
2:30 p.m. (CET)
CHAIR: Welcome to this session. We have a session for you. We have a full talk about my favourite subject, DNS, by Geoff Huston, and not one but two lightning talks, one from Daniel about IPv6 and one about the Rob Blokzijl Award from Nigel Titley.
Housekeeping: Again, don't forget to rate the talks, it really helps the Programme Committee to decide on the future Plenary and it helps the speakers become even better than they already are. Also, I would like to remind you that the nominations for the RIPE Programme Committee are still open. We have two seats up for election, and you can send your nominations through the RIPE 82 website. You have until 3:30 tomorrow at CEST, so that's only 24 hours and 59 minutes left. So please send in your nominations; we could always use some fresh blood.
.
Without further ado I would like to give the floor to Geoff.
GEOFF HUSTON: Who is going to load my slides, me or you?
JELTE JENSEN: I can probably enable them.
GEOFF HUSTON: This is a topic really dear to my heart, and I think many, many others'. There is two things that hold the Internet together as one network: it's names and addresses. And the problem is, we have kind of stuffed up the addressing business. This whole v4 and NATs and v6 means that, you know, the addressing domain is a bit of a fractured mess and so we're kind of relying on names to sort of keep the Internet together as a single hole, and so names are really important.
.
I'm not sure they are behaving themselves. What I want to look at today is kind of where is the DNS going? You know, what's the ‑‑ what's the next bit that's going to happen in the DNS?
.
Someone is going to have to advance this slide or I'm going to have ‑‑
.
I don't know about you, but I always kind XKCD to be spot on from time to time and this particular cartoon I found to be spot on. The DNS is really important. You know, because if you think about it, the DNS is used by everything and everyone; it's the window on your soul on what you do online and, quite frankly, if I could see a stream of your DNS queries, I know you, I know everything you have done, I probably know everything you are about to do, because the DNS is one of those things that makes a surveillance economy just work.
.
Yes, the DNS is really important because everyone uses it.
.
And the problem is that, not only can everyone use it, it's really easy to abuse it as well. Queries are open, queries are unencrypted. Payloads aren't secure. I'm, like, tampering couldn't be easier, hit me! And, quite frankly, some of it just involves getting there first. Responses are predictable. If I know what you are going to ask for, I can substitute an answer in faster than the real answer and you can't tell.
.
And so, in some ways, the DNS is just an open target, so no surprise, everyone picks on it. And, of course, you don't know where your queries go, I don't know where my queries go, nobody knows. And so when you get an answer, it's kind of someone answered me, isn't that good? Yeah! But you can't tell. And so, in some ways, the DNS is just one of those perfect targets. So, what I want to talk about is how we're responding to this and look at the measures that we have done in recent times in trying to make the DNS a little bit better and assess our success in that, which is I think the most important thing.
.
So, firstly, let's talk about authenticity, and I guess you know what I'm going to say here. How do you trust the DNS answer? Well, you know, if you ask the right policeman you will always get the right answer. So if I send my query to the right IP address, you know, the right answer will always come. Or I could be a little bit more careful and say, prove it; give me not only the answer but a digital signature that I can validate, because just sending your address to the right place is kind of stupid. It's what we did for years and it hasn't worked for years either.
.
And so obviously we all need to use DNSSEC and actually check the answer, actually request a digital signature and then go and validate that signature. We all should use DNSSEC, yes! But maybe we don't, because the answer really is yes and no.
.
You know, yes, there is a lot of people who actually validate DNSSEC responses. Here is a map of the world; the greener it is, the better it is. That's an odd collection. You know, yeah, Scandinavia, yeah, Mongolia, yeah, the Saudis. Yeah, Somalia, and New Zealand, even better. But what an odd collection. And some countries ‑‑ China, Spain, UK, don't. I don't know.
.
Let's put it in numbers. The grand numbers.
.
How many percent of users on the planet actually validate their answer? It's 22%, which is a little less than v6 these days, it's still good, but three lines on that graph. The orange line is the total of the red and the blue. What's the red line? The red line is you use the validating resolver and it gave me back no, so I went for one that didn't validate because I want the answer anyway.
.
So 10% of users actually know that they are getting this and they go: I don't care, give me the answer anyway, I am desperate. And so DNSSEC is kind of being used and kind of isn't. The real question is: How much of DNSSEC is out there anyway?
.
Wish I knew the answer. Wish anyone knew the answer, because no one knows the answer. How much zones are actually signed? Well, you have got to figure out how many zones there are and how popular they are. We don't know. There is not a lot of DNSSEC use, is our suspicion, even though lots of people validate, but there are very few zones that are signed, is our suspicion.
.
In some ways DNSSEC is a bit of a disaster. Why?
.
Well, one of the things about the DNS is, one of the large arguments is it works best where the answers are tiny. They fit inside a single unfragmented UDP packet. Even better, they sit inside 512 octets. We are still relying on this figure that comes back from the late eighties of going, keep your answers small, no problem; make it bigger: world of hurt. And so large responses just encounter that nightmare of fragmentation in the TC and IP, that's sort of Achilles' heel of the protocol. UDP and fragmentation don't mix. Quite frankly, validation takes forever, because you have actually got to go backwards up the entire delegation chain and check every signature. People don't live that long.
.
And, you know, it's just a whole bunch of more queries with more fragmentation loss, more TCP transitions.
.
Oh, and by the way, we are all getting ready for quantum recruiting, yes, so we really, really need to make our keys stronger, yes? They need to be a whole lot bigger? Yes. Yes? No. Because we just can't cope with stuffing that much information inside the DNS and still make it lightweight and fast.
.
What happens right now? That critical link, me to my recursive, demand validate on the whole. So I end up trusting my validating my recursive resolver to dot job. What if it lies to me? Well, I'm toast. So DNSSEC framework kind of represents a lot of effort, a huge amount of effort for marginal gain because I'm still at the mercy of my recursive resolver. Gee!
.
So, are we getting any better? Good question. We know we can make it better. We can actually use DNSSEC chained responses to get rid of the extraordinary time to validate. We can actually use dense encryptor algorithms like elliptical curve and get things back down again. Of course, if we all use TCP for DNS, we could make these bigger responses kind of work.
.
NSEC 3 ‑ well, I'm not sure if that was an improvement or a gigantic leap backwards.
So, in some ways, DNSSEC is kind of a mixed blessing and the problem is it doesn't cure everything because it can't stop eavesdropping, interception, tampering. All it can do is withhold the bad answers. So it's a trade‑off. It gives you authenticity but at a price. A price of delay, a price of load points balanced against that assurance, a price of fragility. And a lot of folk don't want to pay it. And that's why DNSSEC is kind of a bit one way, a bit the other.
.
So that's the first point of pressure. The next one: Application level rendezvous. You know, it used to be so simple. I want to go to fuzzboz.com. I look up the DNS, it gets an answer. I go there, that's fine. That's the service I wanted to go. All the services that share a name share that common IP address: Service, IP address, same faith, but we wanted more, because, all of a sudden, we wanted to put that service on multiple platforms. We want to differentiate between the service you want to go to and the platform it's hosted. All of a sudden we want a collection that delivers that service. We want to outsource different services to different service providers even if they share a common name. Think about google.com and all the services sitting behind there. We want to steer the user to the right service provider for each user and we want it to be really, really fast.
.
Now, one way of doing this is to just go to one of the named service points and go, well, where are you? I'm in Australia ‑ ha ha ha, you don't want to use this service, go and use the application over there, host it on this platform, etc., etc. This idea of go anywhere first and get redirected. That's not fast, that's slow. And so if you want it to be fast, you can't do those kind of tricks. You want to put all of this in the DNS. And so we did. We had the whole idea of service hosting and distributed content networks by using C names and D names and A names and all kinds of bells and whistles that were kind of compromises all the way down the line. And then we came up with the SRV record which is either the Swiss army knife of incredible agility in using the DNS for quite specific information, or it's another chain saw massacre of complexity, because what you do is actually put the service name ‑‑ the port address ‑‑ and the protocol ‑‑ the transport ‑‑ into the DNS name and use this as the query and then give you another response as to where you should go to to actually get the platform that offers that service over that protocol. And of course the disaster on legs that is the sub‑net query option that says what's this thing about anonymity? Just add your identity in the query. Nothing wrong with that. Well, not much.
.
All of those were kind of compromises in various ways, now we have come up a better one. The SVCB or the HTTP SVC resource records, which is the kitchen sink of DNS responses that provides the application level protocol, the v4 and IPv6 addresses, the encrypted SNI key, the priority, oh, yeah, and an alias form that gives you mapping at the apex and everything else, this will, of course, be the magical cure. But let's think about that.
.
Because all of a sudden, what you are doing is, you are asking the DNS: Where do I send my next packet and what should that packet be? Because now the DNS is giving you a set of service connection parameters that's tailored to optimise that service. And all of a sudden now, if I see your answers, not your queries, but your answers, I know what you are going to do next, I know the next packet you are going to send, which means that all of a sudden this whole thing about DNS privacy is not just an academic debate of where could I hide, but a very real debate about eavesdropping taken to the next level: If I know your DNS, I not only know you, I know your packets. And that's getting kind of uncomfortable. Yeah, it's really fast. Yeah, it's really, really starting to worry me and anyone else because all of a sudden the DNS is saying thing that you don't want people to know about. And we now need to talk about information leaks, because this is now a really important kind of problem.
.
So we already mentioned today the whole thing about query name minimisation, the DNS was extravagantly chatty, incredibly loquacious, it was basically tell everyone, hey, Geoff is going there, to anyone who wanted to listen, including route servers, bad idea, we're kind of plugging that gap.
.
And now we have got no more heavy forms of encryption, DNS over TLS on the stub to recursive, sort of protecting that all important hop to the end user and their recursive and now we're going one step further putting in inside HTTPS, I am including here DNS over HTTPS 3 using QUIC. In other words, going back to an encrypted transport as well as an encrypted payload.
.
And now lately we have got oblivious DNS over HTTPS 3, which actually takes that one step further and now there is no single person other than you, the querier, that knows who you are and what you are querying. Everywhere else, that association is ripped apart through multiple layers of encryption.
.
So we can plug this leakage. We can.
.
And sometimes you might think, well, it's going to come soon. We are also going to take it one step further and do the recursive to authoritative and no one will be able to see much at all. Although don't get your hopes up over recursive to authoritative; that is a lot tougher than it looks.
.
So, can we scale it? Good question. Because the DNS works so well because it's so, so, so lightweight. So if we don't want to sort of, you know, die here, we have got to think about how we make DNS over TLS super fast, and the best way to do this is to keep the sessions open. Now, a recursive and a stub typically have a long‑hilled relationship, and, with the eloquent use of cookies or other forms of semi‑dormant TLS sessions, you can actually revive them quickly, use a TCP fast open option and do this almost as efficiently as UDP. They claim. Probably true, I'm going to accept that. And so the secure web infrastructure points that we can actually do this at scale, we can actually make that stub to recursive work very, very efficiently using TLS, but I think the economics of the DNS say not going to happen so easily.
.
And that brings up the real question here that we have got to think about today: Will this get deployed? And the answer is, well, we can do it. We know what we need to do. We know how to leverage TLS and do session level encryption. We know HTTPS to push although those stub resolver functions up into the application and not rely on the platform to do it and we can use this DNS chainsaw HTTPSSVC resource report to encrypt the SNI. Oddly enough, the server's name that you are going to can be hidden from view. So yes, we can do this.
.
That's not the question. Will we do it? And that's a far, far harder question.
.
Now, I have heard a lot of folk go, well, the web does this. What's your problem if HTTPS works? Well, DoH is just the DNS over HTTPS, it's just another use of HTTPS. So, easy. Not.
.
I don't know about you, but I have really changed the settings on this damn phone. I'm not sure what I'm breaking, and I think I share that view with a view billion others. No one fiddles with the buttons; only you nerds do. Everyone else is kind. Oh, gee, if I fiddle with it it will break. Better not touch it, no one changes the config. And CPEs, those devices on the wired networks that are the arbiters of your behaviour, cheap code built years ago, never, ever going to change.
.
And so any change of the DNS that requires us to change behaviour in devices or changes the edge infrastructure of the Internet, if we want to change that, we have no idea the scale of what we're asking for. This is close to impossible these days. And part of the issue is there is no money in it. And I'm like, there is no untapped financial return in DNS resolution. So, there is no real momentum from providers to actually push this out. So, there is no commercial impetus. And oddly enough, there are a whole bunch of folk, the Australian government one of them, to rely on the DNS to provide their social environment and various lists of naught owe DNS names that they don't want us citizens to go to and Australia isn't the only country that does this, it's probably one of the majority, they all do it and so in some ways DNS oversight and DNS censorship is part of the current infrastructure of the Internet. No one wants to make the DNS that obscure that that can't happen.
.
And while browser vendors were able to push HTTP into HTTPS, they had a huge amount of leverage, and some where between Chrome and Safari and Firefox the world changed into HTTPS because of that push. They have nowhere near that degree of leverage in the larger DNS ecosystem. So as much as they might like it, it ain't going to happen that way for everybody.
.
What does this mean? Well, quite frankly, what it means is the DNS economy resists change. Clients don't pay for resolutions. You don't pay for your queries. DNS is not a revenue raiser. Running a recursive resolver is a cost. And the only way you can get back that cost is kind of difficult, you can do NX domain substitution and say that's not the domain name you wanted, try my new search engine, but everyone frowns at you. Not a good idea. Or I can sell the queries. People tend to frown at you when you do that. The surveillance economy has a bad ring within clients. So, in some ways, efforts to monetise the DNS are viewed with extreme disfavour. And all these open resolvers run the risk of success disaster; the more people use it, the more the operator has to pay for it. You need some business stream that basically shovels money at the resolver. The DNS economy is a wasteland of money. It's with dreams go to die, not where dreams are made.
.
So, making changes in this space is incredibly challenging.
.
So the default option is, the ISP can do it, they are getting the money from the user. What we find when we lock at the DNS is that 70% of all the end clients actually use the same network recursive resolvers. But it's a little bit more depressing than that I think. Because of the other 30%, most of them use their networks recursive resolvers but the network itself is using a forwarding statement that sends all the user queries into some other resolution system. So around 98 to the 99% of all users use the ISP provided default.
.
And because of that, it's heavily resistant to change. So you can't just make things more expensive and expect everyone to do it. So, adding encryption, adding all these fancy bells and whistles, who is going to pay? The DNS is cost, not revenue. So it's a highly resistant to all these wonderful forms of change. And so it's reasonable to ask, now that we're in a slightly depressed mood: All these wonderful changes, will they happen? Will they become mainstream?
.
No. No!
.
ISP based provisioning without challenge encryption is going to be the mainstream. The DNS over UDP unencrypted and open is going to continue forever. And most users won't change their platform settings. I am going to revolt and one my own mobile phone, run my own system on some other open DNS resolver that's actually doing encryption. Yeah right, we're not going to do that. So in some ways all these great ideas are going to linger on and on and on and never get deployed.
.
Or maybe not. Maybe there are other ways that this is going to happen. Because the other answer is that the DNS is part of a very broad ecosystem in the Internet and there are certainly application that is want to move a lot, lot faster that are impatient. They want to tailor the DNS to adopt a more private profile and just hive off and go and do it. Look at the push, what happened with Firefox and DNS over HTTPS. Despite the platform, despite the ISP, despite everything, Firefox said no, sick and tired of this, I am going to use encrypted DNS directly, because they can. The application can actually go its own path. And if it's sick and tired of websiting via your favourite CPE vendor to update its $10 software and run a better DNS resolver which is going to take forever, the application simply goes, right, I'm out of here, I am going to do it myself, and, when it does it itself, it doesn't go back into the normal DNS resolution infrastructure; it actually has its own momentum to fund its own privacy infrastructure, to fund its own oblivious DOH services, to fund their own elements of name resolution, and they will, because they think this is important, and if this is important and they have the money and resources to do it, they will.
.
And so what we're going to find is that those parts of this environment that have motivation and money, i.e. content, not carriage, content, motivation and money, are simply going to stop waiting for everyone else to be dragging their heels and moving and they are not going to pay them to move, those days are over, they are just going to do what they feel they need to do. They are just going to do it anyway.
.
The end result is that what you're going to find is that it's life, Jim, but it's not as you know it any more. Because we're actually going through a progression in the Internet architecture, which is actually a very important and fundamental progression. If you think about the telephone, the edge devices didn't matter, everything was network‑centric. If we look at the Internet, it's platform‑centric. Applications are merely things that sit on the platforms at the edge and all the functionality of the Internet was bedded into the sets of libraries and operating systems into the platform itself. Those days are gone. We are now seeing user‑level transport. Look at QUIC. A UDP shim shell to actually keep the operating system out of the way. Everything else hived up into the user space in the application.
Look at BBR, lock at a whole bunch of these things and what we're seeing is the application is now the driving force of the Internet. We're now having an application centric network and the DNS is not part of common platform infrastructure any more. The name space is now changing. And the name space is actually becoming application centric and different applications and servers are highly likely to head off into their own name spaces, and so that last point on this slide is actually the kicker here; that when we stop losing patience and when we stop dragging everyone along because we couldn't afford to, haven't got the time, haven't got the resources, then the more agile folk will move and move alone. And a single coherent name space isn't going to happen any more.
.
That's over. The entire Internet service domain is now defined by a fragmented address space and a fragmented name space, and that seems kind of scary, but in some ways, there is no way out of this mess, that the folk who are now getting entirely frustrated and justifiably so, about the inability of the Internet to make fundamental change any more because it's just too damn big and too damn difficult and too damn expensive, they are going to make their own changes in their own spaces and everyone else ‑ well, sorry!
.
So that's where I think the DNS is going. I'm sure there might be some opinions or arguments over that. And we have got just a couple of minutes left and I'll be happy to try and take a shot at them. Thank you.
BRIAN NISBET: Thanks very much, Geoff. We have a couple of questions, as you might well have guessed, and certainly from my point of view a very interesting presentation, so thanks again.
.
First off from Andrew Campling, and again, remember you can type your questions into the question bit or you can ask for the mic, which we can give you.
Andrew Campling from 419 Consulting: "Great presentation as always, Geoff. Thanks for sacrificing your sleep, yet again." So two questions:
.
"1. Should we try to Streamline DNS, push some of the other functions elsewhere rather than allowing more bloat?"
GEOFF HUSTON: No, we have no way of doing this. The whole issue is that first touch in TCP in the web is the critical point and so what we're trying to do is front‑load the DNS so that that rendezvous function is one round‑trip time. So, no, if we try and push it elsewhere, it's the time budget. We are playing around with time here, and the application folk are going: I have no time, I really believe in the billion dollar nanosecond, can't waste time doing other functions. So, no, the DNS is going to have to carry this can.
BRIAN NISBET: And question 2: "Is there much/any interest in authoritative resolvers supporting encryption to recursives? The ‑ don't appear to have asked them."
GEOFF HUSTON: I think they need to carry the cheque with them. It's not that they could or couldn't do it; it's who is going to pay. Because as soon as you add TCP and encryption between recursives and authoritatives, and don't forget the query structure is so much more different and long‑hilled sessions don't really work here, it ain't going to work unless there is a massive cheque involved, but in the DNS economy no one knows who pays whom, so it's unlikely, sorry.
BRIAN NISBET: Okay.
GEOFF HUSTON: I am just doom and gloom today.
BRIAN NISBET: I mean, your whole thing, it's nighttime in Australia, it's dark, you are going into winter, you know, it's just ‑‑
GEOFF HUSTON: It's just horrible.
BRIAN NISBET: So, from Benno Overeinder, from NLnet Labs: "Geoff, thanks for the presentation. There is another application that uses DNS extensively: the Cloud. This might not be visible to the DNS end users and difficult to measure from outside. Do you see your know of trends that Cloud providers do use WRT DNSSEC regard to DNSSEC TLS etc. In their infrastructure?
GEOFF HUSTON: I think the Cloud is actually pushed for SSVC and SVCB and HTTPSSVC records. What the Cloud wants is to actually push the rendezvous structure to be richer so that you can actually get to the right point in the cloud simply on the information the DNS provides. I'm not sure at this point that the Cloud wants more time to spend on this. And so DNSSEC is a victim. It's not going to happen because it takes too long. Will they go into TCP based? I'm not very optimistic they will. But if they want to do something quick with DNSSEC like change responses, then they have really got to go into TCP and TLS. Who is going to pay for that is a really interesting question. I'm not sure the Cloud flow want to pay so I'm not too optimistic, no.
BRIAN NISBET: Okay. So Ivan Beveridge from IG: "Great presentation, thanks, Geoff. Authoritative DNS servers work well with lightweight queries and responses, and likewise for recursive resolvers, little network state aside from caching queries. Would shifting to TLS in resolver/authoritative servers holding open for caching or caching connections not cause a higher load on servers causing a scaling issue for DNS?
GEOFF HUSTON: There was a great presentation at one of the DNS OARC meetings, where a presentation ‑‑ I'm going to guess it was from the folk from cz.nic, but someone will correct me if I'm got it wrong ‑‑ talked about an overhead of almost up to ten times the load in doing TLS‑based against straight UDP unencrypted. Yes, there is a cost to pay here, it doesn't come from free and that's the heart of this entire issue. If someone was willing to pay for queries you could get everything you wanted, HTTPS, the lot. But if you are trying to do it inside the current budgets and constraints that the DNS has applied on itself, close to mission impossible, and I think that's the big problem here. That no matter how you try and do sessions etc. You have got a much, much higher overhead here, and that's I suppose the big challenge, to reduce that overhead without spending money and sort of I can't do that, and so no, it's not very optimistic.
BRIAN NISBET: Okay, we're going to close the virtual mic line.
GEOFF HUSTON: Daniel asked the one question here: What level of user confusion do I expect when we fragment the name space? I think we're going to break the Internet, Daniel. I expect a lot of the user confusion. And this is pretty ghastly. Instead of the help detection sayings are you using a macro Windows machine? It's kind of are you using a browser? What kind? What AP are you running? Etc., etc., etc. Wow! Networks we have broken it, so badly. Don't know how to get out of this one, sorry.
BRIAN NISBET: It is one of the things, though, that I suppose ‑‑ and, you know, we have had presentations at RIPE from yourself and from others kind of predicting a certain amount of doom of varying levels of doom in the past, and yet the beast trundles on and more and more users keep using it and sure there are edge case problems, but, you know, it hasn't collapsed.
GEOFF HUSTON: When we broke addressing with NATs, we actually made up for it with names, because it really didn't matter what the addresses said as long as the names worked, you knew where you were going. And so we relied on a single DNS that's going to keep the Internet together because we have blown up addresses; they didn't matter any more. So now we are experimenting as to whether we can kick the other leg out from underneath us and see if we can still stay up in the air. Because as soon as you lose this issue of unique naming structures and, you know, I have a name in Chrome that means a different thing in Firefox, wow! All bets are off. And I don't understand how it can keep this one up in the air. But the pressures to fragment are irresistible because the application folk have just lost patience with everyone else and so they are just going to blast off to the horizon, kind of go, bye all, and that's going to be it, you know.
BRIAN NISBET: I guess we'll see. So we are going to conclude with one comment I think again from Andrew Campling from 419 Consulting: "Just a depressing conclusion. Placing more trust in the platforms and applications seems a really bad idea. They spawn surveillance capitalism, after all. Letting them drive the evolution of the underlying Internet infrastructure seems equally misplaced. They will always prioritise performance over privacy or security, even though they may pretend otherwise.
GEOFF HUSTON: We rip the money out of carriage, we rip the money out of platforms. The only money left is in content. Like it or not, they call the shots. We might not like t you probably don't. But whoever has the money makes the rules. And this is the unfortunate game we're n so I agree with you Andrew, but I don't know how to fix it because those are the people with the money, sadly.
BRIAN NISBET: And on that happy note, thanks again, Geoff, hugely appreciated.
.
So to move on, we now have a couple of lightning talks to round out the session, and the first one is from Daniel Wagner in DE‑CIX, who is talking about IPFIX exports at IXPs.
DANIEL WAGNER: Thank you. Thanks for having me. I am Daniel Wagner, I am working for DE‑CIX as part of the research team and I will introduce you to a small feature we call IPFIX export that we are running in our forwarding platform.
I am a packet developer, and let's get some closer to details of the product.
First of all, the motivation. Actually, it was the customer requested service, some customers requested them to have more insights into their traffic details from a specific and unique vantage point that is the IXP itself and obviously their router. Furthermore, not all routers have the capability to create statistical insights and some of them also don't want you to change the configurations and touch them as little as possible.
.
And one interesting insight is that even beyond the rate limit possible to see traffic in the IXPs on IPFIX data, meaning, for example, that if your link is clogged, it is full, it is at the rate limb, then all you will see in your IPFIX data from your router is what you receive, but from the ISP's point of view that is actually more visible than only that.
.
So, talking about exploring data. We need a protocol for that. That is the Internet protocol flow information export protocol standardised in RFC 7011 which offers a lot of configurability and flexibility, thanks to the templates. The templates are on packets being exported periodically which contain information on how the actual payload data is structured. Therefore 191 data fields is defined and the ones we are exporting ‑‑ I see the quality is pretty bad ‑‑ the flow ‑‑ the fields that we are exporting the resources and destination MAC address is IPv4 and IPv6 source and destination IP addresses. It is the insert protocol number, so in this case you see it's TCP. We have the Layer4, so the transport ports, destination respectively. We have the octet count, which is the byte count of all these bytes that were in this flow as well as the packets that were sampled in this flow, or contained in this flow.
.
We also exported TCP‑FLEX. There are two things to note about this protocol is that the data and the lifetime out, meaning that if you are something your packets and you will put them into flows before exporting them, you have like that time‑out image means that, for a given interval of time, no packet has been seen according to your flow but the flow has been recorded sometime let's say it's that timeout before them, this flow has been exported. Otherwise if you see more and more packets being sampled for this very flow, then after an upper time limit it's called the lifetime out, this flow is going to be exported.
.
The architecture in our case is we have a sampling rate of 1 tout of 10,000 packets that we are sampling, and our dead time‑out is 15 seconds which means there is a 15 second time‑out running out before this sample packet is being exported. Otherwise there are more and more packets belonging to the same flow being sampled then you have a lifetime out of 60 seconds.
Okay, so our back‑end and our infrastructure places the infrastructure into the export virtual machine, that is one I created where the back‑end is running and you are ‑‑ the customer that requested this feature, they can via the front end, request their data, start, stop and let's have a look at the front end.
The front end is imbeded in our customer's portal. You can enter your target IP address, the public IP address, etc., where the data should go to. You can choose from your MAC addresses. Only the MAC addresses, nothing else is possible. You put the action, either start or stop, depending on if you want to trigger RF stop and IPv6 port.
So for the back‑end, we are leveraging sub‑fills called Vermont, that is the versatile monitoring tool, which is publicly available on GitHub, which I use for dumping our IPFIX data which originates from our infrastructure and I will split this up into dumps which are like generated and thrown away over the time, which enables me to pass the same data with many many processes and parallel. So how many process will there be? That depends on the customer's requests. These requests are passed into a web server which will pass the data to a request managing data structure which keeps track of all running exports and will, for every export, that is requested for every MAC address that should be filtered for will be substantiate one Mac filter which then indicator turn passes the filter to IPFIX data which only contains data that was either the destination MAC address of your interface or the customer's interface and will then pass the filtered IPFIX data newly generated IPFIX stream just for this very customer to a DTLS wrapper, which will then take over responsibility in terms of encryption, because otherwise we would not send out your ‑‑ the customer's date via the Internet.
.
Okay. So then have a look at how the data is actually being received.
.
This is received by either our open source decryptor that you can download our other tools that we have been working together with. In this case, you can pass the data that is being corrected at your interface that very IP address that you just entered into the front end and you can pass it to any further process; in this case, it's a search.
.
Planned enhancements. We are also looking at configuring the transport, we want also to give you an overview of what you have been wondering about, because at this there is not yet a possibility of doing this. We want to support other exporting by IPv6 and we want to support other DE‑CIX sites, at this point it's only Frankfurt and in the next couple of months there will be in the DE‑CIX academy, you have enough for this very tool.
So, to sum it up, the IPFIX port is a small tool for the customers enabling them to self‑manage receiving the subset from a unique vantage point which they requested to fuel their own analysis. That be that exported in an encrypted manner around the tool is free to use.
.
That's basically it. I would like to thank you very much. I see the time is up. I would be happy to take any questions. Thank you.
JELTE JENSEN: Are there any questions? I have one. Are you suggesting that all IXPs should start using your tools and offer this as a service to all their members?
DANIEL WAGNER: I don't think that I would propose such a thing, but in case the customers of the IXP are requesting these kind of features, then please contact me, I can give you the code. And we can also look it up on GitHub because most of the source code is publicly available. I placed most of the links here in the slides.
JELTE JANSEN: And this was an excellent question from somebody, but they noticed that the at DE‑CIX, they had some problems with the actual catcher catching up on the traffic and reporting suspiciously low numbers. Do you have any experience in the loads management of your tool?
DANIEL WAGNER: Not yet, actually. I did not have a customer complaining about such a thing. And as I double‑checked and ‑‑ all the working code and I have my watchdog running, I'm pretty confident that everything is in place. Try it out.
JELTE JENSEN: So, everybody, please try it out. Well, Daniel, thank you. That was very interesting and I hope this will find lots of success.
DANIEL WAGNER: We will see. Thank you.
JELTE JENSEN: So, next up is Nigel, are you there? There you are.
NIGEL TITLEY: Here I am. Thank you. Well, this is a public service announcement on behalf of the Rob Blokzijl Foundation, and it's a call for the awards committee. So who was Rob?
.
If there is anybody here that doesn't know who Rob was, Rob was the basically the founder of the RIPE community and the RIPE Chair for many, many years until his somewhat untimely death a few years ago.
.
And the Rob Blokzijl Award was set up to recognise and reward individuals who basically helped the development of the Internet and the RIPE service region and supported or enabled others with the development of the Internet and the RIPE service region.
.
It's usually made every two years. Last year, well you may have noticed that last year was a bit different. We have had upsets, and so last year an award was not made; in fact, last two years award hasn't been made. But it's coming. It's primarily a sign of recognition from the community for services rendered, and that's its main function, but it does also include a mandatory award of €10,000.
.
And the first award was made to Wilfried Woeber, who you may or may not know. Wilfried was a very prominent member of the RIPE community for a long period of time, and he was awarded the first award in 2018, and there is a picture. On the left is Lynn Blokzijl, who is Rob's widow, Wilfried in the middle and Mirjam, whom you all know.
.
So, it's time to make the award again.
.
So, we need an award committee, because that's the process that we have. Basically, the awards committee sets up and decides who to make the award to. It's not done by the Foundation. The Foundation Board, it's done by a board's committee which is appointed each time. We would like your suggestions for the members of that committee. And the award committee, once constituted, will issue a request for the award recipient nominations. So this public service announcement is for the choice of the awards committee.
.
So, what can you do? You can volunteer for the awards committee. You can volunteer other people for the awards committee. Please send suggestions or nominations to the e‑mail address below, board [at] robblokzijlfoundation [dot] org. And finally, if you want more information, you can e‑mail the board again the same e‑mail address or you can look at the website, whose address is there.
.
And that's it. End of this public service announcement. Any questions?
BRIAN NISBET: So nothing in the Q&A. I'll just give people a moment. And thank you, Nigel, for announcing this. I think it will be great to see the award back on track and hopefully lots of other things coming back on track in the near future.
.
If there are no ‑‑ oh ‑‑ so, Jan Zorz, 6connect, is asking: How is the committee selected?
NIGEL TITLEY: The committee is selected by the board. Basically, we have never really had a problem with the selection of the committee. There is usually fewer people suggested than we think is appropriate. So if you think you can serve in this way, then just let us know. The board will make the selection.
BRIAN NISBET: Okay. And I'm not seeing anything else, in which case, thank you very much, Nigel.
NIGEL TITLEY: Thank you.
BRIAN NISBET: Best of luck with all that.
NIGEL TITLEY: Thank you.
BRIAN NISBET: Okay. So that concludes the talks we have lined up for this Plenary session. So, we'll get a little bit of extra time for you to go and make your own coffee or do whatever you have to do at home or in your offices. I will just remind you all, please do rate the talks, because it's really important for the PC, and, as Jelte said at the beginning, we have two spots open so you have until roughly this time tomorrow to nominate yourself or, you know, nominate a friend, with, of course, their consent and permission.
.
So, thank you all very much. The next session will be starting at 16:00 CEST, UTC plus 2, in, unsurprisingly, this platform. So thank you all very much, and enjoy your coffee or standing up or whatever you are about to do now. Thanks.
.
(Coffee break)
