Internet Engineering Task Force 113, 20 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF113-IEPG-20220320-1700

Description

IEPG meeting session at IETF113
2022/03/20 1700

https://datatracker.ietf.org/meeting/113/proceedings/

A

A

B

A

C

C

Let's mute that so we don't get an echo, so this is gonna, be the first time that we're trying the new me echo thing. The way you're supposed to get in and out of the queue is using your phone. So there is a qr code that you're supposed to scan up there yep. So if you think you might want to get in the queue, you should probably scan the qr code, so you can do stuff.

C

Also. We have some set of people who are going to be presenting from here and some set of people who are virtual. The first presentation is going to be jeff houston and he is virtual. We also have justin and eric fink, who I think are in person. Is there a justin and eric think anywhere.

C

Not yet well they'll show up um ignis. Do we have an ignis, we have an eggness. Do we have a lenny.

C

No linear, oh remote, okay villain, I saw a villain and tony lee is remote or virtual. Already, oh excellent, so um I guess we will just jump into it um in case you're confused. This is iepg we're not actually an ietf working group, but we're somehow vaguely affiliated with the ietf.

C

And let's do this thing, so I will start sharing, jeff's, slides and then welcome, and then I will hand the slide shareability to you or you can just ask me to change them for you, but I think you should now have the ability to change, slides yourself and I will try and let you know if there are people in the queue as well or anything like that. So.

D

Thanks warren: um oh there we go. um This is one of two talks this morning about ipv6 fragmentation and extension header behaviors. Why? Because there are a number of drafts out there that seem to think they're, useful, they're, probably wrong. Let's go find out. um uh You know all this, no point repeating it. uh You know all that too no point repeating that um you know the only thing v6 really really changed. If you get down to it, was just taking the fragmentation, controls and basically setting the don't fragment bit to a hard on.

D

So the only agent that can fragment a packet is actually the source, there's a kind of a philosophical question about whether you should ever see tcp fragments at all, because after all, if the source knows that it's going to fragment the packet in tcp, why doesn't it just change the mss and not fragment, but that's a different conversation?

D

Let's assume we're fragmenting, because you know we can so that's now shoved into an extension header. Now, the last time this was looked, that hard uh is rfc 7872 and that work was done in 2014 and 2015. hi jen. I can see you there somewhere, um and these are the results that they publish now the way they did. This was actually sending the packet to the server and manipulating the packet and seeing if the server actually responded and what they found for fragmentation.

D

Fh 512 was bad. I might any time you see, loss rates are between 28 to 50 percent. You know, you know it's bad, uh but it's a little more than that, because they also tried uh destination options. Extension header and the hop by hop options. Extension header, using if I read that rfc correctly, a pad 8 option and oddly enough destination options, seem to fare better and hop by hop was a little bit worse.

D

So just remember those numbers, okay, you're, going to be a test later so got it thumbs up cool you've, remembered it well done. As I said, we will test later. um That's really really bad. By the way you can't fragment, with the fragmentation rate that high you just can't, and so why well firewalls don't like fragments. This is true.

D

The whole thing about ipv6 path. Mtu is kinda broken because it relies on icmp v6, which you actually can't authenticate some random router off the street. Sends you an icmp v6 packet too. Big actually means that all as it did is it saw the packet pass by. God knows why, and so anyone can send you these messages. Why should you believe them and the other part of this issue is extension?

D

Header chains are supported, variably, okay, so there's a problem here, the extension header handling, because it sits between the v6 header and the sort of upper level protocol. The transport header also means that some transport protocol, aware processors with those switches or whatever find the wrong data at the wrong offset. You know, but why is network middleware looking at the upper level protocol header good question, because it does because they all do why well they're just curious right, simple, curiosity, yes or something else.

D

uh Nevertheless, there's a whole bunch of these units that if they find something instead at the upper level protocol, they just drop it. So the issue about 78.72 is that it's not where the traffic goes. It's the other way when you send packets to servers, you tend to send short request. Packets and the server sends you large answer packets, and so it's not the user to the server that really matters. What really matters is actually the back path or the other path from the server to the user.

D

Now this is much harder to actually construct as an experiment, because, although someone might control the alexa top 1 million servers, it ain't me and so trying to get the servers to behave in odd ways is actually more challenging than you think.

D

So what we did was actually try and take conventional servers, dns and web, and actually write a packet wrangler or to be more accurate, a packet mangler that takes a conventional packet from a dns server or web server and actually fragment it and then send it onward to its destination as a client, however right and to make this work of course. um Well, actually we did it. Sorry. I've got a lot of the slides the wrong way.

D

We did this in 2017 and, as you recall, the 28 drop rate in 78.72 when we did this in a v6 measurement platform that uses online ads.

D

In other words, the text eyeballs small number of servers, massive number of clients, we found the fragmentation loss rate was marginally better 21 drop rate, um fair enough, fair enough, um come back again last year, reworked the same experiment, but we kind of redid that pack at mangala a little bit the same kind of technique, though we're sitting in the middle of the tcp session close to the server we shove all the outgoing packets through this dedicated middle box and we're inside a tcp session.

D

So we can detect if the client didn't receive the packet, because the client won't hack it, and so we detect a hung tcp session by the fact that the act just didn't happen and we can't proceed onwards. uh The other thing we did were kind of curious is.

D

We were wondering if, because we were using large initial fragments, it was actually a subtly different problem, because this is the first big packet sent from the server to the client, and so we decided to test a range of initial fragment sizes between 12 and 14, 16, bytes varying them. By strides of eight, we perform this as an ongoing experiment.

D

um There's a slide about how this is not as easy as you think, uh we're using lib pcap to actually snap and send packets. This is great. Lid pcap has no buffer space, and so the problem is you've got exactly one pack of time to get something done. uh That doesn't work, so we spend a lot of time. Writing shared memory systems that implement a ring buffer for both incoming and outgoing packets and actually did a v6 nap to make all this work. The server is actually a normal old server.

D

uh The client we have no control over and the wrangler has all this muck inside to actually make it happen. So what did we see now? The blue line is the loss rate averaged for the world and it's no longer 28. It's no longer 21 and up until you know a few days ago, uh it's coming down again to around 7.5.

D

So apart from the fact, we stuffed up the experiment over the new year. um It's not bad, it's not brilliant, but it's 7.5. It's certainly not bad. The map is kind of interesting as to where this happens. The green is good. The red is super bad. uh The white is there's not enough, v6 to even measure at the time odd graph, but if you think about it, the folks who are doing super good, like india, are actually the more recent v6 deployments.

D

So it seems to suggest that this fragmentation drop rate is network, not host. It's not the destination, that's doing them now, I'm just dropping it. It's actually the network itself and the more recent deployments using whatever more recent equipment is out. There tend to do a whole lot better than the initial deployments, which are sort of more conservative, like france, for example, um and I think even the american ones kind of mixed, whereas you know like I said india and around the middle east- a lot better in terms of percentage of drop rate.

D

Okay, big surprise: this is the drop rate by packet size. You know seven percent, in this case nine percent, nine percent blah blah blah blah blah. As soon as you get to 1360, it jumps up.

D

No idea why, but larger initial fragments tend to be a lot worse, a lot worse and I kind of broke this up by region in the americas. It's there, but less so in europe, it's strongly there and in asia it's you know a definite signature.

D

Why? If you put the initial fragment size high is the drop rate dramatically. Higher um varies by provider, if you're in telus in canada, nothing nothing gets through. It's a 95 drop rate. Well done guys, there is no such thing as a fragment in telus. They just get dropped, whereas barty um and don't forget that sort of anomaly is: is us not them uh party airtel in india, which is a massive deployment? Few hundred million users, uh the drop rate's around four percent, so they're doing a whole lot better than the world average.

D

I mean they're doing a whole lot better than most folks. So again, why is this happening? um Local security policies, slow path, processing? You know you can read this as well as I can um is this fragmentation drop because we're fragmenting is because the extension header in the packet exists and it's dropping because of that. So the first way we tried to answer this was actually bring up the null header, I'm moving really quickly.

D

So I can see you at the microphone, but I'm going to get through this, and then you have your chance to speak so up to you, but I will go very quickly.

D

This is the atomic header drop rate, which is the null fragment.

D

It's in red and, as you see, there's a component of drop, which is this is a fragment. I don't like it and there's a component of drop that says you put in a fragment header, even though it's not a functional fragment, I don't like it, and the atomic fragment drop rate certainly is high six percent, but it's lower than the actual substantive fragment drop rate.

D

um It varies provided by provider uh in germany, the atomic fragment drop rate's, constant, that's bizarre and higher than the normal fragment drop rate in italy. It's almost non-existent, whereas the fragment drop rate is high and in australia the fragment drop rate when we started measuring it is higher than normal, fragments the atomic fragment drop rate's higher.

D

This shouldn't be happening. You know, why do all these providers have completely different? If you will packet policies around the handling of fragmented packets between substantially fragmented there's data in all the fragments and atomic fragments yeah, it's just ahead of filling up space.

D

Didn't help did it. We didn't really figure out whether this is a drop by fragmentation or drop by extension header. So we thought: okay, okay, we will mangle these packets to put in same as 78.72 a pad 8 extension header. So we tried this firstly on the destination options.

D

um The part of the other reason why we chose the pad n or pad a destination option. Is that all the rest of the destination options? Look crazy, weird crap, and so this is the the few that's kind of in doesn't matter if it's there, if the client actually gets the packet, does nothing it's just padding.

D

So the network shouldn't give us stuff and the client who gets it shouldn't, give us stuff. So if anything's going to get through it's going to be a padding destination option, yeah awesome, awesome, 94.5 drop rate. I'm like you actually have to program that that doesn't happen by accident. That happens because you've sat in your code and go I hate destination options, and so it seems that almost every host- and certainly because these days most of the eyeballs, are sitting on mobile platforms.

D

Mobile platform hosts have particular loathing of destination options, whether they contain padding or presumably any other directive, but it seems that it's it's. It's just wow awesomely bad, so we thought. Okay, if that's the case, let's mix this up a little bit and try hot by hop because you know maybe the network truly is being malicious.

D

So there is a padding hop by hop option. Yay pad 8, because we just chose eight so did 78 72 seem like a good one um again. This is null. Nothing should be happening so again, the network should just let it through right wrong.

D

99.5 again you, you really have to work hard to do that. You know if that was our objective. Some idiot would go. No, no, no, no I'd let it through, but it seems like the entire v6 world says now. We don't like this crap, because I've never seen such a consistent response.

D

Everyone drops hot by hot, that's brilliant 99.5.

D

So the issue is over time. The handling of fragment packets has gone from just unusually horribly toxicably, bad to yeah, pretty bad you're, still bad um more recent deployments show so basically better handling of fragmentation, header but hot by hop and extension. Headers ain't, nothing happening in the public internet infrastructure. So what lessons have we learned?

D

Don't fragment, don't rely on path, mtu discovery and don't rely on extension, headers and, interestingly, if you are going to fragment, don't just give a big first packet and a you know a trailing tiny if you're going to fragment, be decisive, make your first packet, small or smaller, go down to 1280, bytes or something and shove the rest in the trailing fragment.

D

If you usually do just big packet, small trailers, you have a much higher chance of losing everything so pick your mss settings and tcp carefully. If you're going to fragment, keep it low, keep it below 1400..

D

It's a good idea. The lessons learned on hot by hop extension, headers and destination, option extension headers, uh that's easy! Don't!

D

And if you want to see the current numbers, because this is working around about, um I think we're doing about six to seven million samples a day across the planet. um That qr code will take you to this url. This url generates a daily report and it actually looks at the state of fragmentation headers all the time, and I am done. Thank you back to you.

E

Excellent is, is it? Can you hear me jeff? Yes, I can jared hi excellent, yeah nice to see you. um So uh you know you covered it a little bit in the end, but I'm wondering how much of the v6 is because of the uh the mobile networks, specifically a lot of the mobile networks. Actually, uh they get tail circuits from different isps to backhaul, to the towers or from different carriers to back all to the towers, and often they have a. They have an mtu on those links.

E

That's less than 1500, even internally for v4, let alone for v6, and so you know, the 1280 kind of you know seems to seems to potentially explain that. But I'm curious, if you have a further sub breakdown of you know if it came from the mobile carriers, ip space, uh you know from the isp or if it's just from their generic ip. You.

D

Know you know every country treats mobile differently.

D

There are folk, like in my country uh that do mobile and wired all off the one address space, all of one piece of infrastructure, and, quite frankly, you can't tell if a mobile device is doing wi-fi tagging attachments into a home or if it's actually out there on the mobile network. uh Other countries are different.

D

The the basic observation is that these days, the bulk of eyeballs are behind mobile platforms. However, they attach- and that's just the reality of the world, so in some ways making that distinction between what's wide and what's mobile, it's getting less and less important when you realize that you know 90 of the users and probably 99 of the money, is actually behind mobile devices.

D

What you're trying to do- and I think you're right- is to delineate the ways of attachment into talking about the radio networks, as distinct from you know the wide feeder networks, the system that I use in ads finds that difficult to detect in general.

D

Now you could take the data that I've got here and apply specific knowledge to a carrier and kind of devise from that which is has which performance and you'd probably be right, but from where I sit, I find that very difficult to do. But you know it's a good question. Thank you.

C

Excellent, thank you very much jeff and for anyone it's.

D

A pleasure thanks for.

C

Anyone who tried the qr code that actually goes to v6 frags with an s on the end of it. If you remove the s the url works, apparently um no worries. Qr codes are complex.

C

um I don't understand how they work magic, so we have eric or justin, I'm not sure who's. Actually speaking, and if you happen to remember what the name there, we go that one.

C

And this is also going to be related to. um I can do slides for you or you can do uh oh crap, there's a clicker thing. I don't know the clicker thing's gone I'll. Do the slides here, okay or I can share it to you. uh Where are you? Where are you.

F

F

I don't see the request.

F

Why is it not showing up yep.

C

uh I don't actually know how I change the slides view, because I don't have a clicker when I see your slides, no you're not allowed such at the computer, they're very clear on that apparently left and right. Does it so never mind great? Is that not working.

G

Use this in the meantime, I.

C

Technology is hard, sorry folk. It's.

G

Better, all right so hi, everyone uh justin from julia and eric over there from cisco and today let me introduce you to james and I have to say that we are particularly proud of that name, because obviously it opens the doors to a lot of fans. But anyway,.

G

um Why did we come up with james?

G

um Actually, there is uh already rfc 7872, which was mentioned in uh previous talk, and actually we wanted to basically present new refreshed and more complete results, and you probably heard in six men that there is a hot topic about hop by hub options and the question is: are: are they usable or reliable, over the entire internet, and specifically, two drafts have recently been adopted, one to define processing procedures for buy-ups and the other one is more about sending and processing all actual extension headers and define some limits on it.

G

So obviously the the goal is to make them more widely adapted and make them progress the way they are supposed to do so. The question is what about other extension headers and that's where.

H

G

Enters the stage.

G

I

This is an overview of the topology.

B

G

We have vantage points in some parts of the world and, as you can see, we are still desperately searching for some vms uh in africa and somewhere in china or japan and somewhere in that zone.

G

So we have a lot of our vantage points in europe: three uh in america, north and one in south, one in australia, one in india and one in singapore.

G

And the methodology we have used uh no black magic here. This is a trace root like technique, even though this is uh or how in library but still trace, would like, and we just test each pair of vms, in both directions and for each experiment. You use udp and tcp, because you never know what filter you can have an error for and for the experiments. We have tested pop, buy up and destination options and we vary the size from 8 to 512.

G

We have also tested writing headers from type zero to six included. We have tested fragment, headers atomic, both atomic and non-atomic.

G

We have tested authentication, headers, no next editor or with ethernet, which is uh defined in rfc 8986, which is, I guess, if I remember well something about segment rotate for ipv6 and network programmability, and so for each experiment. The traffic we send the prop link we send is smart, as proposed in the draft here that you see in the slide.

G

So we have published this draft recently also and the idea is just to either insert an id or an address email or something in a payload somewhere in whatever layer allows to or easy technique that you know it's just to run a web server on the the address you are sending packets and uh just explain why you are sending such traffic, and so with this you have a view.

G

We will see that later of each result, uh so you can see that each routing editor, sorry extension, editor pass or don't pass, and we also try to attribute the drop for responsibility for slipper, hop and then obviously areas and that's where our programs come.

G

So problems first at top level because you have to probe as much as possible, but still you have to respect networks, so you don't have to introduce too much burden, but why do we have to test uh a lot? If you see the first illustration on top you see that the trace, the third hop did not respond.

G

Only the first and the second responded, so you could say: okay, maybe the third hop is responsible for a drop or maybe it did just not respond, and maybe this is the force or maybe it just not respond. That's all! It's the fifth that situates right, it's responsible for the drop and so illustration on the bottom.

G

You run the same experiment a few seconds after and then hope. Surprise you see that the force up did respond. So in that case you just can rule out the third cop from being responsible for the drop and so you're back to the same principle. Maybe if the fifth up is responsible for the drop or if you just not respond it's equation.

G

So if you run a lot of tests like that, you can just correlate them and try to have that zone as much as smallest as possible, and this is one of the challenge to attribute the drop to an as because you have to make that zone as small as possible, and the best case obviously is one right.

G

It might never happen but anyway- and you have also corner cases here,.

H

An example is that the ingredients, the s2, would be responsible for the drop, but the address of this interface is to stick on the first yeah. It was one way of using the drop through the first guest, by or in the trade you could have identified for nothing.

H

C

Does anybody have any double a batteries these died as well? I think I think the batteries died.

G

G

I'm alive so um second case. I needed identified our unidentified s number before and after the hop. So as I said, you might have or might not have identified some yes number between uh before and after the wrapping question, and so you might or might not identify your es here.

G

So the best case is that your interval spends only one es and problems come when your interval spans multiple, so more than two two or more asm next slide. Please.

G

So for the results of biops options, they are unreliable, so we have the same. uh We are agree with previous presentation: the destination options, obviously um size, 8 and 16. They pass so they go true, while once you reach 32, they become unreliable and so for a size. 32 93 percent was true. So it's not that bad, but it's still unrealable.

G

Once you come to 64, it's half that part or 42 percent, and it goes wrong with bigger sizes for the routine headers types 0 and 4. They are unreliable again, unreliable, but still good, so 81 percent and 69 percent pass. But here type 0 is deprecated and type. 4 is segment rating. So no big, surprise here and types, one, two, three four five and six sorry uh they go true for fragmentators atomic fragment adders are unreliable. We have 70 percent that go through and for non-atomic fragmentators.

G

They all go through authentication, headers, no next editor or ethernet they go through, and so that's the results part, but we also try, as I said, to attribute drop for uh per aes, and so this is still a work in progress. So I won't go too much into details here and show results because they are still not that stable.

G

So you can. You can have a look at the draft for more details next slide. Please.

G

About the next steps, so we have set up an operator survey. So if you are an operator uh and watching this, please just have a look. Click on this and fill in the form that will greatly help us and we could correlate what we observed with your data and we keep privacy all right.

G

We also plan to extend the topology. So, as I said uh earlier, we are trying to find some vm somewhere in china or africa, and we also plan to use uh a probing to destinations. We don't necessarily own so, for instance, based on bgp, prefixes or our excerpt of domains, and we also try to improve the drop responsibility. Attribution algorithm for super hop so reduce that interval as much as possible and then per es, and one possibility here is to use vdr map.

G

I t especially for the case uh with the link between two asses next slide.

G

So thank you very much um feel free to have a look at this repo, where we gather all scripts to generate props packets and uh results uh from james.

G

I guess I will take questions now.

B

Hi, oh, it works really good information. The most alarming to me was your last slide. If you want to bring it up, if I saw it right when it gets up to one, I guess next to the last um 12 at 128, you're losing 95 percent and at 32 basically you're getting through about that same amount. Do we know why that size makes such a big difference, and is it a problem we can address so.

G

Your for what extension error.

B

It says doh there. I think if I'm, if I'm reading your slide,.

G

Obviously, it becomes uh bad um because probably routers have some predefined sizes and you are pushing layer four too far away. So maybe there are.

B

Is it? Is it an issue with asics chips or have we not drilled down? Are the routers logging this or I don't know how much detailed information you collected to come up with that? But it's alarming.

G

Yeah yeah, but about details not that much because um all we have is the response from the rulers, and so all we can do is assume something so.

B

I'll ask you know a leading question is: is there going to be a follow-through to drill down to find out why and see if we can do anything yeah.

C

B

Sure, okay, cool and then I'm happy. Okay! Thank you. This is really good.

C

I mean I'll, stick myself in the queue as well. It seems a fair bit of this is likely stuff like where you only ship, the first part of the packet to the forwarding engine like many routers, do or we have a jeff who's interested yeah. So it's.

I

My understanding, anytime, you've got ecmp or you try to launch. You need to look at transport layer to create five double, and this is where the difference comes in. You cannot reach this information.

I

You have to option, you don't launch arrow, you drop and some do drop.

C

And we have a jeff haas in the queue go ahead. Jeff.

J

Thank you warren. Can you hear me yep? Thank you. So uh this is the point where we sort of wind back through multiple presentations on ipv6, that's been given over the years. People's routers are built out of systems that have limited windows into the packet now for fast forwarding.

J

The problem that ipv6 has always had with its headers is basically a stack of tlvs of varying size.

J

It means you're asking something: that's expected to do very fast work to throw windows around for fast look-ups in a rather unpredictable fashion, and the consequences that many routers, except for trivial patterns of known options, simply don't bother to try to actually figure out what window it needs to get this information out of there, such as the information that jeff tansura mentioned now as things move around, and then you are limiting the options for the routers, basically do a static template to look at the fields to do fast, lookups.

J

So this is exactly the predictions that had been made years ago and are suffering from them. Thank you.

C

Thank you very much. Thank you very much. I think that this one worked nicely as a follow-on from the previous one, and now we have something completely different, which is ignis on what would happen to a wrap server if bgp sek was deployed end to end today, and hopefully, ignis can help me find his slide set yeah, just which one is. It called.

C

C

And does it have usbc?

C

That's the problem with it. I've got a clicker, but my machine doesn't have a usb port, so you can push the button if you'd like on my laptop or or you can shop next. Well, I will shout out hello.

K

C

One sec: does anybody have a usb a to usb-c converter handy that I would trust plugging into my laptop actually never mind, never mind.

K

Right uh one presentation on three titles: uh it's uh some experiments and uh well experimentation with trying to implement bgp sec and see how that might perform the more or less real world and uh how the uh rosy and needle world of protocol engineering shatters around into the harsh reality of software and hardware engineering, and also the third one and then specifically for yob, uh which mentions the route server, because otherwise he wouldn't pay attention to me. uh So now I feel happy next slide. Please.

K

ah It's over here so bgp sec in theory. uh That's a really simple uh idea. We do some. uh We add some cryptographical verification into the asp so uh sign of what we are advertising and verify what we receive from our neighbors uh signature is comprised of three elements: the actual fragments of the path, uh the identifier of uh the neighbor to whom we are sending out and the prefix itself well do some calculation and then do some other calculation to verify that next slide. Please.

K

If we, if we'll try to characterize uh the scalability parameters for that, uh there are multiple dimensions which are relevant in uh real uh deployments, so amount of prefixes and the distribution of prefixes to the as paths and there's this space where things can be optimized here, uh the what is called the fan out ratio, the amount of the same uh as part of information signed as part of information that you distribute to your outgoing neighbors and how many of those receive exactly the same as power and there's also caching.

K

So if we look at the practical uh bgp implementations, they they cache attributes in one or the other way.

K

As with bgp sec, the size of the attribute is slightly larger than uh than for say other uh types of bgp attributes. Therefore, um we'd really like to try to cache the things and um let's see how uh bgp sec as the protocol is friendly with that next slide. Please, if we look at the platform specifics uh so in itf, uh it's a spherical bgp, which runs in a vacuum.

K

But uh if we look into the field, it runs on specific platforms and those platforms uh have uh specific and a real world uh say: restrictions and limitations to the performance and most the main one is memory bandwidth and memory latency.

K

While in theory you can have a lot in reality, uh the latency limits. uh What practical amount of memory operations you can achieve, and uh also looking into the developments in the compute platform processors themselves, the scalar processing performance is increasing in a low single digit percent across the generations, and the main increase in compute performance is in making those operations wider. So single instruction, multiple data or in general vectorization, where you have one instruction which operates on multiple parallel streams of data.

K

From a cryptographical point of view, signature validation can be optimized uh in certain environments like uh validating the signatures, which are generated from the same private key might be optimized to a level, uh that's also more of a domain of the software implementation and less so of the protocol engineering. But that also needs to be taken into the account and the protocol should not actively preclude that.

K

And if we look into the developments of the compute platforms as such.

K

The increase in the possible compute performance comes from executing multiple parallel instructions and having wider uh data paths so to say an equivalent uh or in uh well in a more more simpler form. It's a with a wider vectorization. Next slide, please.

K

So if we look in bgp second practice, how does that look from a data structure perspective and how does that? Look from avaya image perspective from algorithms for hash, so first thing uh the long message that they has path with the crypto, all sorts of cryptographical uh keys uh segments and and other uh identifiers.

K

It's compressed uh via sha, two hash function into 32, bytes and then those 32 bytes are used as an input into the signature generation both of these processors. They are vectorizable so themselves. They don't have any preclusion for making them in parallel, and this is more of a domain of the software engineering characterization. If we are talking about the contemporary intel arm, platforms has been around for a decade and, yes, we still have problems in in the industry. Overall, um uh there are problems of compilers.

K

There are problems with uh overall software engineering community awareness to that. uh This is slowly but gradually improving, and this is a basically a free tool that you need to use.

K

Speaking of hashing that operates on fixed blocks, so blocked by itself is atomic. If you compute the block, uh you can continue the next block, starting from the same intermediate state that you got previously. Therefore, this opens opportunities for caching, hash calculation for certain data, uh signature, calculation and verification. Those are computationally expensive, but it doesn't touch memory.

K

While you have to do more arithmetic operations on on a large integers, you can do that, mostly as your uh underlying platform can allow, whereas for hashing you are limited by the memory bandwidth and there are certain ways that you can walk around, but uh the general trend is that the longer your as path get your the longer your bgp sec path gets the more time you will spend on calculating the hash value than on calculating or validating the signature?

K

uh And this there's a small illustration in the numbers. uh So uh in the current specification it's 100 bytes uh per gps.

K

But, however, there are some alarming uh specifics here. uh The signature itself is the signature. Block itself is built from two parts, and those parts are six and 94 bytes and six is not the power of two and that just falls into a direct conflict with uh what the uh any practical vectorization platform can support. It's either four or eight.

K

If you want to uh squeeze in six there it's possible, but uh you will lose far more than you would gain uh in in trying to vectorize that next slide, please uh looking into how that works into into the characterization and where the saving can come. So uh on the top horizontally. You have the incoming message for which the hash needs to be calculated and bgp sec is recursive. uh You need to do that, uh validation for each and every uh intermediate intermediate hop.

K

Therefore, what you do if your platform allows for a gather, efficient, gather or or indexed load operation, you simply point out the offsets from which to take uh the data, and then uh this is a middle middle, green part and the time flows from top to bottom.

K

uh You uh calculate in parallel, for example, for eight or sixteen lanes. uh That's one instruction and uh eight or sixteen instances of separate data within the latency of the longest block. You have a multitude of uh bandwidth, so uh it's a little bit slower than the scalar version, because well you don't have branching some some uh implementations don't support a rotation which is needed for uh shattu. Therefore, you need to implement that yourself by multiple shifts here and there and then combining the result.

K

uh Overall, it's it's around additional 20 percent of latency, but this gives you uh roughly 15 times the overall throughput performance.

K

Therefore, if your implementation allows, you can easily talk about the order of magnitude, speed up for signature generation and validation and then the yellow part is, is the actual key generation or uh signing or or validation path? The same same rules apply. uh You have multiple entities being processed in parallel, even if the key actual key length is a little bit different by a few bits. Oh this is this is purely an implementation aspect of how you can do that efficiently.

K

So uh the outcome of this, you can get substantial increase in performance if your data structures uh allow for that next slide. Please, and here we are coming to the second problem of uh or second real life aspect of bgp sec on the top, you see the wire image and in bgp sec attribute. uh First, you have an array of path elements.

K

Then you have an array of signatures where, for uh the specification itself asks for the hash to be calculated in sequences, so you have path, signature path, signature path, signature, and that means that for for that incoming attribute, which you received, you first need to copy it around then calculate the hash and signature and then copy it back again into the format which will eventually will go on to the buyer, uh touching the memory and copying the memory. Yes, you you have caching system, uh you have uh automatic automatic uh prefetch there.

K

It works if your algorithm is friendly to that. But if you are reaching up more than one or two cache line forward, the backward uh in general, this algorithm cannot cope up with that and you you start to lose uh latency, basically for nothing, uh signature, generation and verification. Well, they are, they are computationally intensive, but overall, that's not the main problem.

K

The main problem is that, in order to have the hash over which which to sign and and which to validate, you need to spend really excessive amount of time, just because protocol is not necessary friendly next slide. Please.

K

The experiments so what what has been experimented with? uh Let's take the realistic, real world distribution of uh prefixes prefix to us path ratios uh the fan out, ratios um and, and the overall uh setup was that it's 24 hours of gdp updates taken from multiple public sources that is past different uh asp.

K

Only as path attributes taken out. uh It's on the order of 75 000 different ass. The assumption is made that one is equals one route, therefore, there's uh one pair one pair of keys, generated per ais.

K

All that is precomputed in advance, then all is fed by rtr into the device under the test, uh then, based on that incoming data. uh Well, bgp sessions are kind of brought up, and all of that is replayed into the device under the test and device under the test feeds everything back with the fan out ratio of 90 uh to a receiver.

K

The summary outcome of that it works. um It actually takes four specific particular implementation in a particular environment. On a particular platform, it took 34 minutes for this to converge uh from the start to the beginning from start to end, comparing that to the plane, bgp without bgp sec, that's one minute, 20 seconds and uh well.

K

I think we can live in certain, uh at least in the beginning of of of deployment or instead well, in certain engineered aspects of network design. We can live with half an hour of the initial convergence if you don't need to bootstrap the whole of a network all the time from the beginning, but if we can do something better, maybe we could next slide please.

K

So if we try to look uh into into the whole uh kind of the situation around bgb sec so is, is it really broken um from a security point of view? Now everything works fine, but it's not very much practically usable as it is today and now two two main problems uh if we are looking at the layout of the data, vgp6 also signs uh the destination asm, for which we are advertising that prefix.

K

The problem is that that s number is in the very beginning of the field over which the hash is being calculated.

K

That means that if we are spreading out the same as path to say a large number 100 as an example of of neighbors, we need to recalculate the hash 100 times.

K

If we move that field, for example to the end, that means that we can calculate it once in pre-cash for uh majority, for for the majority of the blocks, and only recalculate one or two remaining blocks, which also are changing with each prefix, uh the longer the s path gets uh the the higher the savings from that are.

K

The second problematic aspect is the actual wire image uh we have uh data layout on the wire and data layout that is being processed uh really incompatible, and that means that you need to receive something reshuffle. Do the thing then reshuffle again and send it out? This can easily be avoided next slide, please!

K

So what can we do about that? uh Let's look at the reality. Bgp sec is uh well at least at least the current specification version zero. uh It doesn't have real practical deployments. Well, there are some experiments, uh there are some experimental implementations, but there are no uh significant or substantial deployments.

K

The protocol itself is versioned and it has certain hooks for extensibility.

K

um Therefore, we we practically can talk about trying to extend or fix certain things uh doing a new version and then uh within bgp sec there is a mechanism which allows for uh algorithm change the uh that mechanism right now identifies only the algorithms themselves, so it's chat two and and prime 256.

K

It doesn't say anything about a format over which it operates. One of the possible ways for another version of bgp circuit would be to extend this algorithm identifier to cover the format over of the data or which is being processed and whether that's the same meaning of the identifier or separate. That's, I think, an open question for a discussion and also uh the wire image asks for uh changes to make it uh simply friendly to the implementation talking back about the experiments so those 34 minutes.

K

If, if these couple of changes are implemented, they uh converge into something closer to four minutes, uh which is probably a rather substantial uh reduction in in the overall load. uh Next slide, please.

K

So that's a summary again uh that you have uh the hashing and the signature part uh spread around over a set of different uh elements which are scattered around and uh that's not very friendly to the implementation aspects.

K

So next slide. Please.

K

uh Discussion, do we care about this and we should probably keep it short.

L

Okay, so um kiriti um I, this is my first iepg meeting and I came to listen to inyas, so thank you. It was worth it. um I want to pop up a level um if you go to slide eight um he talks about. um You know we should take the specifics of the compute platform.

C

One two three four.

L

Yeah, it's down in the corner, not.

C

On the screen, it's not one more there. We.

L

Go now I can see him so um take protocol engineering needs to take software and hardware specifics into account seriously. I think there's something we need to do in the ietf, not just here we're talking about changes to mpls, yes, and we need to do this, but the word specifics bothers me. I think there are principles, for example, the last thing you said about take the as number and put it at the end in front of the beginning.

L

I have no clue what you were talking about, but that seems to be a change that is independent of specifics, and so we need to really look at.

L

How can we improve whether it's wire rate I mean wire formats or or um processing in in the forwarding path? We need to look at higher level things and say: can we do this in a way that you know we are taking those into account? We can't say this works well on this particular platform or works very well on this broadcom chip, but I think we still need to do more than we are doing today in terms of oh this, this looks like a nice wire format.

L

Let's go with it and then we get 34 minutes of.

K

Yes, so quickly, this, this is basically uh in a context that vectorization is a commodity. Functionality on the compute platforms today has been for more or less plus decades. uh Take exact 86 take arm, take risk five. Those are the three generic purpose platforms which are relevant in the industry. They all have that in one of the other usable shape or we'll have.

C

And I'm cutting the mic line and if we can keep the question short.

M

Job sniders. Lastly, you asked whether uh people care um I would like to raise my hands. I think it is interesting that you observe that, from a security perspective, it's okay and I think that stems from the fact that there is not much to take away. It's the most minimal thing that we could do at global skill, signing prefix path and target the suggestions you make to reshuffle the layouts, it's probably not too late and there's another interesting, mitigating uh aspect of deployment in the real world that might be underappreciated.

M

I suspect that beach pseg is used on bgp sessions that are most valuable, that have the highest local preference, are shuffling the most bits over the wire and have the least btp state. If I look at my employer's network, the most important links have are not the links towards full tables.

M

So from that perspective, I am slightly optimistic that there is a lot of value in working to deploy phpsec in its current version and in parallel work to optimize the current version based on research as what you presented just now or other operational observations, and that there is some leeway in in how the deployment actually happens.

M

So, if I compare say route, origin validation, I think most values stemmed from the fact that the core of the default three zones started. First, the so-called tier ones, but I suspect, hp6 value comes from deploying at the fringes of the network, say cash boxes embedded in to people's network.

M

But thank you for sharing this.

I

And justin sierra. So thanks for doing the research, it's very timely, so the situation is two weeks ago fcc, at least in the u.s realm, asked us how come you haven't deployed bgp yesterday? How come we are so insecure?

I

Probably people live in the us. You have seen two weeks ago, fcc published kind of requests for information about bgp security. So when I go to to him and ask where's bgp security, he says you need to buy new hardware, even so whatever I buy today brings at least broad volvo broadwell class intel right.

I

So I know every vendor has implemented, live beta code, gdbgb security. So whatever I found it's not a secret, it's basic software engineering.

I

Can we create some kind of design team here to take this actually seriously bring him back into implementation and get something working? Please don't leave this presentation here, bring it here inside the ropes or somewhere.

K

So this is on the agenda for side drops in a slightly different message, probably now for practical deployment of bgp sec, there are two parts bgp set the protocol and the under supporting infrastructure of bgp sec, and uh the second problem is probably harder.

K

Well, at least it seems now right, uh so it's not enough to have a perfect protocol uh which is not conflicting uh with with uh the platform specifics. You also need other things around and yes, there's quite a large amount of work.

K

We need to start.

C

Yep somewhere, but I think we need to cut the mic for now and we can maybe carry out the discussion inside cool. Thank you very much just for time. Lenny.

N

C

Me just find your slides okay, this one promises to be entertaining slides here we go share and I will grant you the ability to change slides. You have 10 minutes and we will start them now. Thank you.

N

Thank you, um so I'm going to talk uh today about uh a recent draft that we submitted uh on regional internet blocking. um We are presenting this in the interior and plan to uh see if there's interest there to adopt um uh before we get started. Just a few uh disclaimers. um The the content in this draft represents ideas solely of the authors and does not reflect any of the positions uh or views necessarily of any of our uh affiliations.

N

um Likewise, this kind of goes without saying uh for those familiar with iepf processes, but for those who aren't um this is an.

B

N

Contribution and does not represent ieff consensus all right. We got that out of the way now for some of the fun. um So the first question is: you know a little bit of background and motivation on why uh we wrote this um this draft.

N

um In light of recent geopolitical events, um there has been discussions in various circles, uh both technically and non-technically, politically, um on the concept of, inter of blocking internet connectivity uh for a region, um kind of the internet version of uh economic sanctions or connectivity.

N

um So what we wanted to do is to describe well what would that look like um what would be some of the ways in which this kind of blocking could be accomplished and what are the implications? um Positive negative? What are the advantages disadvantages? What are the potential uh consequences um intended and uh unintended? um The.

B

N

Audience uh the target audience for this document uh is policymakers, um as well as the general public. Basically, everybody who's, not in the room right now or in this.

B

N

But is interested in uh understanding what we who are in the room, um kind of have as common knowledge uh on the topic of uh filtering blocking, um and you know what it would look like and the kinds of considerations uh one should know about um if one wanted to block connectivity for a region.

N

The idea here is that um policymakers do depend on good, unbiased information, um sober uh clear technical uh information on you know what is possible, how it works, and would it actually do anything? um So that's kind of the idea behind this um is to discuss. You know the potential intended or unintended consequences in terms of what this document is not um we are not advocating for or against any particular policy uh or position. um We are not trying to inject political opinion as to whether or not this is or is not a good idea.

N

We're just trying to really. You know report the news. This is how it would work. um This is some of the things it might do uh so that you know people who do want to make it an opinion um on these things could make. uh You know perhaps a better informed opinion on the matter.

N

um We're not uh analyzing the ethics of such an approach. uh We also. Obviously there is a you know, an ongoing um conflict right now that inspired uh the writing of this draft, but we would like this to be generic enough, that it is applicable to more than just one episode. um This is probably not the last conflict, that's going to occur where this topic might pop up. um So hopefully this could be useful um both now and in the future.

N

um Also, uh it's it's. This is not meant to be a blind, a guide on how blocking works or what is blocking um uh or protection against security threats. um Let's say that there was threats coming out of a region, uh and you need to protect yourself from that region. um This is.

B

More of you know.

N

Sanction purposes um we're not trying to also describe you, know kind of a how-to guide on weaponizing the internet. um We have we're not letting out any secrets. um This is uh pretty well-known approaches and you'll see. um You know nothing groundbreaking here. These are. These are pretty well known, approaches that operators use um fairly commonly uh for for legitimate blocking purposes.

N

We also didn't go into a malicious attack, approaches and kind of a survey of those. That's an interesting topic. uh It's probably you know worth worth discussion, um but uh you know that's such a broad topic and it's outside the uh the the scope and the um expertise of the authors. So we um we left that outside just over this document, all right, so the meat of the document. What's actually in this document um we start at the physical layer and work our way up, um so um you know again nothing groundbreaking here.

N

uh You know what would happen if you disconnected cables um uh and then we move on to the routing control point um what it would look like to deep hear someone uh what we would be the results of that um there's route token based on prefix or asn.

N

um There's a data plane filtering, go ip access control list uh and then we looked at dns. You know what it would look like to uh you know. Some some approaches might be removing delegations to plbs and.

B

N

Relevant uh domains um also blocking resolution requests that might be coming from a resolving name server or um in hosts uh that might be in a region. um The next area we examined was all right, that's inefficiency! Would this actually work? What would this do? um Some of the intended and unintended consequences?

N

um So there's the obvious you know blocking connectivity for a region may be counterproductive to the aims of a policymaker.

N

um So you know perhaps a policymaker might want messages to actually get in and out of the region and blocking that connectivity might might prevent that um they may want uh perhaps certain parties within a region to be able to communicate freely, um because those uh say oppositional parties might be sympathetic uh to the views of the policymaker.

N

So again, you know might be some might be a reason you know uh to be aware of that. You know this might not happen. If, uh if you do block connectivity um also, it may end up empowering um you know a party that is, you know the target of sanctions allowing them to uh that. You know party to or regime to perhaps consolidate their power by um not being able to uh allow um some of the information that we just got mentioned to to go in or out or within a region.

N

uh The thing to keep in mind is a network uh is a moral it does not uh discriminate between uh it. Just transmit fits whether they're, good or bad, uh whether they comprise good or bad messaging, um but the network just pushes them. You know from one place to another.

N

um Also uh autonomous systems and prefixes are not allocated based on geopolitical boundaries. um They're loosely uh allocated uh on region- um and there are registries uh about those registers. They are registered information um and you know, can be fairly accurate. um Also, things can change uh an entity that has assigned a a resource like an asm or a prefix uh that exists within one region while it might move to.

N

Another region will be acquired by a multinational corporation that you know multinational entity that might start advertising uh that route or that asm in a different region. um So it's really kind of difficult, there's tourist borders um when it comes to um network um resource allocation.

N

um Also, you know the internet is by design decentralized, um and that makes it you know nearly impossible to completely uh block a region. That's that's a feature, not above bug of the system, um but uh you can put a good dent in in connectivity and throughput um it's at certain checkpoints.

N

uh There has been some um you know: prior art in the area, rfc 7754 um talks about uh internet service blocking and filtering, but it's more focused on um application level uh and transport than actual network infrastructure. um Also, the purposes are a bit different. um It's more like you know, security, objectionability and business arrangements uh and less so about sanctioning.

N

um But there are some overlapping themes. um uh There's a draft in the pea, rg working group on censorship um and again this is more focused on censorship by a regime within their borders, rather than blocking their region stuff coming out for the purpose of sanctions.

N

Sure, uh just finishing up um so uh you know, like I said we're gonna be presenting this in interior. uh Looking for adoption, um you know first question we'll ask: is this document useful? Is this interesting? Is it worth working on? um Are there other things we missed? um uh You know the question of gcp versus informational and um review and comments, um and you know if you have produce to throw um shop at interior.

N

With that I'd be happy to answer any questions. If there is time available or if there are any questions available.

C

Excellent, I guess more questions will happen in an because I'm suspecting there will be some. um Thank you very much honey and yep. If you want one quick question, make it really short.

O

uh Quite obviously, any idea of blocking is in conflict with the ietf goal of making the internet work better.

O

Figuring out exactly good information about the effects of blocking quite obviously makes a lot of sense. In this context, talking about blocking, uh however, can be can can trigger with certain parties the idea that well, okay, they should actually uh think about it and myself. I have noticed over the past years couple of events were parties were starting to think about sovereign internets.

O

And kind of part of that quite obvious, he has been motivated by preparing against the threat of being blocked in some way and regardless.

O

Whether a technical paper explains in detail, the bad effects of of blockage and in the end uh suggests that blockage should be avoided.

O

The mere existence of such papers can be used by parties who are interested in segmenting and well. Okay, maybe uh reinforce their empire of life.

O

So one has to be extremely cautious when doing such papers uh to to figure out ways and that these ways need to be extremely clever to avoid feeding that evil that evil track of arguments. Thank you.

O

N

um Of all fair points- and um you know we're we're not trying again we're not trying to say this is good, or this is bad, we're just trying to say this is what would happen uh to the best of our ability. If one did this uh to, let others decide if this is good or bad, and we, like, I said I don't think we have any trade secrets or network secrets here, um there's really nothing novel here. This is pretty pedestrian uh descriptions of what is going on.

N

So I don't think we'd be planting any ideas in anybody's mind, but thank you for that feedback.

C

Thank you. Okay and yes,.

P

So this presentation is about my efforts in setting up a useful rpi beacon, useful for measuring route, origin validation and also hopefully useful for you.

P

I was searching on the internet for a picture of a lighthouse or a beacon that would lure ships towards it and a vortex in front of it, and you can see that I found a picture like that, and this is a picture of the excellent rock album the milestone ascendant, which also has a accompanying book and of the sydney based rock artist duncan schmidt.

P

By saying this, I have his permission to use this picture. So thank you. Next slide.

P

So I also made a good effort to get this presentation here at the ipg I submitted three times or so I think, and because you know I had to set up our rpi beacon. I will tell you later why but I'm not really an rpi expert, because I know that you all are all rpki experts. So that's a really.

B

P

Audience and I'm also a little bit nervous because you are all rpgi experts, uh but yeah, I'm I'm hoping to make some rpi beacon friends here that can help me. uh You know with this effort and tell me if what I'm doing makes sense and how to make it better and how to make it more useful and yeah. Well, I will tell you later, but I could also use some additional ipv4 resources for some specific aspects of this beacon next slide, so you here, I do sometimes do dns measurements.

P

Here you see a picture with me at the taken at the internet measurement conference in 2019 in amsterdam, we were awarded for a research paper on the root case, cable offer, and during that conference there was just the hijack of the ethereum wallet and that was by a route hijack, but the authoritative surface of route, 53.

B

P

Hijacked and the resolvers were not protected by router region validation, so it was clear to us that it's important that we would do this these measurements as well, and we learned at this conference that there was a person called job schneider.

P

We had the rpi beacon and we spoke to him and asked him if he could use his beacon to do this kind of measurements, and europe allowed that and thank you yup for that. This was really great and we started to do the measurements to measure the uptake of router region, validation of dns resolvers since 2020, but unfortunately, the the beacon didn't stay for a very long time or it stayed for almost two years, but we had to look for another beacon, so yeah.

P

That's the reason for this effort next slide, please, and at the beacon at the time, was the ripe ncc web test. It was the check my dns effort from the dns org, our own validation measurements. Next slide.

P

And the beacon was set up, it had enveloped prefixes announced from the beacon and also valid prefixes for refrence next slide.

P

So the effects of this setup were a bit like this.

P

So if you would be on a validating hop, then it you would not enter up at the beacon and also if you would have been, if you would be on a infillet or not validating hall but surrounding by validating hops, then you would also not end up at the beacon. The next slide.

P

So this was gave some difficulties with doing the measurements in that it was timer based now, if you can reach the valid, but you cannot reach the invalid, then you have to wait for that time out and also about an original validation is to prevent wild hijacks, and so since the invalid prefixes were not announced anywhere else. Validly, you could ask yourself if it was a yeah. It looked like a realistic route. Hijack next slide.

P

So for the new beacon we did it a little bit differently.

P

We announced a slash, 23, less specific, from amazon to be precise in a invalid, slash 24 from that less specific from color glue, which is really convenient because you don't have to wait for timeouts, and maybe it's also a bit more realistic, but maybe not maybe for the most realistic situation.

P

You would have two slash 24s next slide.

P

uh Yeah, so here you can see the uh robot, the route, origin, authorization for the slash 23 and just for the record. I also made one for this list 24, but with for a's and 0 to officially say this is invalid. Next slide.

P

But you know it's still really hard to determine which hop does the actual validation, and uh it also has the peculiar very validity that, if, if you are in a network that is validating this big, you can might still reach the invalids.

P

And why is this next slide?.

P

Because on the path towards the less specific, the lighthouse should say, you might bump into a non-validating hop which is luring you into the vortex next slide.

P

So taking the picture that I used before, it's all, the the white things close to the lighthouse are good, but if you know, if you're crossing a non-validating hop when you park towards the the lighthouse, then you end up at the beacon next slide.

P

Yeah well so all the apps that used the earlier beacon uh they are moved to uh the new beacon uh we. So it was really cool uh easy to do uh rpi test for revolvers, because you just went to authoritative surface one has a zone that says the way you you're protected at the affiliate and one says no you're not protected at the invalid next slide.

P

So at the invalid beacon at color clue, I also created a ripe atlas software probe, which uses the invalid resources and has the command but on a valid resource.

P

So people using vipe atlas can use the beacon as well next slide.

P

The beacon is also at the end of ring. If you are only an unlocked, ring and you're a secure shell to the enameled lobs ring note, then you will see this text that you can enter a network namespace with the invalid resources, but with the command enter invalid net ns next slides- and this is how it works. You can see.

P

So if you secure shell there, then initially it just uses valid resources. You can ping the website of the itf and after entering the invalid network named namespace, you cannot, but you can. It still does work because you can bring in laptops, for example, next slide.

P

So this can be used to measure other things as well like, for example, authoritative servers, but the question is: should services be protected by about a region? Validation because they're not actually connecting to other servers on the internet next slide.

P

So this is it, so does it make sense? Is this a good way to do it?

P

What to which you need to do it, and how can I make it better.

P

So if there are any questions, I'm.

C

In the queue, so I will 18 17 16 15 14 13 12.. There we go um so 12.. I think that's the one. So this is a good point. If you go anywhere where you know the net, you pass through a validating network which then takes you to a non-validating network.

C

You still end up at the bad place, but maybe that's actually the correct thing to be showing because, like that's what would happen in the real world, so I don't know if the right thing to answer is that you're protected or not, because the network you're using happens to validation, but you still end up in a sad place. So I don't know the right thing is anyway. We have three minutes left, so I will help you.

Q

um Is this yeah? It is on um ben work online. um I said that that's an important uh observation and I think the reason it's important is because I I I was struggling for most of your your talk to identify exactly what you're trying to measure, um and if I understood correctly, what you're trying to understand is the extent to which dns resolvers are susceptible to following a route to a hijacked, authoritative, dns server. That's fundamentally what you're trying to measure initially?

Q

Yes, okay, so I think that I think, in order to work out what you need in the way of a beacon, you need to be concentrating on what the most likely attack against that um traffic exchanges, and I don't think that it's a more specific hijack. I think in most cases, most people that are operating, dns, um authoritative, dns servers are already announcing 20 forces for v4.

Q

In order to you know in in order to to mitigate the possibility of people being able to, you know, sneak longer non-rpki related announcements into the routing table, so I think the most likely attack is someone spoofing.

Q

The origin and the the the difficult bit to affect to defend against is the fact that you're then relying on a s path, length for selecting the the the correct uh the the correct destination, um and that will show a pattern, that's similar to the one in your in your map, but will be more pronounced, you'll get more resolvers going to the wrong to the wrong destination.

Q

um So that's that's! That's what I would be trying to mimic. If I was you for that measurement.

P

Yeah yeah, it's it's uh it's indeed it's that, but it's also trying to identify which hops are doing, validation.

Q

If you're, if the question or answer, if you, if you're trying to tell the operator of a recursive dns server, are you likely to be seeing safe results or not? I mean that's a binary question, the the? Why is interesting, but it's.

B

Q

It's not as important as the yes or the note right. um The only other observation I had is your your air. Zero rower is redundant. It's not doing anything.

P

Otherwise, yeah it's just for administration.

C

Thank you and jeff you're up next and let's keep it short.

C

Film there's still one more okay.

D

I'm trying to unmute my audio. Thank you. The problem is villain that the more transits deploy the harder it is to reach your beacon, and if you have only one beacon, that's you kind of die well before it sort of ceases to be useful, because deployment in transit tends to make this weird.

D

We started off in our work with one beacon we increased it to four in any cast, and then we started to glom onto cloud players, because in actual fact, it really depends on what you're trying to measure and what you're trying to measure depends on what you're trying to prove.

D

Oddly enough, everyone must do without origin. Validation is actually not that useful.

D

We can get 95 percent of the result, if, let's say fixed transit networks do validation and no one else does, because if paths go through a small amount of the core and the core is doing a validation dropping it actually doesn't matter what the stubs do and this interplay between deployment right and filtering. This actually hasn't been studied at all in the areas of rpki we've adopted. The mantra of everyone must do it and that mantra is meaningless.

D

It creates a whole bunch of wasted effort with only marginal return. If everybody else does rov filtering, I don't have to, and you can actually extrapolate that statement outward. What's the minimal spanning set for rov filtering for the maximal benefit and that statement hasn't actually been studied hard. The problem is, in a nutshell, single beacons.

D

Don't make much sense anymore because, as we progressively deploy, they become progressively unreachable because of transit, not because of rop filtering, and so you really need to rethink exactly how you do this to make the beacon useful if you want to trace it back to the source. Thank you.

L

P

C

Great, thank you very much. Sorry we're out of time last. One on the agenda is the center tony, and I will give you slide privileges. Let's make sure this works, can you change the slides.

R

Thank you, excellent hi. This uh talk is a footnote on cider. Those of you who are of an age neighbors call what we decided a long time ago um started talking about aggregation and we started talking about doing continental and regional aggregation, but nothing really happened.

R

This talk is about talking, bringing that up again, not because I want people to start doing it, but I wanted to document some thoughts about how to do it before I end up retiring.

R

uh So, what's changed since we started doing cider, one thing: that's surprising is we've started leaking more specifics, all over the place for traffic engineering and that's caused a great deal of noise in the routing table. It would be really nice to clean these up and it would be very effective to clean these up at a distance because, frankly, once you're at a distance, the more specifics don't add a whole lot of value.

R

Frequently none.

R

We have a new idea on how to think about aggregation. I wanted to write this down before it gets lost and we talked a lot about proxy aggregation long ago. I'm going to bring up another idea which is doing unilateral, remote aggregation.

R

So in traditional aggregation we have a isp, he has a prefix p and he filters out all the more specifics and just distributes p everywhere.

R

What I'd like to talk about now is a new concept, an abstraction naming boundary and, and that's just the edge of the isp, where prefix p exists.

R

And another concept: we want to call an abstraction action boundary and here I'd like to give full credit to noel chiappa, who came up with this idea long ago, and it never got written down.

R

The basic idea is that you don't have to do aggregation right at the same place where the prefix actually exists.

R

You could do it several hops away, and in this picture you can see we're leaking more specifics outside of the abstraction naming boundary and then actually taking action and doing creating the abstraction farther out at the edges of the opal. This could be one two three as hops away.

R

What happens if you do this well suppose ispa is the owner of the abstraction and he's leaking more specifics. All over and ispb now does remote aggregation.

R

Well, the traffic is going to follow the more specifics, so ispb suddenly is going to see a bit less traffic he's still advertising p, so ispa is still being served, but traffic is naturally going to flow in the alternate directions.

R

Okay, if you do this, this is not necessarily a horrible thing, not necessarily a good thing where you do this inside of ispb. Actually, matters does ispb care about the traffic engineering. That ispa is advertising and it can, if it does it on ingress, it gets rid of some traffic. It gets rid of some routes that it's going to carry.

R

If ispd does the aggregation on egress, they still get the traffic engineering benefits, but has a few more routes to get right.

R

So could we do this to higher levels of aggregation.

R

So we have a bunch of regional aggregates, the rars have nice prefix blocks, slash 12s, for example, and could we remotely aggregate these, and if we do that, we take out all of those annoying traffic engineering? More specifics. We take out organizations that only exist within that rir's region.

R

Where is it we would put the abstraction action boundary, and this is something you have to look at in a case-by-case basis.

R

If you put it too close to the actual abstraction, too close to the region, you're going to break traffic engineering and if you go too far away, you're being wasteful because more specifics are transiting too far away- and this is a case where it'd be very, very useful- to have a little more field input so I'll. Throw that question out to you guys.

R

Just as a reminder, this is what our rir map looks like you'll notice things don't quite correspond to continental boundaries.

R

If you wanted to say, have a remote abstraction, bound abstraction action boundary around ripe, you might draw this line here, and this is a little bit farther away just so that gets the traffic engineering.

R

You could also do continental aggregation and I'm going to pick on jeff here. Okay, um intercontinental links are relatively rare comparatively, and so we very much want to traffic engineer those intercontinental links, but we do want to do.

R

We could put an abstraction boundary just on the other side of those intercontinental links. We would also kind of like it if the rirs would do continental addressing for us.

R

So you can imagine suppose we want to throw an abstraction of australia and we might put the abstraction action boundary several hops past the transoceanic links going to australia.

R

Okay, um yes, uh we know that there are some rpi, our pki issues, and we have to figure out how to do that with aggregation and that's something we have to work out.

R

Okay, so we'd love to hear what people think about this and whether this is useful and whether they're willing to try that in the field. Thank you any questions.

S

Yeah hi melini elkins uh inside products, okay, so just one anecdotal data point from somebody that I'm working with is a large organization in the united states. That has a global presence with probably people I mean all over the world, and we were talking to a particular rir and they said they would be willing to give them um address ranges for uh globally.

S

So I I I mean I don't know how this fits into your picture. If it does, or can you comment just just I mean I'm just I'm just saying just one data point, I'm just you know just I'm just wondering how it fits into your your picture here.

R

It doesn't fit in, um we know there are lots of organizations with global span that are injecting their prefixes from many many points, and those are not good candidates for aggregation. For obvious reasons.

E

Hi tony, it's jared. uh I am curious. What you're trying to optimize here? Are you trying to optimize the fib or the rib.

R

I'm trying to optimize both so call it rib.

E

Okay, yeah, because I I think there's I, I think it's very important to talk about the two separately, so the the first thing is that you know inside of my employer today we actually have uh a solution that we use to go and ensure that we don't. uh You know that traffic tends to be heavily regionalized.

E

uh When you talk about a global footprint, and so we don't have to, we may receive all the paths in you know our ribbon, but that doesn't mean that we actually need to carry all those. uh You know all those paths in the hardware. It's also possible that many of them have the same next hop and so that we can actually do localized. You know optimization. I know a number of vendors have done.

E

uh You know either internally fib compression work or otherwise to ensure that you know, even though the rib may have more in it. The fib, uh you know actually can run a lot leaner uh from that perspective. So so there have been many different. You know both software and hardware optimizations done there. I I think the the other thing just kind of looking at this just generically is.

E

I think this makes a lot of sense in a case where there's a lot of national, you know aggregators or international aggregators, but that's actually largely not the case anymore. If you're actually looking at the internet today and and jeff houston's, you know talked about this some in the past. It's largely how do I get to the largest n cloud or content providers within my region and almost no other traffic. uh You know, there's there's not a lot of long distance traffic. uh You know in that regard anymore.

E

If you look at what enterprises are doing, they're largely integrating into one of the cloud operators but uh and purchasing direct interconnects for on-ramp off-ramp activities, and so the need to do this.

E

There's a very interesting question you know around this is: how much is this actually really needed per se and at the same time I also want to comment. Is that I know my employer is really bad about polluting the route table and we're trying to I'm working hard to try and address that, um because we largely had a lot of things globally that were very unique, discrete sites and over time. My long-term goal is to continue to advertise out those local, more specific routes to ensure that we attract the traffic in the right locations.

E

But globally not everybody needs to see those routes, and so we don't need to advertise those all globally, which may end up with much wider divergence in what a local versus global table looks like, uh but that is heavily optimized around the locations that need to get the routes, and so I think that this is, you know just looking at this at a high level.

E

I think the idea of where these aggregation points are is is very interesting because I think they're not where we would have thought they were. You know 25 years ago.

E

So I don't know if you have any comments or responses to that, but I think at least at minimum, the fib optimization seems an area of potential interest.

R

uh Yes, fib optimization is of interest. We talked about that and some people have implemented that we still have lots of people who are having scalability issues at the rib level. So I'm very much more interested in trying to address that.

R

Yes, I'm well aware that traffic is orthogonal to routes. That's fine! I'm still trying to optimize routes.

R

O

Right hi tony.

O

Simple question: are you thinking about any cooperation of the owners of address space or roots.

R

Well, of course, cooperation is always welcome if people want to be aggregated remotely. That would be a very interesting proposal.

O

But well, okay in general, you are not expecting that as a basis for moving forward.

R

uh No, I don't think that's a requirement and I would be very interested in seeing what happens in the field experience both with and without the cooperation.

O

Kind of uh with my simple mind, I feel that kind of, without cooperation, uh the current existing universe does not really is not really expected to get get a solution uh in your direction.

O

uh But uh well, okay, you smart! You! You, smart guy, uh might have ideas of uh what to do: actu, well, okay, what what concepts to use in signaling and so on for uh getting getting cooperation information into this.

R

Well again, I don't think cooperation is required. I don't think you actually break anything if you don't have cooperation and you just go off and do remote aggregation as long as you're advertising the aggregate you are continuing to provide connectivity, um but you are shifting traffic away. I realized that alone could be contractually a problem, so people should think about that, but I don't see that it actually breaks anything.

I

Just consider maybe just a data point, at least my employer. We already have a service, that's intermediate between internal bgp, speaker or external appearing. We already have the slurs that does aggregation both externally and internally. So pretty much what you are proposing here. It's already done donna. I would think that you know other clouds do as well.

R

That would be very interesting to look at.

C

Excellent well, thank you everyone. I think that this brings us to the end of iepg and we actually still have 10 minutes left if I'd planned time better. We could have done some more of willem's questions, but we will almost definitely be meeting again in philadelphia, assuming that we actually meet in philadelphia.

C

um So I'm trusting, everybody will have all sorts of exciting presentations for us then and enjoy.

C

Where are we vienna enjoy vienna.

C

Thank you. Everyone.

C

I don't know how now that I've yeah- I don't know where you stole this from. Thank you awesome perfect. Thank you, sir. I don't know how I logged tony out.

C

C

Would be nice if we could have, but.

T

We didn't really get our lives. Okay,.