SRC Component: traffic filtering in context

This is an unreleased component that was intended to be part of TCP. If your curious, you’re welcome to try it out, but it does not count for credit. If you do try it, we’d appreciate to hear any feedback! There is a form at the end where you can submit comments, or feel free to email Nick.

We’ve spent the past few weeks implementing critical parts of Internet infrastructure. We’ve learned how to forward packets, and, in implementing TCP, we’ve learned one a key way to transfer information reliably.

But every router or device that processes packets is also in a position of power over network traffic: it can simply drop packets, or actively try to sabotage with clients’ connections. This power can be used, for example, to disrupt a denial-of-service attack on a web server by dropping the attacker’s packets, or for other purposes, such as censoring communication or denying users access to resources.

Internet Service Providers (ISPs)—such as Verizon, AT&T, and others—and institutions that operate routers in their networks—from Brown’s OIT to a coffee shop—often face decisions about what traffic filtering rules to install in their routers. In this component, you will face these decisions and apply some traffic filtering in your own IP stack implementation to explore how this would work.

Specifically, you will consider the needs of two pairs of stakeholders involved in how networks make decisions about certain types of traffic:

For the first pair (your “primary” pair), you’ll consider how you might implement a simple filtering strategy in a
After that, you’ll comment on how your implementation might extend to a different pair (your “secondary” pair, more on this later)

Which pairs you will work with depends on your final project team number. If you are working with a partner on a different final project team, just pick one of your team numbers. To find your team number, search your email for a message from Nick with the subject “CS1680: Final project team”, which was sent on December 4. Your pairs are the result of computing (your team number) % 4 (where % is the modulo operator):

if (team number) % 4 == 0: your pairs are Pair #1 and Pair #2
if (team number) % 4 == 1: your pairs are Pair #3 and Pair #4
if (team number) % 4 == 2: your pairs are Pair #5 and Pair #6
if (team number) % 4 == 3: your pairs are Pair #5 and Pair #2

Task: Read over your stakeholder pairs in the next section, and then see the instructions below.

Stakeholders

This section introduces each stakeholder pair and explains the context for traffic filtering.

Note: To keep the assignment simple, and to avoid any clashes with real IP allocations, each stakeholder described below has been assigned an imaginary IP range that isn’t available on the real Internet. For the full list of IP ranges and port numbers that are fair game, see this section.

Pair #1: Government of Schlaraffia vs. Schlaraffian Civil Liberties Union (SCLU)

Click to expand

Stakeholder 1: the government of Schlaraffia (a liberal-democratic state) is concerned about disinformation related to Schlaraffia’s upcoming general election concerning candidates from all major parties running for office, which was posted by foreign content creators on Y.com, a popular social media platform hosted in Usaffria. Y.com and its eccentric owner, Leon Dusk, rejected their request for Y.com to remove the content. To restrict the spread of electoral disinformation, the government of Schlaraffia requests that ISPs within their country configure their routers to prevent users in Schlaraffia from accessing Y.com, which has servers in the IP range 10.133.7.0/24. However, Schlaraffian ISPs have no legal obligation to comply, since Schlaraffian laws prohibit government interference with communication networks.

Stakeholder 2: Schlaraffian Civil Liberties Union (SCLU): the SCLU is a non-profit public advocacy group dedicated to the promotion of civil rights and liberties. They oppose the Schlaraffian government’s request to restrict access to content on Y.com. They have a long history of advocating for civil rights, and have brought cases both against the government and against other organizations. SCLU speaks for a large population of Y.com users in Schlaraffia, who use the platform to find out about news, to share information, and to post satirical content.

Your job is to implement whichever traffic filters you decide to add on the routers of a Schlaraffian ISP.

Pair #2: Government of Schlaraffia vs. Polly Glotta, an international student from Xalaria

Click to expand

Stakeholder 1: The government of Schlaraffia (a liberal-democratic state) is a member of the Atlantian Union (AU) which recently imposed a range of economic and political sanctions on the state of Xalaria in response to Xalaria’s invasion of its neighbor, the Republic of Elysia. As part of these sanctions, the AU asks member states to block access to XT (Xalaria Today), a state-run Xalarian TV channel that broadcasts war propaganda amongst other content. Since XT’s online streaming service is popular amongst young people, the AU requests that Schlaraffia should ask its ISPs to block access to XT’s servers, located in IP range 10.7.7.0/16. However, Schlaraffian ISPs have no legal obligation to comply, since Schlaraffian laws prohibit government interference with communication networks.

Stakeholder 2: Polly Glotta is a Xalarian citizen and currently a Junior at Brown. Like many Xalarians living abroad, she frequently watches XT’s online stream to stay up-to-date on popular Xalarian Soaps. Indeed, Polly has for over ten years enjoyed watching and bonding over these soaps with her younger brother, who still lives at home in Xalaria, and the rest of the family. She tunes out for the propaganda programs, and would be very disappointed to lose access to XT.

Your job is to implement whichever traffic filters you decide to add on the routers of a Schlaraffian ISP.

Pair #3: Moonbucks Coffee vs. Bruno J. Ava, a CS student

Click to expand

Stakeholder 1: Moonbucks Coffee is a small, artisan roastery that offers an open WiFi network to its customers from the network 10.30.2.0/24. However, Moonbucks is concerned that hackers might mix in amongst the customers and use the WiFi network to execute their attacks, with the blame (and possible legal consequences) falling on Moonbucks. Since hackers often use SSH to connect to targets they’re trying to break into, Moonbucks wants to block outgoing SSH traffic on their router (i.e., block packets with destination port 22).

Stakeholder 2: Bruno J. Ava is a CS student at Brown and also a true coffee lover. Bruno likes to work at Moonbucks Coffee, his favorite artisan coffee shop near campus, but this semester he is taking the OS course, which requires him to use department machines (which live within the Brown campus network at 10.10.0.0/16). Bruno is excited to find that he can log into Sunlab machines in the CS department remotely over SSH (a network service that sends packets to server port 22), so that he can test his code without leaving the only coffee haunt that makes a flat white up to his standards.

Your job is to implement whichever traffic filters you decide to add on Moonbuck’s router.

Pair #4: Brown OIT vs. Selena C. Oder, a cybersecurity student

Click to expand

Stakeholder 1: Brown’s Office of Information Technology (OIT) is responsible for the campus network and its security. As such, OIT tries to protect the network — and the students and staff who use it — against both external attackers and internal machines that may have been compromised (e.g., because of a weak password). One major concern for OIT is that an attacker may use a single compromised computer to figure out the structure of the campus network in order to find new vulnerable machines to attack. Hence, OIT wants to block traffic generated by network tools primarily used by sysadmins and hackers, such as traceroute, in order to hide their network structure. The most common versions of traceroute generate TCP traffic on port 33434, and sends a sequence of packets with increasing time-to-live (TTL) to map out the path that packets to a specific destination IP address take through the network.

Stakeholder 2: Selena C. Oder is a cybersecurity master’s student who is taking CS 1660 and 1680 this semester. Excited about what she is learning in class, Selena wants to try out some of her new skills and explore the structure of Brown’s network and the wider internet, to better understand the cybersecurity challenges of protecting the IT infrastructure. Selena is careful to only explore and gather public information, and she studiously avoids doing anything that negatively impacts servers or other network users. Her current project is to make a map of the internet connectivity between Brown and Cornell, which requires her to use traceroute.

Your job is to implement whichever traffic filters you decide to add on Brown’s campus network routers run by OIT. For the purposes of this assignment, we’ll pretend that the Brown campus network uses IP range 10.10.0.0/16, and that Cornell uses 10.50.0.0/16.

Pair #5: Biggish Broadcasting Corporation vs. Tristan Blunt, an international student from the United Kingdom of Big Britain

Click to expand

Stakeholder 1: The Biggish Broadcasting Corporation (BBC) is the major (state-funded) public broadcaster of the United Kingdom of Big Britain (UK). In addition to its own productions, it frequently acquires the rights to broadcast a range of popular TV series developed by independent production companies and makes them accessible on their online streaming platform for its viewers. The terms of the BBC’s licensing agreements with the production companies grant it the right to distribute those programs only within the UK, and hence the BBC is keen to ensure that this content can only be accessed by viewers who are physically present in the country. Hence, the BBC wants to block traffic from outside the UK (including the Brown campus network’s IP range) from accessing its content servers.

Stakeholder 2: Tristan Blunt grew up in the UK and is currently a Sophomore at Brown. His favourite TV series is Doctor Who, a classic Biggish TV series which has run since the 1960s, and which he’s been watching with his mum since early childhood. Tristan pays for a TV license in the UK (as is required), so he has the right to legally watch BBC content while in the UK. He’s distraught by the thought of no longer being able to watch each new episode right when it comes out each Saturday night during the semester when he’s at Brown. While new Doctor Who episodes eventually become available in the US, they often only become available after some delay, and Tristan is worried about running into spoilers if he has to wait for months.

Your job is to implement whichever traffic filters you decide to add to a router at the BBC. For the purposes of this assignment, we’ll pretend that the Brown campus network uses the IP range 10.10.0.0/16, and the BBC streaming service uses 10.68.123.0/24.

Pair #6: Blitzbytes ISP vs. Brown OIT and students

Click to expand

Stakeholder 1: Blitzbytes is an ISP that provides connectivity from the Brown campus network to the wider internet (one of several ISPs that Brown has peering agreements with). Blitzbytes is subject to provisions of the Digital Millennium Copyright Act (DMCA) that require ISPs to “promptly block access to alleged infringing material” on request by copyright holders. Netmovies, a well-known streaming site, has sent Blitzbytes a DMCA notice telling them to block Internet connectivity for a range of Brown IP addresses (10.10.12.89 to 10.10.12.120, all in the same dorm) that have been streaming pirated movies that Netmovies owns the copyright to.

Stakeholder 2: Brown’s Office for Information Technology runs the campus network used by thousands of students. Some students stream pirated content, often thinking that “we’re students, we have little money — we’ll pay enough for content later when we have a job”. OIT wishes to maintain good relationships with the ISPs it works with, but also wants to avoid accusations of censorship by students and academics who use the campus network. As such, OIT is uncomfortable with Blitzbytes blocking the IP addresses, arguing that the network is a service provided for all and that the individual students are ultimately responsible for their actions. OIT offers to locate and discipline the students involved.

Your job is to implement whichever traffic filters you decide to add on the routers run by Blitzbytes. For the purpose of this assignment, we’ll pretend that the Brown campus network uses the IP range 10.10.0.0/16, and that Blitzbytes uses 10.20.0.0/16.

What you will build

You will consider implementing a traffic filtering approach based on the concerns of your primary stakeholder pair. To do this, imagine that you are responsible for managing a router that sits at the boundary of your stakeholder’s network and the rest of the Internet, such that all incoming or outgoing traffic is forwarded by your router, like this:

In terms of forwarding, your router would ordinarily consider each packet and decide where to send it. To implement your traffic filter, you would modify this process slightly, based on the filtering strategy you decide to implement. Specifically, before forwarding each packet, you would need to consider:

Does this packet need to be filtered? (e.g., What IP ranges, port numbers, etc. would you need to consider?)
When encountering a packet that should be filtered, what (if any) action should your router take?

For the second part, there are number of broad actions your router could take, including, but not limited to, the following:

Dropping the packet
Modifying or corrupting the packet
Sending a forged TCP reset (an RST packet in-window with the data stream) to forcibly terminate the connection
Delaying or probabilistically dropping packets (to degrade the connection, perhaps hoping the user will give up)
Logging packets or metadata on IPs that sent problematic traffic (instead of, or in addition to, active filtering methods)

Assumptions for our virtual network

To implement and experiment with filtering in our network, we make a few assumptions about traffic to operate within our “virtual” IP space, and keep the implementation simple:

We’ll assume that all traffic uses TCP. This isn’t always true for the traffic types mentioned (eg. streaming video, traceroute), but it’s a “good enough” approximation for our problem.
To test things in our virtual network (and to keep the IP addressing simple), each entity mentioned has been assigned an imaginary IP range, listed here. If your filtering strategy requires other specific IP ranges, you can invent them, so long as you state your assumptions. (In other words, there’s no need to go looking up any real-world IP allocations.)
You don’t need to worry about attempts to circumvent your filtering policies (eg. VPNs, proxies, masquerading traffic on different ports, etc., which we’ll discuss in lecture on December 5). Handling this would be quite tough, so it’s out of scope for our implementation part (though it’s a good thought exercise for discussion!)

“How much work do we need to do?” We will not grade you on the level of sophistication in your filtering strategy, but rather on whether it works. As long as your written answers justify your choices, you will get full credit, even if the implementation itself is simple.

How to think about the problem

You might initially feel overwhelmed with the situation you’ve been presented with — we’ve engineered each situation such that the conflict is intentionally difficult to deal with from a conceptual standpoint, even though the implementation can be very straightforward. There is no clear-cut answer we expect you to figure out, but rather we want you to grapple with the potentially complex trade-offs between the claims and interests expressed by both of your stakeholders. Because of this, we want you to consider the following questions before you touch any of the code. You don’t have to submit your answers for this, but we recommend writing down some notes for yourself.

Consider why Stakeholder 1 is interested in requesting traffic filtering? What kind of ethically, socially, or legally significant claims would support or reject their request?
Consider why the opposing stakeholder (ie, Stakeholder 2) would not want this filtering. What kind of ethically, socially or legally significant claims would support or reject their position?
What strategies or mechanisms could you propose to mitigate potential harms to your stakeholders that might result from instituting traffic filtering or not doing so? Consider different technical decisions you could make and their effects.

Important note: we don’t expect you to find a solution that satisfies everyone – rather, the point is to make what you believe to be the most reasonable tradeoffs between the opposing parties’ claims.

From this point, a good way to get started is to understand how we’ll be using our virtual IP network (and your router) to do filtering, which will give you a sense of the constraints and assumptions for your implementation. See the next section for details on how to try it out!

How to get started

You have two options for how you can implement your traffic filter:

Option 1: use your own vrouter and IP stack: you can start from your TCP repo and modify the part of your IP stack that forwards packets. This shouldn’t be a big change, and shouldn’t interact with your TCP stack at all. If you changed teams for the final project, you can still do this option–you can start from either partner’s TCP repo.
Option 2: use a pre-made stencil (in Go) if you never want to touch your IP/TCP code ever again, or if you are concerned about modifying your IP stack, we’ve prepared a small stencil that implements enough of a IP stack and vrouter to do this problem.

We’ve carefully designed this problem so that either option should be the same amount of work, regardless of how you implemented your IP stack. If you’re unsure, we recommend reading through the rest of this page before you make a decision.

Option 1: Using your existing TCP repo

Expand for instructions

To keep your original TCP code intact, you’ll start by migrating your TCP code to a new repository, just like you did from IP->TCP. To do this:

Create a new blank repository using this stencil link, but don’t clone it yet.
Follow these instructions from the TCP setup guide to push your TCP code to your new repository. Please follow the instructions and don’t copy any files manually–this will lead to errors and waste your time!
Come back to these instructions after you’ve pushed your code to github (no need to do update_from_stencil).
Clone your new repository in the home folder of your container environment, similar to how you started your TCP project:

 - ...
 |--DEV-ENVIRONMENT
 | |--docker/ 
 | |--home/
 | | |--snowcast-yourname/
 | | |--ip-team-name/
 | | |--ip-team-name/
 | | |--src-team-name/     # <----------------- Clone your stencil here!
 | |--run-container
 | |-- ...
 ...

Now you should have a fresh repository to start working! Before continuing, you will need to add some new files to your repository to run our new test network. To do this:

Open a terminal in your container environment and cd into your new repository with your migrated TCP code.
Copy this link to your clipboard:

https://github.com/brown-csci1680/ipstack-template/raw/refs/heads/f24-src/update_src.sh

In your container terminal, run the following commands, and paste in the link where prompted. This downloads and runs a script that will load some more files into your repo:

 # Download the update script
 you@container:~/your-tcp-repo:$ wget -O update_src.sh '<paste the link you copied>'
    
 # Make the script executable
 you@container:~/your-tcp-repo:$ chmod +x update_src.sh
    
 # Run the script (and follow the prompts)
 you@container:~/your-tcp-repo:$ ./update_src.sh

The script will prompt you as it downloads several files and adds them to your repository. When it’s done, it should look like this:

 [ . . . ]	
 mode of 'reference/arm64/vrouter' retained as 0755 (rwxr-xr-x)
 mode of 'util/vnet_filter_run' changed from 0644 (rw-r--r--) to 0755 (rwxr-xr-x)
 mode of 'util/vnet_run' retained as 0755 (rwxr-xr-x)
 Fetch complete!
 About to add all fetched files to git

 Press Enter to continue, Ctrl+C to exit. 
	
 Done.

To make sure everything worked, run git status. You should see several new/changed files, similar to the list in the box below. Please check this list to make sure it matches up:

Expand for details

you@container:~/your-tcp-repo:$ git status
[ . . . ]
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   .gitattributes
        modified:   reference/arm64/vrouter
        modified:   reference/vrouter
        new file:   util/filter-net/config.json
        new file:   util/filter-net/nodes.json
        new file:   util/filter-net/ref-router.lnx
        new file:   util/filter-net/tester.lnx
        new file:   util/filter-net/your-router.lnx
        new file:   util/stakeholder-nets/pair1/config.json
        [ ... a bunch more files in util/stakeholder-nets ... ]
        new file:   util/stakeholder-nets/pair6/outside.lnx		
        new file:   util/vnet_filter_run
        modified:   util/vnet_run

If this list looks correct, you’re all set, yay! Commit your changes, and proceed on to try out a network.

Option 2: Using the pre-made vrouter stencil

Expand for instructions

To use the pre-made stencil, one person on your team should do the following:

Create a new repository using this stencil link.
If you’re working on this problem with someone else, please create a new team and add your partner. (Note: even if you’re keeping the same from TCP or the final project, the team name you use MUST be different. This is an annoying limitation of Github Classroom.)
Clone your repository in the home folder of your container environment, similar to how you started your IP project:

 - ...
 |--DEV-ENVIRONMENT
 | |--docker/ 
 | |--home/
 | | |--snowcast-yourname/
 | | |--ip-team-name/
 | | |--src-team-name/     # <----------------- Clone your stencil here!
 | |--run-container
 | |-- ...
 ...

Navigating the stencil

You can interact with your minimal vrouter stencil similar to how you interacted with IP/TCP:

You can build the stencil using make. See the Makefile for details.
The core of the router’s IP stack (which you’ll modify) lives in pkg/ip/ip.go. The router’s main function lives in cmd/vrouter/main.go.
Otherwise, the repo is set up similarly to your IP/TCP repo: it contains a reference router, a vnet_run script, and several other files you’ll need for this problem (explained in the next section)

Once you’ve set up your repository, you can try out the test network to see how filtering will work in our virtual IP network.

Running the test network

We’ve created a custom set of lnx files that emulate each scenario in our virtual IP network. While some stakeholders’ networks are quite large (eg, an ISP for a whole country!) we only need to emulate a small slice of this to test filtering: we can represent each scenario with just three nodes (listed below, and shown in the figure):

inside: A router that provides the IP prefix associated with your stakeholder’s network (eg. ISP, Brown OIT, coffee shop, etc.). In our setup, this will be represented by a (slightly special) reference router.
outside: Another reference router that represents else, i.e., the rest of the “Internet”. Since our virtual network isn’t actually connected to the real Internet, this is just another router that provides a large IP prefix (10.0.0.0/8).
filter: This will be your router, which will act as a “bottleneck” between the two networks. In terms of IP forwarding, the lnx files will set up each node’s forwarding table such that traffic arriving from the “inside” network will get forwarded to the “outside” network (and vice versa), using the normal forwarding procedures you implemented back in the IP project.

While it might seem odd to have an entire router (the filter) whose sole job is to forward packets between exactly two networks, this is common in practice. Network administrators often install dedicated devices (often called middleboxes or appliances) on the path between networks to perform tasks like filtering or health monitoring. Like any router, middleboxes adhere to the basic principles of IP forwarding, but may also apply more specialized policies on what traffic they permit, and might do more complex processing on certain packets.

For this problem, imagine that your router is a filtering device installed in your stakeholder’s network. From there, your job is to decide on the filtering policy to implement, based on your scenario!

With this in mind, here’s how to try out the test network for your scenario:

Open a container terminal to your repository (whether it’s the stencil or your TCP repo)
Build your code to compile your vhost and vrouter binaries. If you are using the stencil version, run make, which will build a minimal vrouter.
To run the test network, we’ve provided a custom script called vnet_filter_run that works similarly to vnet_run. Each stakeholder pair also has its own custom set of lnx files. To use these to start the test network, run the following (in this case, let’s try pair #1):
```
you@container:$ util/vnet_filter_run --router ./vrouter util/stakeholder-nets/pair1
```
This will run the test network using your router (./vrouter) as the filter. The reference router will be automatically selected for the other nodes, but you can also specify it with --ref-router. For more options, see util/vnet_filter_run --help.

When the filter network starts up, you should see a tmux session like you’re used to seeing with vnet_run, with one pane for each node (inside, outside, and filter) that should look like this (panes might be in a different order):

The example in the figure is for stakeholder pair #1, where the inside router is for a Schlaraffian ISP with prefix 10.33.7.0/24 (as given by the stakeholder IP ranges). Each pair network will have a different “inside” prefix to represent the different entities involved.

If your network does not start up properly

Some things to check:

If you are using your own TCP repo, make sure that you ran the update script as described here. After the update, you should have an executable script util/vnet_filter_run in your repository, as well as some lnx files at util/stakeholder-nets/pairX matching this repo.
If you are using the stencil, make sure that you compiled the code with make to build the stencil vrouter.

Once your network is running, you can test it out by sending some test traffic!

Sending test traffic through your filter

To try out your router in the test network, and see how filtering should operate, we can send some test traffic from the inside to outside network. To do this:

(Recommended) Open up Wireshark and start a capture with the filter udp (Note: be sure to filter on just udp, not a specific port like you did for TCP), as shown in the figure:
To generate test traffic, the reference routers (ie, “inside” and “outside”) have a new command tcpsend, which sends an arbitrary TCP packet to a given IP and port. We can use this to send traffic from, e.g., the inside to the outside network, and then watch it get forwarded by the filter. To try this, run the following on the inside node:
```
 # Format:  tcpsend <source ip> <dest ip> <dest port> [optional message]
 > tcpsend 10.33.7.100 10.100.1.5 22
```
For <source ip> and <dest ip>, you can pick any IP address in the prefixes associated with each network (the source being the network where you’re running the command).

After sending the packet, you should see a message printed in the outside network’s router, like this:

If you don't see a packet

Some things to check

When running tcpsend, make sure the source and destination IPs are within the IP prefixes each router prints at startup: the source IP should be an IP in the range for the node where you’re entering the command (eg. 10.33.7.100 is within 10.33.7.0/24), and the destination IP should be within the prefix of the other node (eg. 10.100.1.5 is within 10.0.0.0/8).
If you’re using your own router from IP/TCP and are concerned it’s not able to forward the test traffic (eg. if your router crashes, or if you know you can’t handle this type of traffic), feel free to use the stencil version instead, or let us know and we can help.

Similarly, after you send a packet, you should see two packets in Wireshark, one for each hop: inside->filter, and filter->outside, which should look something like this:

Wireshark’s output may look odd (see details below), but the point is that you should see two packets and the second one was the result of forwarding from your filter. Later, depending on your filtering strategy, you should look for differences in this output. For example:

If your filter drops packets, you should see only one packet instead of two
If your filter decides to send a RST packet, you should see an extra RST packet show up
If your filter delays packets, you should see this happen
… and so on

Why does the wireshark output look odd?

Some notes on the wireshark output:

Wireshark will try to decode the packet based on the port number (eg. SSH is port 22), but it might say the packet is malformed–this is okay and expected (our tester can’t replicate content in-spec with each protocol)
The second packet will show up as a TCP retransmission: this is also normal and expected. Similar to when we were testing TCP, wireshark doesn’t know that packet 2 is a duplicate of packet 1 (because it was forwarded), so this confuses its TCP analysis.

Now that you’ve seen the environment where you’ll be implementing filtering, you should think about your overall

How to build your implementation

So how would you do this? Building your implementation will require modifying your router’s (or the stencil router’s) logic for forwarding packets between interfaces. Specifically, your router should have logic like this:

for each arriving packet {
   if (packet is for this router) {
       // handle locally
   }  else {
       // forward packet <----- Add to this part!
   }
}

Depending on the filtering policy you decide to implement, your goal would be to add some extra processing to the forwarding step to consider (as stated earlier):

Does this packet need to be filtered? (e.g., What IP ranges, port numbers, etc. would you need to consider?)
When encountering a packet that should be filtered, what (if any) action should your router take?

For an example of a simple policy (with no relation to any of the stakeholders), a filter that drops HTTP traffic (port 80) from 10.100.5.0/24 might look something like this:

    someNetwork := netip.MustParsePrefix("10.100.5.0/24")
	if (someNetwork.Contains(ipHdr.Src) &&
	    ipHdr.Protocol == 6) {
		tcpHdr := ... // Parse TCP header in this packet
		if tcpHdr.dstPort == 80 {
			// Drop the packet
		}
    }

Remember: your filtering implementation does not need to be complex. Rather, we want you to think about what strategies you would implement given the conflict, and just reason about what it would take to do the implementation.

Remember: implementing your filter isn’t meant to take a long time: if you find yourself spending >1 hour on implementing/debugging, please pause on your implementation and explain what you would do in your writeup. This entire component (implementation + writeup) should not take you more than two hours.

A few implementation notes:

Filtering traffic by port number would mean that your router needs to read fields inside the TCP header. However, your router SHOULD NOT need to import or use your TCP stack to filter traffic. Instead, your router should just use the same library code that your TCP stack uses to parse the TCP header, like the TCP-in-IP example from Milestone I. While this may seem like an architectural violation of layering, this is common in practice: routers commonly parse transport-layer headers to implement filter-like features, without needing to run a full TCP stack!
The conflicts here are designed such that you can implement a filtering strategy without considering the content of TCP packets. You may consider using content-level filtering if you want, but this is not required. If you consider this, there is no need to consider reassembling TCP packets into in-order messages (we know you already know how to do this).
You don’t need to add any configuration options to turn filtering on/off. In practice, the set of filters to use would be user-configurable (eg. via the lnx file), but we can skip this step since this would be quite a bit of unnecessary file-parsing work. We have chosen IP ranges for all the stakeholders such that they don’t overlap with any other networks we use in the course. When testing, you also can assume that only one of your routers will be running at a time (our test networks guarantee this).

Writeup: after you’ve implemented your solution

Now that you have finished your implementation, you should consider the potential pitfalls of your design choices in practice.

Task: Answer the following questions in a file that you include in your repository (eg. another section of your README, or a separate file):

You may want to read the How will you be graded section below before beginning this task to understand what we are looking for!

Q1. Who was your stakeholder pair? (< 1 sentence)
Q2. What kind of packet filtering function (if any) did you implement and why? Explain your decisions as if you were reporting to an ethical auditor who will determine whether your design is justified. Highlight how your decisions address stakeholder concerns, and explain why you addressed their concerns in this way. If you purposely ignored any stakeholder concerns in your implementation, explain why they were not addressed (2-3 sentences)
Q3. Consider your second pair of stakeholders: does the strategy behind your traffic filtering approach still work for this pair (even though the IPs/port numbers, etc would be different)? In other words, if you were asked to implement traffic filtering for your second stakeholder pair, would you make the same decisions to implement it (or not)? Would you reasoning for implementing (or not implementing) the filtering differ? If so, how? (2-3 sentences)

How to submit

There is no Gradescope submission for this assignment. Instead, when you are done, please do the following:

Push your code and your writeup to your repository
Please fill out this form to let us know what you think!

Thanks again for working on this assignment! Your feedback is super helpful as we work on building new SRC content for future generations of students (in this course, and others)!

How will you be graded?

Your implementation needs to work and do what you indicate it is doing in your comments. In your README, list one or two test conditions (eg. calls to tcpsend) that will demonstrate that what you consider to be working behavior, based on your filtering strategy.
You’re not being graded on whether you picked the “right” answer — there is no one correct traffic filtering decision for each stakeholder pair. Rather, the bulk of your grade is determined by how well you explain why you chose your specific implementation: the justifications you offer in support of your implementation should reflect an assessment of the context and competing claims and weigh them against each other in a nuanced way.

Your response should show that you have thought thoroughly about the positions of your stakeholders. A good response identifies the legitimate claims that each stakeholder may have, explains why those claims are important, and compares the importance of both claims. It provides concrete reasons for (fully or partially) prioritizing or rejecting individual stakeholders’ claims and how those trade-offs are reflected in the chosen implementation. A good response, importantly, also touches upon the limitations of those choices.

Stakeholder IP ranges

We’ve assigned imaginary IPs to all of the entities involved, listed here (all in the 10.0.0.0/8 range):

Brown campus network: 10.10.0.0/16
Blitzbytes ISP network: 10.20.0.0/16
Weeklymotion streaming service: 10.30.1.0/24
Moonbucks coffee shop: 10.30.2.0/24
Y.com: 10.133.7.0/24
XT streaming service: 10.7.7.0/16
Cornell campus network: 10.50.0.0/16
BBC streaming service: 10.68.123.0/24
All UK ISPs: 10.68.0.0/16
All Schlaraffian ISPs: 10.75.0.0/16

If you need to make up other IP ranges to represent other entities, feel free to do so, just state them in your writeup.