Hello, and welcome back to CS615 System Administration! This is week 6, segment 4, and with this video, we're continuing to illustrate different network protocols, briefly covering ICMP, the Internet Control Message Protocol. I'm sure you've all used ICMP, but it's useful to show how we can observe and analyze even trivial communications. We'll cover the two most commonly used ICMP applications -- ping and traceroute -- as they help us answer at least some of the questions that had arisen in earlier videos. --- Now ping, of course, is about as trivial as a packet exchange can be, but let's quickly observe it on our host by capturing the IPv4 ICMP packets via tcpdump, and having the ping utility send just three echo requests over to www.yahoo.com. We then inspect the captured packets and see indeed just individual "echo requests" being sent by our host with each triggering an "echo reply" from the web server on the remote end. We also see here that ICMP echo request / echo reply packets can apparently have an identifier, to make it easier to differentiate packets that belong together, but so perhaps there _is_ a bit more to the packet format, so let's take a look at what the RFC tells us. - As we see here, the packet is rather simple: We have a type, - which is set to 0 for an echo reply and set to 8 for an echo request; a code field, - which is all zero for this type of message, - we get a checksum, - the identifier we just mentioned, and - the sequence number for the messages being ping-ponged between the hosts. But note that we also have a _data_ section here, which perhaps is a bit weird and not something you may have used in the past. --- Let's see what the manual page says: Here, the '-p' flag allows us to fill some data here, which can be used to better identify and track packets when troubleshooting connections. [pause] But note that of course this can also be used in perhaps unanticipated ways: many organizations prohibit egress traffic from their systems to the internet to, amongst other reasons, prevent data exfiltration. But ICMP messages are often times permitted, since ICMP is rather useful and important for all sorts of troubleshooting. So you could encode the data and hide it in ICMP echo request packets, like so: [continue] We encode the data into hex and then... let's capture the packets so we can observe the data being exfiltrated then send the ping packet with the extra data. So then when we read the captured packets, nothing looks particularly different, but if we ask for the full packets via the '-X' flag, we notice that our packets now _do_ contain the data as we specified. While this is not a major concern in most cases, this is just another example of how understanding the different protocols across the stack is important, and that there's usually a little bit more to dig into than initially meets the eye. Anyway, so this is IPv4 ICMP echo-request / echo-reply. --- What does this look like in the IPv6 world? Turns out, it's really not all that different. Let's capture some ICMPv6 packets and repeat the same ping exercise from before. Here we go, and yep, this all looks almost identical. Source sends an echo-request to the destination, the destination replies with an echo-reply and that's about it. Easy peasy. --- So regardless of which IP version we're using, the packets look the same. - echo request - and echo reply. But here we go again glossing over all that's going on in this silly internet cloud over here. How do we get the packet from our AWS instance over to Yahoo's web server? --- Remember, a few videos back we looked at the different AS numbers of the systems that we determined from the traceroute we ran. We didn't go into the details of just how traceroute determined the path our packets are taking between two systems, but guess what? It involves ICMP, and what do we do when we don't know the details of some network communications? We go back to tcpdump. --- So here we are on our EC2 instance, ready to capture packets of type IPv4 that are either ICMP or UDP. We use the '-v' flag to get a little bit of extra information about each packet. Then, over here on the right, we're running the traceroute command, asking it to only send a single probe to make it easier for us to inspect the packets. When we run this, we immediately see the captured packets here on the left. So let's scroll back up to see just how traceroute works: The first packets we see up here are the DNS lookup for www.yahoo.com, which we've seen before. Then, below, we see our IP address 10.10.0.47 sending a UDP packet to port 33 435 with a TTL of 1. We then see that we get back a packet from 216.182.238.127 of type ICMP "time exceeded in transit". [pause] This is because every router will decrement the TTL, and if the TTL reaches 0, it will generate this ICMP "time exceeded" message. So we in effect tricked the first hop to reply to us by setting a TTL of 1, knowing that the next hop must necessarily generate this message, and we thereby learn its IP address. [continue] We then repeat the same process with a TTL set to 2, thereby allowing the first hop to pass the packet on to the next hop, which then will generate the "time exceeded" message. Then repeat again with TTL set to 3 to then again have the first two hops pass it on and the third to trigger the ICMP message... ...and so on and so on. Finally, at the last hop we're setting a TTL of 16 now, which reaches the destination. But the destination won't generate a "time exceeded" message, and there is no "you've reached your destination" ICMP type, so how do we know we've reached the destination? Well, look at the packet here: it says "destination port unreachable". That is, we again tricked the system in sending us a message by picking this random UDP port here. Which of course means that if the host _was_ listening on that port, we _wouldn't_ be getting a response, so we're once again really just being opportunistic. Alright, so that's traceroute in IPv4. Now for IPv6... --- ...we want to avoid capturing some of the other ICMP noise we've seen -- neighbor discovery or router solicitation in IPv6 also happen over ICMP -- so we restrict our capture to only echo-request and echo-reply types. Ok, let's run our traceroute over IPv6: Let's scroll back up... ...and here we go. Looks familiar, right? In IPv6, the TTL is called the "hop limit", so here we see the hlim set to 1, and the first router returning the "time exceeded" message; the second message with an hlim set to 2 returned the second hop, and so on and so on until down here we again get the same "destination unreachable" message when we hit the destination host. --- To visualize how we tricked each router to tell us its IP address along the way to the destination, we - send a packet with the hlim set to 1 - the router decrements the HLIM, then checks if the HLIM is 0; if so, it - returns the "time exceeded" message and we can - record the first hop. --- then we send a new packet with an HLIM of 2; our first router decrements the HLIM to 1 and forwards it; the second router decrements the HLIM, finds it to be 0, and generates the "time exceeded" message, - and we have our second hop. --- Once more, now with HLIM = 3, - which gets forwarded - and forwarded - but then hit the limit - generate the time exceeded message - and we have our third hop. --- On our last packet, - we repeat the same process - until we hit the destination - which hopefully is not listening on anything on the random UDP port we had picked, and it will then - generate the "destination unreachable" message, letting us know - that we've hit our target. --- Ok, time for our quick summary: We've seen some uses of ICMP, most notably the - ubiquitous echo request / echo reply messages sent via ping(1). We've also seen - the use of traceroute, which uses - a random UDP destination part and then sends packets with an increasing TTL, tricking - the routers along the way to send back ICMP TIME EXCEEDED messages - until our destination tells us that the port we're trying to talk to cannot be reached. Now since it's possible that something along the way blocks UDP, for example, you can also - use ICMP or TCP packets to send to the destination. One thing we haven't discussed is - IPv4 PATH MTU discovery. This is used to determine the maximum packet size that will make it to the destination without fragmentation. Look up why that would be useful, and just how exactly it works -- you should find that it works very similarly to traceroute. --- But ICMP is not just restricted to these use cases. There's several other types -- go find out what they are and when you might want to use them. It'll soon help you understand why it's generally a bad idea to block ICMP across the board. - When you run your traceroutes to different locations on the internet, you will likely encounter several that either include asterisks in the middle or that time out and do not reach the destination. Think about under what circumstances that happens. - Finally, recall that we can look up the AS numbers of the networks along the way. When you traceroute a system from AWS, you may find several that are listed as being in - AS0. What's up with that? Look at the IP allocations for this AS and try to find an explanation for why we are seeing these here. With all that, I hope you've gained a bit of an understanding of the Internet Control Message Protocol and expanded your horizon beyond just UDP and TCP. These latter two we've already seen in an earlier video, and we'll again observe them in future videos when we talk about different application layer protocols. Until then, thanks for watching - cheers!