 A welcoming event to give a presentation here, and since I don't know him so well, he'll present himself. Hi everybody. I have a lot of things to say, and I rarely speak English not so fast as Robert Watson does, so I'll try to do my best. A quick overview of what we will see this morning. I quickly introduce Netask and myself. I explain you very quickly what we are doing, how long we live, and some other things about our products. One of the most interesting parts I hope will be how to build a mountain and appliance firmware, which uses some parts of open source. On the last but not the least, how can we work with open source software, operating system, community, and other things. So what will not be in this talk? No source code. We should not see too much technical things. I won't be paying more if you buy each one an appliance, so that's not the subject today, and we will try to avoid tools. So who is Netask? We provide a UTM appliance, so it's basically an appliance which chips a firewall on a lot of other things. Firewall means much more than letting packets pass or block them regarding their IP header. We do very much more things, but that's out of topic today. We live and we work nearly in France, so I may say a few slides like that. Software is developed by our research and development team, so we also do other design, but production is done by other companies. We sell products mostly in the European community. So who am I? Most important things are that. I am a member of the research and development team. I am the VPN project manager. I work on IPsec stack. I am also a kind of pearl on shell guru for Netask, and I do other stuff. I became one of the maintainers of IPsec tools project. I'll talk more of that later, which made me a NetBZ developer since IPsec tools are not exhausted at NetBZ now. I also already did some free basic contributions. We will talk about that also in some slides. You can easily find more information about me on the Internet. So very, very quickly, history. We live since about 10 years. There were five people in the company at the beginning. The first products was called F10, which shipped three 10-megabyte device, 32-megabyte RAM, a very whole free basic operating system now. Stateless packet filtering for the very, very fast version, and already a graphical user interface. 10 years later, well, quite 10 years later, we're still alive. That's very important. Most companies are not alive after such a duration. We are about 60, 20% for research and development. We provide appliance for all, for the very low and to the almost very high end. It's important to note that you provide the same security level for all products. Our firmware is actually version 7, which is just shipped out a few weeks, days ago. We still use a quite old free birthday version. I'll explain that later. We will use a six version in next year. Well, we already work on that, but it will be available for customers next year. We provide a lot of features. We'll see that quickly. We sold about, well, lots of units last year. We are viable in more than 30 countries actually. What are our products today? We provide some products from the very low and to the very high end. These slides come from an internal corporate overview. So you can see lots of things that are left. We have common criteria certifications. Let's see just the very low product, the F25, which ships CPU, which is quite not speed. Well, it's not for that. We which provide two internet interface, not so much RAM and not so much memory, which is flash memory. It's important. These memory were quite lower a few years ago for all the version of products. 128 megabyte memory flash means not so much space, quite slow. Flash memory is really slower than hard drives. And we must limit white access to flash because flash drives do not like writing much more on them. F25 is like that, small. Great. The high end product is ships two CPUs. At about the next version should use a ship of four gigahertz CPUs, one gigabyte RAM, a lot of hard disk memory, hard disk space up to 24 gigabit internet interface. Thank you. And excuse me, but I just came with a picture of it. So that's another slide for corporate overview. So we provide a lot of features. Let's see some of them. So we do fire rolling and intrusion prevention system. That's not detection, that's prevention, that's not the same. We provide the plugins for some protocols which do much more tests on packets. We provide NAT, VPN, which is maybe IPsec SSL. We provide LDAP, including server if needed. We provide PKE for some of our products. We provide a lot of other things. I probably forgot some of them, but we provide a lot of things actually. What's running behind? So that's the reason why I'm here. We provide, we're running a BSD system. Our marketing team calls it NSBSD for Netax Secure BSD. It's a free BSD kernel, which about lots of kernel patch and a few user-only ones. We do not patch so much the user-only file system, but we are doing heavy things on kernel. We also have about 10 megabytes of Netax source, which includes binary libraries and our intrusion prevention system. Most of them are in C, a few of them are in other language. About 30 things we call scone-tribs, which maybe, well, we'll see later. So some of them are already patched. We'll see later that a lot of patch are not there because they are already in the project. So it's important to remember that almost all I just said is available on all products, on the higher-end, but also on that one. That's important. We just have some few IFF codes to tune things that are recognizing the products, mainly for memory usage. So what are our constraints? Of course, our first constraint is security. Security of the code, but we also have to secure our customer's network. We need to do both. We have memory constraints for the allowing products. We must be fast, of course, but we still must secure customer's networks. We must try to root file system as less as possible, still because the lower-end products. We must keep as much as possible compatibility with older products, but no, we do not support anymore in the seven version, the first products we sold 10 years ago. And of course, we must provide new features from time to time. Let's see what's more interesting for you. A few warnings. So you may experience some things if you like to do some strange pipe with your shells. You may also experience some other things if you are not used with your editor. You may still have much more strange things. Hopefully that's not true anymore. And you may still have some other problems. Most of that things have good reasons to accept that one. The shell is a BSD license shell, which is not so fat. And the guy who made the choice do not use inline shell anymore. The editor is quite light and most of our customers don't like VI style. And of course, we have not so much memory space on low-end products, so we just add space for one operating system. Forget everything you know about network configuration on BSD system, because you will actually do configure interface routing, but you will not configure our security engine, which will not let packet pass if it doesn't know they are allowed to. A lot of other things you usually see on a BSD bus system are just not there. So, flight system mounts show one thing which is important, that what flight system is synchronous. Because one, we are not doing so much right, we are trying to avoid that. And I made a lot of years ago some heavy checks, just to do a lot of right and plug the power. And for that kind of test, this is really much more reliable than soft updates. Slash system is on run, because we need to do some modify, a lot of things. So, as we do not want them to be on the slash file system, we put them somewhere else. And for quite all products, we have a hard drive, so we can put logs directly on the product, on the separate file system, because this one can really not be synchronous. A few interesting things on the file system. Don't worry, we have the copyright. Of course, we have KNL, we can be compressed for small products. We have a dedicated directory where we put everything which is done by us. So, it includes a user, well, administrator's configuration. Everything which is related to us, including binaries on how labor is, and any file-specific information. So, I already talked about SlashVar, which includes everything which needs to be generated and changed frequently. So, another interesting thing is still about the size. Update.tgz includes everything needed to create a new product or to update one. So, it includes kernels, system, our binaries, everything. Actually, the turbo is less than 10 megabytes, which I guess is quite small. Memory is a disk usage, excuse me. So, on the quite old product, because you won't be able to buy that anymore. But I still use it. You will see that on the basic system, our disk usage is quite light. We use less than 40 megabytes memory disk, excuse me. This size can be much more, because if administrators use some things like URL groups, you will need to put them somewhere, and it's quite heavy. Interior has the same issue, and it's difficult to have a good estimation of appliance configuration. It can be less than one megabyte. On my firewall, it's really less than one megabyte. But if administrators want a lot of things, it can grow up very quickly. Size of the root file system is model-dependent. It is one gigabyte for high-end products and really much less for low-end products. Of course, we have the size on high-end products, so we just use it. And we also consider that high-end products have more configuration, more hosts on objects, more users in the database, more everything. But the size of our update table is almost the same for all products. We have various tables for various products, but they are almost all the same size. Upgrading is a tricky issue, because we can just do a binary update of the file system. Configuration, file-specific information are on the partition, so we do not have a binary image of the file system, which is the same for each product. We could have do that at the beginning. It would have some advantage on drawbacks. Actually, that's not what I've done at the beginning, so we just have to do with that. It's safer to upgrade file while doing a boot than if our uptime is about some days or weeks. Mainly because during the boot, we have much less open files. That's the main reason. We have some issues with customers. Because when things take time, the best thing we can hope is that the product is not just near the administrator. If we have to move to the door next a few meters further, it's still dangerous. If the product is on the data center a few kilometers in another place, products have a better chance to survive. Too much time is really customer-dependent, so we need to do things as fast as possible. The solution we found some time ago is to do things in various categories. We have a boot table and NSBSD, so now you all know that NSBSD also exists. I'll be at the project status next year. And the firewall table, which are actually not table as are not compressed by JZip anymore. Each one is written to disk and extracted only if needed. Well, needed, not the same already on the firewall. Boot table is extracted before reboot, of course. It includes the kernel. Other are extracted now by custom in its process, which just runs with PID1, which works because I like that the PID1 do the less things that are possible. PID2 will do all update process, then we'll leave, then PID1 will say, OK, update is done. I'm just replacing with the standard in it, and we are continuing things. That ensures that quite no file is open now, but we'll experience some other issues with that, we'll see that later. So, an interesting part is how to do that. Of course, at the beginning, two guys, two three later, it's quite easy to do things. A few features, but that's not in more white, so what do we need? Some things which are completely out of topic today, but we need a repository for our work, an easy way to manage contributions, an easy way to build our source, everything, which includes also some things that are not directly code. We need an easy way to manage patched kernel, so you saw that patch is a good one, it's very heavily patched. We need to get minimal privacy system, I'm talking about user-only tools, and of course we need one command to work them all. Repository for our work, so just we use service for some years, which was good, which are the most important command repository needs. The main problem we had is that commit profile, which was quite an issue, and we needed to do some scripting to get the complete source because we needed some various repositories. We use S-Ven now for quite two years. One commit buffer, that's great, or by effects of course. It was easy to import CVS tree, which is quite important. It is easy for CVS user to move to S-Ven, which use almost the same commands. There's an external feature, I never understood anything about, but which seems to do greatly some stuff. And we still have the most important command for repository system. We need an easy way to manage contributions, so what do we need? We need to fetch, build, and clean contribs. We can install what we need by simple copies. We usually do not need everything which is installed in contributions. We need to be able to update contribs the most easily as possible. Some contribs are purchased, so we must deal with that. Parts must be stored somewhere, and of course they must be used by our build process. We tried for one of two projects to have our own copy of patches source, but that's not a good solution, because it's easy to do our work on that. But when we have to update the contribs, that's a very, very, very difficult job to do. There's another solution. Such constraints are exactly the same as the one free-based support system have. So, they did a great job dealing with that. We just use that, and we just use the free-based support system to manage our contribs. Even for some contribs, we do not have a standard free-based support. We just create some new port for that. What about our own source? Well, for binaries on libraries, we need to build them with various options and specifications. We need to install them in a specific location, we know. And here are the colors we like to compil again things only if that is the value needed. That's makefile jobs. Unfortunately, there are a lot of makefile commands, of make commands. There are a lot of syntax, of various makefile styles, etc. Once again, before doing the stuff for ourselves, we looked at what exists. We just use the BSD makefile and the BSD.mkfile, which do great stuff. Which allow us to have small makefile, which do what we want, which are easy to maintain. We just need a cross-platform make. We choose CMake for some cross-platform works. So, we also have a very heavily-patched kernel. What are our constraints? We need to build and clean it. We'll have to handle various kernel configuration files, but that's not a very big issue. We need to be able to upgrade kernel source when we want, and it must be as easily as possible. And once again, we have a lot of patches. They must be stored somewhere. They must be used by our build process. Once again, having our own copy is not a good solution for exactly the same reason. And once again, Freebase's port system is great for that. So for us, Freebase's kernel is just a port, a country, almost like others. And it works well. Our patch is just in the system-slash-files directory. So we also need a minimal Freebase system. We only patch a few user-land files. So actually, we just apply this patch to the build host, and we just copy them after. We can do that because we have only a few patches. I guess we'll change that if we have more patches. So we know what we need about binaries and libraries. Binaries is quite easy to do, to do it with. But for libraries, we have an issue. It's dangerous to forget an important library, of course. And it's not interesting for us to keep something that's not really useful. So we have a script which takes that. We have all the needed libraries and which deletes those who are not used. We generate a table for those files. We keep the name on the MD5 sum for each version. So we are able to use the exact same one and ensure that it's still a good table. We keep them for years because we must be able to build again the exact same version. Any version, we must be able to build them again. Actually, the ZStarBall is less than 4 megabytes, so we just take the really, really, really needed files. Just one command to hold them all. So we have a just shell script which generates everything, which no firmware or revision we must build, which extracts and builds everything. It's important to keep a correct order for something. Which do the whole stuff that's not the most important. Okay, well, I speak quite as fast as Swabba, in fact. I didn't knew that. So you're working with open source. That's the way I'm here today, in fact. First question is, well, working with open source. Why? How? First, very, very first question. Remember, our main constraint is security. The question which has been asked more time is, do you really use open source for security? Of course, the bad answer is yes. But people want more information. Someone wants to have some explanations for that. So, of course, lots of reports confirm open source is secure. But some others confirm that a closed source project are more secure. Well, that's not an answer. And of course, people can also say that some open source program have an UV vulnerability history. Some open source program are not secure. That's true. That's just true. It's easy to also find some closed source program which have the same issues. I have a theory that says that if it is always easy to find some numbers which will be able to tell what you want. Just take Firefox versus Explorer vulnerability reports. Just change the year you're looking at. Just change the way you check vulnerabilities. And it will be easy to say that one or the other is more secure or is less insecure. So, we're caught up. We tried to find some caught up solutions, caught up answers. So, that's what I did. Who knows anything about C programming here? So, this is an open source program. That's said on the other. Who already saw the problem with that program? Okay, for everybody? Okay. There's a lot of stuff done here, but if you look very accurately, there is a security issue with that program. Then I wrote another program. That's another one. You can check the MD5 sum of the file. That's not the same. So, that's a different program. This program is not open source. That's written. And I have to kill everybody before the end of the conference. Sorry. If you look accurately, this program also does a lot of stuff and also includes a small vulnerability in it. So, that's the only answer I have for such questions. In fact, my conclusion about security is that closing or open source is not the overall solution. Closing source can make things be a little more easy, but that doesn't change anything. If there is a security issue on this source, just changing the license in one way or the other will not change anything. So, closing source is not more secure. Even if it's not less secure anymore, security of the code just depends on the developers. That's the only real answer I found, and I think that's the only real one which is really true. So, now we know we can use open source projects, some open source projects for our clients. First question, of course, does it provide what we want? Sometimes the answer is no, but we could easily add them. Well, we have developers at NetAsk. We can do things. Sometimes it's more easy to start from scratch. Sometimes it's more easy to use another project, but sometimes it's more easy or at least more interesting to take a project which is not what we want, but which can be easily what we want. We can work on that. We also talked about GPL style coding. I told that I would try to avoid trolls, but of course, for such kind of appliance, licensing is very important. Sometimes we just can use GPL style program. At least it was true before the GPL version 3. Sometimes we just cannot. We have some programs on which we are doing modification. Some modification cannot be sent back for via Schwesn. We'll see that later. And sometimes GPL on source header is just good with an enough to not use that. I know that some of our appliance manufacturers do not consider such problems, but we are trying to be a licensed compliance. Of course, one of our questions is, is the code stable enough? Of course, is it secure enough? Once again, the answer can be no, but we can deal with that, we can change that. Sometimes the answer is no, we just have to do other things. How much would it cost us to write from scratch? Sometimes the answer is two days. Okay, let's go. Sometimes the answer is 10 years. Okay, let's do something else. And how much would it cost to use a third party program? Because it's always a solution too. Well, a little more information about how much. How much can be money, of course, but it also can be time. And time is money. How much will it cost to have the functionality we need? But also how much will it cost to maintain it over the time? Our clients do not want something today. They also want us to guarantee that if there is a problem tomorrow, we will find a solution tomorrow in the morning. How much will it cost to extend it one day or the other? We'll have to extend it, we'll have to have things, we'll have to change things. I don't know what actually, but we'll have to do. And of course, if you are using third party programs, what will he have to pay to the third party? So, using FreeBSD, so we use a FreeBSD variant. I'm on time, that's great. We made a great choice. Of course, I didn't have time to add more detail, but of course, that's just a good reason enough. As George on the other side said a few minutes ago, most projects, most appliance tools, phones, I don't know what else, toasters, use Linux-based products like K&Ls. And I guess they'll have some problems caused by the JPL version 3. Some of them already had problems with previous versions. We know that some other products had some issues with JPL version 2. But that was because they were using it at the same time, telling us that Linux is bad, we use it on software. But that was not true. The second version why we did the good choice is because FreeBSD had a good network stack. That's true for years. NetGraph and MPD stuff is also very interesting for some protocols. At the beginning, we could just ship in with the IPF, work on other things and be able to quickly provide a product which could do a basic job. Well, ten years ago it was the job. Now it wouldn't be so true, but we have been able to provide quickly a working product for our customers. Our customers were able to buy it, so we already were able to get money. NetAsk is not a foundation, it's a company. Of course, we need money to work, to be alive, to be paid to work on such projects. So it was very interesting and we had no technical problems to replace it by our engine when it was already able to do the filtering job. A few years ago. Some other reasons, FreeBSD have a lot of ports. I can easily use FreeBSD on my workstation. That's a good reason to use it. We can have our working station at work to choose the exact same operating system as our appliance. I'm not sure if that's also true for some other BSD-based system. Well, at least for me. When one BSD is supported by third parties, most of the time it is FreeBSD. In fact, I don't remember one third party provider that told us you should switch to Net or OpenBSD because that's the one we support. I just don't remember one single situation when we heard that. Of course, the world is not perfect. First drawback, people know Linux, BSD, what that. And some people are most important for us than others. That's sometimes an issue. Product managers at NetAsk have to answer at least once or twice a year to share orders to explain again why we are not switching to Linux. Well, it will be there now with the GPL version 3. So we also have some driver issues. The most important issue is actually related to hardware web support. I also have some minor issues, but I know it will be solved with the FreeBSD 7 version. Of course, some third parties only support Linux. Well, some others just support Windows, but usually we don't have to deal with them. So we're still using FreeBSD 4. Why? First problem we got when trying to switch to, well, actually we tried first to switch to FreeBSD 5. We weren't ready fast enough to release a version with FreeBSD 5. Then we continued switching directly to FreeBSD 6. One of the first problems we encountered we got is that of system 5 star ball is 25% bigger. And remember, we have free available space issues on our low end product. So 25% increase is an issue for us. That's the reason why we started to have a look at other compression algorithm on products. We had some network performance issues. The first test we did with the FreeBSD 5 and 6 showed, well, almost the same value, but in performance loss, that was still a problem. Most of them looks to be related to pulling. I'll talk a little bit more about that later. Of course, everybody in the kernel had to switch for locking system for another. Our prevention engine is in the kernel, so we had to do the same thing. We experienced some crash in all versions. I guess most of them are solved today, but we can keep one or two guys if needed and not leave until everything is fixed. Of course, some of our patch needs to be updated or to be completely changed for a few of them. We also had some save core issue and it is really difficult to debug kernel when you cannot have the save core and when you cannot run KGB. Well, even when you can run it, it's not always easy. I had a last problem. Damn, there was one person which is not here, actually. That's the one I wanted to see. So, I have a problem with the she-home. Remember, we use a specific init to update our products. That update init starts forks to keep the PRID1 doing as less stuff as possible. So, the PRID2 starts by upgrading things. Of course, to upgrade the file system, you need to remount it with write. Well, at least I did not find any other solution. When it's done, my first idea was to say, well, I want to be as close as possible as the normal init. So, my idea was to remount the file system with only. It works. With Freebase E4, it works. Well, great. And then I also added that to our working branch using Freebase E6. It also works, but sometime after doing the boot, we see that FSCK just claims about device which is remounted with write. It is remounted with only. I added some debug, some touch on file system just before or just after the FSCK. The Z file system is remounted with only, but FSCK claims it's remounted with write. I send the mail to Geom mailing list. Is there a bug in that? The only answer I got, the most important and interesting answer I got is, yeah, there's a bug. Geom is in the kernel. And actually, I still do not have a solution for that. So, don't worry. Freebase E6 is great. First, because it's maintained. We need that, of course. And that's an issue. We'll see that later. We have more AdWords support than in Freebase E4. We have ports. Some ports don't work anymore in Freebase E4. We have a better SMP support. One we already know that it will be even better in Freebase E7. Our first bench are very interesting for that. There are lots of other interesting things in Freebase E6. We just don't care for our appliance, but some are very important for our workstations. So, we have also some waste conditions. Support for Freebase E version is almost one year. I just heard that yesterday in the next room, in the other room. We release a major version, sometimes like its share. Well, that's what we would like to do. Sometimes it's faster, sometimes slower. During such a duration, we spend a few times to do minor upgrades. For example, when we switched to Freebase E4.10 to 4.11, it took us not so much time. So, that's good. We can do such switches quite easily. Doing upgrades for major versions takes a lot of time. Actually, it took us more than two years to move from 4 to 6. Well, okay, that's not two years of full work for everyone, but that's still a lot of time. I just heard that Freebase E6.2 or on .3 will come to End of Life next year. Next year, that's when we release our major version using such versions. So, that's a problem. We will still need to maintain, to backport some patch, some problems. Sometimes it's easy to switch to the minor version, switch some weeks before we release, but that's not always easy. We do some heavy qualification process, and such process takes time. We cannot, every time, delay our release to shunt versions. Sometimes we need to release. I have no real solution, actually, except doing some backports. A few examples of what we did and what we will probably do in the future. First, why? Because it's fair, of course, that the enthrower you all expect, and not the answer I can say to my shareholders. They don't care about that. The real answer is because it's more easy to do not have to maintain our patches. When we update, when we do project updates, the last patch we have, the most easy it is. Some code which is in the public project is known by everybody and is taken in consideration when other works on the project. When you are the only one who know your code, other guy will completely break it during the next version and will just not know that they did that. Another reason is because we can have some feedback, bug reports, improved version, some other things. The last version, well, at least for some of us, is to become some kind of member of the community. That's complex, I'll talk about that later. How can we contribute? Of course, maintaining project, doing some problem reports, patch, features, that's the most easy and most visible way to provide things. There's another important thing, really. I started a little bit later. Being there is also some kind of support. I wrote that as a joke when I created this slide, but yesterday evening I had a very interesting discussion with some BAT developer and it is really, you can stand up or join if you want, it is more easy to understand people and to help people understanding you when you talk around a beer or water, than when you talk by mail with people you never met in your life. We could do documentation, let's talk to something else. We also are doing some benchmark. We also provide some feedbacks. Benchmark can be interesting because we have the needed hardware to do such things. We need to do such benchmark for each new product version. Most of the time it's quite fast for us to add standard FreeBSD benchmark of the same thing. We can talk about BASEDES to help people including our shareholders to know that there's not only Linux on Windows in the life, there are also some other things. There are some things we are not contributing. Why? Because that's internal stuff. I guess no one wants to have a patch that adds NetAsk logs to public products. You don't care about that. Nobody is interested in just having our way to configure things and we do not contribute ASQ for now. Sometimes we do not contribute things because we're not sure it's interesting to contribute for other reasons. We avoid as much as possible well ugly acts. I hope we didn't have to do such acts since years. I hope so. But sometimes a patch is just good enough for us because we have some limitations. We know what our customers are doing with the products. We know what we ensure our products do and what we ensure that they are not doing so. Sometimes it's easy to patch for our specific usage but it's more complex to patch in the more general usage. Sometimes we don't contribute because we just don't have time to. Just a few words about NetAsk and IPsec tools. We used Raccoon for years but older version where it lacks a few stability and well it lacks a lot of things. We need to do a lot of work which I did over the year. IPsec tools 4 was far more reactive. Well in fact it was reactive. So some patch were quickly reported and as I already had a spy in the place I got the commit bit since K4 and I'm now a NetBSD developer since IPsec tools is hosted on NetBSD for a year. Some few examples of past contributions well that's not the most important because it's done. Backfixing and wheelies engineering is the most important because that's project life. Other things as future we needed so I would have done then anyways but backfixing, wheelies engineering and yes, auditing and reporting contributing to our patch that's a lot of stuff. Other things are not very interesting but I accepted that one for 3.0 users. I am a member of the team. Why is it interesting? First because I get security report before everyone else. We are working with security appliance that is really important. Of course that's a difficult because I have to deal with other people who want also the patch quickly. That's something to deal with but that's an easy way to do that. The first one to get information. That's great. Of course it's more easy to report my work and a patch that is committed to the public version is a patch that I won't have to maintain for NetAsk anymore. Well of course if there are bugs or other things I'll have to work on that but I won't have to just work on a patch that doesn't apply anymore. That's more interesting. Of course it needs some times to do that and some people already ask me if I would do some direct contribution to NetBSD. According to the menu from NetBSD project I already contribute to that. I consider our most contribute to IPSec tools. Well that's also a NetBSD. That's a part of the NetBSD project. That's true and false. I hope I'll have time to also work on NetBSD's IPSec stack. Some past contribution to FreeBSD. FreeBSD's port of IPSec tools. I'm the maintainer of that port. Some patch to IPSec stack. Some of them will need to look more cluttered like that. Well that are some past contributions. Some other contribution to some other parts of kernel that are not only my contributions but also NetAsk contributions. We'll talk a little bit about... No, it's not on that slide. And a few other things. Expected future contributions. Of course I continue working on IPSec. We'll talk about that in a few slides. Another issue, I think George saw that on the high number of SPDSID entries. Feedbacks on fast IPSec. Now we use it and now we will have customers on the qualification team which use it. Feedbacks on network performance. We have the hard work to do such bench. And we'll talk about putting system in a few slides. Hopes of some problem reports for ports. And I hope some other things. I still don't have an hour. Yes, well next time. Can I just finish very very quickly. IPSec. So we'll talk on a private discussion about that. There are a lot of problems with that. Just an information. There's an SPDCache code in Flavio Z6. It doesn't seem to work. We did some bench with and without it. It's the same. So we'll have to do things with that. Pool next generation. Fabien is here who worked on that. So there's a mail on the mailing list. You can see all sort of information on the mailing list. You can see the architecture. So Fabien will explain that to you. For those who are interested. I would just like to spend two minutes. I guess two minutes on that. I started out at quarter past 10. Please. Not to the self suppose. Not to the self suppose. So the information is that the first patch was provided some years ago. On the 3bsd is actually the only operating system that not provide not to the self suppose since years. I told that with George yesterday. And we noticed that in fact this may be just a delayed issue for most of the time. So we'll work on that. Some social engineering. What's mine of contributors? Most of the time. I'll do that tomorrow. It's not so simple. Committers mind. Of course it's more interesting to work on our own job. Of course I'll have a look at it tomorrow. I am also the maintainer of projects. So I know what that contributes. Most of the time it's just available time. And sometimes it's memory. Committers constraint are exactly the same. We have extra context. Sometimes as an employer I can spend quite all the time I want. Sometimes I just can't spend no work time. And some things I can switch from one situation to the other. So I have the same problem. Time. Most of the time problem is related to time. Even some of us may have social life. We can't punch day to have 48 hours. So sometimes we just have communication problem. I think we all, you do not, I do not. We all need to improve things and faster things. Keep an easy track of problems. One of my mistake was probably to not do a problem report at the beginning of natural assault patch. Find an easy way to tell I don't have time. We all have that problem. A few years ago at BSDCon there was a question. Is it time to, do we need, do you need? I am not a member of one of BSD project. Well, not that one. Is it, do we need to grow up community? I don't know what was the answer. I'm not sure then sure would be no today. Another solution would be something I often do on IP sector is to commit but be disabled by default. I just ensure that when it's disabled it does not break anything. And I want people that we did not test that. Please avoid moving to a Linux style development. Linux does that well. My conclusion, I'm quite on time. It's possible to make business with BSDs. It's possible to make a security device from BSD. Of course. It's possible to do business and contribute. That's interesting. But some things will need to be improved, I hope, I guess. And I think we will all take benefits of such improvement. BSD projects will take benefits because they will have more manpower. That was asked a few minutes ago. Well, an hour ago now. We will gain from that because it will make our job much faster, much simpler. And I don't like wasting time maintaining one patch when I can spend that time doing other things. I guess committers don't want to spend time just checking that patch which is talked about for years has just changed one million minor things. I guess you also want to work on other interesting things. And I guess we actually all waste time which would be spent in a more efficient way. So I guess questions will be done out of the room. I already knew that I wouldn't have time for that. Is there just one fast question on which I could answer quickly? No, it looks like nobody has questions. No! Thank you.