IP Forwarding

Roadmap IP forwarding A protocol design exercise Notes on the lab

Delivery of an IP datagram View at the data link layer: Internetwork is a collection of LANs or point-to-point links or switched networks that are connected by routers IP

Delivery of an IP datagram View at the IP layer: An IP network is a logical entity with a network number We represent an IP network as a “cloud” The IP delivery service takes the view of clouds, and ignores the data link layer view IP

Delivery of IP datagrams There are two distinct processes to delivering IP datagrams: 1. Forwarding (data plane): How to pass a packet from an input interface to the output interface? 2. Routing (control plane): How to find and setup the routing tables? Forwarding must be done as fast as possible: on routers, is often done with support of hardware on PCs, is done in kernel of the operating system Routing is less time-critical On a PC, routing is done as a background process

Routing tables Routing table of a host or router Each router and each host keeps a routing table which tells the router where to forward an outgoing packet Main columns: Destination address: where is the IP datagram going to? Next hop: how to send the IP datagram? Interface: what is the output port? Next hop and interface column can often be summarized as one column Routing tables are set so that datagrams gets closer to the its destination Destination Next Hop interface 10.1.0.0/24 10.1.2.0/24 10.2.1.0/24 10.3.1.0/24 20.1.0.0/16 20.2.1.0/28 direct direct R4 direct R4 R4 eth0 serial0 eth1 eth0 eth0 Routing table of a host or router IP datagrams can be directly delivered (“direct”) or is sent to a router (“R4”)

Delivery with routing tables to: 20.2.1.2

Processing of an IP datagram in IP IP router: IP forwarding enabled Host: IP forwarding disabled

Processing of an IP datagram in IP Processing of IP datagrams is very similar on an IP router and a host Main difference: “IP forwarding” is enabled on router and disabled on host IP forwarding enabled  if a datagram is received, but it is not for the local system, the datagram will be sent to a different system IP forwarding disabled  if a datagram is received, but it is not for the local system, the datagram will be dropped

Processing of an IP datagram at a router Receive an IP datagram IP header validation Process options in IP header Parsing the destination IP address Routing table lookup Decrement TTL Perform fragmentation (if necessary) Calculate checksum Transmit to next hop Send ICMP packet (if necessary)

Routing table lookup Destination address Next hop/ interface When a router or host need to transmit an IP datagram, it performs a routing table lookup Routing table lookup: Use the IP destination address as a key to search the routing table. Result of the lookup is the IP address of a next hop router, and/or the name of a network interface Destination address Next hop/ interface network prefix or host IP address loopback address default route IP address of next hop router Name of a network interface

Type of routing table entries Network route Destination addresses is a network address (e.g., 10.0.2.0/24) Most entries are network routes Host route Destination address is an interface address (e.g., 10.0.1.2/32) Used to specify a separate route for certain hosts Default route Used when no network or host route matches The router that is listed as the next hop of the default route is the default gateway (for Cisco: “gateway of last resort) Loopback address Routing table for the loopback address (127.0.0.1) The next hop lists the loopback (lo0) interface as outgoing interface

Routing table lookup: Longest Prefix Match = 128.143.71.21 Longest Prefix Match: Search for the routing table entry that has the longest match with the prefix of the destination IP address Search for a match on all 32 bits Search for a match for 31 bits ….. 32. Search for a match on 0 bits Host route, loopback entry  32-bit prefix match Default route is represented as 0.0.0.0/0  0-bit prefix match Destination address Next hop 10.0.0.0/8 R1 128.143.0.0/16 R2 128.143.64.0/20 R3 128.143.192.0/20 R3 128.143.71.0/24 R4 128.143.71.55/32 R3 0.0.0.0/0 (default) R5 The longest prefix match for 128.143.71.21 is for 24 bits with entry 128.143.71.0/24 Datagram will be sent to R4

Route Aggregation Longest prefix match algorithm permits to aggregate prefixes with identical next hop address to a single entry This contributes significantly to reducing the size of routing tables of Internet routers Destination Next Hop 10.1.0.0/24 10.1.2.0/24 10.2.1.0/24 10.3.1.0/24 20.2.0.0/16 20.1.1.0/28 R3 direct direct R3 R2 R2 Destination Next Hop 10.1.0.0/24 10.1.2.0/24 10.2.1.0/24 10.3.1.0/24 20.0.0.0/8 R3 direct direct R3 R2

How do routing tables get updated? Adding an interface: Configuring an interface eth2 with 10.0.2.3/24 adds a routing table entry: Adding a default gateway: Configuring 10.0.2.1 as the default gateway adds the entry: Static configuration of network routes or host routes Update of routing tables through routing protocols ICMP messages Destination Next Hop/ interface 10.0.2.0/24 eth2 Destination Next Hop/ interface 0.0.0.0/0 10.0.2.1

A Route Aggregation Example Algorithm: More specific address prefixes that have the same next hop may be aggregated into one more general address prefix if their address blocks are contiguous.

A Protocol Design Example  The type of DoS attack we focus on is the IP flooding attack. where attackers send packet flood to a destination to congest a bottleneck link. Legitimate packets will suffer heavy losses, and cannot reach t heir destiations. This type of attack has become an increasing threat to the reliability of the Internet. The important of the problem has triggered a number of proposals, each has its merits and limitations. For instance, address validation is able to filter attack traffic with spoofed addresses, but is insufficient in limiting attacks that use valid addresses, such as those attacks launched by botnets. Traceback is often too little and too late. When the attacking sources areidentified, the damage has already been made. In the pushback approach, the network decides which packets to filter. It is often the case that the network cannot precisely distinguish between legitimate packets and attack packets. As a result, legitimate traffic may suffer collateral damage, and attach traffic is not punished enough. The secure overlay filtering approach requires that a server gives its legitimate clients offline authenticators so that the overlay nodes can filter the illegitimate traffic using the authenticators. However, the internet supports an open communcation model. A public server, such as www.google.com, may not know its legitimate clients prior to communication. DoS is not even close to be solved .

Researchers have proposed a packet logging algorithm to track down the attackers  A router logs every packet it sends by computing a short packet digest. A victim can send queries to routers to obtain the trace of a packet.

Your task is to design the query protocol. What’s the task of the protocol? Which entities would exchange messages of this protocol? What messages do we need? What actions would these entities take when they receive/send the messages to achieve the task? Does the design achieve the task? Can we optimize it? What are the desired properties of this protocol? E.g., low message overhead, secure … Which protocol we have studied so far handles simple/generic queries? Can we extend the existing protocols?



ICMP message format 4 byte header: Type (1 byte): type of ICMP message Code (1 byte): subtype of ICMP message Checksum (2 bytes): similar to IP header checksum. Checksum is calculated over entire ICMP message If there is no additional data, there are 4 bytes set to zero.  each ICMP messages is at least 8 bytes long

Query message Source IP address: router/host Destination IP address: next hop router Contents: Packet digest Originator’s IP address

Reply Message Source IP address: router that has the packet digest Destination IP address: the originator’s IP address Content Packet digest What else are needed for the victim to determine the order of routers that forward the packet?

Analysis of this protocol Message overhead How about the message get lost? Sequence numbers will help How long will it take for a message to come back?

Notes on Lab

Loop back interface Question: which answer is correct? In the first lab report, there was a question in exercise 7: "How many of the Linux PCs responded to the broadcast ping?" (1.1) some students answer that 4 machines reply, according to the output of ping, like: ping -c 2 -b 10.0.1.255 WARNING: pinging broadcast address PING 10.0.1.255 (10.0.1.255) 56(84) bytes of data. 64 bytes from 10.0.1.11: icmp_seq=1 ttl=64 time=0.456 ms 64 bytes from 10.0.1.12: icmp_seq=1 ttl=64 time=0.744 ms (DUP!) 64 bytes from 10.0.1.14: icmp_seq=1 ttl=64 time=1.39 ms (DUP!) 64 bytes from 10.0.1.13: icmp_seq=1 ttl=64 time=1.48 ms (DUP!) 64 bytes from 10.0.1.11: icmp_seq=2 ttl=64 time=0.034 ms (1.2) But some students answer that 3 machines reply, according to the output of tcpdump, which is something like: tcpdump -n tcpdump: listening on eth0 16:24:58.460818 10.0.1.11 > 10.0.1.255: icmp: echo request (DF) 16:24:58.461098 10.0.1.12 > 10.0.1.11: icmp: echo reply 16:24:58.461437 arp who-has 10.0.1.11 tell 10.0.1.14 16:24:58.461474 arp reply 10.0.1.11 is-at 0:4:75:ac:87:e9 16:24:58.461499 arp who-has 10.0.1.11 tell 10.0.1.13 16:24:58.461509 arp reply 10.0.1.11 is-at 0:4:75:ac:87:e9 16:24:58.461745 10.0.1.14 > 10.0.1.11: icmp: echo reply 16:24:58.461843 10.0.1.13 > 10.0.1.11: icmp: echo reply 16:24:59.466162 10.0.1.11 > 10.0.1.255: icmp: echo request (DF) 16:24:59.466422 10.0.1.13 > 10.0.1.11: icmp: echo reply 16:24:59.466538 10.0.1.12 > 10.0.1.11: icmp: echo reply 16:24:59.466635 10.0.1.14 > 10.0.1.11: icmp: echo reply 16:25:03.453514 arp who-has 10.0.1.11 tell 10.0.1.12 16:25:03.453538 arp reply 10.0.1.11 is-at 0:4:75:ac:87:e9 Question: which answer is correct?

Processing of IP packets by network device drivers