All right, let's get started. I figured out how to present our point on my machine this time. So hopefully it will work. I just used bra lines. Okay. I actually went to the wrong classroom and then had to sprint here. But I ended up in WP carry. It was here, right? I ended up at six. Awesome. Obviously I'm not Adam. As much as you might all just not meant to be. I'm a young. I'm here. Today and Thursday. I made out and go to London. So this is the payback. So. Another confirmation. This is where Adam ended up. Since, since getting. Yeah. Paper. So let's start back up with. Also known as half open scanning. I've never really heard of it. I mean, it is also known as. And that makes sense. I've never heard of it. Have you seen a. Yeah. And all of these classes. Oh, you did. Perfect. Okay. Sorry. We are. You're at the same flooding attack. You did all this fingerprinting. Yeah. To be spoofing. To be hijacking. To be spoofing. To be spoofing. To be spoofing. To be spoofing. To be spoofing. To be hijacking. I see. Sin flooding. Okay. A different type of attack also. Has to do with sin. Packet. With. Sin flooding. And with a lot of other. Denial service and tax in general. The. Attacker takes advantage of this concept. That for many operations. Something that is very easy for the attacker might be just a little. And so the attacker. In this case. Open the connection. To a normal server. All the attack has to do is send a sin packet. Right. If the attackers are planning on actually connecting. To the. The system or doing. Anything with that. They don't have to. Actually keep any state. They just send one packet. Whereas the server. If it is. Trying to. Actually handle the action. It has to hold some states. And say, oh, I got this in packet. I'm going to respond. With an act. And I'll wait for the. All right. I'll respond to the sin act. And I'll wait for the. Sin packet. I'll wait for the. Sin packet. I'll wait for the. Sin packet. I'll respond to the sin act. And I'll wait for the act. Right. In order for. The server to be able to connect. That initial sin. With the. Act that finishes the handshake. He needs to hold some state. You say, okay. I've received this thing. I'm waiting for that for that. I received this. I went for that. I received this. I went for that. And as the attacker sends more and more sin packets. The defender runs out of. Resources to track. Right. This. Each sin packet might take a time to memory. To track. But in aggregate, they add up. Right. I have any of you try to. One from your machine. And seeing how, how many packets you can send them a second. Let me show you. This used to be all the rage back when. I was. Now base. There's not much that. My machine could do to overwhelm the server just by flooding it with, with. Back in the day before. Network cards would actually handle a lot of themselves. Before a lot of this stuff was. a server with a pink flood, right? Have you talked about ICMP in this class yet? So just another type of packet, a type of protocol, PC, UDP, their other one's ICMP is basically a... Just a protocol to... Off the top of my head, I don't remember what ICND stands for. Do you remember, Max? ICMP? Yeah, they're that connectivity management protocol, something like that. So it's basically to test connectivity, right? So if I ping Google.com, of course, who are here has done the ping? All right, perfect. So if I ping localhost, this ping's localhost, I respond. And of course, when you do ping, you send one a second. You can also ping flood. This floods my local machine with things and every dot is like 10 things and it's deleted when the response is received. So you can see just from that short time, they took me to say something, it was 690,000 packets were transmitted, right? That's a flood. I can also ping flood Google. This isn't very nice, but we're not nice people here. That was much slower, 477. If I remember correctly, the thing utility rate was based on how many packets I've responded to or something. But you can just flood packets. No one's stopping you from that. Except for eventually, if the network admins are paying attention, you will get a drop off the network. But that's okay. Anyways, the point is it's very easy to generate a lot of packets. In the same way of generating ICMP packets with ping, I could write a very quick program in Python just to generate insane amounts of SIM packets and seminal. If for every SIM packet, the server weighs just four bytes of memory, then in a billion packets, I can exhaust four gigs, which is quite a lot. And realistically, these early servers, when this attack was relevant, took more than four bytes to act at some stage for an additional SIM packet.  And the server is just waiting there with the messages on red and whatever. So this is what it made a problem. How do you fix this problem? There are a number of things proposed. One solution was filtering. So you say, OK, we're just going to sit on the network and say, as some sort of a monitoring process, running on the server, on the server, whatever. They say, OK, there's two names in packets from this host. But that's annoying as false positives. You're going to increase the limit of the people at use. They say, you don't actually accept arbitrary amounts of connection. You only support 100 half-open connections at a time, and then future connections are just rejected. So this is 1.5, the solution number 1.5, as we get two solution dues. What's the problem with that? So you need to take down a server and others. Yes. Then I will serve. So now you've taken down from taking down the server or life. Because it runs out to taking down the server because it's off the network fundamentally because it's not accepting connections. That's not much better. So you could also say, OK, well, then we're just going to have a really long queue. But it turns out, realistically, these sort of things, that no matter how long the queue is, the attacker will be able to exhaust it eventually. You could reduce the timeout, after which you will forget about that half-open connection. This has some problems. There are, again, false positive rates. There are legitimate issues that might cause a fine lack of the handshake to arrive well after that SIDAC was set. SIDAC and TTP is supposed to support that. So you don't want to do that. You could have a kind of round, what's it called, a loop instead of a queue, where if you get a new connection, you drop the oldest connection that's half-open that you haven't finished the handshake with at a server. You might get away with that, but then this has similar issues running in the attacker, plus a lot. You will still start dropping network connections. You might limit per source, but as you've seen, it's trivially easy to spoof source references. And the final kind of concept that is being adopted was syncopes. Syncopes are described in this document along with some other ideas. If you are really passionate about these attacks, you can read this document. Who wants to have a reading class? So you should tell Adam when he gets back. RFC 4987. Tell your friends. So let's talk about syncopes. This is the solution that's typically used. I actually never really verified myself with the solution that's used. That's just what everyone says. So you can take a look, but it seems like a good solution. The basic idea is that the sequence number has some amount of bits that you can use. And it used to be that the sequence numbers were nice and monosonicly increasing. And so they roll over. You see issues with that, and so forth, with predictable sequence numbers. But the basic idea is that you use that sequence number as a sort of cookie in your syn packet. And the cool thing here is that this doesn't require any changes to the protocol. The TTP protocol doesn't say the syn number has to be blocked. It can deal with pretty much any initial syn numbers. And so what you do for your first sequence number, sorry, for your sequence number of your first syn packet is come up with a scheme where the top five bits is your counter. It's a five-bit counter. The following three bits, some other stuff. And the important thing is the rest of it, it's a key hash, a keyed hash of your counter. That's the first five bits. And the idea is an enforce of the source and destination. So you have basically a unique identifier in your sequence number that is keyed. So it's not easily reducible, ideally. You still remember keyed hashes and what's called HMACs and stuff, similar sort of concept. And when you create your first sequence number, you set it to this. And suddenly, you don't have to hold any state because you encoded all your states in a sine way in the syn sequence number. So when you send back a syn act, you send your syn cookie, your sequence number along with it. When you receive the act, you can look at that sequence number and you can say, hey, did I generate this sequence number? And that's very, very easy to do.  Let's go back. Sorry, sequence cookie is simply here. You look at the top like this. That's your T. Now you have your T. You have the source and destination added to that force. You make sure that the T is kind of makes sense for the time period where you received it. And then you can basically verify that the syn cookie that you received was one that you would have sent. And then you say, OK, connection established. And you don't have to worry about half open connections or anything. You just don't try that anymore. The ability to send this sort of not cryptographically secure secret, but like some sort of a secret that is then returned back to you makes it not necessary for you to store state. There's some drawbacks. The sequence number is a little less kind of normally predictable. I'm not actually quite sure why that's a drawback. Definitely not really a back hole in the modern internet. The maximum segment size, now you only have to read this for it. But that's also kind of OK. Eight possible values. Realistically, networks aren't sold in same variable that you need very granular control of that stuff. And then you can't send any data at your initial syn packet. Otherwise, what you get back from the server or your SNAC, otherwise, what you get back from the client will have a SYN that is a little bigger than this one. And that is basically a price you pay for this sort of denial of service protection. Any questions on sympathy? Oh, so let's do some board work. I just noticed these nice boards don't even. They'll go through an attack. And I'll try to get this in a place where it's kind of recorded for you guys. But then you probably can't see it. Hold on. Well, that's not better. Max, do you want to come hold this? Awesome. Maybe that table also moves low enough. Really? Who said that? Extra credit. Tell Adam. Max, thank you. Locations from Adam live. Maybe he's watching. What's the? OK. So let's say you're the server. This is a server. And this is your connection state for half open connections. Your server is your queue for half open connections. And an attacker starts at the use in packets. Right. S0, S1, S2. For every SIN packet, without the use of SIN cookies, you have to respond as a server with a SIN act. Right? S0, S1, and S2. And for every SIN act, you have to come up with a sequence number that you need to track. Because this server is going to, or sorry, the client, if it is not a malicious client, it's going to rely on those SIN values during TCP communication. Right? So you need to remember the next packet you send what your old sequence number was. So in fact, for every connection, every other connection that is successfully established, your server or your machine will track the sequence numbers in the kernel and continue to do so for the length of the connection. So whenever you receive this, and then, of course, wait for that final act, you need to store a sequence number here. Right? So this is your local sequence number for connection 0, local sequence number for connection 1, and so forth. Right? And do you understand how if you never receive this, how just getting more and more packets will end up, we're getting more and more SIN packets will end up overflowing this and basically running your system out of resources. Right? Cool. So there's nothing you can do about storing some resources once you've accepted a connection, once the connection is live. Right? But this is super easy for the attacker to do. It just takes one packet. There is no connection. So if you can avoid having to store the resources, it's better. So if you, instead of having this, you still have your queue but only for actually established connection. And in the meantime, you have a secret K that you can use to essentially sign, not securely, but pseudo-securely, sign a response in the SIN act and send it back. So when you receive a SIN instead of actually generating a sequence number and storing it here, you generate a sequence number in a predictable signed way and send it over. The kind of signed way, in this case, is taking the source and destination IP access, some number T that is also included in the sequence number and passing it in a keyed way that you can verify later. And you just wait for the attacker or the client, maybe they're not an attacker, maybe they're actually a good guy. In the case of the attacker, the attacker will just never send you an act and everything is fine. You don't care because you don't have a state that's being wasted. In the case of the actual client in the case of the actual client, the client will send you a SIN.  And the client will send it back to you in their response. They'll have your sequence number. And then when the response happens, you process that. You validate that the act has a valid sequence number because you can validate it because only you can generate that hash secret. And then and only then do you add connection three to your queue or to your internal state. Does that make sense? Any other questions on this? Awesome. The cookie is the sequence number. Yeah. It doesn't require any modifications to the protocol. So now we can turn this back on. That was fast. All right. So moving on to other TCP attacks. Of course, the SIN flooding isn't the only attack that's happening to other things. As I mentioned, you still can't really get away with keeping state for actually open connections. There's no magic bullet there. You still have some amount of memory that is taken up by an open connection. Nice thing is that open connections are a little easier to track, easier to reason about. So you can deal with that. You talked about why open connections are needed to track that means half open connection with SIN scanning. You talked about how SIN scanning flies under the radar or some internal protection systems. So with the same attack, conceptually, as this SIN packet flooding, you can also check it before developing. You send a SIN packet to a specific port of a server. And then if that server is open, it'll send a SIN app. If it's closed, it'll send a reset. Using that, you can figure out which ports are open without having to do the full connection. One advantage of this is that a lot of intruder detection systems don't count, or now they probably do, but back on this with Java, didn't count that as a full open connection and wouldn't fly due to get away with your port scan without triggering in that scenario. So anyways, for those reasons, the fully open connections they're tracked a little more, and you can't really get away from having something out of memory usage there. Anyways, there's not much we can do about that. Even worse is a lot of systems, let's say, I have performance web servers, might spin off a thread or a process to deal with each incoming connection. So that's quite a lot of memory use. There can be an interesting attack where there are actually all sorts of attacks. But one other thing is when a server sends you some data over TCP, it needs to be ready to resend it in case that packet is lost. TCP is resilient like that. But that means it needs to keep it in memory. And so until you send the hack, the server has to keep that data in memory. That's another interesting attack. There's other ones dealing with fragmentation on the IP level. I think that's a little deeper than what you really need to be familiar with. But there are attacks generally how other ways to kind of exhaust resources of a server as you're attacking it. Not that I'm saying that you should attack servers. All right. So how do you protect a network or protect a server? Who here uses a firewall? Who here has a home router? So if you have a home wireless router, then you'll use a firewall or at least been. I mean, really, everyone period has been impacted by firewalls in the modern world. But if you have a home router, then you own a firewall and you actively use it every day. The firewall basically says, OK, what should be blocked and what should be allowed? What is an attack? Generally speaking, firewalls work on a synchronous model where everything going into the firewall. Actually, switch back to here. We'll redeploy this. There we go. We're doing that in time. OK, I think we're doing OK. OK. So this play the network diagrams is like a brick wall that's on fire. And your machine is here. The scary internet is out here. And the scary internet might attack you, right? And this applies to, of course, your house, but it also applies much more painfully to library computers, right, your ASU and so forth. So generally speaking, you want to be very careful with things coming in that you don't expect, right? So if something on the internet is scanning for whatever to try to exploit the latest vulnerability, you want to make sure that when it connects to you that unless you are actively trying to expose something to the internet, it stops, right? At the same time, you want to make sure that someone sitting inside the firewall isn't super negatively impacted by the presence of the firewall. So generally speaking, you want to allow anything going out unless it just actively looks super weird and then there's a question of how to detect that. We'll move on to that next. You want to allow it to happily connect out. And then, of course, you want the response to come back to you as well, right? So this is an interesting sort of problem with some applications you'll get into. Basic idea is, how do you create these firewalls to allow this to happen without making this a huge pain in the butt for everybody? Basically, what ends up happening is by default, a firewall tends to close all ports nowadays and this applies to your home wild shrouder. It also applies to the Windows, whatever they call it nowadays, Windows Defender Firewall, where by default, either you or an application that is listening on the port has to allow the ports through. And who here has had to forward a port for a video game or something? Exactly. And that's what you're doing when you're forwarding a port. You're basically creating new firewall policy that says, on port whatever, this is actually counter-strike when it does, right? And then we will allow incoming connections on that port. Oftentimes, nowadays, this is done in kind of an automated fashion using a protocol called UPMP. Basic idea there is using UPMP, a program running your machine and say, hey, I'm actually trying to play this game and I need this port. It'll talk to your router's firewall and forward that. That's, of course, some residential connections, connections that are corporate, much less forgiving. But I can tell you, you can still play a lot of games from my industry base. What's up? So basically, when you're doing your traditional home routing, you have one wireless router and it has one IP to that side world and just makes everything behind it look like it's IP. You can really only have one service on one port so you've got to choose. An interesting thing, actually, when was this class end? 1.15. 1.15. All right, let's go on a quick tangent. Did you guys talk about UTP? So I'm going to take you back to this firewall example and here's a question for you. So let's say you're here on one side of the firewall. Someone else is on the other side of the firewall. This is what the firewall considers internal, right? So this is inside your house. This is someone else. Maybe they're even behind a different firewall. Worst case scenario. And then there's the internet between you and this is what their firewall considers to be internal. You want to talk to each other, but you don't have the ports open on this firewall and they don't have a port open on that firewall, right? Or maybe they, and if we get to the more complex case of later. So you don't have any ports open. So how would you fix this situation with TCP? First, I'm going to tell you how a firewall works or a masquerading firewall works. This is the case where to the outside world, you appear as one IP address. How masquerading firewall works when there is someone behind it, I said two people behind it, talking to the same service outside. So kind of the inverse scenario, what it was just asked. So you go through the firewall and you talk to Google.com and this person goes through the firewall. Talk to Google.com. How does the firewall know when Google responds who to send that packet to? Obviously, multiple people on ASU's network can go to Google.com at the same time. So there is an answer. Let's give them some of your firewalls. Yep, exactly. So you create a, when you create a connection, every connection has a source port and a destination port. So you have a source port and you have a destination port and the destination port is for the AD, let's say, and you're a friend of the source port and the destination port. The destination port is the same, but the source port is not. So when Google responds, they will send a packet back on each connection to that connection's source port, right? Or now the destination works, they're sending to it.  I know where port S0 is. Port S0 is person A. If it gets a packet to port S1, it says, oh, I know S1, that's person B, right? That makes a lot of sense. So how can we apply that scenario to allow communication between person A and person B behind two different firewalls? I have at least some note in the work of the other department. Let's say there's no port S0. Of course, yes, if a person had a port open, that was configured to, you know, so I can traffic to them, that's nice and simple, right? You just talk to that port, boom. What if that wasn't the case? Inject essentially a spoofed state into the firewall, right? So this firewall, when these connections are made, it says, oh, okay, S0 is talking to D0, port-wide. So inside here, there is some sort of a status that says, okay, A, open up connection from S0 to D0, B, open up connection from S1 to D1, and so forth. And this is the table that is queried when Google.com responds. But you remember UDP, right? What's the difference between UDP and TCP? So let's say that's a drawback, what's an advantage? Or, I'm sorry, faster speed. Faster speed, why is there faster speed? There's no chats.  Because that's UDP, UDP's supposed to work with that. So if I'm A, and I'm talking to, what's another hit question, Reddit? If I'm talking to Reddit, I might send a UDP packet.  Well, other than that, I can send a UDP packet just like I send a TCP packet. So instead of Reddit, let's talk about games. Those use a lot, or VoIP, or something like that. So let's say Skype. This isn't very good. What's the hate version of Skype? This is Skype. What? Discord. Oh my God. Don't tell anyone, oh, it's Discord.hiki, right? Or something? I will at least look presentable. Okay, you want to talk to the chat for gamers. So you send a UDP packet from S0, or let's say S2, to D1, right? And here, the awesome thing is, as far as UDP is concerned, there's no connection handshake. You just start sending data, right? You send a datagram. The server might or might not respond to the data, and you have no way of knowing it. You have no way of knowing if the server's even listening on that connection, right? But in order to be a good firewall, because above all else, firewalls and routers, they need to be able to not screw up your traffic. You need to, your connection needs to be usable. This mastering firewall has no choice but to lock that connection over UDP as having, as being active, right? Maybe there's a timeout, but it'll have to lock. So it's advocating S2 to D2 goes to Person A. At Person B, you can do the same thing, of course, right? They can say, okay, S3 to D2, D3 over UDP goes to Person B. And again, the server doesn't have to respond. The server doesn't have to have a connection open, but there's no way to really check. So how would you use that to enable communication across two firewalls between two people? So the first part is absolutely correct. The TCP part is not. UDP and TCP are two different worlds. I grew two different squares. They should have been more specific. The connection also has its protocol. So you can have the same connection, or the connection between the server and the network. So you can have the same connection between the server and the network. It also has its protocol. So you can have the same connection between the same ports on a different protocol. The firewall will see it as two different connections, but you're right. All that A and B have to do is agree on a port, port X and A sends a packet from port X to port X. And obviously there's going to be two different numbers, from X to Y and then mirror it on the other side. But let's just keep it easy. From X to X, send it to this other person's firewall.  I have no knowledge of it. But this firewall says, okay, we'll record that A is talking from port X to B port X. And then person B, like you said, does the same thing in reverse. Person B says A, okay. Let's make a connection from port X to port X. And person B's router says the same thing. There is person B is making a connection from X to person A or X. And all of a sudden you have created a bi-directional connection with the agreement of both firewalls, even though there were no ports open. So you punch the port X through the firewall between A and B. And now you can communicate directly. Skype used to use this. I think nowadays Skype might just be a centralized system, but I'm not positive. Don't quote me on that. It could still be this style peer-to-peer. A lot of fire sharing platforms use this games. Don't tend to use it. It's considered fairly impolite. But using this, you can create a UDP packet, a UDP connection as much as a UDP connection exists between two devices. Very easily. Pretty cool, huh? This is still pretty predictable by ideas and stuff. Like you'd be like, oh, that portal. Yeah. For sure. This is especially like this pattern. I guess if you're careful about it, you could just make it look like any other UDP communication. Right? If you don't choose the same source and destination port, and if you often have to make this work, the two parties just flood each other with UDP connections until the states line up in the firewalls. If you don't do that, it's less accessible. But that's typically done or not. I'm actually sure why that's done. On paper, it doesn't seem like it'd be necessary because usually there's some timeouts and so forth. Other questions on this? Cool. Good insight. That was like immediate attack development. Moving on from firewalls is intrusion detection system. Intrusion detection system. We'll monitor all communication on the network for some large amount of communication on the network and try to say, oh shit, we're being hacked. My question with intrusion detection system is how to specify what being hacked looks like. Let's talk about some questionable UDP traffic being flooded from one port to the same port. Might be a questionable thing that might raise an alert for some human effort panelists to look at later. But there could be other ways to detect the tasks. For example, you might look at all TCP connections coming into your web server and try to match with all the signature for an expert. So typically, an expert has some sort of a detectable vulnerability to explain vulnerability or to send it, especially a crafted data, to attribute a vulnerability in a service. And you can, of course, have an IDS that looks at all data that comes across and says, this looks like the type of data that we have seen triggering this vulnerability in other analyses. So that's probably a guide. An intrusion detection system detects attacks and raises an alert. It doesn't actually stop the attack. An intrusion prevention system will actually stop the attack if it detects. These are more complex. Generally, you might have an intrusion detection system on the server and actually looks at all the data that's received before the server can process it. Whereas an intrusion detection system might just simply set up a network. Yeah, absolutely. So you put a, for a honeypot, you will put up a server on your network that shouldn't ever be connected to. And then you see, oh, someone's connecting to the server. This is either a very curious employee or an attacker that is scanning that network. Yeah. So that's a good example of an intrusion detection system that's non-traditional. Traditional ones just will monitor traffic and say, oh, the traffic looks weird. They're more active things like the honeypots. And then there are more heavyweight things like intrusion prevention systems. Interestingly, there is this new class of systems that have come out. I've gotten very popular, I would say, in the last eight, nine years now. So that actually sounds pretty silly saying it's new. But it's called the reverse firewall. Traditionally, I mentioned the firewall. The only thing concerned is what's coming in. A reverse firewall is actually more concerned about what's coming out. The idea behind the reverse firewall is you're going to get hacked. An organization the size of ASU, for example, an ASU is the size of a large company, is just you're going to have compromises. There's zero way to prevent this. NSA has compromises. You're going to have compromises. As in security compromises where hackers get on your network and are able to auto-release. So what you need to prevent from happening is those hackers begin to exfiltrate the data. So you do your best trying to keep the hackers out. You assume eventually the hackers will get in. And then you have a firewall that says, okay, but once they're in here, they're not getting out. They're not getting back out. And there's various techniques that you can use for that. A lot of, for example, botnet infections that have known command and control servers. So you can prevent communication out to the command and control servers. You can prevent communication out to popular data exploitation sites, all of this sort of stuff. That's a very active area of at least entrepreneurialism. There's a lot of companies in this space so a lot of money is being spent. Whereas intruding detection systems, traditional ones, have kind of had their big data back in the 90s, early 2000s that have mostly been standardized into boringness, let's say. Although with the rise of AI, now you can say, hi, it's an intruding detection system but it uses artificial intelligence. People still pay a lot of money. Hi, where is networking research nowadays? These slides are probably five years old where everyone first built them. But a lot of research actually is happening in software-defined networks. So everything you've learned about networking so far, at least in this course, really assumes that you have a physical switch that someone sat down and plugged tables in in favor. There's this worldwide network of physical switches that are all hard coded to be plugged into each other. This is less and less the case as software-defined networking rises up. The first kind of cracks in that perception was the rise of the cloud. So once you could boot up virtual machines on Amazon AWS, and later on it's out to Jir and Google for QdEntion and all of our app spaces offering and whatever, and you could also create virtual networks to connect these computers, people started thinking you need to have these very strict network policies applied to other switches that are physically plugged into specific other switches. And all of this is designed ahead of time and overseen by grumpy old men with big ears from the other networking in the 1980s. And people have been making moves to change that. To, for example, come up with an architecture where maybe instead you have, you started your switches, but they're all plugged into every other switch. And in software you define how all of the routing works and what switches they actually communicate with. And this introduces an industry new attack surface which is the controller of that software-defined network. They're called SDM controllers. That's another machine that is actually making the decisions talking to the switches and updating dynamically routing rules and access control rules and so forth. That's a new area of research that, for example, they're pursuing in our lab as well. Actually, Adam is in London, along with one of our students to present a, what do you know about the lab? Last year in Toronto, we presented a paper about software-defined and routing attacks and we're working on some follow-up stuff right now. Firewalls, you're still seeing research into firewalls and including technical systems. As I mentioned, big data and machine learning has started making its way into this field as well. And the idea is that you've been, if you need big data, firewalls and network traffic stuff, that's very big data. Maybe you can use that to identify attacks and so forth. Honey net, for example, and honey pots and honey controller and the products of all types are big research areas in networking. Research. IPv6, who here has heard that they're running out of like 94 addresses?  I've been hearing this for 20, I'm not committing this up for 20 years. Let's say 19 years, ever since I built my first server. I'm sure it'll happen. I'm sure it hasn't been happening and just like being resolved and so forth. But eventually we'll all be running IPv6, which will do away with a nice, you know, blah, blah, blah, blah, blah, blah, IP address system that you're used to and all familiar with and introduced an absolute freaking monstrosity of hexadecine numbers and colons. IPv6 is terrible, but it's definitely a little painful to get adjusted to this. Has that been talked to you about DEF CON? Yeah. Yeah. So one DEF CON, I think it was 2012, maybe 2011, spent all summer preparing, literally all summer.  Ready. Our automation was so incredible. We show up and instead of IPv4, it's IPv6. And nothing worked. It was so disheartening. A friend of mine quit grad school over there. So IPv6 can be painful. If you don't prepare for it, get ready for IPv6. And then IPsec, but more generally ways to secure communications on the internet. You talked about crypto, of course. IPsec with this idea that what if we have encryption on the IP layer, right? So when you reach out to a server, you immediately, all communications with that server would then be encrypted. This turned out to be a huge thing to ask because of many reasons, right? Basically fragmentation and different solutions on the layer right on top of the IP layer. The IP layer is kind of a pain. You can imagine it. Every major company that sold on networking appliance, I don't understand. This doesn't exist, but this is what's happening with IPsec. Instead of the true promise of IPsec, where you say, okay, bad IP all communications will be secure and instead have VPNs. We are using the VPN. VPNs basically create a virtual networking device on your computer. All traffic to that virtual network device gets routed through a UDP or TCP connection over normal IP space to a server and then out from there. For now, that's the actual reality of securing network connections. And who knows what's next. It's a lot of... If I were to remake this slide today, a lot of this 5G, you know, next generation wireless networking stuff. 5G heavily uses software defined network. For example, a lot of very interesting security properties and the networking properties with slicing pieces of networks across the world. So your phone could be on the same network IP-wise than it is when you're at home, even though you're across the world and so forth. It's an interesting security space. And a lot of new low-power devices. So since, let's say, five years ago, Bluetooth low-power has gotten super big. Everything is like with Bluetooth low-power thingy. You're talking over that with your scooters that you ran and so forth. So the big area that also has a lot of network relevance basically Bluetooth is essentially also networking protocol on top of connecting your headset. Any questions about networking? No? It's perfectly clear. Who's excited about it? There we go. Three people. Let's do it. No, it is good. I don't know. I feel that people don't get a lot of exposure to networking. When I was learning about computers, that was like all the rage. Everyone had like a TCP flash ID on their resume. And like literally skill, colon, like gardening, comma, karate, comma, TCP IDs. You can also put that down. But karate classes are probably next semester. Yeah, if I had to guess, that's why. Even when I was in undergrad, I didn't have an everything class environment. Yeah, I think it just started working so normally that just normalize.  You know, make the server listen to TCP or UDP, understand the location. Nowadays, everything is HTTP. So if you're even moved beyond that, no one even learns what they should speak for. Everyone just uses REST APIs, right? And all of their services. You can get away without ever making a TCP connection to a database. You spin up a cloud database in AWS and you talk with it over REST. I'm not saying that's a bad thing. I think it's actually a very nice step. And whenever I make anything that's distributed, it's all over TCP. But it's very different. So yeah, I don't know. I don't know. Do we have like a web application development course where we have REST API and so forth? Yeah, exactly. So that's where things are moving toward from like core network. I think this stuff is still very cool, but it's very cool in kind of a hacker way, not always extremely applicable in your daily life way.  And so you can still get internet if you put some effort into it. Cool. Okay. It's 111.  Next. Class can dive into application security. So this is where you get super in-depth. We're going to talk about assembly. We're going to talk about processes. I'm going to be pretty fat. What is the meaning of this? I don't know. That's a big explosion. No, that's a big explosion. Yeah.


What makes for excellence in heart care? It starts with one of the most amazing teams of heart surgeons and cardiologists that I've seen assembled under one roof and the region's leading technology in a new 40 million dollar facility. This is the nationally recognized Heart and Vascular Institute of Eastern Kentucky at Pikeville Medical Center. The Pikeville area family YMCA continues to host their weekly Wellness Wednesday event to everyone's satisfaction. On March 8th, Pikeville Medical Center made an appearance to further spread awareness and talk about the importance of cancer screenings. By hosting these events the Y is doing their part to make a more health conscious community. So Wellness Wednesdays we really wanted to focus in 2023 on health and resources in the community and truly to be to be invested in the community have to be collaborative and so you know we are a health and wellness organization we're a youth service organization but we also have space and we have traffic through the facility where other community partners can come in and talk about their resources what's going on at their businesses so it's like really a one-stop shop. So I thought it was really great that we partner to do Wellness Wednesdays and we bring in different agencies to set up in the lobby and catch members and guests as they go through the facility. Really excited to have PNC here with us today they're talking about a very important subject colon cancer awareness they have some literature here about how how you get screening what are some signs and who you need to talk to if you think you need a screening. Justice Fouts mentions the success of hosting Wellness Wednesday has been overwhelming information and schedules can be found on pikevilleymca.org and the YMCA Facebook page. I think it's really awesome the response that we've had to you know requesting people to come in for Wellness Wednesdays. A lot of people were really eager we thought maybe we would just do it during heart month but so many people kept coming to the table like hey we want to spot hey we want to spot so we think we're going to try to continue it through the whole year that way everyone in the community has an opportunity to visit once or maybe twice. Really encourage everyone to check out our website and Facebook page learn about what next Wellness Wednesday events coming up. Very thankful to PNC and their partnership with the YMCA it's always great to reach out to them when we're having health fairs or events they're great to come in and partner and be a part of our community outreach. Reporting for mountaintop news I'm Nick Colum


Morning, friends. Just a bit of a depressing day here. It's turkey season. Should be a reason for celebration. But, uh, well, I'm just having trouble calling turkeys in. And as much as I know I shouldn't, I call Paul. What's up, casuals? Look who's back. Gummy Hunter's back. Tell a friend. I know last time was a fiasco, but I mean, he ran away from a bear. I had to do it myself. But I just, I don't understand birds at all. Are turkeys even birds? I don't, whatever. I just, we call Paul. We call Paul. And I just could get in front of this one real quick. I didn't actually run from the last situation. Nope. And I'm out. I got called out of town. Things happen where my chiseled creatures are needed. I know I previously stated that I'm a bit of a gummy bear hunter expert. That's not actually true. The two-time specializes in turkey calling. You know what this is. This is the GCGTCC. You're talking to the two-time here, baby. That's the 1994-1995 Gobble Gobble Guernsey County Gummy Turkey Calling Championship. There hasn't been an egg laid that's birthed to turkey that the two-time can't call in. You Gobble Gawkers probably want to hear a couple of these strategies. So I'll give you a few, just a little taste. The two-time doesn't run.  I gave them all. Now I'm asking you to send me a video of your best turkey call. If it's good enough for the two-time, I'll use it to bring this turkey down from its final roost. Check the link in the description to send those videos of your calls. Gobble Gobble.


Welcome again to another OpenShift Commons briefing. Today, we're really thrilled to get an update on the latest release of OpenShift Commons. OpenShift Commons is an OpenShift container platform. 3.7 is out the door. And Steve Spiker, who is part of the product management team, is going to give us a, basically a quick and dirty, very fast overview of everything in 3.7. You can ask questions in the chat. We'll have live Q&A at the end. And we're going to try and do this in right around 30 minutes, which is a lot, because there's tons of new features in 3.7. So I'm going to let Steve get started and take it over there, Steve. Thanks, Diane. So Steve Spiker. I'm working on the part of the OpenShift product management team. And really excited to talk to you today about all the new stuff coming in and OpenShift container platform 3.7. And so as Diane mentioned, this is an abbreviated set of presentation material. You know, some of us have been pushed to the back of something like 120. I didn't count the final one that covers everything in sort of detail. But I'm just going to hit some of the highlights. And so we'll go through that in the next 30 minutes. Feel free to put some questions in the chat. I know Diane and Tchar are in the background. Can I keep an eye on that? But we'll just go forward. So a quick interslide as far as OpenShift and the base of what it is. And we look at what Red Hat provides with OpenShift. It's kind of a complete layer for your application, you know, from the standardization down to a secure operating system as far as enterprise Linux goes for abstracting away the physical, virtual, public, private, whatever infrastructure you're dependent on. And then beyond that, how do you manage a larger number of those computers, right? So they need for cluster management or orchestration of your applications and deployment across all those different compute nodes and a lot of different requirements there. So that's the main Kubernetes part. And then on the type of things that help you leverage that platform with a number of capabilities around the management of those applications, the deployment automation, build automation, number of services, and the ability to self-service. So we'll dig into some of those. First, let's talk a little bit about the timeline and the roadmap. So typically we put out a release about every three to four months. And so our three to six release where we've just delivered in August. It seems like yesterday and here we are getting ready to put out three seven. And as you know, you can take the Kubernetes distribution number and add 2.0 to it and you get the open shift numbers. We're continuing to move forward with this pace and continue to pick up the latest and greatest Kubernetes distribution and adding in the capabilities during our validation and then distributed to our users. So within the container platform, it's our distribution of the software of OpenShift, namely the OpenShift Origin repository open source project. And so what you'd look through there and then as we build on top of those was the main capabilities we've delivered on it and around it. It's really around enabling some capabilities around multi-cloud services. So there's always this key and I'll dig in more about what we've done there around bringing different platform services onto the platform and better ways to integrate with a different infrastructure and automation for delivering of that. So digging in, what is sort of the main pain point you've struggled with in IT? A lot of times it's like, how long is it going to take me to spin up a VM to do some testing on or to do some development on or what's it going to take for me to be able to request access or some amount of data on either a test database or even a production one, you know, it's going through the process. It's typically got to open some type of ticket, whether it's service now or whatnot. You have to, you know, clearly identify your business, the age, the request itself, wait weeks, months, hopefully not. You get the approval, eventually come back, you have something that is the credentials you need to connect to that thing and then hopefully it can work and hopefully you understand how to inject it into your application. Well, the whole point of this is to automate that away, right?  The service provider will receive that request and then either immediately or asynchronously return back the needed pieces to connect to it and then inject it on that way. So good stuff. Part of that model is built off of an open API. So there's a multi-vendor standardization effort that has taken the proven service broker API that had been part of the Cloud Foundry service catalog feature and put a lot of effort into kind of baking in and really hardening some of the definitions around that API and then leveraging that for work within Kubernetes and OpenShift. So what is a service broker? A service broker is really just automated standard thing, entry point into the service. So it's the one who, as the name would say, brokers the conversation between the service catalog or really the consumer through the service catalog. The catalog is just a manifestation of all the services that the service brokers provide and then the service provider will facilitate that request. And so one of the big things we've done in the 3.7 release is we've completely redone the user experience. So when you're looking at the initial login, you'll see a page not just telling you about, hey, you need to create a project or hey, here's the project you need to work with. It will say, here's the service or here's the things you can do on the platform and also some additional material to help you get started. So there's an ability to take a tour. So it'll just take a minute from off the presentation here and I'll drop over to actually a running instance. So here we have a starter cluster that's running in 3.7. As you can see, it's the new experience. I wanted to, I could take the guided tour to help me understand what I can do and how I can leverage the interface. I can jump right in to some of the languages. That's like, wow, I like JavaScript. I'll just grab this and quickly be able to provision a Node.js application to be able to run this. So I'll give it a new name. So I'll give it one, two, get repo. And just like that, I've deployed my Node.js application. If I wanted to, I could kind of quickly go over here and see what's going on. Also, if I wanted to play around kind of locally, I could just go to Object Origin. I could look at the releases. This is the upstream. I could see there's a 3.7, 0, RC 0. What I've done is I downloaded the OC command and I can do an OC cluster, take it up and then I can point to the version I want to. I can say deploy the service catalog. And it's that simple. It's up and running. I've done that already. So I've preloaded it. And here's an instance of that running. It looks just like what I just showed there hosted by Red Hat. That's part of our online starter tier. But here it is running locally in my environment. And so I can go to my project. I can see I have different applications already running. If things don't look healthy, whatever reason, I can kick off a build. And I can also see the great integrated experience we have here, including that came in 3.6. They all come together here and seeing the things working to build logs in line and seeing everything I need to see at a glance. So that was a quick view at that picture and a bit more of a real time or live version of it. So what makes all that happen? So I mentioned the service broker API and a service catalog implementation that exists. And we're going to be rolling out the template broker. So now you can take your OpenShift templates like you've been deploying today and continue to deploy those applications. We're rolling out a new Ansible service broker, which you can define an artifact called the Ansible Playbook Bundle and we'll deploy that. We demonstrated way back in Red Hat Summit, some Amazon integration. We're doing work to bring that forward as well. And since it is an open service broker API, it's an open API. People can write their own brokers. You can bring third-party brokers, et cetera. So Ansible service brokers. This is a relatively busy start as a number of pieces, but it's actually a fairly simple concept. So basically there's some broker that's pulling content from a catalog itself, from someplace that's got to hold that image. That image is just basically a bundle somewhere and it can provision a set of services. So that bundle itself just looks like a runtime to execute on it and a standard set of verbs that, files that match verbs. So if you match it up to the open service broker API, the different things you can do, provision, deprovision, bind, et cetera, and matches those things. Plus it adds some capabilities to do some additional validation, such as testing. So a lot of good stuff there. I mentioned the template service broker, so that again gives you the flexibility of leveraging the same interface to bring it onto the platform. It also adds in the capability to inject config through binding. And so binding is the action to not just provision, but once you provision, you want to inject your application with configuration of that service you're consuming. And the binding operation is part of that process. So we talked about the initial experience. One thing I didn't highlight, but there's a neat way to be able to search, you can either from the search bar itself, you can do it through the filtered views down below. There's many easy ways to manage getting at what you want. And hopefully there's a lot of great content in there, so you need to search to find what you want. So this is showing the binding operation. So if you have an existing set of instances, you can actually combine them together. Another great piece is notifications. So you bring all of the notifications under the single bell at the top. So we're all kind of used to seeing this now, whether it's from GitHub or other places, is a common paradigm of a notification. And so now a number of key notifications are here and you can do all kinds of things as you see. There's your markup red, clear them, et cetera. So you can easily get the information you need and understanding what's going on in your environment. And if hosting is not your game and you have the need to hack locally, we have something for you. So I showed OC cluster up, which is the foundation for mini shift in the CDK. That provides a way to run a single node open shift cluster on your machine and allows you to really validate out your application in a number of ways. And one of the, some of the different features that people have been asking for, it's really been helpful, is like around multiple profiles or instances. So now I can easily say I have this profile that kind of matches a certain set of applications and I want to quickly switch to a different type of profile then you can do that now within the CDK mini shift. So let's move, I guess, we're going to start at the top of the stack. We're going to move down the stack. So we're looking at like the orchestration layer. The one thing I'm just going to point to is that there's already a comments webinar that talks about some of the work that's going on in the Kubernetes 1.7. So I encourage you to go watch that. And then also there's a number of exciting projects we can just want to highlight was the custom resource definition. So that's one of the, some of the different ways that extensibility has been integrated into the platform. So now it's easier to add capability into a running Kubernetes instance itself, including encryptions of secrets within that CD, daemon sets and upgrades to both staple sets and burst mode as far as a scale up goes. So let's take you that a little bit more. So a lot of work around installation and upgrade improvements around what we do with our Instable Playbooks that we ship product. So we have the capability to migrate at CD as it was before the 3.7 upgrade and also be able to scale out the CD cluster. So it's quite important. The other is the ability to have a more modular installer. So you have the, you may want to break things up in the roles and different playbooks so that you can target certain ad hoc administration tasks. So a fair amount of work has gone into provide those capabilities in a new install experience around sort of breaking, breaking up the installer itself into phases. And so you'll see that as well. And now jumping over to networking. If you've been following along, especially within the OpenShift releases, we've had this core feature of a network policy and tech preview for a couple of releases and happy to announce it's coming out of tech preview. And so we've done the work to validate it and actually have supported. And so it's a great way to have really fine control access and rules around our policies on communication between the different services you have on the platform. So in the past, you would have the ability to either talk all services within a given namespace or you would have it opened up across the cluster. And then you could do certain things around joining namespaces if you had the multi-tenant STM plugin, which would pair those namespace networks together and then they could have access to everything between those two. Now you have the ability to find, say this specific service at this port can only receive incoming traffic from this source itself. So really a key feature. Some other stuff around networking is we allow some flexibility around the cluster IP ranges. So it really allows for things around multiple set, some nettings for host, getting this request a lot. So glad to be able to provide this. And this is also a popular topic is reference architectures. And so we have a lot of, you know, one of the great things about OpenShift is the ability to run on an, as I mentioned, on bare metal, on virtualized instances, on different infrastructure layers and through different configurations. So with that level of flexibility, it's also very valuable to have reference architectures and implementation guides around that. So you'll see, as we put out releases, we usually have a little bit of time after release when we roll out updates to these reference architectures. So those will be rolling out as the release rolls out as well, or after the release rolls out. So while that was a, I did not do a, a true coverage of everything that's part of the orchestration layer. But the whole point was just want to hit on a couple of highlights and refer to you to the proofs presentation highlights, some of the core capabilities. And then talking a little bit about what's going on within the container space. So one of the key things is a project called Cryo, which you've probably heard in the number of the Commons meetings as well, the broadcast as far as what's going on there. We're doing work to validate that as part of, because it's a container runtime just focused on Kubernetes. And so we're doing validation within OpenShift until we're coming out with a tech preview of that and continue to test and validate that and strengthen that and look forward to moving that out of tech preview status. One of the, a couple of the things that just wanted to reiterate is since it's focused solely on the Kubernetes use case, we're able to, Cryo is able to keep itself as a very minimal and secure architecture. So it doesn't have to have to concern itself with other use cases that may expand the overall capability of it and they expand the number of interfaces and then possibly different attack vectors. And with that as well, since we're focused on that, that given use case, we're able to really focus on scale and performance for that without having to be concerned about a wide variety of cases there as well. And the great thing about it is you don't have to change anything. So like someone asked recently, well, how do I notice the differences? Like what, you won't, I mean, from an end user, it's just how containers run in the background.  It'll just run them and you'll end user will not know any difference, hopefully they'll notice better performance. Along those lines is when you're looking at how you build those containers, you also want to have a solution that will allow you to have minimal dependencies as well. And so build as a Daemonless tool for building and modifying OCI based images. And so we look forward to rolling this out. And so this is just in a preview fashion as well. So builder is great stuff. System containers come out in support for, for rail and atomic hosts. And this is a key part from the operating system update that can, that openshift container platform is actually is using in a tech preview fashion. So it allows you to bootstrap some of these capabilities. So if you, the container runtime is actually running within the system container itself. So it's a, it's a more flexible way to be able to manage and run the various pieces of the platform. And also allows for a set of capabilities as mentioned here, you know, it's real simple to, to upgrade and rollback pieces within the managed by the system containers. And so that gives that level of isolation and flexibility as we've seen with containerized application. And it's now coming at a lower level within the operating system stack itself. So I overachieved and shooting down my, cutting down my slides and trying to get through the content. But one of some of the things that I just wanted to reiterate is it's, this is, there's so much content. I just didn't want to take too much time to like cover everything in a bunch of detail. But I also wanted to make sure I covered some of the key highlights. And the thing to, to note is that it's, it's a release coming out. You'll see announcements about it over the coming weeks, both the announcement of it, the availability of it, the way you get your hands on it, the, the, there's the ways you can get your hands on it today. As I mentioned is, is hopping into the, the opensh, the github.com open shift origin repository, grabbing the 37 RC release and playing with it there. As a other aspect, as I mentioned, you can go to openshift.com, register for the open shift online starter. We are starting to roll out the 37 upgrades here. We have it available in the Canadian regional cluster today. And then, yeah, there's, there's all these great ways you can, you can always get your hands on the product that's kind of early and see what it does and, and also provide feedback through github issues, the community forums, open shift commons, many, many good ways to provide feedback. So with that, I'll see if there's any questions. I see if I think the main one really is, you know, the rest, I think we have addressed, but I think the main one is, can they, can people get access to 3.7 RC code online? I think is the question. So they can get access to 37. Yeah, the only code that you can get available today is through the, what's built through the open shift origin repository. And then the, the actual release bits as far as like when Red Hat will release the open shift container platform 3.7. That's due out in a couple of weeks as far as one of those bits will actually be available. I think the other question that's actually has been answered in the, in the chat, but I think it's worthy of saying out loud for people who are watching this as a video is people are asking, can you work now entirely without the doctor Damon, use trio and build it. We're doing some tech preview there. So that is not. Yeah, so see there for, from Ben is I answered some of these were right. It's, there still needs to docker for, for some of the building aspects. But if you're looking to isolate some of your workflows, I mean, there's always some live interesting things you can do within open shift and containers to label or isolate workloads so that you have builds only land on certain nodes. And so you can even further isolate different workflows if you're, even if you're experimented with different things. But again, the builder and cry are in tech preview in 3.7. So. Let's see, there's a couple of other questions once you pop over and take a look and see if they do that. Jonathan's asking, can you talk a little bit about how system containers work to isolate Kubernetes from the host OS? Are these Docker in Docker or VMs or something else? You want me to take that, Steve? Go for it, Ben.  We just add a little bit of metadata to the image. And then we run it slightly different. So if you've done existing containerized installs for OpenShift, those will drop the unit file on the host. We carry that forward with system containers. What's different though is we store them on disk. We leverage OS tree for the deduping. So, you know, again, the classic example of that is if you're troubleshooting a node and, you know, you fill up a Docker pool and you blow that away with a system container as that kube role or as the container runtime role, you won't blow away those really important roles if you ever wipe the storage pool, right? So it gives us that kind of extra resiliency for bits. You would classically associate with being a part of the operating system, but you could still iterate and get all the advantages of running in containerized. Does that kind of help? I think so. I think that was a good answer to the question. Let me just go back here and see. I think we answered the question in chat too. Are you imagining service brokers replacing templates? And you did walk through the templates being able to be used them as backends to service brokers? Yeah, I may just be clear that the brokers just an API or means to provide a service at the end. There's still got to be something that defines what that application is or does some of the provisioning and so templates are still, you know, supportive way to do that. Chris had asked a question. I don't think we actually answered it. Can we access and set up accounts on the cluster where 3.7 is running? I think it was around the networking slides. And how does the networking policy compare to Ixio? It's just coming out. So, yeah, the... So the... Sorry, can I interrupt somebody? So, yeah, it's network policy is really just focused at I think Tshari mentioned it there is the layer 3.4 aspects where Ixio is layer 7. Really, I mean, you look at network policy, it's a declarative model to define kind of the communication past between the different surfaces and what's allowed and not. And Ixio itself is a service mesh which has a lot of different capabilities around policy as far as like, you know, what network policy kind of does. And then also kind of a programmatic kind of routing aspect so you can do intelligent routing based on whatever criteria you define a program in, among other things like telemetry and different reporting aspects to understand what the different, you know, usages are, you know, what's actual traffic was being allowed, denied, et cetera. So, yeah, those are kind of, you know, always complementary and also Ixio will provide a fair more capability as well. There was one other question there. There's one other one. Yeah. Do you have example service broker definitions or links to the documentation for how to create these? Maybe pop over to where the documentation is. Yeah. So the, that might be good to follow up with a link in the blog post itself, but I'll start digging into it. We've, we're working on our increasing our enable material. We've, we have someone called it their pre alpha version of even a go SDK to help end users when writing brokers and working with the appropriate partnership teams to help enable folks, partners of writing service brokers itself. So, yeah. Like, yep. I don't have a good link for documentation. So I'll continue to search. Plan release date for 3.7. I think you mentioned. Yeah. The bits will be available by the end of the week. I'm not the end of the weekend of the month. So we're looking to, to the official red hat, you know, the push of container platform will be available. I think the target date is November 29th. So we'll keep an eye out for that. Yeah. Just in time for coupon because we do everything based on when the next event is, but folks to that. Judd is asking with rail now released on arm is red hat. Helping move going to arm. The off topic, but I don't know. I don't know any status on that. So not aware of anything. If there's things about 3.7 and we did this really fast today that your people who are on this call want a, yes. I want to deeper dive into just email me on the mailing list or email me at D Mueller at red hat.com. And I will try and stage this. Actually, I'll, I'll chime in on arm real quick. This has been on the, on the rail side and eventually from the whole container platform. I will say that we're, we're definitely looking at, at multi arch being, being on an option. So we will have base container enablement. Coming up soon in rel for arm. So probably around the 75 timeframe that, that all extras repository and base images will be there. But then, you know, from there it's, it's, it's, you know, it's a lot more work to bring open shift to it. So, but, you know, that, that first phase is definitely pretty solidified at this point. You're getting me excited here. It's pretty cool. So, yeah. So again, everybody, thank you for joining us. Oops, there's a mention of Federation is mentioned in the 3.9 category. That's a good topic. Could you talk at a high level about the Federation roadmap? Yeah, so the, the, the Federation roadmap, I can talk about. So if folks don't pay attention, the Kubernetes community, there's the, the, the SIG Federation has been doing work around understanding, you know, what's the right path forward for how Federation fits into the Kubernetes. So there's a couple of different pieces of work around, you know, what's the right use case, which is the right approach. And so they're doing some analysis around those pieces, you know, whether it's a single control plane that aggregates a number of back ends and that replicates sort of state across those, or is it sort of another tool that sort of sits on the side that is controlling and working across those. It's going to some type of that validation. You know, we're, we're, when you look, when you break down the number of use cases around Federation, there's a lot of different pieces that play into it, as far as global load balancing, DNS, geo replication, replication of images and state of configuration. So we're doing a work kind of focus more on the registry into that scenario towards the 39 release. And so that's where, that's where it stands. Cool. So I'm going to do my final pitch here for questions. And so if you have one, pop it in the chat and we'll try and ask it. The other thing that I want to just remind everybody is that the OpenShift Commons gathering the face-to-face for all the upstream project leads and road maps will be happening on December 5th in Austin, Texas the day before KUKON. So if you're coming to KUKON, please consider registering and coming for that because you'll get folks from the engineering team, Clayton, Dan Walsh, and Raul. A number of the PMs will be there as well as folks from the project leads for Kubernetes and folks from Amazon talking about running OpenShift on there. So there'll be a lot of good folks in the room and lots of customer case studies. So I'd love to see y'all come there. And here's one last question for you. For the OpenShift specific add-ons to Kubernetes, are there considerations of working towards a modularized plug-in e.g. a Helm model? Very good. So a modularized plug-in. If I understand this question correctly, is it maybe just a you want to run Helm with OpenShift or is it wants to follow a model like Helm as far as modularized plug-ins? I guess I can answer both of those. So one is we published blog articles of what it takes to run Helm with OpenShift and so there's some ways you can run it. Your Taylor server within a given namespace that will allow you to deploy Helm charts. That's not something that's, you know, we don't ship and support Helm or Helm to help Taylor today, but that's a, you know, we define how you can do it. As far as running a Taylor cluster-wide server, there's some considerations there you'd have to be aware of if you're doing that. I mean, it sort of depends on your own deployment and what you're okay with there. As far as, and what we're continuing to track and watch in the upstream, within the SIG apps around Kubernetes, there's, you know, that primary focus around that is around enabling a number of application tooling if you're all around Kubernetes, not that it's any given supported set of tools or endorsing one, but clearly Helm is one that is used widely by the community and they're going through a process of defining what Helm 3 is and so we're, you know, continuing to work with that to find a way forward to provide a supported fashion, a supported solution as needed to meet the customer use cases. So yeah, any feedback there and we're continuing to look at it and evaluate it. And we're continuing also to evolve how we build OpenShift and how we add the different capabilities into Kubernetes and so as you look at the service catalog, it's actually built in as an add on itself and so then you can, you know, sort of build the various components of OpenShift as sort of add-ons, if you will, to base Kubernetes. Yeah, there you go. There's another follow-on question for that. So it's a two-part question, I guess. So if you took Helm question out of that and just said to use something to install OpenShift components more of like I want to have a Kubernetes and I want to inject OpenShift components. Yeah, so that's a model we're heading down as you well know. We started with this journey around building OpenShift based on Kubernetes and contributing to Kubernetes well over three and a half years ago and so when we built some of the core concepts, it was done in such a way without a true and extension model kind of built in or an add-in model. We've worked with the community to help build those things in and start to build new capabilities that way, but at the same time, there's a cost involved in time to move things to be more of this add-on or plug-in model. So we're continuing to evaluate those things and do what makes sense based on our customer needs there and how those add-ons exactly get installed, whether technology is home or something else. I think that's still to be determined, but since currently Red Hat doesn't have a Helm-supported solution, I would have to see. I think we're at a close here, Steve. Thank you very much. I know I'm trying to get you to do this in 30 minutes or less. It's impossible. So thanks for all the questions and Tushar for joining us and Ben as well. We'll do this again soon. And again, hopefully you'll all join us in Austin where we have lots of engineers in the room to answer even more questions around 3.7 and look for the blog post shortly. All right guys, thanks. Thanks everyone.


Okay, well let's talk a little bit about Earth's atmosphere. Here we're viewing Earth from outer space and we can see there's this faint blue shell encasing the planet and that faint blue shell is indeed Earth's atmosphere. So this gives us a sense of how relatively thin Earth's atmosphere actually is as it turns out the lower 80 kilometers, that is the first 80 kilometers above the Earth's surface contains just about 99% of the atmosphere. So the atmosphere really is this thin blue shell around the Earth. Now we can further decompose the atmosphere into various layers. The lowest of these layers is what we call the troposphere. Depending on the latitude it's somewhere between the first 10 and 14 kilometers. And it's the area of the atmosphere within which we reside, within which most of Earth's surface resides, in fact all of Earth's surface, even the tallest mountains. It's also the layer within which weather takes place. Now this plot here shows temperature as a function of altitude and we can see that within the troposphere temperatures decrease. It turns out they decrease at about a rate of about six and a half degrees Celsius per kilometer and they continue to do so until we reach this boundary here between the troposphere and the next layer up the stratosphere where that temperature trend reverses and temperatures in fact start to increase as we go up further in the atmosphere. The boundary between these two layers is what we call the tropopause. Now why do temperatures increase as we get into the stratosphere? Well it has to do with the chemistry of the atmosphere and in fact the existence of ozone within the stratosphere. It's the photo dissociation of ozone by solar radiation and the heat given off during that photo dissociation process that actually heats the stratosphere and leads to the increasing temperatures as we go up in the atmosphere. Now primarily in this course we are going to focus on the troposphere and to some extent the stratosphere. Those are the main parts of the atmosphere that we're going to be interested in.


Amphibious operation, a combined attack in which every man is assigned a time and place to do his part. What is the assignment of the military policeman? This is a simulated attack in amphibious maneuvers. Let's start at the final briefing as your troop ship nears the beach. First, using the map issued to you on shipboard, you locate your post of duty. You may be either with a division military police who go ashore behind the first assault waves and follow them inland, or with the amphibious support brigade military police who service the beach area after it has been cleared of the enemy. And now you division MPs lead off. Each of the infantry assault regiments is accompanied by a group of division military police. Your job is to get ashore and follow the infantry assault waves. The purpose of the division military police is to bring order out of the confusion the assault waves leave in their wake. Now you head inland to take the post assigned to you. As the division assault troops move up, you division MPs stick with them. You'll funnel stragglers and prisoners of war back to the beach collecting points and control the traffic of personnel and equipment through beach exits. The amphibious support brigade starts ashore as soon as the beach is cleared of enemy troops. The support brigade will direct transport and guard supplies. Now in our mock attack, it's the turn of the support brigade to hit the beach. Each of you knows his job and starts for it. You control traffic. You direct stragglers to the collecting point. You guard prisoners of war under orders of the shore commander both before and after enclosures have been built to hold them. And supplies. They come in fast and jam up the flow of personnel and equipment unless piled in supply dumps off the paths of traffic to prevent bottlenecks in this critical area. For the enemy does all he can to make it tough for you. He may on occasion have the aid of storms and seas to turn your efforts into rescue work and salvage from wind and water. Directional and information signs are issued you in the embarkation area. You check the illuminated blackout signs. You'll be kept informed of battle and road conditions so you can direct traffic to the safest and best routes. If you're assigned to a motor patrol, you report vehicles disabled on the road to the nearest ordinance wrecker crew. And the traffic block is removed from the roadway. Members of the amphibious support brigade help units disembark and keep them moving, directing them to the exit roads and rendezvous points. Those white-taped lines indicate a safe thoroughfare through a minefield. You see that vehicles and personnel keep within those limits. A helicopter may be spotting traffic tie-ups and reporting them to your command post. When a wreck blocks traffic, stalled vehicles will be diverted to an alternate road, while patrols of the support brigade and a wrecker crew will be dispatched to clear away the obstruction. Keeping the beach exits clear doesn't only mean directing traffic. A driver may decide to de-waterproof his vehicle right now and you direct him to get going to the unit de-waterproofing area.  When you set up an information post, a careful study of your map gives you the facts on unit locations, routes of advance, military police installations, locations of enemy positions. But conditions change swiftly, so you keep your facts up to date through patrols and other authorized sources. At a de-waterproofing area, you direct the parking and spacing of vehicles as they report in. In an assembly area, you may be part of an escort for a priority, tank, or heavy equipment column, perhaps area where division military police will take over. When on a roving patrol covering the beach, pick up stragglers and take them to the straggler collecting points to be returned to their units. In enemy territory, there is no more important assignment than helping to maintain security of the command post. Poopers may have to be captured, contained, or destroyed. You'll hunt snipers, guerrillas. Prisoners of war, captured by the assaulting troops, are turned over to the division military police, who establish a temporary collecting point at an inland location with some natural cover and concealment. A group of the Amphibious Support Brigade military police, whose special function it is to guard prisoners of war, now hit the beach and establish prisoner of war enclosures in the beach area. Relieving the division MPs of their prisoners, the brigade military police conduct them back to the prepared beach enclosures. When enemy towns are smashed and fought over, the movement of civilian refugees must be controlled, and that becomes the job of the military police support brigade. Masquerading among the homeless and hungry are enemy guerrillas, and a mine detector helps you recognize them. The mine detector has encountered, on this innocent looking fellow, something made of metal. It's a pistol. You cooperate with the CIC in their interrogation of enemy personnel. Your aid to the CIC may win a battle behind the lines. The military police Amphibious Support Brigade operates these refugee collecting points. And lastly, you protect from pilfering and sabotage the vital store of supplies and property on which the army's forward drive is based. So as a military policeman, think over what this simulated Amphibious operation has taught you. Some of you division military police landed with the first waves and moved inland with the assault troops. In the Amphibious Support Brigade, you functioned on the beach and kept traffic moving up through the beach exits, returned stragglers to their units, made sure that traffic obstacles were removed, protected vehicles from landbines. You set up information posts, you guarded prisoners of war, helped capture enemy paratroopers, took care of enemy guerrillas, you controlled civilian refugees, and guarded the all-important supplies.  This Amphibious operation needed your 24-hour support and got it.


I'm super excited, quite nervous, looking at the elevation chart, analyzing how I'm going to drink and overthinking it probably a little bit, but I like that sort of thing. I'm here with my father, he's a driver today, and of course my brother behind the camera. And we are all excited and driving up this beautiful area of Norway and we'll be there in about half an hour and we'll check back with you there. I'm at the start, it's about 50 minutes until we go. I'm super excited, quite nervous, but feeling ready. It's a nice day, I think it's probably about 250-300 people total and we're all going to just have an awesome time. It's mostly on gravel roads, it's about 400 meters of elevation and yeah, it's just a perfect day. It's about 18 degrees Celsius which is really nice, I'm glad it's not too warm. Mass will be filming a little bit along the course and I'm going to just get ready, warm up a little bit, get my clothes off and just get down to the race gear and I'll see you later. Alright, so it's now three days after my first ever half marathon race and I want to give you guys a little bit of an idea of some of my thoughts leading up to the race during the race, most importantly. And after the race, how it went and what I learned. So, the race I did was Krogskogen Halmarathon which is a half marathon here in Norway, held on the 30th of July 2018. It's a yearly event, it used to be called Nordmarka Halmarathon before, now it's changed its name. It's not a huge event, small and cozy, probably like 400 people or something total, which was very nice and perfect for me. The course is on gravel roads and there's a fair bit of elevation, I think 300 something meters of elevation gained throughout the race. So, it's certainly not a flat course, it's not a race, it's not a course where you would have a personal best. But of course for me it was my first ever half marathon so it was a personal best. And I'll break it to you right away, I ran it in 1 hour 45 minutes and 47 seconds I think. So, that's super cool, I'm happy about it. I think certainly if it was on a flat course I would obviously run faster and I did a few mistakes during the race. And those mistakes are something I want to share with you here today. So, before I get to that, let's just talk about the days leading up to the race. I was super excited, quite nervous, like I always get before events of any sort, but especially running events. It's my third ever running race though, so I'm not really used to the racing scene and all that. I was positively nervous. I met a couple of my friends that are some of the best half marathon runners in Norway really. They were there and they both got John, one of my friends, he got third in a fierce battle for second. He got third and then Andreas got eighth. So that's really good, that's impressive. I arrived at the race on race day together with my dad and my brother. My dad has always been into running, he's done a lot of races in his life. So he has a lot of experience to sort of share with me about how to do the race, etc. He's run a lot of half marathons in his life and a few marathons too. And Matt was there of course as well for support and doing some filming and stuff like that. So it was a really nice day, perfect weather, just like now really. It was like 18 degrees Celsius, not a cloud in the sky. I mean ideally I would probably want it to be even a little bit cooler and a few clouds because that would run faster that way. I lined up at the start, there was a countdown kind of, one minute to start and I was just like, oh god, exciting. I placed myself at a point where I thought was logical for me to place. So I was like leaving about 100 people in front of me. And interestingly enough I finished 97th overall. So that was a pretty accurate guess from my part, 100 people in front of me. And then off we went. The first few kilometers are up, I'm not going to go through all the details of the course. If you're interested you could always check out my Strava link. I'll put a link in the description to the Strava activity. And you can read more about my details there, you can see the course, you can see my heart rate, you can see my pace. And you can follow me on Strava to stay up to date with all my training. Anyway, I had some ideas regarding pace starting out. But you know, I haven't done that much high intensity training in the last in my life. Just a few weeks now before the race and I didn't have much experience at those higher paces. So I didn't quite know, and especially because of the up and down nature of the course. I wasn't sure, you know, like what pace should I aim to hit. And in terms of heart rate, well I always need to stay below my lactate threshold, right? That's my initial thoughts of course, I mean it's more than an hour, I'm going to finish in more than an hour. And you can really just stay at lactate threshold pace successfully for about an hour in a race. So I certainly had to stay below lactate threshold, which is probably for me about 86, 87% of max heart rate. But in races, you know, maybe my heart rate is a little bit elevated. This is a problem that I had in my past races too, that I'm not quite sure if the heart rate on my heart rate monitor, my Garmin 630, you know, if it says 90% of max in a race, is that truly representative of that work effort? Or is the heart rate elevated because of the excitement? And so I was at 90% for most of the race in the beginning. And I thought probably a little high, but I was just going with it, you know. I felt like I could sustain it. I couldn't. I definitely couldn't. I worked way too hard for the first 10k, you know, I actually did a personal best 10k in the first half of the race in like 47 something. So that's already maybe a sign right there, like I'm running a personal best in a 10k. It's a sign. It's not necessarily, you know, you couldn't certainly do that depending on where you're coming from and how fit you are at the moment. But for me, that was probably just a little tad too ambitious considering the fact that there was so much elevation in the first few kilometers. Anyway, from the halfway point and onward, I just progressively slowed down. It was a painful, painful event. And after about two kilometers of a steady climb, I reached up to a sort of plateau where I just cruised for a little while. That's where Mads and my dad were standing, waiting for me. And I'll pull up a little footage so you can see how I looked as I passed them. Fresh and naive at like two kilometers in. Check it out. It's going fast. Probably too fast. It wasn't as bad as I thought. Good luck. Then I continued on with the race and, you know, I was pushing. I was really, really pushing. And also on the downhills, I was running faster than I've, you know, I was running at a really, really fast pace. I'm not sure if my legs were sort of able to handle that. Because as I ran, both in terms of my effort, heart rate-wise, probably over-lacted threshold, that sort of thing, but also in terms of my legs running that fast for that long, as I reached the halfway mark, things started going downhill for me, figuratively speaking. I really started to slow down and started feeling, feeling like total crap, basically. Slower and slower and slower was just harder and harder and harder to maintain the pace and even the effort. You know, if you look at the heart rate data on my Strava post, you can see towards the end of the race, I'm actually running at a much easier intensity than at the beginning of the race. It should have been the reverse, right? I should have started at an easier intensity and increased it throughout the race. But I did the opposite. I ran too hard, which is just like a classic newbie mistake. I feel like if I had another chance, and of course I can do this next year or the year after or whatever, if I had another chance like now with the knowledge I have now on that course, I would run it differently and I think I would actually finish faster. If I ran slower for the first half, I could probably run a little faster for the second half and I would actually finish three minutes faster probably. In terms of hydration and fuel, I had a little bottle of sugar water, just like super concentrated sugar and a little water and a little salt. And I just squeezed a little bit of that into my mouth, swallowed it down as I approached each aid station. There was like six aid stations in the race, which is a lot for 21K. But that was perfect for me because then I could just squeeze that and then grab a cup of water and just down like 150-200ml of water at each aid station and move on. Very much of a learning experience for me, this race. Very interesting. I feel like I know my body better now. I think also towards the end I was really struggling to maintain the pace. Even if I wanted to run for 20 pace per kilometer, I was just not able, even on the flat, I was simply not able to get there. I couldn't push past like five minute pace, which was just a strange feeling. I couldn't, I wanted but I couldn't. And it was really painful and I don't know if it was structural fatigue from all the downhill running or if it was maybe the fact that I was running above my lactate threshold earlier and just accumulated too much lactate, probably both. Well, I suffered through the last 5K. The last 5-6K was just... At times I was like noticing in my face that I had this kind of urge to cry almost and it made me laugh. I mean I was not like emotionally down but I was feeling this kind of... It was just so painful I almost wanted to cry a little bit, which is funny. So I just pushed, pushed, pushed through and I got to the finish line. I had to walk a couple of times just for like 5-10 seconds and then I got to the finish line and I finished kind of strong, you know, when I got to the place where everyone's watching and my dad and brother were filming again. I was feeling like I had to push harder at the end. I was able to do that a little bit and then I finished. Here's some footage from me approaching the finish line. Check it out. This is so good! 1.46K, something incredible. I haven't run for like... I've had two days of complete rest now and today I'm going to go out for a bike ride and tomorrow just an easy run and slowly building up to it again over a couple of weeks before I'll start my next half marathon build up which will go until September where I'm going to do a next half marathon. It's also a half marathon on the 15th of September and that's more of a flat course on pavement and that's... I have some goals there, you know, in terms of time. I'm trying to run a little faster obviously and we'll talk about that in another video. Anyway, summing up the race. It was a beautiful day. It was a great race. Really nice. The event management was done well. I mean, we all had our names on our bibs. The bibs was really nice. They were just a little smaller. I'm wearing my t-shirt actually from the race. I won a t-shirt. They just called out my name and I was like, I won a t-shirt. Good atmosphere. Good vibes. It was nice meeting my friends there. Talked to them about running. Nice to have my dad there, my brother. It was just a good overall day. I just... I loved it. And in terms of recovery, I've had in the past where I was less fit, I guess. I was really struggling. I got totally wasted, for example, after my first 15k race. I was just completely out of it for like the next day. But this time, I was fine. I mean, I was really, really tired, obviously. But I was okay, you know, in the evening after the race. And the next day, I was feeling much better already. And now, after three days off or two days off anyway, I'm feeling good. I mean, I can still notice a little soreness. Still tired a little bit. But I'm ready to hit out on the roads for a bike ride. Just easy into training again. And of course, remember, you can follow me other places too, right? You're watching this YouTube video, but I have an Instagram account. There's a link in the description. I post lots of pictures from my runs, etc. Check that out. I have my Strava profile, as I mentioned, where you can see all my training. And then, of course, there's a Facebook page for this channel. Please follow that and subscribe to this channel, of course. And click the little bell button next to the subscribe button so you get notified when I upload a video. I appreciate having you with me. I appreciate you watching this. If you made it this far in a long video about my race, then I really think that's awesome. I'm going to get ready for my bike ride. It's a fine day. I'm looking forward to just an hour or an hour and a half or something out on the road. It's just easy riding. Hope your day is going well. Let me know in the comments what you think. Thanks for watching. See you around.


With that appreciation, okay, with the appreciation of girls, when you're at a seminar like this or watching this kind of seminar online in the future, you've got, you're dedicating a time in your life to getting the most out of this part of your life. Work ethic. Let's apply ourselves, let's get the most out of this. And what happens is you go out and you meet a lot of people. And you approach so many girls in so many situations with such almost predictably similar responses that you lose all passion, that you become robotic and functional. You become a systematic type of guy with no interest or intent or desire for the girls that you want to meet. And I had trouble with this for a long time. My job is to pick up chicks, to go out to bars like three days a week and have my own social life. I'm inundated in it.  So I needed to build in a facility in my psychology, I guess, and my dynamics that would remind me why I'm doing this and bring that passion back.  She's gonna be like, well, this is cool, but this is not passion. You don't really like me individually. You're just doing this to get pussy, that kind of thing. And it's not gonna work.  And the way we designed this dynamic that would give you the X factor and the gleam in your eye and we call it the statement of motivation. And it's exactly the same as you appreciating the girl. So when we started going out and started with that positive type of game, that almost nice guy type of game, positive precedent, I'm running around all the time using this thing called the statement of motivation. So what that is, is when I see a chick, I'll say what I like about her or what motivates me to speak with her. And all of a sudden, I'm not just doing the approach and developing my social skills as a system because it's a self-help type of thing to do. I'm actually refocusing on the individual people that I'm meeting in an emotional way because emotions have to come first and while you're emotionally engaging these girls, all the systems and the ideas and these kind of seminars that you're listening to, they'll pop up in your head and they'll present themselves when you need them most. That's called self-trust. So my first focus when I walk into a set and we have this on YouTube videos online, for the most part, when I approach a girl, the first thing I'll say is, oh, you're so beautiful.  She's like, oh, thank you. It's not a big deal, but I'm like, yeah, she is beautiful. She's a different variation of normal. She's attractive, yes, imperfect, yes, but oh, these are the cool traits and all of a sudden, I wake up to it and any guy can do this, okay? And all of a sudden, you'll go from being maybe kind of socially decrepit and uptight and then you'll enjoy meeting people which makes this yoga type of process of learning and expanding game really enjoyable and easy to get good at because, you know, we all start as like beta males. We start as beta males who are young and introverted and inside of our head and cast by social conditioning and we need to go through that ride of passage where we go out, meet girls, get rejected, have great intimate results and that turns into you becoming an alpha male with abundance.  I know there's a couple Australians in the room and he's talked about as a sex symbol. I see that, I'm like, it doesn't really make sense but when you're walking around with that abundance and if you're that famous and you're that good at meeting everybody, it's not like you're ever filtering anybody. You can meet any person and appreciate them because if you don't do that, you'll hate the world.   Some celebrities make it easy for themselves because they're good at just taking five minutes and appreciating every single person and somebody like.