 software engineer at B12, which is a New York-based city-based startup working on scale and creative work. But today I'll talk to you about Ping, that networking utility that many of us are familiar with. So whenever I'm feeling lonely and wondering if I have a connection to the internet, I ping Google.com and feel really reassured when I see the printout telling me how fast my internet connection is. So I thought it'd be fun to spend this talk talking about how Ping works. So in the next nine minutes I'll go over a history of Ping, a very brief overview of networking, the Ping program itself, and some fun or not so fun security problems. So I was curious about the history of Ping, so I Googled Ping History. And one of the first search results was this article written by the creator of Ping, Mike Musk, about the origins of the program. So here I have a quote from this article and bear with me as I read this out loud. In December of 1983, I encountered some odd behavior of the IP network at BRL. Recalling Dr. Mill's comments, I quickly coded up the Ping program, which we rolled around opening an ICMP-style stock raw AFI at Berkeley-style socket. The code compiled just fine, but it didn't work. There was no kernel support for raw ICMP sockets. And since, I coded up the kernel support and had everything working well before sunrise. So here I've highlighted some of the terms that you might not be familiar with and the goal of the talk is to be able to understand this quote. So let's start with a very brief overview of networking. So the internet is complicated. It's a massive network of computers connected to each other in different ways such as Ethernet or Wi-Fi or an underground underwater cable. And these connections can also be lossy. For example, when there's a lot of traffic, not everybody's data can get through. And to handle this complexity, we use abstraction, specifically organizing it into layers. So this communication is organized into layers where each layer has a specific function and doesn't worry about the implementation of the other layers. So here I show three main layers of what's referred to as the networking stack. So at the bottom is the data link layer, which defines the protocols for sending data over a physical connection. For example, we can imagine our physical connection is carrier pigeons. And the protocol might say that each carrier pigeon can only carry one message at a time. So in the real world, you might have protocols like Wi-Fi or Ethernet. So the next layer is the network layer. And this handle is how to route data from point A to point B when there's no direct connection. For example, when I need to send data from New York to California over my carrier pigeon network, no single bird can fly that far. So you need to send it somewhere closer first. The network layer figures out where you should send it, should it be Texas or Ohio, so that eventually your data ends up in California. And then IP routing is the most common protocol for this layer and has the abstraction of sending data from one IP address to another. But IP doesn't guarantee that your data gets delivered. What if your pigeon gets shot down? The transfer layer takes care of this for you. It'll keep retrying with new carrier pigeons until your data gets delivered. This is referred to as retransmission. TCP is the most common protocol for this layer. So let's look at what happens when I actually try to send data over the internet. So I've got my data, let's say it's a picture of a cat, and carrier pigeons at the bottom are my physical connection. So starting at the top, each layer adds a bit of metadata about the protocol at that layer to the front, referred to as a header. And each layer adds its header while treating the data from the previous layer as a black box. Until eventually I have the message to send with my carrier pigeon. Now at the destination, the data goes, we go back up the stack where each layer strips off its header until finally we get the picture of a cat at the application. So you might wonder, how do you actually use any of this? Do you have to implement these networking protocols yourself? Like do I have to write TCP? The answer is no. Your operating system provides you with an interface to the networking stack. For example, in Unix you can get what's called a socket, which is an interface to the transport layer of the stack. So that'll let you use TCP. You also can use what's called a raw socket, which is an interface to the network layer. And I mentioned this because this is what Ping uses. Because Ping was designed to debug a connection to another computer and the speed of that connection, we want to avoid the retransmission logic of the transport layer. And you might ask, why can't we just use the data link layer directly? And that's because we might want to test the connection, say between New York and California, where there's no direct link. And you depend on the routing function of the network layer. Okay, so that was a long-winded introduction to the Ping program itself. So here I have Ping running on the client on the left. And it's testing its connection to a server shown on the right. And what it does is it sends an ICMP echo request. ICMP is a messaging protocol that's used to send diagnostic and debugging messages between servers. And what the protocol says that when a computer receives an echo request, it should respond with an echo reply. And there's certain fields in the message that should be copied back and sent back in the reply. So here I show that in red. It's the identifier field, a sequence ID, and a data field. And what the Ping program does is it takes its process ID and puts it in the identifier field, the message number, because it might send many messages, it puts a message number in the sequence ID field. And then the current timestamp of when the message was sent in the data field. So then the server takes those same values and sends it back in the reply. So here I show the output from that pinggoogle.com command. I showed earlier in the talk. And each of these printouts is an echo reply message received by the ping program. And then the ICMP sequence ID shows the message number. And the time shows the timestamp in the message subtracted from the current time, which gives you the round trip time between the client and the server. So now that we have some background about ping, we can look at some security problems. So here I show a list of some common ones that you might have heard of. But I'll go into detail about what a Smurf attack is. So a Smurf attack is a form of distributed denial service, DDoS, which is when many computers are used to overwhelm a victim computer with networking traffic, so that the victim computer can no longer respond to normal requests. And what happens in a Smurf attack is it sends an IP packet containing an echo request. So this is similar to what the ping program that we just described does. And as you recall, when an echo request is sent, the servers that receive it will send back an echo reply. And I haven't mentioned it yet, but an IP packet also contains a source IP and a destination IP address in its header. And what the attacker does is it takes the victim's IP address and puts it in the source IP. And a network broadcast IP address and puts that in the destination IP. And what a network broadcast IP address is, is an address where all the servers in a local network are set up to receive data on. So when this echo request is sent, all of the computers in this local network receive this echo request and send echo replies back to the source IP, which in this case is the victim's IP address. So the attacker sends many of these messages, and for each one, each echo request that's sent, multiple echo replies are sent to the victim. The number equal to the number of computers in that local network. So the attack is being amplified by this local network, which is why it's referred to as an amplifier network. And eventually the victim computer is overwhelmed with networking traffic, and can no longer respond to normal requests. So now you know some things about ping. I'd like to thank you for listening to my talk.