Slide 1

Slide 1 text

Noah Kantrowitz Open Source Bridge 2015 How The Internet Works The Life and Times of an HTTP Request

Slide 2

Slide 2 text

It's not a big truck. It's a series of tubes. Ted Stevens What is the internet? Senator Stevens was more right than he understood, at a low level the internet is a series of tiny tubes connected in a vast network.

Slide 3

Slide 3 text

We never, ever in the history of mankind have had access to so much information so quickly and so easily. Vint Cerf A nicer way to think about it.

Slide 4

Slide 4 text

But let's talk about one bit of information in particular, we want to see a web page, https:// www.google.com/. We're going to focus on the parts of this process that interact with the internet, no keyboard interrupts or HTML rendering.

Slide 5

Slide 5 text

https:/ /www.google.com/ We've opened a web browser and typed in https://www.google.com/.

Slide 6

Slide 6 text

https:/ /www.google.com/ The first thing the browser needs to know is "Where is www.google.com?"

Slide 7

Slide 7 text

DNS Enter stage right: the Domain Name System, or DNS for short.

Slide 8

Slide 8 text

DNS • Map names to IP addresses. • gethostbyname() • RFC 1034 & 1035. • "What is the A for www.google.com?" DNS is the protocol your computer uses to find what the IP address for a name is. The most common way to interact with DNS is the gethostbyname() function, but some browsers are fancy enough to write their own internal version of that. The process is the same either way though.

Slide 9

Slide 9 text

DNS Header ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID QR Opcode Opcode Opcode Opcode AA TC RD RA Z Z Z RCODE RCODE RCODE RCODE QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT We need to make a DNS query, so we need to create a DNS message or packet. This will take the question "What is the A of www.google.com?" and put it in a format a DNS server can understand. The first section in any DNS packet is the headers. Like other protocols you may be familiar with, the headers include some standard data the applies to all types of packets.

Slide 10

Slide 10 text

DNS Header ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID QR Opcode Opcode Opcode Opcode AA TC RD RA Z Z Z RCODE RCODE RCODE RCODE QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT The ID field is an opaque number that the DNS server will include with the reply so we know which query is being answered.

Slide 11

Slide 11 text

DNS Header ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID QR Opcode Opcode Opcode Opcode AA TC RD RA Z Z Z RCODE RCODE RCODE RCODE QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT The QR and Opcode fields set the type of packet and if it is a query or reply.

Slide 12

Slide 12 text

DNS Header ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID QR Opcode Opcode Opcode Opcode AA TC RD RA Z Z Z RCODE RCODE RCODE RCODE QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT The other fields on that line set various mode flags for the packet.

Slide 13

Slide 13 text

DNS Header ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID ID QR Opcode Opcode Opcode Opcode AA TC RD RA Z Z Z RCODE RCODE RCODE RCODE QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT QDCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT ANCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT NSCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT ARCOUNT The four count fields set the number of question, answer, authority, and additional records sections. For now we're just sending one question so that will be one and others will all be zero.

Slide 14

Slide 14 text

DNS Question QNAME QTYPE QCLASS The next section we need after the header is the question we are asking.

Slide 15

Slide 15 text

DNS Question QNAME QTYPE QCLASS This is a bit simpler, we have the name we are asking for.

Slide 16

Slide 16 text

DNS Question QNAME QTYPE QCLASS The type of record we are asking for, A.

Slide 17

Slide 17 text

DNS Question QNAME QTYPE QCLASS And the class of value we are asking for, generally always set to 1 for INternet.

Slide 18

Slide 18 text

DNS Message 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 0 0 0 0 1 1 0 0 1 1 0 0 1 1 1 0 1 1 0 1 1 1 1 0 1 1 0 1 1 1 1 0 1 1 0 0 1 1 1 0 1 1 0 1 1 0 0 0 1 1 0 0 1 0 1 0 0 0 0 0 0 1 1 0 1 1 0 0 0 1 1 0 1 1 0 1 1 1 1 0 1 1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 So let's put the header and question sections together and fill all the fields. QNAME 03777777 06676F6F676C65 03636F6D00

Slide 19

Slide 19 text

DNS Message 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 0 0 0 0 1 1 0 0 1 1 0 0 1 1 1 0 1 1 0 1 1 1 1 0 1 1 0 1 1 1 1 0 1 1 0 0 1 1 1 0 1 1 0 1 1 0 0 0 1 1 0 0 1 0 1 0 0 0 0 0 0 1 1 0 1 1 0 0 0 1 1 0 1 1 0 1 1 1 1 0 1 1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 This looks a bit more intimidating, but it's the same header ...

Slide 20

Slide 20 text

DNS Message 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 0 0 0 0 1 1 0 0 1 1 0 0 1 1 1 0 1 1 0 1 1 1 1 0 1 1 0 1 1 1 1 0 1 1 0 0 1 1 1 0 1 1 0 1 1 0 0 0 1 1 0 0 1 0 1 0 0 0 0 0 0 1 1 0 1 1 0 0 0 1 1 0 1 1 0 1 1 1 1 0 1 1 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 ... and data sections.

Slide 21

Slide 21 text

DNS Message 0001010000010000 0000000003777777 06676F6F676C6503 636F6D0000010001 Turn all the binary into bytes and we're ready to hit the road!

Slide 22

Slide 22 text

Now what? We have to send that query to a DNS server. Your operating system exposes a way to ask what the DNS servers are: GetNetworkParams for Windows, NetworkServices for Mac, and resolver for Linux. Usually there are multiple servers in case some aren't available but let's just look at the first one, 208.201.224.11 (the main DNS server for my ISP).

Slide 23

Slide 23 text

IP and UDP Now that we know where to send our DNS query, we need to encode that data in some way that the internet will understand it. We do this using two separate but related protocols. The Internet Protocol is, as the name suggests, the core protocol that powers the internet. At the time it was made, networking protocols were all custom developed by each company that sold computers, leading to difficulty connecting different networks together when they were from different manufacturers. IP allowed true inter-network communications which was the nucleus for the internet we know today.

Slide 24

Slide 24 text

IP and UDP • Address and port. • 208.201.224.11:53 • Wrapped in order. • DNS inside UDP inside IP. • RFC 791 & 768. These protocols are applied in a nested fashion, the DNS query goes inside UDP, which goes inside IP. The IP protocol lets us specify the destination IP address which identifies the target computer, and the UDP protocol is where we specify the port which indicates which program or service on that computer we want to talk to. By mutual agreement of everyone that works with DNS, it is expected that DNS server programs use port 53.

Slide 25

Slide 25 text

UDP Header Source Port Destination Port Length Checksum Data Data As the first layer on top of our DNS query will be the UDP data, let's look at that format.

Slide 26

Slide 26 text

UDP Header Source Port Destination Port Length Checksum Data Data Most of these we aren't really concerned with, but the destination port is where we put in 53. The source port will be randomly allocated by the operating system.

Slide 27

Slide 27 text

IP Header Version Version Version Version IHL IHL IHL IHL Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Flags Flags Flags Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Protocol Protocol Protocol Protocol Protocol Protocol Protocol Protocol Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Padding Padding Padding Padding Padding Padding Padding Padding Then on top of the UDP header we have the IP header. This has a lot more information in it.

Slide 28

Slide 28 text

IP Header Version Version Version Version IHL IHL IHL IHL Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Flags Flags Flags Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Protocol Protocol Protocol Protocol Protocol Protocol Protocol Protocol Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Padding Padding Padding Padding Padding Padding Padding Padding First is the version of the IP protocol we are using. When people say IPv4, that's because the version is actually 4. Fun fact, there was an IPv5 at one point. It was an early voice streaming proposal from 1979.

Slide 29

Slide 29 text

IP Header Version Version Version Version IHL IHL IHL IHL Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Flags Flags Flags Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Protocol Protocol Protocol Protocol Protocol Protocol Protocol Protocol Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Padding Padding Padding Padding Padding Padding Padding Padding Next there are a bunch of fields used to make sure the IP packet can be received correctly. Note that IP (and UDP) checksums apply only to the header information, not the data.

Slide 30

Slide 30 text

IP Header Version Version Version Version IHL IHL IHL IHL Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Flags Flags Flags Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Protocol Protocol Protocol Protocol Protocol Protocol Protocol Protocol Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Padding Padding Padding Padding Padding Padding Padding Padding The Time to Live, or TTL, gives packets a maximum lifespan. It isn't actually measured in time, but in hops between systems and is in there to avoid packets being sent around in a loop forever. Eventually the TTL will hit zero and the packet will be dropped. The protocol field tells the receiver what kind of data is inside the IP packet, for us it will be 17 meaning UDP.

Slide 31

Slide 31 text

IP Header Version Version Version Version IHL IHL IHL IHL Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Type of Service Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Total Length Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Identification Flags Flags Flags Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Fragment Offset Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Time to Live Protocol Protocol Protocol Protocol Protocol Protocol Protocol Protocol Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Header Checksum Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Source Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Options Padding Padding Padding Padding Padding Padding Padding Padding The two addresses indicate where this packet is going and where it came from. These are what we will use to steer the packet to its final destination on the internet. For our case the source address will be our local IP address and the destination address will be 208.201.224.11, our DNS server.

Slide 32

Slide 32 text

IP Packet IP Header UDP Header DNS Packet So here we have our fully assembled packet. An IP header, a UDP header, and then a DNS message made of a DNS header and a DNS question. We can convert this to bytes just like before, there is nothing special about these bytes except in how all devices agree to parse and use them.

Slide 33

Slide 33 text

Local Network We have an IP packet ready to send, but where are we sending it and how?

Slide 34

Slide 34 text

Local Network • Computer • Switch • Router • Modem We're going to look a simple local network. Our computer is connected via wired network to a switch, the switch is also connected to a router, and the router is connected to a Cable or DSL modem. In most modern devices, the switch, router, and modem are all in one physical box but the functions are still discrete. We'll mostly ignore the modem itself as it acts like a bridge to the modem at your ISP and generally doesn't interact with Internet-level things.

Slide 35

Slide 35 text

Most of us have seen a network configuration like this before. An IP address and subnet mask handed out by a router acting as a DHCP server. We won't go in to the details of DHCP, but let's talk a bit about what those three values are used for. The IP address determines who we are on an IP network, while the other two are used to build a route table.

Slide 36

Slide 36 text

A route table is how your computer knows where to send packets. For a normal laptop or desktop, the route table will generally be very small, in this case just three entries.

Slide 37

Slide 37 text

208.201.224.11 Destination Gateway Interface 127.0.0.0/8 * lo 192.168.1.0/24 * eth0 default 192.168.1.1 eth0 So let's use the route table to figure out where we are going to send this packet. We have the destination IP address at the top, and on the left we have a set of address prefixes to match against.

Slide 38

Slide 38 text

208.201.224.11 Destination Gateway Interface 127.0.0.0/8 * lo 192.168.1.0/24 * eth0 default 192.168.1.1 eth0 First we have a route for addresses that start with 127. 127.0.0.1 is the usual address for localhost but technically everything under 127.0.0.0 is sent to the loop-back adapter (lo). Our target IP address doesn't start with 127 so this row doesn't match.

Slide 39

Slide 39 text

208.201.224.11 Destination Gateway Interface 127.0.0.0/8 * lo 192.168.1.0/24 * eth0 default 192.168.1.1 eth0 Next we have the route for the local network. If there was another computer on the same local network this route would let us talk to them directly instead of going through the router. The subnet mask we saw before is combined with our computer's IP address to make the destination check for this route. However it doesn't match this IP address so we move on.

Slide 40

Slide 40 text

208.201.224.11 Destination Gateway Interface 127.0.0.0/8 * lo 192.168.1.0/24 * eth0 default 192.168.1.1 eth0 Finally we reach the default route. This always matches anything that isn't handled by one of the other routes. That is why some operating systems call this a default gateway. So we will use this route, we know we are going to send the packet on the eth0 interface and to a gateway at 192.168.1.1. Next up, how do we send our IP packet on eth0?

Slide 41

Slide 41 text

Ethernet • Wire framing. • MAC address. • Segments. • IEEE 802.3 Ethernet is the next layer we have to pass through on our journey to the internet. Ethernet is the standard that defines how wired network devices talk to each other. When you see a MAC address, that is talking about Ethernet. WiFi is a similar standard, also using MAC addresses and variants on the Ethernet data formats but for simplicity let's just look at a wired network. Ethernet networks divided in to segments in a similar way to IP networks in to subnets.

Slide 42

Slide 42 text

Segments • Electrical broadcast. • Thicknet. • 10BASE-T and hubs. • Switches. A segment in Ethernet is defined as a set of network cards that are on a shared electrical connection. In the original 802.3 standard, it required every computer in the network be connected to the same huge coaxial cable. Every computer would be connected to a shared wire and they would use that to communicate. Over time it was hard to scale that as networks got bigger, so we introduced repeaters and hubs. Later we switched to twisted-pair copper cables from each computer to the hub. We now had multiple segments but a single collision domain as a hub simply repeats data from one port to all other ports. This meant that anyone on a hub trying to send data could interfere with anyone else. As network collisions became more of a problem with faster network speeds, we moved to switches which send data only to the required segment.

Slide 43

Slide 43 text

Ethernet Frame Preamble Preamble Preamble Preamble Preamble Preamble Preamble SFD Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Source Address Source Address Source Address Source Address Source Address Source Address Type Type Data and padding Data and padding Data and padding Data and padding Data and padding Data and padding Data and padding FCS FCS FCS FCS So far we have had a DNS message, an IP packet, now we have another layer; an Ethernet frame. A frame is one block of data sent on an Ethernet network to another device.

Slide 44

Slide 44 text

Ethernet Frame Preamble Preamble Preamble Preamble Preamble Preamble Preamble SFD Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Source Address Source Address Source Address Source Address Source Address Source Address Type Type Data and padding Data and padding Data and padding Data and padding Data and padding Data and padding Data and padding FCS FCS FCS FCS Most of the fields are control data for the network cards on either end. The Type field indicates what kind of data is inside the frame, in our case that will be 0800 for IPv4. You will often see descriptions of an Ethernet frame omit the first two fields as they are always the same and not usually of interest.

Slide 45

Slide 45 text

Ethernet Frame Preamble Preamble Preamble Preamble Preamble Preamble Preamble SFD Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Source Address Source Address Source Address Source Address Source Address Source Address Type Type Data and padding Data and padding Data and padding Data and padding Data and padding Data and padding Data and padding FCS FCS FCS FCS The destination address determines who on the collision domain or segment should be receiving this frame.

Slide 46

Slide 46 text

Ethernet Frame Preamble Preamble Preamble Preamble Preamble Preamble Preamble SFD Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Source Address Source Address Source Address Source Address Source Address Source Address Type Type Data and padding Data and padding Data and padding Data and padding Data and padding Data and padding Data and padding FCS FCS FCS FCS And finally the data field contains the IP packet we built before.

Slide 47

Slide 47 text

1000-BASET • Electrical signaling. • IEEE 802.3ab While Ethernet defines the overall network, other standards define the actual electrical signals to put on the wire or light pulses to put on the fiber optics. Most wired networks these days will be 1000-BASET, more generally known as Gigabit Ethernet.

Slide 48

Slide 48 text

Ethernet Frame Preamble Preamble Preamble Preamble Preamble Preamble Preamble SFD Destination Address Destination Address Destination Address Destination Address Destination Address Destination Address Source Address Source Address Source Address Source Address Source Address Source Address Type Type Data and padding Data and padding Data and padding Data and padding Data and padding Data and padding Data and padding FCS FCS FCS FCS So we are ready to build our Ethernet frame to send our DNS query to the local router, but we have a problem. The route table told us the IP address of the gateway, but to send an Ethernet frame we need its Ethernet address (aka MAC address).

Slide 49

Slide 49 text

ARP We have to pause sending our frame to look up the Ethernet address for 192.168.1.1. We do this using a protocol called ARP, for Address Resolution Protocol.

Slide 50

Slide 50 text

ARP • Bridge between IP and Ethernet. • NDP for IPv6. • "Who has IP address 1.2.3.4?" • In an Ethernet frame. • Broadcast FF:FF:FF:FF:FF:FF. ARP sits between Ethernet and IP, helping to translate between hardware and network addresses. We are only going to talk about ARP for IPv4 and Ethernet, but there are similar protocols for other pairs of network types. For IPv6 it is called NDP. A basic ARP query is "Whoever has IP address X please send me your Ethernet address." Each ARP request is sent in an Ethernet frame by necessity, but it uses the broadcast address so that everyone on the segment will receive and process the query. You will note there is no security here, anyone on the segment can respond to any query. Abuse of this is called ARP poisoning.

Slide 51

Slide 51 text

ARP Packet HTYPE PTYPE HLEN PLEN OPER SHA SHA SHA SHA SPA SPA SPA THA THA THA THA TPA TPA TPA ARP packets are intentionally simple. Requests and replies use the same format, just with some fields set to 0 when they do not apply.

Slide 52

Slide 52 text

ARP Packet HTYPE PTYPE HLEN PLEN OPER SHA SHA SHA SHA SPA SPA SPA THA THA THA THA TPA TPA TPA The important fields are the two pairs of addresses. For our query we will fill in the sender hardware address and sender protocol address using our MAC and IP addresses.

Slide 53

Slide 53 text

ARP Packet HTYPE PTYPE HLEN PLEN OPER SHA SHA SHA SHA SPA SPA SPA THA THA THA THA TPA TPA TPA The target hardware address will be left empty since that is what we are requesting, and the target protocol address will be set to 192.168.1.1.

Slide 54

Slide 54 text

⌚ Then we wait. ARP can take a few milliseconds to respond as it has to get to the other computer, be decoded, and the reply has to make it back. Because of this ARP is aggressively cached at almost every network device. In our case we don't have the answer cached so nothing to do but wait.

Slide 55

Slide 55 text

Sending • Ethernet – 40:4A:3:ED:D2:1C • IP – 208.201.224.11 • UDP – 53 • DNS – www.google.com A But at long last, in computer terms, we get our ARP reply. We finally have all the data we need to send our DNS query! To review, we have an Ethernet frame going to the hardware address of our router, inside that is an IP packet with a destination of our DNS server, inside that is a UDP datagram for port 53, and inside that is a DNS message asking for the A record for www.google.com. This is a lot of work and we haven't even made it to the local router yet!

Slide 56

Slide 56 text

Local Router So the packet is sent down the wire, through the switch. The switch reads the destination MAC address on the Ethernet frame to know which switch port to send the packet to, or if it doesn't recognize the address it falls back to sending it on all ports and hoping it gets to the destination somehow. Either way it eventually makes it to the router.

Slide 57

Slide 57 text

Local Router • Static routing (again). • NAT. The local router in our hypothetical home network serves two main purposes, routing between the home network and the ISP, and network address translation. Unlike the switch, it needs to decode most of the packet to do these but let's look at them in turn.

Slide 58

Slide 58 text

Route Table Destination Gateway Interface 127.0.0.0/8 * lo 192.168.1.0/24 * eth0 173.228.34.0/24 * eth1 default 173.228.34.1 eth1 The first thing the router will do is decode the Ethernet frame. It has to check that it matches the destination MAC address on the frame, meaning it is the intended recipient of the frame. Then it decodes the IP packet headers and checks if it matches the destination IP address. In this case it does not match, so the router knows it needs to send it somewhere else. This works just like it did on our computer, but as the router is connected to both our home network and the ISP's network the route table has an extra entry.

Slide 59

Slide 59 text

208.201.224.11 Destination Gateway Interface 127.0.0.0/8 * lo 192.168.1.0/24 * eth0 173.228.34.0/24 * eth1 default 173.228.34.1 eth1 Just like last time, we check the route table entries in order looking for a match. The address doesn't start with 127.

Slide 60

Slide 60 text

208.201.224.11 Destination Gateway Interface 127.0.0.0/8 * lo 192.168.1.0/24 * eth0 173.228.34.0/24 * eth1 default 173.228.34.1 eth1 Or 192.168.1

Slide 61

Slide 61 text

208.201.224.11 Destination Gateway Interface 127.0.0.0/8 * lo 192.168.1.0/24 * eth0 173.228.34.0/24 * eth1 default 173.228.34.1 eth1 Or 173.228.34

Slide 62

Slide 62 text

208.201.224.11 Destination Gateway Interface 127.0.0.0/8 * lo 192.168.1.0/24 * eth0 173.228.34.0/24 * eth1 default 173.228.34.1 eth1 So just like last time we fall back to the default gateway. Here we can see it is 173.228.34.1 and we are going to use the eth1 interface.

Slide 63

Slide 63 text

NAT • Rewrite IP and UDP header. • Source address and port. • Share one public address. Once the router figures it wants to use the eth1 interface, it checks with the operating system for any special policies on that network interface. On most home routers there will be a network address translation policy. This is because the local network uses private IP addresses that are reserved for internal use. If we sent our DNS query with a source IP address of 192.168.1.2, the DNS server would have no way to send the reply packet back to us. Network address translation fixes this by rewriting the source to its public IP address, and keeping a mapping of any translated packets so when a reply comes in, it can send it off to the correct internal IP address.

Slide 64

Slide 64 text

Sending, Round Two • ARP lookup (or cached). • Ethernet frame. • Send to ISP border router. After NAT is finished, the sending process is just like before. We need the MAC address of the next router we are sending to. Once we have that we make a new Ethernet frame and send it on its way. We're going to skip over the cable or DSL modem as they are mostly transparent in this process but the quick version is they read the Ethernet frame and translate it to a similar frame in DOCSIS or PPPoE and then it gets translated back at the ISP's office. This first router we get to in our ISP's network is generally called a border router as it lives at the edge of the network.

Slide 65

Slide 65 text

The Internet Our plucky little DNS query has finally made it to the internet! Not very far mind you, the local border router for your home connection is probably within a few kilometers of your house, but still this is progress.

Slide 66

Slide 66 text

A Mesh of Trees • Tree-like at the edges. • Partial mesh in middle. • ~Full mesh in the core. So far both hops we have taken have used relatively small route tables with default gateways as a fallback for unknown destinations. This works fine for small scale networks that are arranged in a tree or hub-and-spoke pattern, but as we get further in to the ISP's network it will start looking more like a mesh instead of a purely tree-like arrangement.

Slide 67

Slide 67 text

Next Hops • Regional routers. • ISP backbone. The same process we saw with our own router will usually repeat a few more times through the tree of regional routers in the local ISP office. Each of these will use their own route tables to check that we aren't trying to send a packet elsewhere on the regional network, and if not it sends up to the next router closer to the local backbone connection. The ISP backbone is a set of high-speed links between local or regional offices.

Slide 68

Slide 68 text

Our DNS query has made it through the local ISP office and up to a backbone router. This router is plugged in to many high-speed optical links to other backbone routers run by the ISP in their other offices and data centers. Now we have a problem though, while so far everything has been tree-like, suddenly there is no single default gateway. The ISP's backbone isn't quite a fully connected mesh, but there are multiple paths available. How do we know where to send the packet?

Slide 69

Slide 69 text

BGP The Border Gateway Protocol is the most widely used routing protocol on the internet today.

Slide 70

Slide 70 text

Routing Protocol • Distribute routes. • Update over time. • Find optimal paths. What is a routing protocol? The simplest version is a way for routers to share and synchronize rows in their route tables. This is important as the structure of that mesh we saw before is constantly changing as hardware is swapped out and new links come online. Not to mention the natural enemy of the fiber link, backhoes. The internet is built to automatically detect these changes and re-route packets around them.

Slide 71

Slide 71 text

BGP • Gossip based. • Prefix based. • Share best routes. • RFC 4271. BGP does this using a gossip based approach, each router shares all the routes it knows about with its immediate neighbors (called peers). These peering arrangement are generally hand-coded in to each router participating in BGP so this isn't entirely self-organizing. As before in our simple route tables, BGP operates on IP address prefixes. Somewhere on the global BGP mesh there is a router that announces it controls 208.201.224.0/19 which is the prefix containing our DNS server.

Slide 72

Slide 72 text

BGP • Gossip based. • Prefix based. • Share best routes. • RFC 4271. Each BGP peer announces which prefixes it wants to be the destination for, and each neighbor tracks which peer it saw every prefix from. It compares each new announcement with all its existing routes and if the new route is better than an existing one it gets added to the route table and sent along to all of that router's peers. In this way each router gossips to the next about what it thinks the best routes are. This also means that every BGP router has to keep the route table for the entire world in memory. Currently this is about 600 thousand routes.

Slide 73

Slide 73 text

Autonomous Systems • 1-232 (née 216) • ~51000 so far. • AS7065 Before we talk more about BGP we need to talk about Autonomous System numbers. We have seen a lot of addresses so far, UDP ports, IP addresses, MAC addresses. AS numbers are how BGP handes addressing. An AS represents a network operator that participates in the global BGP network. AS numbers were historically limited to 2 bytes but there have been recent moves to upgrade to 4 byte numbers as roughly 80% of them have been allocated. Some large companies have multiple AS numbers for geographically or logically distinct networks, but you can think of each as roughly equivalent to a company. In this case our DNS server is located in AS 7065. Each prefix announced on the BGP network is associated with a peer and an AS number.

Slide 74

Slide 74 text

IANA • ICANN department • Internet Assigned Numbers Authority • 5 Regional Internet Registries • AfriNIC, ARIN, APNIC • LACNIC, RIPE NCC I should also briefly mention IANA. It is a department of the Internet Corporation for Assigned Names and Numbers which more or less administers the internet. It handles allocating IP addresses and AS numbers through five regional organizations; AfriNic for Africa, ARIN for North America, APNIC for Asia and Australia, LACNIC for Latin America and the Caribbean, and RIPE for Europe, Russia, and the Middle East. These regional registries handle IP and AS allocations for their member countries.

Slide 75

Slide 75 text

1 Weight 5 MED 2 Local Pref 6 Metric 3 AS Path 7 First 4 Origin 8 Tie Breaker BGP Algorithm What determines a best route? I'm skipping a few of the weirder steps but overall it follows these rules when comparing two routes for the same prefix.

Slide 76

Slide 76 text

1 Weight 5 MED 2 Local Pref 6 Metric 3 AS Path 7 First 4 Origin 8 Tie Breaker BGP Algorithm Weight is an optional, local value configured for each route. It allows network operators to prefer cheaper or more reliable links or other manual overrides to the routing mesh.

Slide 77

Slide 77 text

1 Weight 5 MED 2 Local Pref 6 Metric 3 AS Path 7 First 4 Origin 8 Tie Breaker BGP Algorithm Local preference allows similar manual overrides to weight, but is shared between routers within the same AS while weight is local to one router.

Slide 78

Slide 78 text

1 Weight 5 MED 2 Local Pref 6 Metric 3 AS Path 7 First 4 Origin 8 Tie Breaker BGP Algorithm AS path is where things get interesting. As routes are gossip'd through the network, each router keeps track of which ASes the route advertisement passed through to get there. Having fewer ASes in that path means a more direct connection, which is preferred. This doesn't count the overall number of routers in the path, just distinct ASes.

Slide 79

Slide 79 text

1 Weight 5 MED 2 Local Pref 6 Metric 3 AS Path 7 First 4 Origin 8 Tie Breaker BGP Algorithm Origin refers to how the route was introduced to the BGP network, preferring routes from within the same AS instead of external routes.

Slide 80

Slide 80 text

1 Weight 5 MED 2 Local Pref 6 Metric 3 AS Path 7 First 4 Origin 8 Tie Breaker BGP Algorithm The multi-exit discriminator, or MED, allows an AS with multiple connections to another AS to request preferential routing on one of those links over the other. Both routes will still be considered in case one link goes down, but generally this is used to prefer routes along faster or newer fiber connections over old backup links.

Slide 81

Slide 81 text

1 Weight 5 MED 2 Local Pref 6 Metric 3 AS Path 7 First 4 Origin 8 Tie Breaker BGP Algorithm Metric prefers routes with fewer hops across an internal network. This is similar to AS Path but is comparing router hops within the same AS instead of distinct ASes.

Slide 82

Slide 82 text

1 Weight 5 MED 2 Local Pref 6 Metric 3 AS Path 7 First 4 Origin 8 Tie Breaker BGP Algorithm If we've gotten this far, we fall back to the oldest of the two routes. This helps reduce the effect of instability due to newer but equivalent routes being broadcast through the network.

Slide 83

Slide 83 text

1 Weight 5 MED 2 Local Pref 6 Metric 3 AS Path 7 First 4 Origin 8 Tie Breaker BGP Algorithm After this there are a few tie breakers just to ensure there is always a stable solution that all routers can agree on.

Slide 84

Slide 84 text

Security • BGP Hijacking • Ingress Filtering • Rarely used signatures A quick aside because this tends to be a surprise to most people. No where in this discussion of BGP have I mentioned authentication or authorization because for the most part there is none. Any AS participating in the BGP network can advertise any routes they want. Abuse of this is called BGP hijacking and we do see public incidents every few years, like in 2008 when the Pakistani national ISP accidentally sent out routes for the entire YouTube address space.

Slide 85

Slide 85 text

Backbone Router • AS46375 to AS7065 BGP is always running in the background so by the time we get to the ISP's backbone router it should already have a route (in its table of 600 thousand routes) to send along our DNS query packet. While building this route table is much more complex, using it works the same way as the other hops we have seen. The DNS server is run by a different department of our ISP that happens to be in a different AS so we have to pass through a few hops along the backbone to reach the data center containing the DNS server.

Slide 86

Slide 86 text

DNS Server Eventually, also known as about 60 milliseconds, we have reached the ISP's DNS server!

Slide 87

Slide 87 text

Receiving • Decode and match IP. • Decode UDP port. • Deliver to process. Just like all the routers, the DNS server will decode the incoming Ethernet frame, read the IP headers, and check the destination IP address. This time it matches! The packet has reached its destination so the operating system decodes the UDP headers too and sees it is being sent to port 53. It checks some internal tables and sees that there is a program listening on that port. The operating system delivers the packet's data to the DNS server process and now the real work can begin.

Slide 88

Slide 88 text

DNS Server • Decode question. • Check local cache. • Recursion? The DNS server unpacks our question data and sees we are asking for the A record for www.google.com. On a busy, public DNS server normally this record would already be cached locally but for our example we are going to say it isn't in the cache.

Slide 89

Slide 89 text

DNS Recursion Our ISP's DNS server doesn't directly know the answer to our question. It could just reply back saying that it doesn't know, but that wouldn't be very useful. DNS has a mode called a "recursive query" that means we are asking the server to go find out the answer and then send it back to us. Not all servers will allow recursive queries, but ISP-level servers will for their customers at least.

Slide 90

Slide 90 text

Root Servers • 13 DNS servers. • Fixed IP addresses. • Maps TLDs to DNS servers. • [a-m].root-servers.net So if we are going to find the value of this DNS query from scratch we need to start from something. The base of the DNS system are the 13 root servers. These live at 13 fixed IP addresses, though each address maps to hundreds or thousands of servers all over the world to handle the volume of requests. These root servers only map top-level domains like com, net, and org to TLD-level master nameservers. All root servers are interchangeable, so queries will generally just pick one at random.

Slide 91

Slide 91 text

Recursion Round 1 • DNS query to 198.41.0.4 • com. IN NS a.gtld-servers.net • com. IN NS b.gtld-servers.net. • a.gtld-servers.net. IN A 192.5.6.30 • b.gtld-servers.net. IN A 192.33.14.30 Our ISP's DNS server has the hardwired list of the 13 root servers, called the root hint file, managed by IANA. It picks one of those, let's say a.root-server.net, and sends it a new request for the A record for www.google.com. Just like our DNS query, this new query gets encoded in a DNS message, wrapped in UDP, IP, and Ethernet headers, sent on to the local network, across several more backbone links from our ISP to other ISPs, eventually reaches the root server which makes a response packet and sends it back across the internet. Eventually we get a response like this. gtld-servers.net are the TLD-level DNS servers for the .com domain. Instead of being run by different organizations like the root servers, these are all run by Verisign as part of their ownership of the .com TLD.

Slide 92

Slide 92 text

Recursion Round 2 • DNS query to 192.5.6.30 • google.com. IN NS ns1.google.com. • google.com. IN NS ns2.google.com. • ns1.google.com. IN A 216.239.32.10 • ns2.google.com. IN A 216.239.34.10 Again we pick a random server from the response and ask it again for the A record for www.google.com. The TLD servers are populated based on those "what is your nameserver?" boxes you fill out when you register a domain name. It doesn't know the answer to our question, but it looks up what name servers are attached to google.com and gives us those.

Slide 93

Slide 93 text

Recursion Round 3 • DNS query to 216.239.32.10 • www.google.com. IN A 216.58.192.36 Now we pick one of Google's DNS servers and ask it for the A record for www.google.com. Finally we have found a server that can answer our question! Remember that for these three queries during the recursion process it has to do all the same work as our DNS packet so far 6 times, three requests and three replies. But at last our ISP's DNS server has an answer to our question, it stores it in the local cache for next time and builds a DNS reply packet to send back to us.

Slide 94

Slide 94 text

DNS Reply • DNS message. • Headers & answer section. • Sent back over the wires. • Un-NAT. The DNS message we sent to the ISP's DNS server has two sections, headers and one question. The DNS server will now build a reply with headers and one answer section. After a journey over the ISP backbone again, the packet arrives at our local router. The router checks its NAT tables and sees this packet was translated on the way out. It reverses the translation and sends the packet up to our computer. It makes its way through our operating system until finally the reply data gets sent to our web browser.

Slide 95

Slide 95 text

TCP We are ready to open a connection the web server at www.google.com. While DNS used UDP inside IP, web traffic generally uses TCP.

Slide 96

Slide 96 text

TCP • Reliable ACKs. • Three-way handshake. • Congestion control. • RFC 675, 793, ... The internet is a dangerous place for packets, and while most get to their destination there is always some percentage that get dropped along the way. This is most often due to network congestion or data corruption on one of the intervening routers. With UDP, there is no real recourse for this. When our computer sent that DNS query it started a timer in the background and if the reply took too long it would assume the packet had been lost and sent a new copy. TCP offers more reliable stream-oriented behaviors on top of the unreliable internet. Packets will be re-sent if missing and will never be delivered out of order.

Slide 97

Slide 97 text

TCP Headers Source Port Source Port Source Port Source Port Source Port Source Port Source Port Source Port Destination Port Destination Port Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Data Offset Reserved U R G A C K P S H R S T S Y N F I N Window Window Checksum Checksum Checksum Checksum Checksum Checksum Checksum Checksum Urgent Pointer Urgent Pointer Options Options Options Options Options Options Options Options Options Padding Like UDP there is a packet header added to all TCP packets, though it is a bit more complex than the UDP headers.

Slide 98

Slide 98 text

TCP Headers Source Port Source Port Source Port Source Port Source Port Source Port Source Port Source Port Destination Port Destination Port Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Data Offset Reserved U R G A C K P S H R S T S Y N F I N Window Window Checksum Checksum Checksum Checksum Checksum Checksum Checksum Checksum Urgent Pointer Urgent Pointer Options Options Options Options Options Options Options Options Options Padding Again we have the source and destination ports.

Slide 99

Slide 99 text

TCP Headers Source Port Source Port Source Port Source Port Source Port Source Port Source Port Source Port Destination Port Destination Port Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Data Offset Reserved U R G A C K P S H R S T S Y N F I N Window Window Checksum Checksum Checksum Checksum Checksum Checksum Checksum Checksum Urgent Pointer Urgent Pointer Options Options Options Options Options Options Options Options Options Padding The sequence and acknowledgement numbers are used during a TCP connection to track the order of packets being sent and which packets have been received correctly. The window size is the number of packets that can be sent at once before waiting for an ACK.

Slide 100

Slide 100 text

TCP Headers Source Port Source Port Source Port Source Port Source Port Source Port Source Port Source Port Destination Port Destination Port Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Data Offset Reserved U R G A C K P S H R S T S Y N F I N Window Window Checksum Checksum Checksum Checksum Checksum Checksum Checksum Checksum Urgent Pointer Urgent Pointer Options Options Options Options Options Options Options Options Options Padding The checksum field is used to ensure the TCP headers don't get corrupted during transmission. The offset and urgent pointer fields are used to speed up decoding a bit, and options are rarely used.

Slide 101

Slide 101 text

TCP Headers Source Port Source Port Source Port Source Port Source Port Source Port Source Port Source Port Destination Port Destination Port Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Sequence Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Acknowledgement Number Data Offset Reserved U R G A C K P S H R S T S Y N F I N Window Window Checksum Checksum Checksum Checksum Checksum Checksum Checksum Checksum Urgent Pointer Urgent Pointer Options Options Options Options Options Options Options Options Options Padding And finally a set of six one-bit control fields. These are used to set the mode of the packet.

Slide 102

Slide 102 text

Three Way Handshake • SYN • SYN-ACK • ACK To establish a TCP connection we need to complete a three-packet exchange usually called a three way handshake. First we, the client, send a packet with the SYN, synchronize, flag and a random sequence number to the server. The server responds with a packet with the SYN and ACK, acknowledge, flags and its own random sequence number as well as the client's random sequence number in the acknowledgement number field. We then send a third and final packet to the server with the ACK flag and the server's sequence number in our acknowledgement number field. This ensures both sides know the other's starting sequence number and data packets can begin.

Slide 103

Slide 103 text

Acknowledgements • Send 1 ... 10. • ACK 10. • Send 11 ... 20. • ACK 15. • Send 15 ... 24. TCP achieves reliable, in-order delivery by using sequence numbers and acknowledgements. The window value dictates how many packets one side can send the other before waiting for acknowledgement. If a packet is lost, the client can resend any required data to make up for it.

Slide 104

Slide 104 text

Extras • Slow-start • Avoidance • Fast resend • Karn's • Nagle's • SACK • Scaling • CUBIC TCP has been retrofitted and upgraded with additional options and supplemental standards more than just about anything else in the history of the internet. Most of these are transparent improvements but if you want to learn about TCP as it exists in practice, you have a lot of reading to do.

Slide 105

Slide 105 text

TLS With a TCP connection open, the browser can start to send data to www.google.com. If this was plain HTTP we could jump directly to requesting the web page, but most people these days will access websites over HTTPS. This means we need to create a TLS connection before moving on.

Slide 106

Slide 106 text

TLS (aka SSL) • Stream encryption. • Mutual authentication. • RFC 5246. TLS means the same thing as SSL. SSL is just a name for an early version of TLS and was last seriously used in 1999. Just like TCP creates an abstraction for a reliable data stream, TLS creates an encrypted data stream. The data inside the stream doesn't have to know the details of how or why it is being encrypted. TLS also allows either side to identify themselves with a cryptographic proof, though most of the time only the server does this in the form of an HTTPS certificate.

Slide 107

Slide 107 text

Crypto I'm not going to talk about the specifics of the cryptography involved in TLS. There are a ton of great talks about that and we would be here all day. I will just cover the packets and data involved in setting up a TLS connection and using it for HTTPS.

Slide 108

Slide 108 text

TLS Handshake • ClientHello • ServerHello • ChangeCipherSpec • Finished Just like TCP has a handshake to set up a connection, so does TLS. We already have a TCP connection established at this point so TLS messages may not correspond directly to packets anymore, as TCP automatically slices up the data stream in to packets as needed to maximize efficiency.

Slide 109

Slide 109 text

Client Round 1 • ClientHello The first message in any TLS connection is a ClientHello. This message includes a per- connection random value to be used later, and a list of ciphers and TLS versions the client supports.

Slide 110

Slide 110 text

Server Round 1 • ServerHello • Certificate • ServerKeyExchange • ServerHelloDone The server then responds to the ClientHello with a ServerHello. This again includes the server's random number, and picks which TLS version and cipher the connection will use. After this the server sends a Certificate message with a proof of its identity. Then it sends a ServerKeyExchange with configuration information for the connection. Finally it sends ServerHelloDone meaning it is finished with the first round of the handshake.

Slide 111

Slide 111 text

Client Round 2 • ClientKeyExchange • ChangeCipherSpec • Finished The client then uses the server's key data from the ServerKeyExchange to send its own ClientKeyExhange message, negotiating any required information for the cipher. Then is sends a ChangeCipherSpec message to switch from the initial unencrypted mode to encrypted communications. It then sends a Finished message to signal it is done with the handshake. This also doubles as a failsafe check for the encryption negotiation as if something has gone wrong the server will be unable to decrypt the Finished message.

Slide 112

Slide 112 text

Server Round 2 • ChangeCipherSpec • Finished The server does the same thing as the client now, indicating all further messages will be encrypted and finishing the handshake.

Slide 113

Slide 113 text

Application Data • Data wrapper. • Transparent. After this, the TLS connection goes effectively transparent, wrapping the HTTP data in TLS messages and encrypting them. On the other side the TLS system unwraps the data stream and presents it to the HTTP server.

Slide 114

Slide 114 text

HTTP So a quick review, we have done a DNS query to find the IP address of www.google.com, we established a TCP connection, and then a TLS connection. We are now ready to send an HTTP request to get our webpage!

Slide 115

Slide 115 text

HTTP • Request and response. • Verbs, paths, codes. • RFC 2616. HTTP is probably the piece of this journey you are all most familiar with. It is a text-based protocol with a request/response model just like DNS we saw before.

Slide 116

Slide 116 text

HTTP Request • GET / HTTP/1.1 • Host: www.google.com An HTTP request has three parts. First is the status line. This has the verb (GET) the path (/) and the HTTP version (1.1). After that we have the headers section. The Host header is required for all HTTP 1.1 requests, but there are many other optional headers your browser might send. After that we have the request body, which for a GET request will be empty.

Slide 117

Slide 117 text

Sending • TLS • TCP • IP • Ethernet So we have our connection open, and our HTTP request ready. Off it goes! Just as a reminder, our HTTP request data is going to be wrapped in TLS messages, which will be wrapped in TCP packets, inside IP packets, inside Ethernet frames. And then this whole pile of data will be shipped off to our local router where it will follow the same kind of journey as our other packets so far. This time rather than staying within our ISP's network, it will jump across multiple networks until it finally gets to Google's nearest servers.

Slide 118

Slide 118 text

HTTP Response • HTTP/1.1 200 OK • Content-Length: 17914 • \r\n •

Slide 119

Slide 119 text

After the first request, there will be a few others to load things like the Google logo but overall we've accomplished our goal! We managed to brave the internet, get our packets all the way from our computer to Google's servers, and in the end we are rewarded with the search box we all know and possibly love.

Slide 120

Slide 120 text

⌚ It is important to remember that this half hour discussion covers about 150 milliseconds of actual time. For all its failings the internet is remarkably fast, resilient, and useful. Even more so when you remember much of what we've seen was developed in the 70s and 80s.

Slide 121

Slide 121 text

How does the Internet work? So now the final question, how does the internet work?

Slide 122

Slide 122 text

Surprisingly well! Surprisingly well!

Slide 123

Slide 123 text

Questions? @kantrn coderanger.net Thank you!