what my lab is working on these days. It's been really a wonderful conference, chatting with all of you after the talks, listening to talks and so forth. I think there are a lot of overlapping interests, certainly between my group and many of you. Today, what I want to do is tell you about ongoing work, so I'm not going to show you any published work, meaning that in one slide, I'll tell you about what my group has been doing in the past, just so you know what you can come and chat with me about in the next couple of days. So as Simon mentioned, one of the major interests in my group has been studying sudden transitions in populations. So in general, we're interested in how interactions within a population or a community can lead to interesting evolutionary and ecological dynamics. So one of the most basic things that can happen is that if you have cooperative growth, you can have a sudden transition in response to a deteriorating environment. And we've been interested in early warning indicators, the universal behaviors of populations near these tipping points. Now, any time that you have these sorts of cooperative behaviors, you might also want to ask, is it possible for sort of non-productive cheats to emerge and spread in the population? So we've been interested in these sorts of dynamics. And in particular, what sort of ecological conditions might favor or disfavor the emergence of these cooperative or cheating-type behaviors? And some of this work was actually done by Al Sanchez, who's now at Yale. Well, not currently at Yale. Right now, he's here, but in general, he's at Yale. So much of this behavior is here where we're looking at cases where you have secretion of some sort of enzyme that helps to break down a complex sugar source. So this is what you might think of as the creation of a public good. We've also been interested in an analogous set of situations where it's the degradation of a public bad. So there are many contexts in which antibiotics, the way in which a population gains resistance, is via degradation of the antibiotic. So if you have degradation of some antibiotic, then you may be able to protect sensitive cells. And so we, for example, see coexistence between resistant and sensitive populations, for example, in ampicillin. Moreover, you can also, well, we've also demonstrated that you can have a mutualism. So you can have two antibiotic-resistant strains that together can grow in the presence of both antibiotics because they're each breaking down one of the antibiotics. And then finally, we're interested in a variety of kind of spatial dynamics. How is it that cooperative growth processes will alter the kind of spatial patterns that you get? Much of this work has been in collaboration with Kirill Korolev, who was also a postdoc at MIT and is now a professor at BU, also here. So you guys should chat with them about those projects. Kirill's also involved in a number of the early warning indicator projects. So these projects, I think, highlight the range of the interactions that you can get when you have interactions within a population. But in almost all of that work, it was really interactions within a single population, within a single species. And of course, the problem that we're all facing now is that that's not the way that these microbial populations are behaving in nature. They're in these complex communities containing many, many species. This is too complicated for me. So we are kind of, a lot of our work now is focused on the multi-species communities, but when I say multi-species, I mean n greater than one. So we're kind of taking a bottom-up approach to this problem where we're basically trying to understand pairs, trios, and kind of marching our way up. It's not obvious to the degree to which the insights that we get in these simple communities are necessarily going to hold in the complex communities that we all care about, but you have to start somewhere. And so this is our approach. All right, so I'll tell you a few different kind of projects in my group. All right, so first, we've been recently thinking about what are the typical ways in which communities will change in response to a deteriorating environment, in particular in response to increased mortality. Just very generally, it seems that increased mortality favors fast-growing species. This is true in pairs as well as within simple communities. All right, so we've also been interested in these kind of network of pair-wise competitive interactions. So we found that they're surprisingly informative regarding the structure of multi-species communities. And so then there's the question, well, what sort of network motifs or structures that in natural communities may help facilitate the diversity that we see in nature? And one of the proposals is that there could be a lot of these non-transitive or rock-paper-scissors type interactions. And what we've found is that, at least in the communities that we have looked at, so we can't find any of them. So we've looked at thousands of trios, can't find them. So our sense is that these are probably not common in natural populations, although this is something that everyone likes to argue about. And then finally, on a slightly more mechanistic side, so much of the approach that we take in my group is sort of phenomenological in the sense that we are trying to characterize the interaction using some simple parameters and asking, to what degree can we predict what happens later? But it's also good to go and look in and say, well, what is actually mediating the interaction? And one thing that we've found that is surprisingly dominant in determining the structure of the communities that we've been looking at is modifications of the pH of the environment. So just to get started, so this is a project that was being led by Clara Breu, who is a physics PhD student in my group. And what she wanted to just ask is, well, if we were to impose a general mortality onto a community, what is it that you might be able to predict in general? So the idea is that we have some complex community and it's gonna be put under stress, or this stress could take a variety of forms, antibiotics, diarrhea, attacked by the immune system. So some of these could be specific, but right now we're gonna try to imagine a general increase in mortality. So what we wanna know is, what is gonna be the structure of the resulting community? So as I said, we wanna start simple, so we're gonna start with pairs. And in particular, I think it's worth highlighting. In our group, we've been studying a lot of pair-wise competitions, and almost all the time what we see are simple outcomes. So there's basically three things that we see over and over again. It's not just, and other people see these things too, but I just wanna, it's good to be clear about what the simple and that, because it's easy to imagine that everything has to be infinitely complex, but what we find is that at least in the context of pairs, things tend to be simple. So one thing that we often see is dominance, where if you just compete two species and you measure the fraction over time, what you see is that one species outcompetes the other species. So dominance and competitive exclusion. Another thing that we often see is coexistence. So you compete a pair of species and they coexist in that environment. At some equilibrium fraction that's independent of the starting fraction that you do the competition at. And then finally, we sometimes also see bistability, where the outcome of the competition depends upon how you start. So what you see is that if you start with a lot of one species that's gonna win, and vice versa. And this is actually all experimental data, but just characterizing the three typical things that we see when we compete pairs of species. So maybe 95% of the time we see one of these outcomes, 5% of the time we see something crazy. Crazy could mean a variety of different things. Sometimes there's just rapid evolutionary dynamics, so you mix and you see that things kind of go weird. It happens, evolution, you can't always forget about. Sometimes we've actually also seen bistability with coexistence in one of the states. So here, this is bistability with exclusion on each side, extinction in one or the other. We've also seen a few cases where it's bistable, but one of the two states has coexistence. And then finally, occasionally we've seen oscillations, well, at least once in the context of this mutualism between the antibiotic resistance strains, we actually see period three oscillations. So these sorts of things can happen, but in almost all cases we see one of the three things on top, which is convenient because those are the basic outcomes that arise in just the simplest models that you might write down of pairwise competition, in particular this competitive lotcavoltaire model. So the idea here is that you just have two species that are inhibiting each other's growth, and depending as a function of the strength of the inhibition, then you get these three, you could think of it as four outcomes, here there's dominance and then exclusion, kind of the same thing, flip side, coexistence and bistability. So you get coexistence if there's weak suppression of each other's growth, and you get bistability if there's strong suppression of each other's growth. Just to be concrete, and I'm gonna put in, this is kind of the only equation I'm gonna include, just to be concrete, so this is the two species, this is the per capita growth rate here, and what it's determined by is just a few things. There's a maximum growth rate, this R1, it inhibits itself, in this case the assumption is it inhibits itself logistically, so it just decreases linearly like this, and then finally there's the inhibition by the competitor. It's a very simple model, and I wanna stress that this model is certainly not true. In any actual set of species, none of the assumptions in here is actually what's happening. So the question in my mind is, what are the qualitative predictions of a model, and do they actually pan out in a given experimental system? So in particular, what I'm gonna do is just ask, if we take this model and we add a uniform mortality, what happens? So uniform mortality means we're just up here and we just add this delta term. So this is just meaning that both species are experiencing some increase in mortality. Very simple assumption. It turns out in the context of this model there's a very simple prediction because this delta can actually just be brought into those other terms, and so you can just redefine the parameters within this model, and there's a simple geometric interpretation. So now instead of N1 and N2, I'm calling it NF and NS, we're assuming that one of them is gonna be faster, more fast growing than the other, so RF is larger than RS. So in general, that's just a label so that you can assume that without loss of generality. And what happens in this context is there's something very simple, that as you increase the mortality rate, the prediction in this model is that you should just travel down and to the right at a 45 degree angle. So for example, if you start up here where the slow grower is winning, so it's slow growing, but maybe a strong competitor, so it could still win, as you increase the mortality, the expectation is that you'll travel down this 45 degree angle where you're favoring the fast growers. Eventually, you expect to make the fast grower win, but along the way, you expect to cross either a region of coexistence or a region of bi-stability, but not both. So again, this model is certainly not gonna be an accurate or quantitative description of any given real pair of species, but this is a qualitative prediction of the model that could be robust to the fact that the assumptions are not actually gonna be true in any given system. But that's an experimental question, right? All right, so yeah, so then what we did is we went and we do a lot of competition between species, so we basically just started looking at some of our species where in particular, the slow growers seem to be strong competitors. And what we found is that this basic picture is surprisingly predictive regarding what happens in pair-wise competitions. And important, yeah, so let me do it. So I'll tell you about the experiments. So what we're doing is we're just competing pairs of species in liquid, all right, and we allow the populations to grow up. And then each day we're gonna perform a dilution where we transfer a small fraction of the cells into fresh media, and then the population grows back up or the community competition occurs again. We just repeat this process five or six times, typically 50 to 70 generations, so that we allow the competition to reach resolution as in the data that I showed you before. Okay. And in particular, what we're gonna do is we're just gonna increase this dilution in order to impose and increase mortality on both species, right? And indeed, it's symmetric, it's imposed on both species. And this basic picture works surprisingly well. So what we see, for example, is that when we compete pseudomonas veroniai against enterobacter aerogenes, what we see is that PV, the slow growers, winning at low dilution factor, but then as we increase the dilution, we cross this regime as kind of expectants. I'll show you the data, but just give you a picture that this is what we think is happening, right? So first of all, if we look at the fast grower fraction, that at low dilution factor, it goes down, right? So we get exclusion of the fast grower, that's fine. Question is, what happens as we increase the dilution rate? And it's really just as we were kind of expecting, which is that you see that the fast grower, it loses at low dilution factor, we get coexistence at intermediate dilution factor, and then we get the fast grower winning at high dilution factor. I'm sorry that it's very hard to see those lines, but yes. And the way that we like to visualize this sort of data is via these things we're calling subway plots, where what we show here is basically the color of the species is telling you about whether that species can survive at equilibrium when in competition at that dilution factor. So here, blue is saying that only that slow grower is surviving at intermediate dilution factor, we get coexistence, and at high dilution factor, we have again competitive exclusion where the fast grower is excluding the slow grower. Yes, yes, so indeed in all of these conditions, the monocultures can survive in all those conditions, yeah. But I think what you're highlighting though is that at some limit, this thing has to be true, right? Because if you dilute faster than the slow grower grows, then it's gonna go extinct and the other one should win. So indeed that in the limit, it's kind of trivial or it has to happen, but it happens in very particular ways, I guess. Yes? Okay, so the question is about the slow grower, like why is it? Yeah, yeah, right, so we've been characterizing many pairs just to get a statistical sense of what's going on, so we have not in this case delved into what is the mechanism behind that. Okay, so for example, it could be that the slow grower is making a toxin that is costly to make. Yes, sorry, sorry, slow grower, yeah, so yeah, exactly. What I'm referring to is the growth rate on its own, yeah. And it's the growth rate at low density on its own, yeah. By sampling both species. Oh, I see, I see, because by sampling, you're imposing immortality, is that, yeah, yeah. And if you want to do that, that's fine, but you have to be aware that you are doing it, right? And I guess I'm a little bit embarrassed by some of this stuff because we've been spending years doing competitions or, well, at least thinking about this stuff, and we often, I didn't think too hard about what delusions we were using in the sense that we would often just say, oh, yeah, this pseudomonade, it out-competes this other species in minimal media with x-me-o-e-o, so we define the media, but we often don't feel we need to specify the dilution factor, yet what you can see is that I can make anything happen by changing the dilution factor, right?  I mean, we're only allowing a fraction of each of the two species to survive when we do the dilution. So in that sense, I would say it's the same mortality that is, same mean mortality is experienced by both species. Yeah. Oh, I mean, we spend a lot of our life thinking about density-dependent effects, for sure. Oh, no, I mean, for sure, and again, that model is super simple and none of the terms in the model are correct, and that's what I find surprising is that the qualitative prediction of the model works not just for this species, but for others, despite the fact that life is complicated, yet, yeah, I guess, you know, I'm always looking for what simple things can we say despite the complexity of life, right? And I guess this seems to be a pretty robust thing, right? That you favor the fast grower and in between, you cross either a region of coexistence or a region of vice-tability. All right, so maybe I'll, okay, so I showed you data for one pair, but we've done this for many pairs. And in particular here, what we've done is we've taken four different species with different growth rates. What you can see is that at low dilution factor, the slow growers do better than the fast growers, right? But as we increase the dilution factor, we can plot just the mean fraction of each of those species in all the pair-wise competitions, and you see there's just very clear patterns as we shift. What you see is that the slow growers do worse and worse, the fast growers do better and better, and then you can kind of interpolate between them, right? Yeah, indeed, okay, yeah, so in almost all these cases, there was only one pair that had vice-tability. So in all these cases, basically what we did is we started with a bunch of different fractions. And in only one of these pairs was their vice-tability, so it actually doesn't, it doesn't, this sort of data is not affected very much by that, but yeah, we started with a wide range of fractions. And all right, so this is how the pair-wise competitive outcomes are varied as we vary mortality, right? Favors the fast grower in stereotypical ways. And the question is, well, what can we say about more complex communities? Well, so luckily we've spent a fair amount of time over the last few years thinking about these community assembly rules. So based on pair-wise competitive outcomes, what can you say about simple communities, right? So first of all, this is the subway plots for three other pairs. What you see is that the two fast growers, they coexist at all dilution factors, and that's because their growth rates are so similar, you don't have much of a lever arm as you vary that dilution rate. So then you don't change the outcome. But the other two pairs, they have a difference in growth rate, and again, you have the slow grower waiting over here, a region of coexistence, and then the fast grower wins. And the question is, all right, so these are three pair-wise outcomes. What can we say about what would happen if you have all three species together? And in particular, we have proposed these community assembly rules that are based on qualitative pair-wise outcomes to qualitative trio outcomes or more. And basically, what the proposal is is that we're gonna say that a species will survive in the multi-species competition if and only if it's not excluded in any of the pair-wise competitions. In particular, if you look down here, for example, the yellow species is out-competing each of the other two in pairs, so then we would predict that it's gonna out-compete them in the context of the trio, so only maybe yellow will survive down here, and we can kind of apply this rule all the way down. And at least, for example, in this trio, that assembly rule works for all the dilution factors. What happens is that the yellow is the only one that survives at low dilution factor. Over here, at 10 to the five, you see that there's coexistence of all three pairs, so you would then predict coexistence of the trio, and indeed, that's what we observe experimentally. And then finally, at high dilution factor, since the yellow species is out-competed in the pair-wise, you would predict it to be out-competed in the trio, and indeed it is. As before, what we found is that these assembly rules predicts, correctly predicts survival about 90% of the time in the context of going from pairs to trios or four or five, and indeed, we see, again, similar things. You hear it, it happened to work for all of these dilution factors, but we've done all the trios in the four. So indeed, 90% of the time, we correctly predict survival. So it's not 100%, and you wouldn't expect it to be 100%, but it's, I'd say, not bad. And just to be concrete, in the previous experiment, instead of varying the environment, what we had done is we had just taken eight species and done all the pairs and trios in a single environment, and that's kind of where we had first developed these assembly rules, and so that generates some sort of network. Oh, and incidentally, we've also recently found that these assembly rules work surprisingly well in determining the structure of the gut microbiome in the worm. In particular, if you apply these rules, you can predict the fraction at equilibrium in the gut of the worm within about 10%. Actually, so the median across 20-some trios was an error of 10%, which, frankly, is close to our measurement area. I mean, if you just do the same thing. So it's surprisingly good, I would say. So given that these pairwise outcomes seem to be so helpful in sort of guiding our thinking in the context of determining community structure, a natural question is to ask, what does this network look like if you were to sample it from some sort of natural community, some co-occurring set of bacteria? Because all of the species so far that we've been studying were just from random soil isolates taken from different parts of the world, and then we just put them together and see what happens. So to get at this question of what it is that this network might look like within an actual community, what my microbiology student Logan did is she just, well, she sampled from a single grain of soil, isolated 20 species, and then measured all the pairwise outcomes. Now, the reason that she wanted to do this is because one of the major questions in ecology is to try to understand how it is that the diversity is, that we see in natural communities, how is it that that's possibly stable? And I'm not gonna solve that question here, but this is what we're trying to figure out. Yeah, yeah, so I went out to the front yard, dug 10, 70 years. So oxy, Albee, that sort of thing? Oh, yeah, so all of this is done in the presence of oxygen. We have a chamber that, yeah, but this is all done in the presence of oxygen. So maybe the structure of this network might give us some insight into how it is that these communities can be so diverse. So the question is if you go and you look at some set of species and you measure their competitions, how they interact, then maybe you might see some patterns in that network that would provide guidance in terms of what's going on. So you might, for example, see something like modularity where different subnetworks are strongly interacting or maybe you'll look up here and you'll see something like these non-transitive rock, paper, scissors type interactions. And the reason you might expect those is because they're predicted to increase the diversity in the community because if you have something that looks like this, then no species can get to abundant because that opens the door for another species to be spreading. So there's a great deal of theory in this field basically asking, as competition goes from being very transitive, like a competitive hierarchy, like you were talking about, to more non-transitive, then you expect to be able to get more diversity at equilibrium. But this is an experimental question. We have to go out and we have to make measurements to see what these networks actually look like. So what Logan did is she just walked out of the door of the lab, she went into the grass, she dug 10 centimeters down, grabbed a grain of soil, brought it back to the lab, vortexed, plated in the presence of oxygen. And I said many species, but in particular she chose 20 of them to study further and do all the pair-wise competitions. And just to tell you, yeah, so what we see is basically what Karina was talking about before which is we found a very strong competitive hierarchy. So it's really that one species with basically the best could beat everybody, this species could beat everyone except for the first, all the way down. So this is the kind of network that should be least favorable for leading to diversity, but that's what we see. I'll show you the data just so that you can believe that we did a lot of work. This is the 20 species arranged in order of mean competitive fraction in all of the measurements. And what you can see is that basically there's a lot of red down here meaning that these species are outcompeted, go extinct as a result of competing with the vertical one. A lot of green up here meaning that these species drive these other ones extinct. Blue corresponds to coexistence between the two and yellow corresponds to bi-stability. So in all these pairs we did a 5%, 95% starting condition so we could assay for bi-stability. And what you see is that there's a very strong competitive hierarchy. Yeah, so this is measuring after 60 generations, what happened? Yeah, okay, so this is a mixture of the alphas and the Rs. This was all doing daily dilutions of 100. We thought that maybe this competitive hierarchy was driven by the dilutions, so then we went and we repeated this for a low dilution and it was still hierarchical. So yeah. Yes, except that once you add a dilution in there then it couples to the Rs like what we were talking about before. Yeah, so there are many possible explanations. This is one of them. Yeah, I'm not gonna give the answer for why these things coexist because I don't know. But it was Roy first, yeah. So the question is how many of these competitions can be turned around by doing different dilutions? I would say that over the range that we have access to I think we could probably alter a third of them. But we've only done two. I mean it's a lot of work to do one of these matrices. Yeah. Yeah, yeah, so this was one 10th LB. We've also done it in a defined media. We've also seen hierarchy. So yeah, of course, this is not the soil in a lot of different ways, but as far as we can tell we have not been able to get rid of the hierarchy despite a fair amount of effort to do so. In the sense of different medias, different dilutions. Yeah. So okay, so this is, okay, so the question is whether the logical Volterra model predicts oscillations. So unfortunately not this logical Volterra model. It's the predator prey logical Volterra model. Yeah, but we basically don't see oscillations anyway. So yeah, yeah in the back. Yeah, so yeah, all of the data that I've shown so far the species abundances were determined by plating because they have different colony morphologies. About the genus, yeah. Oh, the cheaters. Oh, okay, so yeah, so there could be many complications here. Yeah, so all of the competitions we've done here were done from single colonies. So we don't, so this is, we're trying to study ecology rather than evolution, right? And as I said, a few percent of the time you can't get away from evolution, but by and large these are clonal populations within each species and we're competing species. Yeah, so we're really just trying to focus on the ecology. Extreme competitive hierarchy and in particular you can go and you can look at all the different trios and ask how many different cases of this sort of rock, paper, scissors type interactions can you find, right? So with 20 species there's over a thousand trios that you can look at. So we went and asked, okay, can we find any rock, paper, scissors? And the answer is no, right? So basically there were no robust examples of rock, paper, scissors among these 20 species. So our sense is that, well we spent a lot of effort trying to find these non-transitive type interactions and we can't. So my provisional takeaway is that they're not playing a significant role in stabilizing the diversity we see in natural communities. So there we are. Okay, so I'll probably not finish what I was going to say, but it's fine, all right. Okay, all right, then I'll try to be clear. So that you don't have burning questions. All right, so far what we've been doing is taking this purely phenomenological approach. We're just asking what is the interactions, but there's some effective interaction between the species. What can we say based on that? And in particular we were imagining that there was some direct interaction between the species influencing each other. But of course in the context of microbes most of the interactions are mediated through the environment. So things are being secreted or uptaken from the environment and that's influencing the growth of other species. So the question is what can we say about this sort of environment mediated type interaction? In particular my postdoc, Christoph has found lots of examples where it's really the pH that's determining an awful lot of what you might want to know. So first of all, microbes when they grow they change the pH of the media. I think we've all seen this, but I just want to highlight that it's ubiquitous. This is just, we took 119 different bacterial species that we'd gotten from the soil. We grew it up in some vaguely reasonable media. We measured the pH afterwards and what you see is pH goes everywhere. We started pH seven, there's a couple species that stay there, but almost all of them changed pH. Some of them acidify, some of them alkalize, a variety of effects associated with the growth in terms of the pH. The question is, is this important? And we're gonna argue that the answer is yes. So what we see is that the pH can lead to all the kinds of phenomena that we've been studying in the context of a lot of these other interactions in the context of, for example, breaking down sugars. So first of all, you can have positive interactions where microbial species is, say, acidifying the environment and that's good for it. For example, budding yeast does this, right? And this leads to all the stuff about cooperative growth, minimal viable density required for survival, all the stuff that we and others have been thinking about in the context of cooperative growth shows up for pH as well. We also see that there are many cases where microbes change the pH of the environment in a way that's bad for it and this leads to something that you might call ecological suicide where a population kind of kills itself. And then we also see that just by thinking about the pH, we can often get a good prediction regarding the kinds of outcomes that might happen when we compete pairs of species. So some people think that Easter Island population of humans had this ecological suicide kind of thing where Easter Island started looking something like this and then humans came, they chopped down all the trees and then they left behind this. There's a lot of arguments among anthropologists about whether the human population on Easter Island actually did this. I'm not gonna try to convince you that that's the case but I will try to convince you. And incidentally, In Yu Huang on Monday talked about a quorum sensing mutant that did really precisely this thing here where in that case it was alkalization but what we see is that many different species will change the pH in the environment in either direction in a way that is so bad for it that it kills itself. So this is just, this is an example of data for a particular species where we at high kind of temporal resolution went in, plated to measure the CFUs. What you see is that the number of live bacteria, it grows exponentially but then very rapidly dies exponentially and after 24 hours and we actually, there are no viable cells left in the media. And indeed, this is accompanied by a acidification in this case. Doesn't prove that it's pH but we can, for example, increase the buffering and what you see is that eventually you can save the population by adding a sufficient buffer. So it's not, again, this is not just this species surprisingly common actually. And given that this is already kind of a weird phenomenon, there are a bunch of corollaries of it that are very natural. In particular, what we can do is we can harm the bacterial population in order to save it. So what we can do, for example, is do a bunch of different things that harm it. We've done antibiotics, ethanol, salt, lots of different things to harm the population can actually save it. So what I'm showing you here, for example, is the fold growth experienced by the population as a function of an antibiotic that we're adding. In the absence of the antibiotic, the population's all dead. It's this ecological suicide phenomenon I was telling you about. If you add enough antibiotic, you can kill the population again. Not a huge surprise. But there's this region of antibiotic concentration where you can save the population because you're inhibiting growth and preventing that acidification that was going to kill the population. I think that this is interesting consequences if you think about what happens when you have mixed populations, communities, resistant sensitive, I'm not gonna get into it, but it's a kind of a natural surprising consequence. Yeah, so this is just batch growth over one cycle but we've also done multiple growth dilution cycles and the same basic thing happens. And it's common. But I do wanna just highlight that this interactions between the pH, there's just a few different kinds of interactions that you can imagine. Basically, because there's different combinations of whether each species is acidifying or alkalizing and whether that's good or bad for the species. So what you can do is you can just make a little table where you can say, well, what is it that the pH that they're imposing on the environment and what is it that they prefer? So you get cooperation on this diagonal and you have inhibition, possible ecological suicide in the other one and then you can ask, all right, what are the possible outcomes that can occur based on combining these different species? And there's some very, I think just basic interesting qualitative outcomes. So first, if each species is changing the pH in a way that's good for it but bad for its competitor, you might imagine that could lead to by stability between the population and indeed that's something that we can observe experimentally. You can also imagine that there's a case where species is trying to change, is trying to say acidify the environment and make it, and it's good for it but can't quite do it on its own but could do it with the help of another species that maybe you could get an example of succession where a second species helps the first species survive but doesn't survive at the end of the day and indeed we see that kind of, that outcome experimentally as well. You might also imagine that there could be something that you could call a murder suicide where it's an environment where a given species is gonna be killing itself and along the way it kills its partner species and indeed we see that experimentally. And then finally you can imagine that if each species is doing something that's bad for it then if, but in opposite directions then they could stabilize each other, right? So there can be an example of a mutualism and indeed we can see that experimentally as well. So this is all just based on knowing how the single species behaves in a monoculture and how the pH is altering its growth, okay? And I'll do the last slide because I think it's fun. So in this case of bi-stability that I mentioned where the two species are each changing the pH in a way that's good for it but bad for the competitor, you can think about this in the context of alternative stable states. In the human gut microbiome there's a lot of attention that's being paid to what we think are alternative stable states. Between for example the C. diff dominated unhealthy state with the healthy gut microbiome and what we would like is to know how to transition between these alternative stable states, right? So we've been using this as kind of just a model simple little community that we can use to ask well what is it that we can do to perturb this community and induce transitions between them, right? So we found a variety of different kinds of abiotic perturbations, right? So different perturbations that we impose but there's also something that we found that I think is really kind of surprising and fun which is that we can induce transitions between these alternative stable states via a third species that acts as a transient invader. So what it does is it catalyzes the transition from for example the LP, the lactobacillus dominated state to the CA, right? And what's interesting is that it doesn't survive the transition, right? So it can induce the transition but it can't survive that final state. And interestingly there's a fourth species that we can add to induce the transition in the other direction where we can again make it go back to this state and again this species doesn't survive, right? So there's, well there are many cases where we observe these transient invaders where they can induce the transition but there's no evidence that that's what happens. Later you look at it in the community just switched and there's no evidence that that species was ever present and it makes you wonder to what degree species invasions could induce transitions for example in the human gut without showing leaving any trace. And I don't know if that is real or not but at least here we seem to see it. All right and so with that I'll summarize. All right so we've been interested in this bottom-up approach to try and understand multi-species community assembly. So here we found that there's just some very simple things that you might expect will happen as you increase mortality in pairs and in simple communities and that seems to be borne out in our experiments. We'd love to be able to see this kind of thing in for example the human gut with diarrhea. I was talking to Tammy Lieberman actually last week about whether you could see these kinds of things in complex communities like the human gut or in the worm. We've also been interested in these sorts of network structures and one of the dominant ones that people talk about are rock, paper, scissors trios. There are experimental examples of these but my sense is that they're not actually so common in natural communities. And finally we found that the pH seems to be a dominant determinant of how a lot of these species are interacting in a way that, I mean of course there are many examples where people look at the pH in the context of the oral microbiome and others where it seems to be structuring things and it's just a matter of trying to figure out which, what are the list of things that you should first look at when trying to determine the origin of the outcomes that we're seeing in various systems. And with that I will thank the group who are the ones that have actually been doing the work. You guys should all introduce yourselves to Carol and Al who are here and I'll also maybe just mention that I have three postdocs that are gonna be starting groups this coming fall. So if you guys are looking for postdocs and so forth you should check them out. So Nick Vega is starting a faculty position with Bruce over at Emory. Jonathan Friedman is starting the Hebrew University of Jerusalem and Alfonso is gonna be starting a group in France with a CNRS position in Toulouse. So yes, thank you.


Guess what? If you go over to the Winchester website, I have a blog on Winchester where I share my ideas on how to make your game taste better. So when you're in the field, you're shooting Winchester and when you're in the kitchen, you're following my blog on Winchester.


So I feel free to ask any questions, like just raise your hand, interrupt me, and if it's a question's too big, I'll like, we'll take it offline somewhere else. So I work for the LibreSound project, that's where my main focus is on, and Red Hat lets me do a lot of work on that, so it's really nice. Most people know us from being the enterprise IPsec solution. It works really well, but we also have this other leg of our project, which really has its aim to encrypt the entire internet. And we're not there yet, but we're hoping to add more and more, but as I'll show you in some of the history, that's been a really long, slow project. So yeah, we've done recently a lot of certification stuff to get our code into good shape, and we actively are at the ITF proposing new standards and extensions to Ike. Not so much for IPsec, because it's defined and it works, but for Ike, we do have a bunch of things that keep getting proposed and added to the standard. So we're pretty active there as well. So for those of you not very familiar with IPsec, this is the one-slide explanation of IPsec. It consists of two part, Ike. That is interesting. That scrolls fine here. So what do I do then? Unplug? Okay. Is that full screen? No. Too high. Okay. Okay. Thank you. So now I won't be able to read the slides, so I'll be working around a bit more. Sorry? Oh, sure. If that doesn't crash my laptop for... Yeah. I had a lot of windows bars. Okay, awesome. Thank you. So try not to block the screen. Okay. So we'll try that. So IPsec basically consists of two part and it's a little bit confusing because people tend to call it IPsec, but IPsec is really the data channel. That's where all the packets are encrypted and decrypted. It's the kernel that's usually doing that. And then we've got Ike, which is the command channel. So that's your userland application that sends the negotiation packets to authenticate the other peer and then set up in what they call Ike association. And after authentication, they agree on some key material and then they send that key material to the kernel that will then do the encryption. And there's some parameter negotiation as well, which IP addresses are allowed. IPsec is not a virtual ethernet where you can just throw anything at it. You're supposed to really climb down on the policies of source destination address sports protocol, even though a lot of VPN people don't do it and they just build a tunnel from zero, zero to zero, zero. That's not really how we like to see things done. What else? So Ike itself is encrypted. Don't mistake that for the encryption of the packets. Those are two separate things. And some weird things is that we have two modes, tunnel mode and transport mode. Transport mode was supposed to be the simple one where you have a source IP and a destination IP and you yourself are the source IP. So you can use that for the encryption and protect the packet itself so you don't have to encapsulate the packet. But because we invented NAT, we sort of destroyed that usability in a reasonable way. So tunnel mode is the much more preferred option these days to use. And because there are also many firewall administrators that tend to block anything not TCP and UDP because they don't really know what the other things are, they sometimes tend to block the ESP protocol, which is protocol 50. And so there's also a mode also for when you're behind NAT is to encapsulate it into UDP packets. So it's literally just putting it in a UDP packet pre-panded with four zeros to market and send it out. So that's ESP and UDP. So let's see. Do I have range? I have range. VPN, two insecure networks, very red. They're not encrypted at all. They're all talk plain text in the cloud or in the data center. And except when you go across the internet, do people go, okay, we should encrypt this. Let's put some gateways in there and they do the encryption there. And those are usually your choke points, single point of failure, maybe dual point of failure if you've got like a hardware failover set. And usually these machines also are fairly expensive if you're doing like high bandwidth stuff. The licensing costs go up. So it's the traditional way of doing it and we can do much better. This is the other traditional setup. It's where you've sort of got the remote working setup. You're roaming. You connect to the corporate VPN server and then you again get access to the network. But that network itself again is completely in the clear, unprotected. And so half of your connection is still sort of in the clear. Luckily we all use SSH and HTTPS, so it's somewhat mitigated, but we still leak a lot of clear text packets. So to give you a bit of history, this goes all the way back to 1996 when John Gilmour started the project and was like, you know what, we should encrypt the internet. Let's start with in 1996 to get 5% of the internet traffic protected against passive wiretapping. So we kind of failed on that. But it was a really good start. The idea was opportunistic encryption. John Gilmour didn't really give care much about the enterprise VPN. He was like, well, those people have money. They can come up with their own thing. What I really want is to encrypt the entire internet. And that means encrypting between two parties who've never heard of each other before and who not necessarily trust each other, but they just want the communication to be encrypted. So some people sometimes ask me what the swan stands for. There's a few forks you'll see in a bit. Swan stands for secure wide area network. It was trademarked by RSA, so people stopped using it even though the FreeStrom project had some permission to use it. And so instead the term VPN became really the common term that everybody started using. It predates open SSL, which means there was no crypto library that the project could use. It all had to be written from scratch. There were no protocols yet. So the RFCs hadn't been written yet for IKR or IPsec. So they were part of the efforts of making the IPsec and IK protocols happen. So they joined the ITF from the start and tried to make this happen. It took a really long time. One famous quote from Gilmour is that the NSA tried to slow down the project and add to many features. And I think the quote is a little bit out of context because we were really our own worst enemy, you know, designed by committee kind of things, delivered these kind of solutions. And I don't think that NSA actually deserves credit for that. I think we really all did it ourselves. It predates the crypto API for people who are old enough to remember kernel i.org and export laws and all these things. So all these problems were added to the project. We want to encrypt, but where do we publish the source code? We can't publish it in the US because then it's export restriction, so it has to be done elsewhere. And Americans cannot touch the code because at the time President Clinton could order via a national security letter that if Americans touch it, it's Americans and nobody else can use it. So what happened was that most of the development actually happened in Canada because no Americans were, you know, John Gilmore did not let Americans touch code, which also caused a problem because at the time the network maintainer was Dave Miller. And so there was quite a bit of friction, like he didn't want to pull it into the kernel if he couldn't maintain it and change it and patch it. So there's this weird standoff that caused basically the kernel part of IPsec to live outside of the main kernel like up until like the early 269 days. And so all this time there was this separate kernel module called CLIPS, which Richard there maintained a bunch of it. And when he left, I was forced to take over some of this gluing. And the history with the absolute Halloween before Halloween, that's when Dave Miller checked the pile of IPsec stuff. And one of my first times that I actually met some of these kernel developers, and Alan Cox and Dave Miller, was when the Freishand people and the networking people got into a room together and said, OK, how are we going to hook this together? And in the end, I was decided to use the routing because there was nothing better than routing into some device that gets tied to a kernel module that can then do the processing. The most interesting part for me at that meeting was I was a pretty new person to it. I didn't have much experience at all. Was that in a room full of kernel experts, only Alan Cox was able to go to the whiteboard and say, this is how the packet flow works in the kernel. You go through this part and this part and this part. And I was like, it was already really complicated. And we're talking about 2.0 kernels. So these days it's orders of magnitude more complicated. There was also no DNSsec and not much of a CA industry at the time yet. So one of the big problems was key distribution. Like, how do you distribute your keys to basically strangers to validate those keys? If you're talking to someone with no pre-configuration, how can you trust them that they are who they are? And so the solution was sort of embedded in, well, we'll do it in DNS and make sure that DNS gets secured and then later on we can build on that. Unfortunately, that took a really long time. So what happened? Well, it really worked really well. Like, enterprise setups with IPsec worked really well. During interop tests, like FreeSwan was the gold standard. If you interoperated with FreeSwan, you had a properly working icon IPsec stack. Like, it was really the cornerstone of IPsec. So that was good. Things that didn't work out as well, it took a really long time. So the development within the IETF went really slow. United States citizens couldn't touch the code, so there were less people that could actually do things. The other big thing was, because everything was packet triggered, it meant that when the kernel would send a message to the use lens saying, I've got an IP packet from this source to that destination, and you want a tunnel but I don't know anything else, then the ICD man had to go figure out, OK, this is a source destination, who is this? Who's talking to who? Where do I find the authentication of this person? Where's the identity? And so the only method that was available at the time was the reverse DNS. So we said, OK, well, we'll put the key, the IPsec key, in the reverse DNS. And then by the time later on when that gets secured with the DNSsec, then we will have a really good distributed authentication mechanism. The problem was that basically the reverse got abandoned. Like, for IPv4, you could really only get to it when you were in the data center. If you're an end user at home on your DSL or your dial-up line at the time, you just had no chance of getting access to your reverse. So from a practical purpose, that just never worked. The other thing that was problematic was NAT support. Like when NAT really started to become so common, you didn't even have an IP address that you could attach to yourself. So you would have this asymmetric thing where you could connect to a server and you would know its IP address, and maybe you could from its reverse get the identity and then look it up. And then you yourself could then tell the server, well, I'm really this entity. You can look it up in a forward DNS. So that could work. But then if you had two entities on dynamic IP address, it wouldn't work. Or if you wanted to connect to your neighbor, it wouldn't work. So it was fairly limited. And that's the other problem. Like, to make this work, you had to have an identity. So your laptop or your phone would have to have an identity that is published somewhere somehow. And that really didn't work very well. And the reason that SSL actually took off, as it did, was that it didn't require the client to authenticate itself. It could just authenticate to the server. The server didn't really care who talked to it, as long as it was encrypted. And it was fine with whomever. The unauthenticated encryption. So let's just do Diffie-Hellman, do a session key, and not bother authenticating. It was rejected by the project at the time. It said, this is just too insecure. Let's not do that. It's really easy for a passive attacker to become an active attacker. And it offers no real protection. Now, had they known that everything would take 15 years, they probably would have said, OK, let's start with this, and then we'll bump it up as we go. But they didn't. So it was another 15 years of massive monitoring and storing of data that people could do. DNS stack, it was really slow. Like, 2010, the root finally got signed. Now we're finally seeing enough support on end nodes that they can actually use it and validate and not have DNS packets drop, or Cisco firewalls drop, DNS fragments, and other things. So it's finally now becoming useful. But then the other main point was this. These are all technical points. The other main point was that even when in 2001, the echelon network was outed and published to the world at large by Duncan Campbell, people didn't really care. Like, they're not spying on me. Why do I care? Like, this is also sort of before everybody's life was attached to their mobile phone, where all their data and email and everything came in. So they didn't really care. Like, I don't have that much to hide. So meanwhile, so John Gilmore gave up. He's like, I've funded this for, I don't know how many years, seven years. He was like, I'm done with this. The only people really using it are the enterprise VPNs, and they can fund it themselves. Like, I'm not doing this. So I met up with John Gilmore at the CCC in 2003 in Germany, and we sat down and was like, OK, how can we do this? So we let's fork this nicely, because we're still good friends, but he just wanted to pull out. So what happened was that we agreed to fork. We used OpenSwan as a working name. It couldn't come up with anything better, so it stuck. And John did some, he talked to Snire and Niels Ferguson. They decided, let's do a paper that says, all the bad things by IPsec. We'll strip it out of FreeSwan as a demo to see that you can do this. And then we'll just never do a FreeSwan release again. So that's what happened. FreeSwan 205, 206 are releases that removed transport mode, AH, NAT support, and I think there was some X5 and NINE support that got yanked out.  We yanked them out. And so, of course, nobody used it. But John made this point. Meanwhile, a company was founded, plus the OpenSwan project was founded, two separate entities that one was supporting the other, moving forward. Red Hat actually got a bit involved and hired the company to do some things. They supplied the native IPsec packages. So meanwhile, the XF-RAM net key stack got added to the kernel in about 269. It took a few iterations before it was usable. And it actually took a long time, I would say probably until late in the 26 early three series that it's really got all the features that we wanted. And I'll list them later on. But for OpenSwan, it was folded into REL6. It became even more of a standard enterprise solution. There was some hardware acceleration support added to OpenSwan, not used in REL. It's OCF-based. That was the Open Cryptographic framework from OpenBSD. That was the Dev Crypto device. At the time, it was really important to have the hardware drivers accessible in USALENT because it was still cheaper to copy the whole thing from USALENT to the kernel, have the kernel do it with the driver and then push it back. It was still faster than for USALENT to do it without acceleration. Meanwhile, we've reached a point where that's no longer true, USALENT has access to direct AES instructions. So all of these things are no longer true. So it's since also been removed. Ikev2, the successor to the first Ike protocol, there are some things that people really didn't like. For instance, the worst thing was that if you did pre-shared key authentication, the only way you knew that the other side and you didn't agree on a pre-shared key is if you got garbled stuff and you couldn't decrypt it. So the error messaging was horrible. Like, I cannot decrypt your packet. Maybe your pre-shared key is wrong? I don't know. So there are a few extra things. Also, Ikev1, both sides were responsible for retransmitting, which gets you into this really denial of service thing where amplification attack, where you send one spoof packet to an Ikev1 gateway, and it will start sending like 10, 20 packets, depending on the exponential backup that they've implemented. Akamai actually did a paper on that a couple of months ago. So that was not good, but people realized it. So in Ikev2, it's the sender's responsibilities. Only the sender retransmits if it doesn't receive an answer, and the responder never retransmits. Unfortunately, we had no funding at the time for opportunity encryption. Like I said, no one really cared. There was nobody behind it. So it sort of fell off and didn't get used very much. And 2011, 2012, the company that was related to this but didn't own the project sort of fell apart, and there was a discussion on who owned the name or not. There was a lawsuit, and at some point we decided this is better to rename our project and to spend more money on lawyers. So that's how we got to LibreSwan. It's really a continuation of OpenSwan. It's got the exact same people behind it. And so LibreSwan got into REL7. It meanwhile got into REL6 because at some point backporting things was just too hard, especially with the new FIPS code. And there were just too many changes. We couldn't backport it anymore. It's like five years of code was being backported. It was just unsustainable. So I finally managed to convince people inside Red Hat to get rid of OpenSwan and put LibreSwan in. So lots of updates. Where in OpenSwan you could optionally use NSS or the old, old, old pre-open SSL crypto code, all of that legacy was removed. NSS was made mandatory. We removed all the X5, Y9 code, ASN1 parcels. Everything was outsourced to NSS. Cryptosweets update. So we removed things like Blowfish and other things. And well, Single Desk was never supported. Some older ModP groups we also, we were always pretty progressive compared to other people. So we never supported ModP 768. We did support ModP 1024 and 1536. And now we're actively pushing those out as well. So for IGV2, we started with ModP 2048 and accept higher. And I'm actually part of, within the ITF of both the documents for ICANN IPsec, the mandatory to implement crypto algorithms. And we're pushing it even further out to make sure that all these old algorithms are going away and we're focusing on the new ones. Just a question? Or are you looking at it? Sorry? You're looking at it. Yes. The ITF, yeah, the ITF working group has looked at it. And there's a proposal to basically what the ITF wants to do now is they want to put a stop gap in for post-quantum computers. So if they now start collecting all the data and 10 years from now, they have a quantum computer, we want them not to be able to decrypt the last 10 years of traffic. So this allows us to sort of defend without knowing what a quantum computer exactly will look like. So the idea that's been floating around now is that we'll use a post-quantum pre-shared key, which kind of sucks because the whole idea of IK was to not have pre-shared keys done. But so for now, people who want it can do an additional pre-shared key. You can send an identifier in the first packet so you can list where you want it, or it could be like an entanglement device with a light beam, or it could be a one-time pad, or whatever construct.  Then we do a regular, what's likely? This is all draft material, so it's not guaranteed yet. The idea is that if you care about the IK essay, which is just a command channel, which normally you don't, because 10 years from now, who cares what the command channel is encrypted to, you cannot do anything with it unless you can decrypt the keys. So you really only want to protect the IPsec keys, and you don't care so much about the IK keys. So with that protection in, there is still a mode where people say, well, we also want to know because you can have address assignments happen inside IK, and maybe that will reveal who it was because he always gets the same address. So for that, the idea right now being floated is we do an immediate re-key with the post-quantum key mangled into the key material stream, so to throw into the KDF. So then, at least, the first IK exchange, they would be able to decode 10 years later, but then the next one that immediately comes out should be fine. And then, of course, there's also the post-quantum protection for the IPsec keys. So that's the sort of stopgap people are now thinking, and it's also independent of any of the designs of hardware and things that they're now doing. OK, so we got to the point again where we sort of could look at 10 years of past or 7 years of past. Let's look again if we can do opportunistic encryption. IKV2, one of the features, as well, is that it allowed asymmetric authentication. So like TLS, we could say the client can identify differently from the server. It didn't support null authentication yet, but we added support for that. I'll show it in a sec. IKV1 also didn't really natively allow a nice address assignment, and in V2, that was more internalized, was more fundamental to the protocol. So we know that everybody has the support. Same for like, on IKV1, they bolted that peer detection on later, and so you didn't know if the other end would support that peer detection, but with IKV2, it's part of the core spec, so you know everybody supports it. And the same for natural reversal support. Like, you couldn't guarantee that it worked for any client, but now in IKV2, you can. So we've got all these features that are now ready for us to actually much better see what the other end point is capable of and actually use this, because we will need some of those features. Linux XS4M was vastly improved between the early 2.6 and now. I'll go on a little on the sidetrack, actually. When people talked about earlier about bugs that live for seven years, I will give you a bug that is still living. The early draft for SHA-2 in encryption was to use, for SHA-256, the truncation was set to 96 bits in the draft. When the RFC was finalized, it became 128, like half the key size. In XS4M, there's the struct XS4M auth, which you can only specify a key size, not a truncation size. So whoever, I don't know who decided this, they decided to leave the old draft truncation in and come up with a new struct called XS4M auth trunk where you could specify the key size. So basically what they did is they left the default the wrong non-RFC value. And so some software that was actively maintained, like LibreSwan and StrongSwan, they started using this new method and they had no problems. But it turns out that, for instance, if you look at IPsec tools, Raccoon didn't get updated to that. So now we have, what was it that they said earlier, 1.4 billion devices that cannot properly do SHA-2 authentication with IPsec. I tried to convince people earlier to just get rid of the 96 one, or at least allow the 96 one only through the new mechanism with the truncation set. But they decided, I guess, that to be compatible with was already out there to keep it. And I think this really shows that was the wrong decision. Now we have 1.4 billion devices that do the wrong thing. And we didn't have that seven years ago when this was first came up. So if you ever run into a similar situation where there's an old thing and a new thing, try to do the new thing per default and let people deal with how to do the compatibility mode. Try always to move to the new thing and drop the old thing. The other thing that came, because DNSSEC has now started to move to the end node, because you can only use secure DNS if the last one is also protected. So you have to basically run it on your phone or on your laptop to get the full protection. So that actually allowed us to sort of see the DNS lookup and see the name and what it resolved to. And so earlier when I said we only had packet triggers, we only had source destination address. But now if we hook into the locally running DNS server, we actually have a name and a destination address. So then we can go lookup for the key in the DNS or at whatever LDAP or active domain or the blockchain. Wherever you think you can find a way of securely pulling keys, you can pull your keys. And that is an advantage that we're gonna use as well. And Linux contract actually got a lot of new features. So you can actually now match with IP tables. You can match based on if there's an IPSEC policy. You can say this packet can go through only if it would get encrypted or this packet can only come in on port 25 if it had been encrypted. So you get a lot of extra flexibility in there as well. So the only thing that we looked at it's like, okay, we're ready, we can do this now, we can do opportunity encryption. But there was still the one big problem that people didn't really care. So that's until this slide came along. For those who recognize it, the Edward Snowden slide on the NSA, where they said, well, this is all where the plain text lives that we can sniff and this is all where we can add and remove the SSL so we can see what's happening. So suddenly, literally everybody cared and I guess I don't have to explain it further in this audience. But everybody now wanted that data centers protected the cloud instances, there, the MPLS was suddenly, everybody always assumed MPLS. Well, it's just from my vendor, it's secure, it's private, it's not shared with anyone else. And suddenly I would just like, shit, we need to encrypt this as well. We can't trust anyone. So it's really good for us. And for us, we came to the realization that actually, opportunity encryption is the same as cloud encryption. You just want an easy way for all members in your cloud to continuously mesh to everybody. And in a way, it's the same thing as internet-wide encryption, except where you pull the authentication keys from, where it's from secure DNS of your internal zone in your cloud or a public DNS on the internet. It's sort of the same thing. So that's good because now we can sort of look and I presented this to Red Hat and said, this is what we need for the enterprise encryption. And meanwhile, for free, I will get internet-wide encryption. So some of the ITF responses, they first defined that pervasive monitoring is an attack. So any plain text is basically considered a weakness and we must fix it. So that's a good point from the ITF. And second, they tried to define opportunity security. It started with defining opportunity encryption, which is really hard because the original popularity of the term came from the FreeStrom project. And what they meant with opportunity encryption was two parties with no pre-arrangement. When we find out they have a, the other side has a key, we are going to encrypt to that key. And if it fails, we're going to heart fail. What people now mean with opportunity encryption and that's why they sort of renamed it opportunity security is that, okay, let's try authenticated encryption. And if that fails, let's try unauthenticated encryption. And if that fails, we'll do plain text. And of course, if you have a good indicator that there should be mandatory authenticated encryption, you will not do the downwards attack. So the terms are a little bit different. But we're still going with the original. If you can find someone's public key advertised in a secure way, we take that to mean you must use encryption because they publish their key, they don't want plain text, they want encryption. So we first defined a null authentication for Ike so that we could do the SSL model of being anonymous, connecting to a server because that means all our laptops and phones can use this without having to have a key or publishing mechanism or anything. And the second part is how we deal with the NAT. And I'll get back to that. So first, the Linux IP second implementation, basically how it works is you've got a security policy database and a security association database. So one is basically the states between the endpoints, like the gateways, the IP sec machines. And the other table is basically the policy table of source destination addresses that are allowed to go over it. And they're linked with what's called a rack ID. They're linked to two together. So when a packet comes in, it's matched to a policy. The policy links to a state. The state has an encryption of a decryption key and you process the packet and then you send it on. And for each policy for which you don't find a state, you basically generate an acquire to use a land to anyone who's listening to the request for acquires and say, hey, I've got the packet that triggered this policy but I have no state. Maybe you wanna go do something about that. And then the Ike daemon can go, do Ike to the remote peer, set up a state, inject the key and be ready. And meanwhile, you have to do something with the packet you are about to send out or receive. Like the packet you receive does nothing you can do if you got it in the clear. But if you have a packet that you're sending out, then you can prevent it from being sent out. So that was actually a big problem because up until the three something series of kernels, the packet would always be eaten. If we generate an acquire, it would mean the packet is gone. Like it doesn't live anymore. So for things like ICMP or UDP doesn't really matter because the application will resend it. But for TCP, that was really a problem, especially if the TCP time was long, people are really seeing delays. So I was hoping that this would get fixed and actually only find out about a month ago that it has actually been fixed in a three series kernel now. So they actually cache the first TCP packet and once the tunnel comes up, they remember that they cached a packet and they send it out encrypted. So that was a big problem of the opportunistic or the on-demand tunnels in general that we couldn't do that. And now we can. So that was a really good point. So this is how it looks like. So the top half is the policy in a kernel. So you can see in this case, this is me on the Red Hat VPN. They assigned me the address 10, 3, 2, 30, 191 and it's destination 10 slash eight. So that's the IP ranges that are covered. And for all of those packets that comply with those ranges, they will get encrypted by the key from the state that you see listed on. And so the IP addresses at the bottom entries, this is the remote and this is the local IP address. So these are the IPsec gateways and above it is the policies. If you use the IPXFRAM command, you see a whole bunch of policies as well. For instance, we do a thing like we poke a hole for the Ike port. So you can never have a conflicting policy that says, oh, you should have encrypted your Ike packet with IPsec. So we poke holes in. So it looks quite ugly when you do IPXFRAM pull but I simplified it for this slide. So what do we want to do for opportunistic? We want to make sure that every device that supports it can talk encrypted individually to the server. So there's no man in the middle, there are no gateways that collect traffic on behalf of others because even though the original freesaw implementation allowed you to specify a gateway, you could say like the entire slash 24 has to go to data IP address. But since that was defined in a reverse DNS tree, they sort of were authoritative for that IP range. Since that didn't work and we have nothing else, I cannot ask anybody who is authoritative for <IP_ADDRESS> slash 24. So we abandoned the whole concept of gateways. So it can only be host to host for us. But if you're a laptop or a phone, you can go through that or not and you can connect to those servers if they support it. If they don't support it, you'll just get like an unencrypted link which I marked here as red. But you could of course also run it. Like let's say you have a little router at home and all your devices, whatever your smart TV doesn't support this for a while, you can have your little device do all the opportunistic encryption, it will just take all your connections. And since it's triggering with the same mechanism, the netting it does for the internal net is separate from the IPsec encryption it does for upstream. So it will just work as well. So the problem is when you're behind NAT, you have an IP address. Let's say in this case, what did I pick, <IP_ADDRESS>? There could be many people with that same IP address.  If you talk to different people with OE and you have the same pre-net IP address, then how is that server going to distinguish between the two sides? So one solution would be, well let the server assign an address to the client. So now you've moved the problem, right? Because now the server has no conflicts. It can take a thousand clients and hand out a thousand IP addresses and it's happy. But now the client connecting to two different opportunistic encryption servers can get assigned the same client and then it gets confused about what one wants to do. Plus if you do this, you really don't want your laptop to have 10,000 IP addresses for every stream it talks to any remote machine on the net. So we wanna have a method where we don't have to configure the IP address locally and we don't have conflicts. So what we've done is we added another IPsec policy rule you can see in blue at the bottom. So you see the first three is the regular set of the client address obtained. So the 16040.2 was given by the remote server to the client. It installed that policy in the remote service to 131. So it installed the standard three rule policy but then it also installed an IPsec policy from its pre-net IP address. And the only thing we do there is we're going to catch it. We're gonna catch the packet. We cannot actually encrypt using that source address because the remote end would actually drop the packet because it wouldn't match the policy. But we'll use it to just grab the packet. And then in IP tables, we're adding a rule that says, oh, by the way, not this thing to whatever the IP address is that they gave us. So now we basically, we don't have to configure the IP address it only sort of lives in the IPsec subsystem. So the server assigned us an address and it only lives inside the IPsec system. It doesn't get exposed to the machine itself. You don't have to configure it. You don't collect IP addresses. Now the only problem with it is that it sort of interferes with other rules that people might put in the IP table. So because it really only applies to IPsec, I'm hoping that we can push this actually into the IPsec subsystem so that we can do an XFRM call to the kernel saying I want it to be IPsec and added to this third address and then that the kernel will do it all by itself without having an IP table's entry. Any kernel hackers that have nothing to do, please approach me. So how do you configure this? So again, we're trying to make it as simple as possible and so really my slides should just be way too simple for everybody. We're looking still at making it simpler. This is still not as simple as we would like and we've had some feedback from people that said that they find it confusing. But currently we have five different what we call food groups. Block, clear, clear, private, private and private are clear. Block basically means drop all, if you got a packet with this destination, ignore it, drop it. It's sort of overlaps with a firewall so people don't have to use this. It's just that originally when these things came along, firewall rules were still IPFW admin, it was still like prehistoric. Clear means just ignore this packet, just send it out, we will never do IK on it so just send it out. Private means we mandate that it's encrypted. So if it's not encrypted, drop the packet. If we don't have a state for tell the IK daemon to do IPsec, try to set up a tunnel and if the tunnel fails, just keep dropping the packets. Private or clear means try and initiate and if it for some reason fails, you'll just allow the packet to go out plain text. And clear or private is more meant for servers instead of having to try all the clients that connect to it and all the clients don't support it. It will just go into a respond-only mode. So it will accept clear, but if someone comes in with an IK packet, it will go and do, I agree to do encryption. So here's an example, you've just put ciders in the file. So in this case, I have two slash 24s, so I put them in private or clear because I know I have machines in that network that can do it. Of course, ideally, once this gets deployed widely, you can put zero slash zero in there. And you can also combine this with like an enterprise encryption. So you can say, in private, I will put 10 slash eight because that's my local enterprise and they all do encryption and I want it to be mandatory. So the question is, how does authentication come in? And I'll show you a few more bits and tweaks that is the problem and that's why also we're looking at redoing this. So this is the original design which we sort of revived and put in, but we now know that because we do wanna say, like, try to do authenticated and if not do anonymous and we need to have a better way of specifying that. Again, we have an OE mailing list. You can join us OE at list.libersound.org and we welcome your input because this is a hard problem. Like to keep things simple is really difficult. So how does this work internally? Internally for Libersound, this is just an IPsec connection. It's not really different from anything else. So, left equals default route basically means grab whatever the IP address is that is your default route and use that as your source address. Left that is from cert as if you have a certificate just use the ID from the certificate. Just read it in. Oh, so this is the example for an enterprise encryption code. So imagine you have a 10 slash eight cloud deployment. You have, you have Puppet, you've given all your hosts a certificate, right? So then left cert is your certificate. Right is opportunistic meaning anyone can connect and it will trigger this, this special private connection. Again, the remote has its ID from the cert. You just say write CA same. So the CA that's authorized your certificate is also valid for the peer certificate. IqV2 is insist because we ripped everything out of the IqV1 code that had to do with opportunistic encryption. We didn't want to deal with any kind of, so we've, it only works when you force the connection to IqV2. And then here's two of your tweaks. Fill your shunt and negotiation shunt. Fill your shunt is what to do after you fill to bring up an I connection when you filled. You can say drop, clear, and then there's one negotiation shunt. So some people actually find it more important that the communication keeps running unencrypted, but they would like it to be encrypted if possible, but they don't want you to drop the connection. So they don't even want to pause while the Iq negotiation is happening that they don't have a packet flow. So this allows you to say negotiation shunt, either hold us and drop the, hold onto the packets or really drop them, it's not holding them. Drop the packets until the Iq is done and then do whatever the outcome is. Or you can say negotiation shunt is clear, in which case you will leak packets during the Iq negotiation. And we sort of, we like having these options, but we're still a little confused about, we don't really want to bother the users with this because they're going to make the wrong choices, they're going to copy old configs from Google searches. And so we're looking at how to make this more obvious to people still. But it works really well. So this is a fully anonymous IPsec. So this is like no authentication on either side. So you see the only change is really our left ID is null, right ID is null, and auth by is null. And clearly you make sure that you do a pass through because if you don't get anonymous, you will just leak clear text. And then we did one as an example to use Let's Encrypt. So like everybody has a CA that they sort of trust, Let's Encrypt is pretty famous, they see pretty wide deployment. So we're like, you know what, we can use this CA to do our anonymous client to authenticated server. So we just like feed onto their system. So this is how you grab the certificates from Let's Encrypt site. Unfortunately there's one, so the IdentityTrust X3 one, for some reason they published them without the begin certificate and end certificate lines on our website. So I just copied it and put those lines in front of it and put it on my website. So it doesn't make it easier to install it. And there's some commands to read these certificates, import them into the NSS database. Liberswine uses its own NSS database that is like only for IPsec. It doesn't, so it doesn't have all the root CAs from all the TLS servers all over the world. It's just for IPsec. So when you put this in, you're ready to be an anonymous client to a remote server. So this is the demo that I will actually try and show you. But in case it fails, I'll explain it. So the config I just showed you, you can download from that site. You can put the single IP address in the private or clear so that the magnetism will trigger. And then you just ping and you'll see here that the first packet was eaten. The first packet didn't make it and the second and third packet did. And then when you do IPsec back traffic status, it will show you. And so we got the address zero.2 assigned. But again, that address only lives inside the IPsec subsystem. So you don't have to worry about it. And it just works. So this is that client config for asymmetrical. So you can see left ID is null, left office null, left mode CFG, it just means that you will allow an IP address to be assigned. Left cat is yes. That is our crypto NAT solution. So we say yes, you can do this hack with the IP table rules and the extra policy. And then the other side is just a regular ID from cert. I expect them to authenticate by cert and expect that I know the CA in my NSF database. Narrowing is yes, it's just a feature of how IQV2 works with an address assignment. The client basically says, hey, I'm okay with zero slash zero and I'll allow you to narrow down and then the remote server can narrow down to one address. It's okay, but we're gonna make a tunnel for only this one address. This is the server side. So at the server side, what you do, you first install let's encrypt normally. So what this is, I forgot what the tool was called cert com or com cert, like the let's encrypt tool to set up for let's encrypt.  And so we just take those certificates, we put it into a pkss12 file and then we import it into the NSS system for LibreSwan. So now the IP sex system knows about it. You do the server configuration and you put the entire world into clear private so you will respond to everybody who wants to do IQ to you and then you run it. And this is how it looks like. So you can see here, I define the address pool to be 164.01. For those who might recognize the address, I stole it from the carrier grade network people. Since they decided to cause all the problems with that, I decided to take their addresses. They're never supposed to be visible outside of carrier grade networks. I'm never supposed to see them anyway. And it avoids conflicts because if I would, if I would put RFC 1918 addresses here and you're pre-enacted IP addresses also in that range, you get weird conflicts. So this is my way of staying out of RFC 1918 with addresses of people who cause the problems. And then our features that we're planning. So we're planning to add like Kerberos, GSS API. We're going to do the DNS triggers. One of the features I actually didn't talk about, the old clip stack had this vini-nites feature you had an IPsec zero interface and people could TCP dump on it and see all the clear text, all the post decrypted and pre-encrypted traffic. And then when they sniffed the ether device, they could just see the encrypted traffic. And you couldn't do that with XS-RAM until recently when the VTI support actually came in. And now you can use the IP tunnel command to actually add a VTI type device and you can sort of recreate the IPsec zero device. And these two features, this and the opportunistic encryption packet caching for the TCP packet were the two things that were missing for us to finally kill the clip stack. And it's been since, what was it, 1996?  If you want to see the pain of my life, let's see if I can, I was afraid of that. Okay, where did my browser go? That's a new browser. Huh, I cannot even unfold screen my browser to move it to the other window. Okay, so there's a file called in the LibreSan tree, linux net include ipsec kversion.h. That is basically a giant if def from kernel versions. We stripped everything from two, four before, but it used to contain everything from two, four up until the three kernel. Every time you guys changed the API, we had to put a macro in place to support the older and the newer kernel. And so it's a giant if def file with where I learned a lot more about the kernel that I really wanted to know. So let's see if I can move these for a little demo. The other really bad thing before VTI was that if you run TCP dump on an IPsec tunnel that you had set up, you would outgoing packets, you wouldn't see the encrypted version. You would see the plain text version because TCP dump grabbed the packet before it got encrypted. And so after TCP dump saw it and displayed it to you, it would get encrypted, but you would never see it. But for the incoming packet, you would see the encrypted packet and you would see the decrypted packet. That confused so many people that, oh, my tunnel is working half, but half of this plain text like, no, I'm sorry, you just run TCP dump on another machine in between them and you'll see it work. So you'll see here that I've logged into a different machine to avoid that problem. So that's let's encrypt.liberson.org. So we run, I guess maybe people already started doing things. Oh, that's SSH. Okay, hold on. I guess it's showing too much. So I'm not running IPsec on my laptop yet. So let's ping. So we see ping pack is going there. Okay, baseline test. We also predate all the init system. So we have an IPsec command that does all of that and maps to sysv, systemd, upstart. So I never have to worry about like what init system wins today. So that's the file I showed you that is loaded. So now let's ping again. All right, I'll clear the screen here. It's getting encrypted. And so this should scale easily, right? You can put this on all of your servers. Your client will just do it. If you prefer not to have packet loss and leak a bit in the clear at the beginning of your connection, you can do so. If you want to hold your packets and you're willing to wait one second or so before failure or click attacks hits, then you can do that too. So that's it. Questions? Comments? Do I have time? Sorry? We're running out of time. Okay, we're running out of time. Okay, so catch me now always on round if you want. So thanks.