CS 261N Internet/Network Security Projects

General Information

Your term project should address a research issue in network security, interpreted broadly - it need not be a topic discussed in class. The goal in terms of depth and quality is to develop the effort to a degree that would merit a workshop-caliber publication. Most projects will fall into one of the following general categories:

  1. Analyze. Undertake a substantive analysis/assessment of security issues for a given network system. For example, to what degree does Skype expose its users to remote compromise? Preserve their privacy? Admit misuse of the system to aid in denial-of-service attacks? Surreptitiously monitor their communications? Have vulerabilities that enable fraud? What is its trust model? What steps could be taken to strength Skype in this regard? What can you say about the expected efficacy of those steps? Note: it needn't be an application nor involve end systems. You can consider schemes relevant to other layers of the networking stack, or that concern infrastructure/internal components.
  2. Measure. Empirically explore and characterize a network security issue. For example, under what circumstances and to what degree do nodes in the Tor anonymizing network alter the content that passes through them?
  3. Innovate. Devise and analyze (and possibly implement) a new mechanism, technique, or architecture. For example, this could be a new way to protect servers from application-level denial-of-service attacks; a new detector for some type of malicious activity; or a novel approach to email or social networking identity that provides better properties regarding the threats of impersonation, Sybils, or account compromise.
  4. Test. Take a result in the literature and undertake a thoughtful and meaningful reproduction of it to assess to what degree you obtain the same results, and why.
  5. Attack. Develop a new threat. Assess its efficacy, countermeasures/defenses, and likely "arms race" evolution.
  6. Research. Conduct a deep, thoughtful literature survey of a particular area in network security ("research" as a verb). Assess the strengths and weaknesses of the published results in the area, delimit the boundaries of the state of the art, identify themes and abstractions, frame avenues for future work.

I encourage you to find a topic of interest to you; feel free to be creative in selecting a project topic! You're welcome to pick a topic that is connected to your current research, and in general I'm happy to discuss possible topics with you in advance. (See the end of this writeup for a list of past projects to get the flavor of what students have done. I can provide more specifics about these if you'd like.)

Often you can pursue the same project jointly for two different classes. If this would be the case, you need to discuss it first both with me and with the other instructor(s).

In general, you should work in a team of two. One resource for finding a partner is posting your interests/thoughts to Piazza. Individual projects may be doable but require prior discussion with the instructor. If you want to work in a team larger than two, first talk with me about why this is appropriate and how the work will be divided.

With coauthors, I've written some papers providing advice for researchers:

The Process

  1. Send me a short email summarizing your initial thoughts regarding possible project(s) you are considering. Briefly sketch the topic; what you would hope to achieve; why the project interests you; who you might partner with (if known); what concerns you have at this point.

    The Initial Thoughts email is due the evening of Friday Sep 2.

  2. Write a concise (approximately 1 page) project proposal that clearly states the problem you will be tackling, the key challenges for new research, and your plan of attack (including milestones and dates). If there are any special resources you might need, flag these. Mention any relevant papers of which you are already aware.

    The project proposal is due the evening of Friday Sep 16.

  3. Post a brief summary of your project to Piazza so the other students know what you're up to. This should be written "elevator story" style, i.e., a succinct paragraph that captures the gist of what you're doing and how you're going after it, with the target audience (in terms of existing knowledge and what you think they'll find interesting) being your fellow students.

    It works best if each project is its own Piazza thread, so if there are follow-on comments/questions, they are easy to associate with the particular project.

    (The term "elevator story" refers to being able to explain your research in a useful way if you happen to share an elevator ride with someone you'd like to inform about it. It's for sure a useful skill to learn how to "tell the story" briefly but effectively!)

    Summaries are due the evening of Friday Sep 30.

  4. Put together a related work writeup. This writeup should reflect a solid grounding in the literature relevant for your project, written in a style similar to the related work sections in the papers we've been reading. For each item of previous related work, briefly discuss the contributions of the paper, its relevance to your undertaking, and (if appropriate) in what ways it differs from your effort. Be concrete but concise in describing specific findings. When relevant, also discuss evaluation: how did the authors go about assessing their results? This can be very helpful in illuminating evaluation issues/approaches for your own work.

    In general, you can tell if your related work framing is possibly too narrow is by looking at the citations of those papers you currently discuss. If you see that they cite tons more work that at least from their titles sound like they could be germane, then it's your task as a researcher to then track those down - ideally, all of the ones that sound like they could be relevant - and assess which ones you indeed need to read and absorb. Note, read-and-absorb here can run the range from reading in detail, similar to how you read papers for the class, to just reading sections or such, as you gauge relevance.

    You then recurse on the citations in those papers, repeating the process until you converge by not finding any new papers, and/or the ones you find become only lightly related.

    At this point, you've then mastered the full literature on the area you're working in (and usually gotten a bunch of new ideas about what to try or, often more importantly, not try).

    When gathering these related papers, you may run across some that require payment through portals such as those run by ACM or IEEE. Note that UCB has site licenses for most of these libraries, so you should be able to readily fetch them using a campus machine/address without needing to provide payment.

    You should format your writeup (11pt font or larger!), like you would for including in a paper, including citations. Be sure to consider these the pointers regarding writing technical papers, and take note of the "Regularize your bibliography" section for your citations. Include your source (e.g., LaTeX) as well as the formatted version of your writeup.

    The related work writeup is due the evening of Friday Oct 7.

  5. Write up a short status report explaining what work you have completed, what remains, and any open issues (such as problems you haven't figured out how to solve or additional resources you require). Begin your report with a sketch of your project so I'm reminded of the context while reading it.

    As part of turning in the status report writeup, include your team's availability for a meeting, which I may ask for so we can further discuss the progress of your project. Also include your presentation slot (see below) preferences.

    The status report writeup is due the evening of Thursday Nov 10.

  6. Prepare a class presentation. These will be held at the end of the semester, potentially extending into RRR week depending on the size of the class.

    24+ hours prior to the class in which you'll be presenting, post a brief (~2-3 paragraph) description of your project to Piazza.

    There's an art to scoping a presentation to effectively make use of the available time. You need to gauge what context your particular audience (here, this means your classmates) already has regarding the problem space your work addresses, and not spend time developing that broader context; at most, just remind them. However, it will (better!) be the case that your particular area has depth beyond what the average audience member knows about. You do need to frame this additional context, both in terms of what makes the problem interesting and significant, and how the problem space has been previously viewed in terms of prior work and the assumptions this work reflects.

    You might also find it valuable to absorb this discussion of how to give a good talk.

  7. Finally, your project report is due on Tuesday Dec 13, at 1PM. (I may adjust this date depending on the resolution of a major campus commitment I have during that time frame.)

The Final Report

You are expected to write a technical paper, in the style of a conference submission, on the research you have done. State the problem you're addressing, motivate why it is an important or interesting problem, present your research thoroughly and clearly, compare to any related work that may exist, summarize your research contributions, and draw whatever conclusions may be appropriate. There is no page limit (either minimum or maximum), but reports will be evaluated on technical content and not on length.

If relevant, include a section where you describe how others (beyond your team) contributed both to different parts of the work and to the text in the writeup. My expectations are that the strong majority of both the work you report on and the writeup text will be yours, but it's generally okay if relatively minor subsets are from others, as long as these are flagged as such.

Be sure to pay attention to these pointers regarding writing technical papers.

Submit PDF via an email attachment. I generally review papers from hardcopy, so it needs to print clearly and with sufficiently large text and figures. If you use color figures, mention that in your cover note so I can send it to an appropriate printer. In addition, also submit your document source. It doesn't need to build (e.g., okay to leave out LaTeX packages and figures; it can be helpful to include your bib file, though).

Examples of past projects

To give you a flavor of possible projects, here are examples of what students have done in the past (note that some of these could make sense to redo or work on further):

Here's a similar list (including project writeups) from a Computer and Network Security course at MIT.

Some possible projects

As one resource, here are some projects that members of my research group have current interest in. If you want to consider one of these, mention that in your Initial Thoughts note (and of course feel free to ask me questions about what's involved), but you should also frame alternatives, given that other students might want to pursue these too.
  1. Mining Wireshark to develop protocol analyzers: is it feasible to automatically extract detailed knowledge about different network protocols by analyzing Wireshark's source code? This project requires expertise in program analysis.
  2. Building an oblivious cache: how to enable a CDN to serve as a cache without knowing what is being requested and what objects it is storing. Berkeley researchers (Barath Raghavan and Justine Sherry) have a basic approach that involves using Intel SGX support, and a few mechanisms they are thinking of exploring.
  3. Monitoring name servers associated with domains to detect registrant breakins/redirects: there is strong anecdotal evidence that some APT-style attackers briefly take over the name servers associated with a target domain to introduce a hijacking window and then revert the domain back to its normal name servers to evade detection. The heart of this project would be to analyze name servers listed in zone files for short-lived deviations to detect such hijacking.
  4. Assessing Chrome's design decisions: the ACM Queue article Browser Security: Lessons from Google Chrome frames the rationale behind the design of Chrome. Analyze what the subsequent vulnerabilities found in Chrome say about the architectural analysis (and implementation realities) outlined in the paper. What worked, what didn't, and why?
  5. Measure what mechanisms different sites use for password recovery: How many of them use unencrypted communications? How easy is it to trigger a recovery? Can a MITM attacker use password recovery to take over accounts even if the main account access is conducted using an encrypted channel?